【51CTO專稿】在敏捷實踐中，Scrum可以說是用于運行項目的框架，它基于敏捷的 原則和 價值。對于管理嚴格的項目團隊，Scrum會議也會每天都在同一時間進行。通過每日Scrum 會議，團隊成員之間可以彼此相互熟悉工作內容，充分了解項目進度，相互幫助解決問題。那么，在Scrum中的Sprint計劃會議應當如何進行？記者采訪 了敏捷個人創立者，周金根老師跟網友們談談Scrum的實施與Sprint計劃會議。
個人簡介：周金根，個人成長教練，軟件產品架構師，培訓師，敏捷個人創立者和推廣者。
以下內容為采訪實錄：
記者：請問你是如何接觸到敏捷開發的？敏捷個人的創立是出于什么樣的想法？
周金根：最早我們是采用RUP開發的（可以看看從IT方法論來談RUP）， 我記得在一個產品設計階段，我們使用Rose畫了很多圖，但是最終開發的時候其實沒有人去看；更為重要的是，產品交付之后需求變更很多。這之后，我就開始 關注軟件全生命周期的方法、技術和工具，于是了解了敏捷。最早是XP，然后是Scrum。08年我去了一個新的項目組，這個組沒有開發流程方法，也不知道 如何做需求，于是我在這個組實踐了一些新的方法，其中包括Scrum。在Scrum的實施過程中，我發現并不像最初想象的簡單?？此坪唵蔚牧鞒毯徒巧?，真 正要發揮功效并不容易，除了技術能力之外，我還需要讓自己學習更多管理方法，更需要自己深入領悟敏捷管理背后的東西。對Scrum的深入思考，我越發覺得 團隊中每個人的成長是敏捷發生效果的動力，這讓我對個人管理這個話題有了更加濃厚的興趣，于是把自己在個人管理和個人成長方面的思考寫下來，并在團隊中學 習和實踐。團隊中的成員有自發打印出來給家屬學習的，也有主動參與討論的，以及后期社區對敏捷個人的認可，這都鼓勵和激發我慢慢系統化的思考個人成長，并 提出了敏捷個人。 經過兩年多的思考，目前敏捷個人已經是一個較為體系的個人成長框架，它可以幫助個人成長，并促進敏捷團隊的形成。
記者：請問敏捷開發是否真的能解決傳統開發的一些問題？如何去認識敏捷的根本？
周金根：從瀑布到敏捷，我們已經發現產品更適合用戶、質量越高、上市時間也越短，敏捷順應不斷變化的時代，是否能解決傳統開發已經不是一個問題。對于敏捷，我認為其根本在于學習和適應，這也是擁抱變化需要具備的兩項最重要的能力。
記者：團隊的敏捷實踐與管理是分不開的，您是怎么看目前國內的管理？
周金根：在沒有敏捷之前我們就在管理，但在敏捷盛行的時候，有些管理者就分不清敏捷和管理了。其實我不太在意某種最佳實踐出自哪種敏捷方法，我認為 只要有利于當前團隊的實踐都是管理的一種工具，也就是說，作為管理者，我們仍需保持更大的視角，敏捷僅是管理的一種工具，我們還要學習目標設定、流程優 化、團隊建設、個人成長等更多管理方法。
記者：有些人認為敏捷開發并不適用于水平一般的程序員或團隊，您是怎么認為的？
周金根：任何方法都不是銀彈，也說明了沒有一種方法是完美的。既然沒有完美的方法，那自然也不必是完美的人去執行了。水平高的程序員在技術實踐領域 的敏捷固然可以做得更好，但一個產品的失敗大多數都不是因為你是否采用了測試驅動、結對編程等最佳實踐，而是開發管理上的問題。Scrum作為一種敏捷方 法，背后具有很多管理思想，只要管理者和團隊對Scrum有進一步的思考和認識，也可以很大程度上去提高技術水平一般的程序員團隊。
周金根：敏捷方法在國內實施起會導致項目管理原有模式的改變，而很多公司都沒有達到敏捷的目的。以致公司往往不愿意引進這樣的開發模式。您怎么看待這個問題呢？
回答：從公司角度來說，你能把軟件越快越好的做出來就可以了，至于采用的是敏捷還是瀑布并不重要。與其說是公司不愿意引進這種模式，不如說是軟件開 發負責人不愿意或者沒有能力引進新的方法。敏捷開發相對來說已經比較成熟，我認為現在不是討論是否愿不愿意引進這種開發模式的時候，反而是思考如何引進的 問題，這不僅僅是技術實踐，還有管理，甚至是個人成長方面的改變。
記者：團隊的人數對于敏捷開發有何影響？如何進行拆分？
周金根：人數的規模會帶來團隊的復雜性，隨著人數增加，管理、溝通等都會越來越困難。而保持7±2人左右的小團隊，可以更利于團隊的形成。在這樣的 團隊中，人與人之間都更為熟悉，協作起來就更容易。那這樣的小團隊由哪些人組成呢？這也需要根據產品的規模來定。對于一個小型產品，這個團隊將由市場、需 求、開發、測試等人員組成全功能性團隊；如果產品屬于中大型，那有可能會形成單一功能性團隊，再由多個這樣的團隊組成一個大的敏捷團隊，由這個大的團隊來 實現對客戶的交付。
記者：敏捷實踐過程中Scrum實施整個過程怎樣規劃。
周金根：實施Scrum，我們可以采用類似學習一樣的過程，首先完全按照Scrum流程執行；然后再根據執行后的效果進行自我裁剪和補充；最后淡化Scrum的概念，與更大范圍的軟件產品周期過程融合起來。
記者：敏捷開發的方法內有很多不同的程度，而幾乎每個敏捷開發團隊都有scrum會議，在您們的團隊中是如何進行的？
周金根：溝通在任何團隊都是必不可少的，而會議是其中一種。我認為Scrum中的Sprint計劃會議是最重要的事件，這確定了每次迭代的目標?；? 顧會議是第二重要的事件，因為這是團隊做改進的最佳時機，如果沒有回顧，就會發現團隊在重犯相同的錯誤。如何進行可以看看我之前寫的幾篇blog：
1、Scrum之 Sprint計劃會議（以下內容摘自周金根博客）
在sprint第一天召開sprint計劃會議，這個會議分為兩部分，計劃會議1由PO、SM和Team參加，主要是從產品 backlog中挑選出需要放到當前sprint下的既定產品backlog，然后由SM、Team參加計劃會議2，把既定產品backlog的故事拆分 成任務進行估算，PO也可以一起參加這個部分來了解具體的開發細節。以下我將把會議主要內容羅列一下。
會議內容
sprint計劃會議1
產品負責人和團隊一起，在先前評估的成果基礎上，定出 Sprint 目標和既定產品Backlog。
目標
定出 Sprint 目標和既定產品 Backlog
會議準備
會議進程（4 小時）
會議結果
為Sprint計劃會議2的進行準備好既定產品 Backlog
sprint計劃會議2
在 Sprint 計劃會議 2 中，團隊將既定產品 Backlog 中的每一項細化成多個任務。每個任務完成的時間限定在一天內。
目標
確定所有任務，生成 Sprint Backlog，確認 Sprint 目標
會議準備
會議進程（4 小時）
會議結果
2、Scrum之 站立例會（以下內容摘自周金根博客）
在sprint期間，每天都會通過站立例會來進行溝通，以下我將把會議主要內容羅列一下。（以下會議內容來自于Scrum Checklists)
會議內容
目標
團隊成員間工作進度的溝通和協調
會議準備
會議進程（15 分鐘內）
會議結果
其他
可以指定一個主持人（或輪流）。他來召集并控制會議時間，會議中注意引導話題，在會議結束時可以做個簡短的總結，說出重點就行，做好每日規劃。
3、Scrum之 評審會議（以下內容摘自周金根博客）
在sprint周期最后，需要進行一次評審會議，讓團隊向產品負責人和利益相關者展示已完成的功能。sprint審核的大部分實踐用于團隊成員展示 功能、回答利益相關者對展示的疑問并記錄所期望的更改。評審會議可以吸引相關利益者的關注，讓其他人了解團隊在做些什么，并得到重要反饋。做演示也會迫使 開發團隊真正完成一些工作。
會議進程（4小時）
會議結果
其他
4、Scrum之 回顧會議（以下內容摘自周金根博客）
Scrum中Sprint計劃會議是最重要的事件，第二重要的事件就是回顧會議，因為這是團隊做改進的最佳時機。如果沒有回顧，就會發現團隊在重犯相同的錯誤。在sprint的評審會議后，團隊需要進行一次回顧會議，以下我將把會議主要內容羅列一下。（以下會議內容來自于Scrum Checklists和scrum-and-xp)
會議內容
目標
通過總結以往的實踐經驗來提高團隊生產力。
會議準備
會議進程（1－3小時）
會議結果
記者： 對于未來幾年敏捷開發的發展，您希望看到哪些新方向?有何建議?
周金根：敏捷只是一個代名詞，我希望它不僅僅只包含開發，還能能夠在基于敏捷思想下，把方法框架擴充到市場、業務、營銷環節等軟件產品開發全生命周期。
轉：http://developer.51cto.com/art/201303/387329.htm
推薦：你可能需要的在線電子書
敏捷個人sina微刊：http://kan.weibo.com/kan/3483302195814612
歡迎轉載，轉載請注明：轉載自敏捷個人網站
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
