[Agile] 完整前期設計 vs. 漸進式設計
傳統開發團隊在轉換到 Agile 時，第一個遇到的問題應該會是如何切換成「Iterative and Incremental Development」。也就是說，通常一時間會難以接受沒有細部設計就開始實作的方式，不過我待的團隊很幸運，剛好有機會嘗試這兩種開發方式，這邊來談談施行經驗與觀察吧。
這裡的結論可能不是很客觀，我們團隊嘗試這兩種方法的時間點不同，所以成員的能力也有差異，另外，這也只是我憑著記憶整理出來的結果，不過相信結論不會悖離事實太多。
因為這邊談到的狀況，不全然是基於 Scrum 框架下的運作，所以這邊定義一下角色，針對寫程式的人，我們叫做 Programmer，而 (Architecture) Designer 則是軟體架構的主要設計者。
環境：
- Programmer 的能力偏向 Junior Engineer，沒有 Design 能力，看得懂 UML 表達方法。
- 時程壓力不大
- 專案的需求變動度低
開發方法：
- 完整前期設計: 定義出 Designer 及 Programmer，從需求分析到 UML 圖設計都先做完後，再進行實作，後續有問題時，再由 Designer 進行修改。
- 漸進式設計: 定義出 Designer 及 Programmer，由 Designer 將基礎架構訂出後，就開始實作，並由 Designer 擔任設計顧問，Programmer 主導區塊的設計細節。
| 前期準備時間 | 單一開發週期產生之成果 | 成員自我管理 | |
| 完整前期設計(方法1) | 多 | 少 | 少 |
| 漸進式設計 (方法2) | 少 | 多 | 多 |
在方法1的執行過程中，團隊初期會比較專注在架構的設計，而不是產出可用的軟體單元，但偏偏又無法在初期就做出沒有問題的架構設計，所以日後還是推翻先前的分析與設計。方法1很難在短時間裡，從實作面得到需求和架構意見，日後還是要花時間大幅度修正架構。
在方法2中，因為直接讓 Programmer 投入細部設計並直接實作，所以可以從早期就取得許多回饋，並能與 Designer 早點將問題引入架構設計的討論中，架構因此能夠逐步穩定，並且讓 Programmer 及 Designer 對架構和需求理解更有信心。
在成員的成長方面，方法2對於 Programmer 的學習有很大幫助，Programmer 可以參與架構的細部設計，一方面可以讓成員有學習設計的機會，並且直接了解架構細節，另一方面，能增加成員自我管理的可能性。而方法1則造成 Programmer 按圖施工的可能性大增，而忽略達成需求的目標，此外，也無法從 Programmer 身上取得較多的回饋，增加架構崩壞的可能性。
不過，雖然早點開始實作，可以在一定的時間內取得部份成果，但是，對於主導的 Designer 卻是很大的負擔。這是因為成員不懂軟體設計相關議題，所以要確保實作品質、協助 Programmer 理解需求、串連不同的單元，跟 Programmer 就會有極大量的溝通。這樣的好處是在過程中，比較有機會直接讓 Programmer 了解什麼是有效的設計，也能降低實作與需求之間的落差，而且 Programmer 會比較懂得反應問題點，並討論解決方法。但問題就是會耗費大量時間，卻未必可以在週期內出現有效的產出，而且Programmer 和 Designer 也可能彈性疲乏。
從實行結果來看，方法1相當可惜，因為前期準備時間過長，後期溝通成本又居高不下（因為 Programmer 還無法理解設計，也無法提出細部設計的意見），所以最後還來不及產出可用的成品，就因為其他專案的加入而中止了。
發佈留言
很抱歉，必須登入網站才能發佈留言。