| 假設我是你的客戶，我想讓你和你的團隊給我開發一個軟件系統。於是你的團隊動手實現這個軟件系統。一共花了一整年時間——12個月——來完成這個運作正常的、通過測試的系統。 於是我向團隊表示感謝，接受了交付的系統，然後把它丟掉。然後我讓你和你的團隊給我重新開發這個系統。你的人員保持不變。需求也保持不變。工具軟件也保持不變。基本上什麼都沒變——整個環境完全一樣。 你和你的團隊要花多少時間來重新完成這個系統呢？ |
不過，因為帶過太多團隊，這是我之前常自省的問題；於是，有一陣子我將焦點放在"架構"(architecture)上。
架構設計好之後，寫出所謂的code template，幻想著這樣就能加速開發。
但，所謂的爆發性進度這件事，從來沒有發生。
讀了這篇"The Secret Sauce of Highly Productive Software Development"，真的找到了之前專案延遲所發生的缺口，就是團隊學習。
| 當我們提出這個假想的情形——提問的對象中很多都有著超過二十年的軟件開發經驗——他們的答案多數在第一次完成時間的20%到70%之間變動。也就是說，原來要花一年時間開發的系統，重新完成一次只需要2.5到8.5個月。這是一個很大的差別！很難再找到另一個因素能夠對軟件開發有這麼大的影響了！ 那麼，問題到底在哪裡？第二輪開發中到底有什麼不一樣了？是團隊。他們一整年都粘在一個團隊中，因而互相瞭解。他們又理解了真正的需求——不僅僅是寫下來的那些需求。他們還學會使用手中的工具，理解了在整個軟件開發中浮現出來的問題領域的種種特質；基本上在創造並交付一個成功的軟件解決方案之前，他們已經解決了所有未知的東西。學習過程正是軟件工程的瓶頸。 學習過程的存在佔據了工作量的很大比例。實際上，我們估計它消耗了30%到80%的開發時間。正是出於同樣的理由，敏捷實踐才如此成功——它們的主題就是識別並應對變化。 |
以「學習過程是瓶頸」的眼光檢驗敏捷
作者這麼說。所以，在架構跟code template之後，看來要認真對待的應該是"教育訓練"這件事了。
另外不錯的文章：
提高軟件開發生產力的秘方(中文版)
什麼敏捷實踐會遭遇失敗？
漸進式敏捷：由下而上的敏捷推行策略
還有這篇，非常好的XP實踐方法。
用“看板圖”實現敏捷項目的視覺化
0 意見:
張貼留言