如何處理技術債務
Technical Debt a Perspective for Managers
http://www.infoq.com/articles/technical-debt-levison
技術債務來自何處
1. 沒有經驗的開發人員
- 有時候開發人員沒有任何參加Java/C#/Ruby訓練, 或是不知道好的物件導向的程式要怎麼寫. 他們可能仍然採用Visual Basic的方式來撰寫程式
2. 時程的壓力
- 從經理或是客戶所來自的有形和無形壓力, 會讓團隊便宜行事. 只要不是處理P1的bug, 其他的事便不做. 通常還會得到經理的支持. 可是啪們卻不知道這之後會帶來多少cost.
3. 凌亂和難讀的程式碼
- 如果現存的程式碼很難讀, 那下一個接手的開發人員, 很難把這段程式改好. 所以常常是一小段不好懂的程式碼, 變成一大段不好懂的碼.
4. 專門化及分工化
- 導致會有這些想法出現: "雖然有些部分寫的不好, 但那不在我所管的範圍內, 我不需要去處理他"
5. 過度的複雜
- 通常開發人員會預先設計一些東西, 來預防未來的需求. 可是大多數的狀況, 他們並未對問題有明確的了解. 所以過度的設計導致開發人員花了更多的時間, 並且產生一些可能沒有被使用, 或是並不滿足未來區求的程式碼
6. 糟糕的設計
- 有些解法是很糟糕的設計. 如果在這不好的設計上繼續開發, 而不去修正它, 這將會使事情變得更惡化.
解決方法
這些問題都不是一下都能解決的, 解決方案都需要經過幾個iteration才能work. 你必須要有耐心, 並且不同角度來找尋解決方案
1. 讓開發人員能參加一些程式語言的訓練, 並且教他們什麼是物件導向. 這可能需要幾週的訓練, 並且需要有經驗的人來訓練和追蹤成果
2. 告訴開發人員和經理, 這些問題都會造成你公司的損失. 讓大家知道解決這些問題是非常有價值的. 經理們非常重視這些問題, 並且已經開始著手處理這些問債務. 並且持續這樣的活動. 這樣團隊才會相信你是玩真的.
3. 提供訓練告訴大家什麼是code smells, refactoring, unit test和TDD. 結合一些課程, 網路教材和書籍來輔助.
4. 在上班時保留一段時間(一周約2個小時), 來研究和練習這些技術. 有時間實際動手試試看, 才能讓所學的東西發酵. 可以採用Dojo(道場)的方式來進行;
http://www.notesfromatooluser.com/2008/10/tdd-randori-session.html
http://www.notesfromatooluser.com/2008/10/tdd-randori-workshop.html
5. 使用一些工具(Static Analysis, Unit Test, Continuous Integration, Automated Acceptance Tests), 來幫助團隊找到, 減輕, 或是評量他們的債務. 但是這些資料, 經理不能拿來當做績效考核的參考.
6. 對於參加訓練, 或是能力因此提升的人們, 需要給以獎賞. 可以表彰或是給一些小禮物. 但不要直接給予現金的獎勵
7. 每兩周舉辦一次午餐聚會, 和技術方面的學習型會議. 讓學員間能個討論學習習得和交換經驗. 提供午餐能增加出席率. 經理們的出席, 更宣示對這活動的重視
8. 維護技術債務的backlog. 當注意到有些債務無法立即解決, 需要加以記錄下來. 並在iteration中企圖花費10-15%的時間, 來解決這些事情.
留言列表
