在今天開發人員的周例會上，大家吵的不可開交，我們在討論在敏捷開發中是否應該將“故事點(story point——敏捷開發中的一種工作量單位)”分配給修改bug和程式碼整理工作——將它們跟軟體功能需求一樣對待。我們使用的story型別都是 Pivotal Tracker系統裡預設指定的。概括起來，通常認為軟體功能單位是一種能夠給使用者帶來價值的“story”(所有你可以對它們使用這樣的套話“做為一個使用者，我想要的是…”)，但bug和程式碼整理工作不屬於這類(儘管它們有些是必須處理的，例如償還技術債務)。
根據Pivotal Tracker系統裡的設定，只有軟體功能特徵才配分配給”故事點“。團隊的“成績”依仗於在過去的3-4個迭代開發週期裡完成的“故事點”的多少，所 以，如果你將大量的時間浪費在重構程式碼和修改bug上，你的“成績”就會下滑。於是，經理會極力反對將“故事點”分配給程式碼整理和修改bug，因為“只有 把時間用在開發功能上，客戶才會認可我們的努力工作”。
遇到這種情況，勾起了我對往事的一段回憶，那是我在童年時整理房屋的事情。如果你跟我小時候一樣邋遢懶惰，你會像我一樣將髒襪子、糖紙丟的滿地都 是，幾乎看不到地板。媽媽會反覆嘮叨說“每天記住把襪子丟進洗衣機，把糖紙丟進垃圾桶，這樣你就永遠不需要打掃房間。”但有時候，這些事情看起來需要太多 的努力，於是垃圾總是越積越多，直到無法忍受。
問題是，正確的保持室內整潔的方法給人太大的壓力。於是，大家最終還是選擇了將髒衣服不斷的塞到衣櫥裡，用力的推衣櫥門關上(用力，不然會塌落出來)，這樣屋裡似乎整潔了。但事實上，髒亂依舊存在，儘管你看不見(不想看見)它。
修改Bug和整理程式碼的努力對於軟體開發來說是同樣的道理。敏捷開發中使用“故事點”的最大好處是，用給使用者創造了多少價值來衡量一個程式設計師的生產 效率，這樣正確的激勵程式設計師的工作積極性。將“故事點”分配給bug修改？花一個月時間裡重構程式碼中的資料庫層？你的“成績”的下降是指警告你某些事情有 問題。你需要思考，需要明白這是為什麼，以及如何糾正。
也許是你的需求不完整，或根本就是錯誤的，你並沒有開發客戶真正想要的東西。也許你沒有寫出足夠的單元測試和整合測試，所以在開發迭代中bug越來越多。也許你們的編碼速度太快，沒有充分的規劃，所以你的架構設計無法接入新來的需求，需要頻繁、大量的重構。
不管是哪種情況，如果必須把“故事點”分配給bug和程式碼整理，這是存在底層問題的一種反映，就像是整理房間一樣。讓“故事點”充分發揮它的作用，讓它提示你在你們的開發過程中存在潛在的問題。但不要只理解我的話的表面意思，就像你媽媽如何告訴你整理房間的話一樣。
Matt
英文原文：Here's How Your Mom Would Want You to Develop Software
來自：外刊IT評論
相關閱讀
評論(1)