敏捷軟件開發之Scrum/Sprint(2)

　　如果項目的所有人都坐在一起, 連工位的矮墻都沒有, 那的確很爽, 但是在很多公司中那是不可能的，有些團隊成員甚至在不同的時區工作，怎么辦? 他們就不能敏捷了?這時候我們的確需要文檔和其它輔助手段來溝通。

　　燃盡圖, 有些燃盡圖只是列出了任務的數目, 這種圖無法展現項目的拖延, 一個任務有大有小, 它們在圖表中都是一個點, 一個16小時的任務需要3 天完成, 一個2小時的任務處于種種原因也花了3天時間, 他們在圖表中的表現是一樣的。 在實踐中, 我個人認為以時間為度量的燃盡圖更有效果.

　　下面是一個實際項目的燃盡圖, 有三個每天跟蹤的時間值:

　　實際剩余時間/remaining hour: 每個團隊成員所有任務的 remaining hour 的總和

　　預估剩余時間/projected remaining hour: 根據每個人每天的理論進度推算的剩余時間

　　實際花費時間/completed hour:

(Sprint 進行中) (sprint 最后)

　　注解1: sprint 從8/22 到 9/28, 中間9/15 - 9/18 整個團隊外出開整個部門的年會。

　　注解2: 開始預計所有工作量為340 小時， 每個工作日能減少 (burn) 17 小時。

　　注解3: 開發人員有 5.5 名, 絕大多數第一次接觸正式商業項目和 SCRUM的團隊開發模式。 最終完成的工作量為524 小時, 是預計的 1.5 倍。(這暴露了什么問題呢?)

　　注解4: 有 0.5 名UX 設計人員, 0.5 名PM, 和 2 名測試人員。

　　注解5: sprint 結束后, 各個任務宣告完成, 并且沒有P1 (最嚴重的) bug，但是P2 及以下的bug 有80 多個, 加上前一個版本遺留下來的70個bug, 總共還有150 個bug 要解決, 才能發布。

　　注解6: sprint 結束后, 有兩個原來的設計發現很有問題, 團隊決定在sprint 結束之后進行重新設計，或者叫 Design Change Request (DCR)。

　　第三步半:

　　做過項目的人都知道, 當你說“任務都完成了”的時候, 那只是說, 開發人員認為該寫的代碼都寫完了, 還有很多事情沒做完. 例如寫一個Windows 客戶端的功能， 顯示一個新聞圖片加上和與它相匹配的文字 (假設這些圖片/文字都可以從互聯網上拿到) , 做完之后, 還有下面的事情:

　　驗證這個功能顯示在WinXP, vista, win7, win2008 server R2, win2012 server 都顯示正確。 (開發人員表示自己的機器是win2008 server, UI 看起來不錯, 其它平臺想必也不錯!)

　　驗證這個功能的顯示布局和字體在100% 到150% 的DPI 上都顯示正確, 在各種色彩配置中都顯示正確。

　　驗證文字無論是中文, 英文, 阿拉伯文都能正確顯示 (聯合國五種工作語言我們得支持吧? )

　　驗證程序效能上沒有問題

　　驗證程序在長期使用, 沒有內存和資源泄露

　　驗證這個功能和其它功能有較好的集成

　　誰來做這第三步半呢? 程序員寫完功能的時候, 我們感覺好像項目完成了 80%, 殊不知后面的20% 往往要花費80% 的時間, Sprint/Scrum 沒有明確表明到底 何人/何時/何種優先級 來完成這個20% 的任務。

　　軟件團隊中還有一個重要的角色 - 測試。 測試人員在一個沖刺中怎么工作呢? 有敏捷專家建議測試人員可以擔負起 Product Owner 的部分責任，同時掌握 Acceptance Test 流程, 對產品的最終質量負責。 但是測試人員的開發技術能力在團隊中并不占優 (在有些中國公司中甚至是最弱的一環)，他們在大家都要 “燒光”所有任務的壓力下，能擔當起 Product Owner 這一責任么?

　　第四步:

　　得到了一個增量的軟件發布, 當然好, 但是誰來驗證這個增量滿足了事先的計劃呢? 如果程序員們在沖刺的過程中發現了新問題, 改進了原來的計劃, 這是好事呢還是壞事?

　　每一次沖刺結束后, 大家要放松一下, 總結上一次的經驗教訓，爭取下一次做得更好。 這個博客記錄了微軟學術搜索項目組 10 次沖刺的過程。

　　軟件開發流程有好多種, 我們怎么衡量一個開發流程是否對當前的項目/團隊合適? 我覺得Scrum/Sprint 能成功實施的關鍵在于 ScrumMaster。我聽到有些團隊也實施Scrum, 但是他們隨機挑一個成員來做 ScrumMaster, 好像 ScrumMaster就是招呼大家開開會, 記錄每個人的進度而已。這種方法失敗的可能性很大。 一個好的ScrumMaster 能在兩種語境 (描述軟件項目的商業語境，描述實現細節的技術語境) 自如地翻譯和切換，事實上是一個強有力的PM，如果團隊還要求她做全職的開發工作，這樣的人就更難找了。

　　Scrum 很特別么?

　　我個人認為它和質量控制理論的模型， 例如 經典的戴明環 PDCA Plan-Do-Check-Act/Adjust 沒什么太大區別. 正如 Ken Schwaber 在描述Scrum 的核心特點的時候說:

　　在迭代開始時, 團隊審視擺在他們面前的任務，選擇他們認為可以在迭代期間完成的那些 (Plan)。然后團隊獨立地盡最大努力完成這些任務 (Do)。在迭代結束時, 團隊給利益關系人展示他們的成果 (Check)，并對開發流程進行調整 (Act/Adjust).

　　在 6西格瑪理論中 ( Six Sigma) ，我們也可以看到相似的流程, 只不過它變成了 "Define, Measure, Analyze, Improve, Control" (DMAIC). 此模型不強調迭代的重要性。

　　Scrum 和 漸進交付的流程 (Evolutionary Delivery) 也很相似:

圖片來源: Rapid Development (1996), Chapter 7, “Lifecycle Planning” (p. 133)

　　Scrum 的團隊

　　Scrum對團隊的要求很簡單：self-managing， self-organizing， cross-functional， 但是這很難做到。軟件項目的團隊各式各樣 (各種團隊類型的介紹)， 假設一個團隊做得還不錯，現在要變成 Scrum 流程, 那團隊要做下么的改變:

原文轉自：http://www.kjueaiud.com