這個人必須知道帶領的團隊需要做什麼、製造什麼產品以及取得什麼成果，必須會面考慮到風險與回報、什麼具有可行性、什麼能做以及他們對什麼富有熱情。
真正做事的是誰？這個團隊必須能夠落實產品負責人的願景。團隊規模宜小不宜大，一般3~9人較為合適。
主管為scrum過程負責，負責培訓團隊其他成員，確保scrum得到正確運用，幫助團隊消除一切障礙。
這個清單高屋建瓴地列出為了落實產品負責人的願景而需要完成的所有事項。在產品的整個研發過程中，這個清單一直在，並有所演變，相當於產品研發的「路線圖」。無論在任何時間，要想知道乙個團隊要做的所有事項（按照優先順序排列），待辦事項清單都是唯一具有決定性的參考依據。待辦事項清單只有乙份，意味著產品負責人從頭到尾必須不斷地對優先順序加以調整。產品負責人應該與所有利益相關者和團隊進行協商，以確保產品待辦事項清單既能反映使用者的需求，又不會超出團隊的能力範圍。
讓負責實際開發工作的團隊對待辦事項做出評估，是乙個至關重要的環節。團隊應該審視每個事項，看看是否切實可行。但要完成這些事項，現有的資訊足夠嗎？該專案是否細分到了可以評估的程度？團隊是否具有了每個成員都能接受、用於評定乙個事項已完成的標準？乙個事項能否帶來顯著的價值？各個事項在完成後必須產生能夠用來展示的成果，如果這個成果能交付給客戶試用會更好。不要用所需小時數去去評估，因為人們根本不擅長做出這麼精確的評估。要用相對難度去評估，比如，難度是小、中、大。更好的採用斐波那契數列的數字（1、2、3、5、8、13.。。。）
這個第一場scrum會議。團隊成員、scrum主管以及產品負責人坐到一起，規劃衝刺的內容。衝刺週期一般是固定的，不超過乙個月，大部分是一至兩周。團隊要從待辦事項清單的頂端著手，看看乙個衝刺階段中能完成多少。如果團隊已經開展過好幾個衝刺，那就記錄下每個衝刺階段中提高這個數字。這個數字相當於團隊的速度。scrum主管與團隊成員應努力在每個衝刺階段中提高這個數字，團隊成員和產品負責人也可以借助「點數」確保每個人都能了解待辦事項對於落實最終願望的作用。對於衝刺目標，即在這一衝刺階段完成哪些事項，所有人都應該形成共識。
scrum的基石之一在於，產品負責人告訴開發團隊他需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次衝刺中他們能夠承諾完成多少訂單項。在衝刺的過程中，沒有人能夠變更衝刺內容。團隊必須在衝刺階段自主工作。
在scrum中，最常見的做法是準備一塊白板，上面分成三欄：待辦事項、在辦事項、完成事項。把待辦事項寫在便箋上，隨著進度的推進，將相應的便箋紙轉移到其他欄目。
讓工作透明化的另乙個工具是燃盡圖。在這張圖中，乙個軸代表工作量，另乙個軸代表時間。每天，scrum主管都會記錄待完成的剩餘點數，而後畫在燃盡圖上。
這是scrum的活力源泉。團隊每天在固定時間進行內部溝通，時間一般不超過15分鐘，且站立進行，scrum主管向團隊成員提出下列問題：
你昨天做了什麼去幫助團隊完成衝刺？
今天你打算做什麼來幫助團隊完成衝刺？
什麼因素阻礙了團隊的前進之路？
scrum主管要問的問題就是那麼多！整個會議的內容就是這麼多！如果會議時間超過15分鐘，那就說明開會的方法存在問題。這樣做的意義在於讓整個團隊清楚地知道在這乙個衝刺週期內各項任務的進展。所有任務都能按時完成嗎？有沒有機會幫助其他團隊成員克服障礙？團隊的任務都不是自上而下分派的，而是自主決定的、自主完成的，也不需要向上司做詳細的匯報。
scrum主管負責消除團隊面對的障礙。
在衝刺結束前，給產品負責人展示成果，也就是展示哪些事項可以挪到完成事項那一欄，並接受評價。這是一場公開的會議，任何人都可以是參與都，不僅僅包括產品負責人、scrum主管及開發團隊，還包括利益相關者、管理人員與客戶。
團隊應該只展示那些符合完成定義的事項，也就是全部完成，不需要再做工作就能交付的成果。這個成果或許不是完成的產品。但至少是一項完整的、可以使用的功能。
團隊展示之前衝刺中創造的成果，也就是展示已完成的事項，看看可以為顧客傳遞哪些價值，並徵求反饋意見，大家就會坐下來想想哪些事執行得很順利，哪些事應該做得更好，以及在下乙個衝刺階段中可以做出什麼改善。那麼，如何發現流程中的哪個環節需要改善？
要讓這個衝刺回顧過程有效，團隊需要相互信任。必須記住關鍵的一點，即大家不要團隊中找乙個人當成責備的物件，而是要將注意力集中在流程上，認真分析以下幾個問題：為什麼會發生那件事？為什麼我們當時忽略了？怎樣才能加快工作進度？作為乙個團隊，大家要對自己的流程和結果負責，要集思廣益，共同尋求問題解決之道。
與此同時，團隊必須有勇氣把真正的障礙檯面上來，這樣做是為了解決問題，而不是為了指責某個成員。團隊成員必須能認真**問題，並虛心接受他人反饋的意見和建議，以便尋求問題解決之道，而非只想為自己辯解。
然後進行關鍵環節。團隊確定乙個最值得改善的地方，將其設定為下乙個衝刺階段的首要任務，當然，改善的結果必須通過驗收測試。你如何證明自己成功地完成了改善？你需要用具體的、可操作的方式界定什麼是成功，這樣，在下乙個衝刺回顧會議中才能很快判斷出是否完成改善。
利用在之前的衝刺過程中，團隊在消除障礙、改善流程方面積累的經驗。
如何實施敏捷開發
如果嚴格按照書本上的 scrum 法則一條條地看，那麼我們隊伍現在的做法也許根本不算 scrum。不過好歹我們也被稱作 scrum 一段時間了，我的資歷比不上前面的資深開發者，只能說一些目前的一點經驗。經驗一 整個團隊必須理解 scrum 的目的和限制。如果管理團隊把 scrum 當作一種新的管理流...
敏捷開發實施流程
敏捷開發實施流程 迭代週期 2 3周 一 需求過程 1 2天 與產品經理，產品使用人員溝通產品功能與新需求 程式經理完成需求整理與確認 程式經理 開發經理 測試經理完成需求溝通 要求 二 開發過程 3 5天 開發經理確定開發任務點，並分配任務 開發人員完成開發 確保每日構建，並交付測試人員進行迭代測...
遊戲開發中敏捷實施
兩個程式設計師的 msn log a 說 2008 09 17 11 23 20 對了，問個咚咚，你們那邊是用scrum 麼？b 說 2008 09 17 11 23 26 對 a 說 2008 09 17 11 26 36 你們也是每天morning meeting 羅？a 說 2008 09 1...