敏捷其實是面照妖鏡，能提早暴露出組織和團隊的問題，好讓團隊能及早進行討論，和思考改善方案(當然前提是有想要改善，有能力改善)。隨著專案越來越大，系統越來越複雜，技術債這個議題已經越來越不能忽視，因此最近團隊時常討論的題目便是"該如何償還技術債"，但是如果直接基於這個命題來討論，我們很容易就直接跳到了how 的議題，於是各式各樣的爭論就出現了：
- 是不是應該要每個 sprint 保留時間解決技術債
- 技術債不解決，到了後期要解決所花的成本會是以指數倍增
- 既然是債務，要還債就要考慮是否有盈餘可以還債
- 我們應該等到有盈餘和餘力的時候再來考慮還債 (謎之音：原來沒賺錢就可以不用還錢~:P)
- 身為一個快速成長(預期持續會成長)的公司，新需求會越來越多，系統只會越來越複雜，那會有時間嗎？
- 如果我們不能先養活自己，賺到足夠多的錢，是沒有本錢談還技術債，只能先衝各種商業機會所產生的新需求
不過我覺得一個好的討論應該參考 - 問題解決金字塔：理清Why、What、How 讓你工作沒煩惱 的順序來討論，也許可以把問題重新定義成：
Why 為什麼會有技術債？
What 是怎樣的技術債(技術債也有類型)？該不該被解決？ 何時要解決？
How 如何去解決技術債？
因此我比較喜歡先從 Martinfowler - TechnicalDebtQuadrant 對於技術債的定義開始討論，我們可以把技術債分成產生原因分成四個項限，蠻幹（reckless）和謹慎（prudent），而另一個象限，則是刻意的（deliberate），以及無心的（inadvertent）：
無心且蠻幹造成的技術債
我稱之為臭臭/混亂的程式碼，造成這個的原因可能是技術能力不足，沒有良好的開發習慣...對於這種應該就是只能靠工程師和團隊努力提昇自己的技能，只要有看到不臭臭的code 就順手(花時間)把它修掉....
謹慎且有意造的技術債
這時候通常就是Team也知道，PO也知道，隔壁的老王也知道，但是為了商業考量只好衝了...這種最容易發現，也最好討論，因為往往是商業考量，也是最有可能不需要還的，很多時候商業需求和時間點一過，搞不好整套都要丟掉。此外因為跟商業考量掛勾，也比較好在將來排進去還債。
謹慎但無心造成的技術債
這個項限最有趣，也最難理解，我的理解是隨著專案進行，或技術進步，突然想到又更好的解法，於是舊的東西就變成技術債了?故意又蠻幹造成的技術債
時程太趕，又一直被壓時間，這時候工程師的百寶箱內的工具盡出~(怪我摟)這種通常就是爭論角力的所在點，明知到有問題，但是何時能要到時間還債？
我覺得最容易產生爭論的就在後面兩種，不過知道成因後，比較能針對不同的項限討論接下來的債務償還策略：
- 直接償還：將視為技術債的程式碼，架構，框架，技術作重構或更換
- 債務轉換：選擇當前夠好的替代方案，而不是完美的方案
- 純支付利息：重構代價太高，反正堪用，在只需要維護的狀況下，就繼續使用吧
不知道大家團隊都怎麼處理技術債?
最後只想說....
沒有留言:
張貼留言