今天做案例分析，分組討論。乙個問題是說，有個大專案第三期工程，時間大概是20個月。由於第二期狂趕進度，拉下很多技術債：糟糕的設計，重複**，等等。現在要考慮，第三期要不要重新做架構，還是在第二期的基礎上接著往上堆。
這種類似的問題在國內的論壇就已經討論過很多次。主張繼續堆的說，時間緊任務重，抓緊完成功能交貨收錢是要緊；主張重新架構的說，勿在浮沙築高台，深挖洞才好廣積糧，更何況架構改好了**重構了，開發效率也會提高，消耗的時間也能趕回來。雙方都有理，誰也說服不了誰，架都是這麼吵起來的。
今天的討論，我們得到了乙個數學模型。設第三期時間總長t，重新架構需要時間t，重新架構之前開發平均速率v1，重新架構之後平均速率v2。在最壞的情況下，重新架構會要求整個團隊停下來等待，於是有：
t / (t-t) < v2 / v1
通俗的解釋是，如果速率的提公升能把耗費的時間找補回來，那麼就值得重新架構。這個道理每個人都明白，但有了這個方程之後我們就可以代入變數去計算。現在已經知道t=20個月，那麼如果我們花兩個月重新架構，代入計算就是：
20 / (20-2) < v2 / v1
=> v2 / v1 > 10 / 9
也就是說，如果兩個月的重新架構能換來超過11%的速率提公升，就值得去做。11%的速率提公升是什麼概念呢？就是每天少用50分鐘來奮戰、除錯、改bug等等。這個提公升看起來比較合理，不過還是覺得有些偏高，那麼乙個月的重新架構換來每天30分鐘的提公升，我覺得就是比較合理的。同學問我，你怎麼就知道這個合理呢？我沒有證據，憑感覺猜的。但區別在於，我不是在猜20個月會怎麼樣，而是在猜1天能不能節約半小時，相比之下這個難度低得多了。
所以，我覺得自己學到兩點。第一，像「重新架構」這種事情並不是非黑即白的，整條座標軸上的任意一點都是可能的選項。第二，直覺很重要，但量化統計和計算可以縮小直覺的責任範圍，讓直覺更準確。敏捷方法之所以強調快速迭代和反饋，也是為了讓客觀資料多一些再多一些，讓直覺判斷準確一些再準確一些。
西行漫記（11） 數位化敏捷
今天做案例分析，分組討論。乙個問題是說，有個大專案第三期工程，時間大概是20個月。由於第二期狂趕進度，拉下很多技術債 糟糕的設計，重複 等等。現在要考慮，第三期要不要重新做架構，還是在第二期的基礎上接著往上堆。這種類似的問題在國內的論壇就已經討論過很多次。主張繼續堆的說，時間緊任務重，抓緊完成功能交...
西行漫記（3） 敏捷的奧秘
昨天和今天，數節課都是關於敏捷的 迭代開發 迭代管理 adaptive requirements estimation stand up retrospective 總之，就是這類東西。關於敏捷，冰雲的觀點我認為很正確 it s all about money。客戶之所以認可我們的做法，因為他們 按...
西行漫記（3） 敏捷的奧秘
昨天和今天，數節課都是關於敏捷的 迭代開發 迭代管理 adaptive requirements estimation stand up retrospective 總之，就是這類東西。關於敏捷，冰雲的觀點我認為很正確 it s all about money。客戶之所以認可我們的做法，因為他們 按...