夠用就可以了！就是說不應該太多，但也不能沒有。我們需要找出來對我們真正有用的文件，真正值得花精力的文件，然後做增量設計。”

“話雖如此！問題是咱們在大的流程上還必須按照公司的產品生命週期走，這中間會涉及很多的里程碑，而每個里程碑都要求有完備的文件，才能透過檢查，進入下一階段。”阿朱接著說。

“那我們先來看一下公司的PLC（Product　Life　Cycle）好了。”阿捷邊說邊在白板上畫出公司的產品生命週期。

“雖然整個週期很長，但咱們必須透過的CheckPoint只有DEV和SHIP。咱們Team目前自己實施敏捷開發，也就是在DEV到SHIP之間。其實，這也正是敏捷軟體開發跟CMMI/ISO　000等流程相互補充的最有效方式。其間的SQ雖然很重要，但不是必需的，公司強制得並不嚴。所以咱們只要在DEV和SHIP這兩個CheckPoint上提供完備的文件就可以了。”

“DEV　在我們開發的啟動之初，可以周旋的餘地不多，這個念頭就不用想了，該準備的文件還要準備好。不過，這個CheckPoint更多的是針對Marketing、Product　Planner等除R&D以外部門的，對於我們R&D來講，只需要給出一個專案計劃文件和一個軟體總體架構文件即可，所以問題不大。而SHIP是在後期，可操作的餘地比較大。”

“這樣的話，那我們是完全可以按照儘量簡化、增量設計的思路來做的！在每一個Sprint，我們都只做簡單設計，產生對於當前Sprint所必需的文件，而沒必要一次性給出大而全的設計方案，寫出非常完備的文件來。這樣也不現實，因為最終還是要不斷地修改的。完全可以透過後繼的Sprint，不斷完善，不斷重構，直至產品釋出前，給出最終版本。當然，每次的設計都應該是可以擴充的，而不是走入死衚衕，以後沒法重構。大家覺得如何？”。　最好的txt下載網

第11章　你開車，我導航（3）

“應該是可以做到的。關鍵還是度的問題。設計要適度，文件要適度，不能成為我們工作的累贅，又要做到出現爭議的時候有據可查。我覺得有些文件還是一開始就要有的。”大民回應道。

“可哪些文件是必須要有的呢？”小寶還是很關心具體的東西。

“在我看來，至少有兩份文件是必需的：需求文件和概要設計。需求文件的目的是告訴大家，我們開發的軟體要做成什麼樣子、要實現哪些功能，這份文件應該是經常更新的，記錄�