對於軟體過程和專案管理的一些雜亂的想法

我的理解，項目，是為達成一個或多個目標，在某些條件的限制下，做出的計劃和工作。
從理論上講，目標、條件都是客觀的因素，只要把握客觀因素，在分析達成的可行性後，目標就一定會達成。但是，事實上卻並非如此。

因為，客戶對於目標的理解、與項目人員對於目標的理解，以及項目成員間對於目標的理解，存在或多或少的偏差。而對於存在的條件限制，由於條件比目標往往來得更加隱蔽（人總是喜歡好的東西），就導致了更多的不同的理解。

客戶對於自身業務，通常情況下是比較熟悉的，那麼客戶對於目標和條件的理解，就取決與這個客戶的素質和能力。高素質的使用者是不多見的（簡直是鳳毛麟角）。這種情況下，顧問（Consultant）這個角色就出現了，他們對於某方面的專門的業務有良好的基礎（如財務，人力，物流等），對於業務應用軟體的特徵，有敏銳的觸覺，他們能夠誘導客戶，充分的闡述出其實際業務的情境（stories），並且能夠區分和抽取一個實際情境中混雜的看似相同實則有異的多個業務步驟。為系統的設計，做出高品質的準備工作。（這是多麼理想的需求階段啊～～）只有以上情況都成立的時候，完美的需求才可能出現。

假設業務清晰的情況下，設計又如何呢？設計是產生交付啟動並執行產品的前奏（產品當然不僅僅只有可啟動並執行artifacts，但上帝們最關心只是這個）。當然，很多時候是沒有設計的，只有思維的片斷，而這些片斷則很經常被某些人叫做“解決方案”，然後告訴上帝的時候，“業務需求”稍為改一改，就變成了“系統設計”（SAP這樣的超級ERP也不能完全做到，我想一般系統組件化程度不至於高超到可以馬上從業務需求到系統設計的跳躍吧），當然有些有良心的會加上“資料庫設計”意思一下（這樣的資料庫設計可靠嗎？）。 這中情況，放眼望去，比比皆是，也統一的缺少一個項目關鍵人物：系統分析員。對，就是我們可愛的“系分”同學，做一個系分不容易，團隊有一個好系分也不容易。沒有系分怎麼辦？三個臭皮匠頂一個諸葛亮，發揮群眾優勢，大家民主議事。只可惜，議事之前“大家”通常沒有完整的思考，議事之後“大家”也往往沒有review，更可惜的是，每個“大家”都不可能站在足夠的高度去考慮和評價每一個問題的解決辦法。於是，問題背後的問題，或者問題解決帶來的新問題，將在以後的階段不斷被遇到，越遲遇到的常常越難解決（玩遊戲時越大的boss越在後面）。（回頭看看最開始的假設“業務清晰”，如果沒有這個假設，那麼……）

哈哈，終於到了可以開發的時候了，再來假設系統設計是perfect的吧。（現在，通常的做法是詳細設計由開發人員做，或者內嵌程式碼中。如果是在那些沒有稍為像樣的系統設計的情況下，可能也就完全不在意詳細設計了。）開發語言是開發的最小顆粒，同一個問題在不同的人看來，都會寫出不盡相同的代碼。說這些幹嘛？“反正寫完了，以後也不是我維護，更也許再兩天我就在這個項目組了”，“這樣比較方便啊，就先這樣吧，沒關係能搞出來下班，再說了”。在沒有完善的開發平台和系統的開發規範的情況下，開發人員間完全沒有一致可言。你不能告訴一個開發：要這樣寫啊，這樣對於以後的維護方便啊，對於整個項目或者其它開發人員有利啊。也就好比，在沒有立法的情況下，你對造紙場說，愛護環境功在千秋啊，那完全是白搭。

又到了美麗的假設時間，我們再次假設，我們的淫是好淫，好淫是高素質的，寫出的代碼是，符合XXX結構滴、思路清晰滴、易於修改滴、便於維護滴好代碼。對了還有，是沒有錯的代碼。什麼，居然沒有錯嗎？是滴，因為超級的淫，是不需要單元測試，就能寫出完美的class滴。（好淫又被假設成超級的淫了，汗啊……）

當然，超級淫也是淫，組合起來測試也使會有錯的嘛，所以，沒有智障的都會做一下功能測試、系統測試什麼的，以免上帝暴走。在有錯後怎麼辦，當然由超級淫改正嘛，知錯能改當然是超級淫的優良品質。當然咯，超級淫之所以是超級，就是改正了代碼以後就一定沒有錯了，錯的地方沒有錯，其它地方也不會有錯。幹嘛，要迴歸測試做什嗎？你難到不相信超級淫的能力嗎？超級淫說沒錯就沒有錯！

如此之多的假設，俺已經汗流浹背了，已經木有力氣在寫下去了，改天再繼續扯吧～～～