敏捷開發一千零一問系列之二十一：怎樣寫設計？（教育軟體案例）

這是敏捷開發一千零一問系列的第二十一篇。（在這裡提問，之一，之二，之三，問題總目錄）

問題

這個問題來自於QQ聊天記錄。

早期的對話大致是：

問： 12:50:06 
敏捷開發 提倡的是簡單設計是吧？ 
那麼是不是就弱化了 設計文檔了呢？ 
陳勇-諮詢-北京(139107533) 12:54:06 
弱化設計是相對的，敏捷的目的只有一個：強化最後的可用產品。 
對於本來設計有點過頭的團隊而言，需要弱化設計來省出時間強化產品；對於本來設計文檔都不寫的團隊而言，則要強化設計來避免返工強化產品。 
可能多數公司都屬於設計過頭的，所以感覺上是弱化了設計。 
問： 12:56:52 
那麼設計文檔還是需要正常的完善是吧 

分析

這個一個常見的“無住”情境，就是人們非常期待有一種方法，是超過其他方法的，只要學習這種方法，開發過程就萬事大吉了。而實際上，因環境的不同，“最佳方法”在不斷變化，必須具體情況具體分析。

當然還有另外一個反面的極端，是認為任何方法都不是好方法，因此寧願隨波逐流，或到時候再說，而不去追求這種情況下的普世價值。這會造成很大的浪費和失誤，因為在“具體情境”到來的時候，如果沒有事先的思考和積累，常常覺得無從下手。因此，對於特定的環境，應該事先思考和總結出可行的“最佳”方法，並基於這個方法進行變通和改進。

下面就是後來的具體案例分析。

案例

這是後來在實際情境中的對話（語序有調整）：陳勇-諮詢-北京(139107533)  13:03:22
你們是什麼行業，什麼產品？自己做產品，還是項目？
這個三個問題如果無法回答，而去找敏捷的答案，會比較麻煩。
問：13:09:33
教育軟體的開發，項目

陳勇-諮詢-北京(139107533) 13:10:56
好，到現在為止， 應該是提前做設計好一些，不需要做太深，但肯定有。有比沒有好。
項目一般而言，人員的流動會大一些，因為長期回報低。
另外由於個體產出低，所以人員的工資和水平都會低一些
所以，應該有一個主心骨的骨幹人員，來協助大家確認一下整個項目的需求、設計，而不是讓大家自由發揮。
否則大家本來水平就不高，發揮失敗了一走人，就白忙了。
但是，教育軟體不屬於生命攸關或重大財產的產品，所以，也不用做太多的嚴謹設計，以能指導大家做出來為宜。
……敏捷開發沒要求一定如何什麼，但是要求面對某個情境，要找到這個情境下適合的方法。 

分析

由於多數情況下，人們很少跨行業工作，尤其是有些人長期在一家企業工作，所以很難意識到自己的行業、項目、團隊是有“特點”的，所以常常會認為一定有一種普適的方法來解決普遍的問題；但事實不是如此。

不過話又說回來，對於一個問題的答案，其實最重要的不是答案本身，而是分析過程中的思路。因為多數情況下，其實問問題的人比回答問題的人更真切地理解實際環境，而無論這個“分析過程中的思路”有多麼正確，如果建立在“不很真切的環境假設”的基礎上，就只能推出“不很恰當的答案”。

因此，問問題的人，應該學會分析過程思路，自己繼續去精化答案，而不是死守答案本身。

這就是火星人諺語中的問問題的人負責找答案。