這是敏捷開發智慧敏捷的第五篇。（之一，之二，之三，之四，之五，之六）

緣起

（立項時）

甲：“你們的設計文件打算怎麼寫？”

乙：“到時候再說。”

甲：“應該有規範的開發流程和模板，才能寫好設計文件。”

乙：“預先定義的流程和模板未必適用，敏捷開發崇尚推遲決策，只有在具體工作之前才能決定是否寫，怎麼寫最好（maximizing the amount of work not done）。”

甲：“你們組才3個人，能比組織級定義的流程和模板還好嗎？”

敏捷開發定不定流程和模板？

先把話說絕點：敏捷開發不定義流程，不定義模板。為什麼呢？

因為如果預先定義了流程，比如“必須寫需求，需求評審過了才能寫設計……先檢查測試環境，測試標準定好了才能開始測試……”以及模板，則在千變萬化的專案進展中，就極有可能多寫了本可以不寫的文件，多做了本科避免的事情，或者雖然沒有“多”，但是形式卻不合適。

這個道理如此簡單，為什麼前人卻經常喜歡定流程和寫模板呢？我們來看看CMMI的情況。

CMMI是最喜歡定流程和寫模板的（組織過程焦點過程域OPF負責定期不定期地發現哪裡有可改進的地方，而組織過程定義OPD則負責將其制定並宣貫下去），不但如此，還派出過程與產品質量保證人員PPQA檢查實際情況與過程或產品標準的偏差。

CMMI這種工作方式哪裡來的呢？

原來，CMMI是美國國防部的招標標準（CMMI3級及以上才能成為其供應商）。長期以來，軍工、航空航天等領域保持了非常高的質量和產量（兩者都遠遠高於我們熟悉的消費電子和網際網路行業），而其首要目標，就是繼承已有的成果，也就是按已有的流程和模板做。偶然有所創新，但其價值與繼承已有成果不可同日而語，所以沒有人會顛覆性地採用新的未經證實的流程或模板。對質量和產量的追求，驅使其整體持有保守的態度，這甚至會影響到其供應商的研發策略，比如IBM。

而另外一些行業則正好相反，比如熱銷的蘋果手機，多年來業務不斷變化的Google等。

首先這些行業有自己對質量的定義，比如不是可靠性99.9999%，而是易用性、操控性；其次其產量也不來自於標準的規模化的生產，而是來自於其創新性引發的市場反應和使用者主動追逐。儘管這不影響蘋果有自己的生產規程，Google也有自己的編碼規範，但其價值與隨時創新不可同日而語。這就引發了這些企業一致性地採用敏捷開發方法（日後會討論“什麼是敏捷開發方法”，進而會涉及“到底NASA、Boeing、Apple、Google誰在用敏捷開發方法”的問題）。

因此，不同行業基於不同價值觀產生了不同的流程和模板理念，他們沒有孰優孰劣之分，只有適合與不適合之分。

我的行業/專案/團隊適合不適合定義流程和模板呢？

沒有人比“我”更熟悉我的行業或專案了，所以這個問題不用問。

不定義流程和模板，可能會受限於團隊的能力而把本可以做好的事情做差；定義流程和模板，可能會限制發揮或導致生搬硬套勞而無功。

兩害相權取其輕，自然會發現答案在哪裡。

或許由於專案、團隊的不同，每次會得到矛盾的答案，這不稀奇也不奇怪，每次都是最好的答案就可以了。

“定不定流程和模板”的常見做法

敏捷開發過程與模板

多數企業做敏捷開發培訓與諮詢的目的，都是為了形成相對穩定、統一的敏捷開發過程，因此過程與模板是應該有的。否則連Scrum Master都不知道自己要維持的秩序是什麼樣子的。

但是，在使用過程與模板的時候，不應該執著，而應該靈活。

動態使用的原則

不知道大家是否發現一個規律，就是每個產品都會有出現，興起，鼎盛，衰落……這個過程，而打敗他們的，往往是另外一個新興的但卻更簡單的產品。究其原因，在初期由於老客戶不斷的要求，新產品的功能都會不斷增加；增加了功能的新產品，增強了競爭力，因而也就更熱賣；但產品複雜度到了一定程度，使用這個產品的門檻也就越來越高，新使用者就越來越不接受這個產品了，市場反而被簡單的產品所搶走。（詳情參考產品之六爻：http://blog.csdn.net/cheny_com/article/details/5872882）

過程與模板也是如此，對老團隊而言，在不斷改進和細化；而新團隊的門檻卻節節攀升，最終造成在整個企業推廣的時候，面臨重重阻礙。

因此組織應該分層、分階段地部署過程與模板，而Scrum Master也要隨機應變地維持秩序。

這一點對Scrum Master的要求極高，因為”隨機應變“不是被動的，就是看什麼能推動就推什麼，而是主動的，就是發現團隊有什麼問題，就知道流程和模板中哪些內容是用來解決這個問題的。