本文以 Visual Studio Team System (VSTS) 2010 的預發布版為基礎。所有資訊均有可能發生變更。
本文將介紹以下內容:
產品和小版本規劃
產品待辦項目簿
容量規劃和報表
小版本積壓活頁簿
本文使用了以下技術:
VSTS 2010、VSTS Process for Agile Software Development 1.0
“敏捷規劃”存在語意矛盾嗎?希望您不會這樣認為,但在最近於洛杉磯召開的一次專項小組會議中,其中一位與會者指出其組織已從敏捷開發轉為採用更為正式的方法。在經過進一步的詢問後,她坦承其團隊無法再根據其經理的口頭要求進行代碼修複並立即將修複結果部署到生產中。現在,她不得不使用正式的程式。對她而言,即意味著放棄了敏捷開發。
實際上她對敏捷開發的理解並不準確,但是我非常高興她的組織能夠制訂正式的更改流程。敏捷並不是指盲目進行加速或出於速度考慮才選擇敏捷的。相反,它是一種符合標準的規劃方法並且其中融入了經驗資料。
Visual Studio Team System (VSTS) 2010 引入了一些新的特性和功能來協助敏捷團隊進行規劃。在本文中,我將向您介紹一些全新的產品待辦項目簿、小版本積壓活頁簿以及一組新報表,它們可以協助敏捷團隊規劃和管理版本和小版本。
長期規劃
人們總是擔心沒有精確的長期規劃,這已成為推廣敏捷方法的主要障礙。在 2008 年度敏捷開發狀況調查中,缺乏事先規劃是受訪組織在採用敏捷方法時最關注的問題。我懷疑對許多人來說,缺乏精確的長期規劃就等同於缺乏協同規劃。敏捷團隊選擇多個層級的規劃並在瀑布式規划過程中進行期間修正,當然本來就該如此。
Steve McConnell 在軟體評估的不確定性圓錐中指出,在項目中過早進行評估可能會得出不準確的結果,偏向高邊的錯誤最高會達到 400%:“在項目早期,待構建軟體本質的具體細節、特定需求的細節、解決方案的細節、專案規劃、人員構成以及其他項目變數均不確定。這些因素的可變性會導致項目評估的可變性。”
當然,這並不意味著主管人員的管理原則是“我們不知道項目何時能完成,也不知道完成時會是什麼樣子”。它實際上是想說明團隊規劃版本的方法以及各版本中所完成工作的範圍均存在變數。
圖 1 產品和小版本積壓