讓老媽告訴你如何編程

在今天開發人員的周例會上，大家吵的不可開交，我們在討論在敏捷開發中是否應該將“故事點(story point——敏捷開發中的一種工作量單位)”分配給修改bug和代碼整理工作——將它們跟軟件功能需求一樣對待。我們使用的story類型都是 Pivotal Tracker系統里缺省指定的。概括起來，通常認為軟件功能單位是一種能夠給用戶帶來價值的“story”(所有你可以對它們使用這樣的套話“做為一個用戶，我想要的是…”)，但bug和代碼整理工作不屬于這類(盡管它們有些是必須處理的，例如償還技術債務)。

根據Pivotal Tracker系統里的設定，只有軟件功能特征才配分配給”故事點“。團隊的“成績”依仗于在過去的3-4個迭代開發周期里完成的“故事點”的多少，所 以，如果你將大量的時間浪費在重構代碼和修改bug上，你的“成績”就會下滑。于是，經理會極力反對將“故事點”分配給代碼整理和修改bug，因為“只有 把時間用在開發功能上，客戶才會認可我們的努力工作”。

遇到這種情況，勾起了我對往事的一段回憶，那是我在童年時整理房屋的事情。如果你跟我小時候一樣邋遢懶惰，你會像我一樣將臟襪子、糖紙丟的滿地都 是，幾乎看不到地板。媽媽會反復嘮叨說“每天記住把襪子丟進洗衣機，把糖紙丟進垃圾桶，這樣你就永遠不需要打掃房間。”但有時候，這些事情看起來需要太多 的努力，于是垃圾總是越積越多，直到無法忍受。

問題是，正確的保持室內整潔的方法給人太大的壓力。于是，大家最終還是選擇了將臟衣服不斷的塞到衣櫥里，用力的推衣櫥門關上(用力，不然會塌落出來)，這樣屋里似乎整潔了。但事實上，臟亂依舊存在，盡管你看不見(不想看見)它。

修改Bug和整理代碼的努力對于軟件開發來說是同樣的道理。敏捷開發中使用“故事點”的最大好處是，用給用戶創造了多少價值來衡量一個程序員的生產 效率，這樣正確的激勵程序員的工作積極性。將“故事點”分配給bug修改？花一個月時間里重構代碼中的數據庫層？你的“成績”的下降是指警告你某些事情有 問題。你需要思考，需要明白這是為什么，以及如何糾正。

也許是你的需求不完整，或根本就是錯誤的，你并沒有開發客戶真正想要的東西。也許你沒有寫出足夠的單元測試和集成測試，所以在開發迭代中bug越來越多。也許你們的編碼速度太快，沒有充分的規劃，所以你的架構設計無法接入新來的需求，需要頻繁、大量的重構。

不管是哪種情況，如果必須把“故事點”分配給bug和代碼整理，這是存在底層問題的一種反映，就像是整理房間一樣。讓“故事點”充分發揮它的作用，讓它提示你在你們的開發過程中存在潛在的問題。但不要只理解我的話的表面意思，就像你媽媽如何告訴你整理房間的話一樣。

Matt