[size=medium]
[b]緣起[/b]
（立項時）
甲：「你們的設計文件打算怎麼寫？」
乙：「到時候再說。」
甲：「應該有規範的開發流程和模板，才能寫好設計文件。」
乙：「預先定義的流程和模板未必適用，敏捷開發崇尚推遲決策，只有在具體工作之前才能決定是否寫，怎麼寫最好（maximizing the amount of work not done）。」
甲：「你們組才3個人，能比組織級定義的流程和模板還好嗎？」
[b]敏捷開發定不定流程和模板？[/b]
先把話說絕點：敏捷開發不定義流程，不定義模板。為什麼呢？
因為如果預先定義了流程，比如「必須寫需求，需求評審過了才能寫設計……先檢查測試環境，測試標準定好了才能開始測試……」以及模板，則在千變萬化的專案進展中，就極有可能多寫了本可以不寫的文件，多做了本科避免的事情，或者雖然沒有「多」，但是形式卻不合適。
這個道理如此簡單，為什麼前人卻經常喜歡定流程和寫模板呢？我們來看看cmmi的情況。
cmmi是最喜歡定流程和寫模板的（組織過程焦點過程域opf負責定期不定期地發現**有可改進的地方，而組織過程定義opd則負責將其制定並宣貫下去），不但如此，還派出過程與產品質量保證人員ppqa檢查實際情況與過程或產品標準的偏差。
cmmi這種工作方式**來的呢？
原來，cmmi是美國國防部的招標標準（cmmi3級及以上才能成為其**商）。長期以來，軍工、航空航天等領域保持了非常高的質量和產量（兩者都遠遠高於我們熟悉的消費電子和網際網路行業），而其首要目標，就是繼承已有的成果，也就是按已有的流程和模板做。偶然有所創新，但其價值與繼承已有成果不可同日而語，所以沒有人會顛覆性地採用新的未經證實的流程或模板。對質量和產量的追求，驅使其整體持有保守的態度，這甚至會影響到其**商的研發策略，比如ibm。
而另外一些行業則正好相反，比如熱銷的蘋果手機，多年來業務不斷變化的google等。
[b]因此，不同行業基於不同價值觀產生了不同的流程和模板理念，他們沒有孰優孰劣之分，只有適合與不適合之分。[/b]
[b]我的行業/專案/團隊適合不適合定義流程和模板呢？[/b]
沒有人比「我」更熟悉我的行業或專案了，所以這個問題不用問。
[b]不定義流程和模板，可能會受限於團隊的能力而把本可以做好的事情做差；定義流程和模板，可能會限制發揮或導致生搬硬套勞而無功。[/b]
兩害相權取其輕，自然會發現答案在**。
或許由於專案、團隊的不同，每次會得到矛盾的答案，這不稀奇也不奇怪，每次都是最好的答案就可以了。
[b]「定不定流程和模板」的常見做法[/b]
敏捷開發過程與模板
多數企業做敏捷開發培訓與諮詢的目的，都是為了形成相對穩定、統一的敏捷開發過程，因此過程與模板是應該有的。否則連scrum master都不知道自己要維持的秩序是什麼樣子的。
但是，在使用過程與模板的時候，不應該執著，而應該靈活。
[b]動態使用的原則[/b]
不知道大家是否發現乙個規律，就是每個產品都會有出現，興起，鼎盛，衰落……這個過程，而打敗他們的，往往是另外乙個新興的但卻更簡單的產品。究其原因，在初期由於老客戶不斷的要求，新產品的功能都會不斷增加；增加了功能的新產品，增強了競爭力，因而也就更熱賣；但產品複雜度到了一定程度，使用這個產品的門檻也就越來越高，新使用者就越來越不接受這個產品了，市場反而被簡單的產品所搶走。（詳情參考產品之六爻：
過程與模板也是如此，對老團隊而言，在不斷改進和細化；而新團隊的門檻卻節節攀公升，最終造成在整個企業推廣的時候，面臨重重阻礙。
因此組織應該分層、分階段地部署過程與模板，而scrum master也要隨機應變地維持秩序。
這一點對scrum master的要求極高，[b]因為」隨機應變「不是被動的，就是看什麼能推動就推什麼，而是主動的，就是發現團隊有什麼問題，就知道流程和模板中哪些內容是用來解決這個問題的。[/b]
[/size]
ref：
敏捷開發智慧型敏捷系列之五 定不定流程和模板？
這是敏捷開發智慧型敏捷的第五篇。之一，之二，之三，之四，之五，之六 立項時 甲 你們的設計文件打算怎麼寫？乙 到時候再說。甲 應該有規範的開發流程和模板，才能寫好設計文件。乙 預先定義的流程和模板未必適用，敏捷開發崇尚推遲決策，只有在具體工作之前才能決定是否寫，怎麼寫最好 maximizing th...
敏捷開發智慧型敏捷系列之五 定不定流程和模板？
這是敏捷開發智慧型敏捷的第五篇。之一，之二，之三，之四，之五，之六 立項時 甲 你們的設計文件打算怎麼寫？乙 到時候再說。甲 應該有規範的開發流程和模板，才能寫好設計文件。乙 預先定義的流程和模板未必適用，敏捷開發崇尚推遲決策，只有在具體工作之前才能決定是否寫，怎麼寫最好 maximizing th...
敏捷開發智慧型敏捷系列之一 序言
這是智慧型敏捷系列的第一篇。之一，之二，之三，之四，之五 本文將解決各種敏捷中需要辯證思考的問題，包括 寫文件還是不寫文件？擁抱變更還是迭代期內無變更？持續交付的產品因為不完整被客戶鄙視怎麼辦？做架構設計還是不做？突出進度忽略了質量怎麼辦？我們不用文件就能開發但客戶偏偏要文件怎麼辦？自動化測試費力而...