西行漫記(11) 數位化敏捷

2021-08-22 03:33:17 字數 953 閱讀 6173

今天做案例分析,分組討論。乙個問題是說,有個大專案第三期工程,時間大概是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。客戶之所以認可我們的做法,因為他們 按...