agile項目管理

本文目錄一覽：

• 1、第3章 敏捷項目管理概述 轉
• 2、敏捷項目管理
• 3、Agile敏捷管理

第3章 敏捷項目管理概述 轉

第3章 敏捷項目管理概述?

3.1? 敏捷項目管理架構 1.敏捷項目管理架構概述 敏捷項目管理架構(Agile Project Management Framework,APMF)，旨在協助團隊聚焦于將項目的商業價值最大化，是基于價值分析和分解的項目管理，也就是價值驅動的項目管理。

第3章 敏捷項目管理概述

3.1? 敏捷項目管理架構

1.敏捷項目管理架構概述

敏捷項目管理架構(Agile Project Management Framework,APMF)，旨在協助團隊聚焦于將項目的商業價值最大化，是基于價值分析和分解的項目管理，也就是價值驅動的項目管理。

2.參與人員

APMF敏捷項目管理過程中，參與人員包括干系人、發起人、產品負責人/客戶代表、敏捷教練、團隊成員和測試員。

3.敏捷項目管理階段

敏捷項目管理可分為5個階段：立項階段、啟動階段、發布循環階段、迭代循環階段、收尾階段。

4.產出

(1).立項階段

1).建立項目愿景，產出“產品盒”。

2).準備商業論證，產出“商業論證”。

(2).啟動階段

1).制定項目章程，產出“敏捷項目章程”。

2).辨識角色，產出“角色卡”。

3).建立產品待辦列表，產出“用戶故事卡”和“產品待辦列表”。

4).進行粗略估算，產出“有粗略估算結果的用戶故事卡”。

5).建立產品地圖/用戶故事地圖，產出“產品地圖”。

(3).發布階段

1).分解用戶故事，產出“已分解的用戶故事”。

2).定義驗收標準，產出“已撰寫驗收標準的用戶故事”。

3).估算用戶故事點數，產出“已估算點數的用戶故事”。

4).發布待辦列表，產出“已排序的產品待辦列表”。

5).刺探，產出刺探的結果。

6).進行迭代循環，產出“增量成果”。

7).發布與回顧，產出“發布增量成果”和“改進行動方案”。

(4).迭代階段：

1).迭代規劃，產出“工作卡”和“已排序的產品待辦列表)”。

2).準備測試用例，產出“驗收測試用例”。

3).開發和測試增量成果，產出“通過驗收測試的增量成果”。

4).每日站立會，產出“用戶故事看板”和“燃盡圖”。

5).迭代審查與回顧，產出“改進行動方案”。

(5).收尾階段

1).交付項目成果，產出“項目成果”。

2).進行項目回顧會議，產出“改進行動方案”。

3).收尾項目活動。

3.2? 敏捷團隊

敏捷團隊是被充分授權且自我組織的跨職能團隊，他們擁有令人贊賞的技能，他們將時間、精力、金錢集中在最有商業價值的部分。

敏捷自組織團隊要做到：

(1).自律。

(2).共同分擔責任。

(3).達成共識的核心價值觀并遵守團隊工作協議。

(4).遵守承諾。

(5).開發過程透明化。

(6).遵從公司標準。

3.3? 敏捷團隊成員

3.3.1? 開發團隊

1.開發團隊的組成

2.開發團隊的工作

(1).確認用戶故事。

(2).羅列待辦列表。

(3).完成增量產品或成果。

3.3.2? 敏捷教練/團隊促進者

1.敏捷教練的責任

(1).改善團隊動態行為。

(2).改善的代言人和影響者。

(3).進行過程裁剪與敏捷實踐裁剪。

(4).促進團隊討論階段目標及相關限制。

(5).促進過程改進順利進行。

(6).協助識別可以使團隊更有生命力的新事物。

(7).使團隊成長并培養出更多的敏捷教練。

(8).對現狀提出挑戰。

2.敏捷教練的目標

(1).協助團隊達成令人驚艷的成果。

(2).協助團隊發展和更健康的在一起。

(3).協助每個人在通往敏捷成功的旅程中，踏出下一步。

3.敏捷教練的工作

(1).以設定共同的愿景和充分授權來領導團隊。

(2).確認大家遵循敏捷價值觀、原則及過程。

(3).以幫團隊擋掉干擾和排除團隊前進的障礙來服務團隊。

(4).促進站立會議、規劃會議及審查與回顧會議的開展。

(5).提供支持，確認項目有明顯的進展，且確保計劃是靈活的。

(6).精髓是幫助團隊成長。

3.3.3? 產品負責人/客戶及發起人

1.產品負責人/客戶的工作

(1).擁有產品待辦列表，也就是項目完成哪些功能。

(2).決定每個發布的日期和內容。

(3).排定優先級，包括項目、發布、迭代及每天的工作計劃。

(4).促進干系人的參與和管理他們的期望。

2.發起人的工作

(1).提供項目目標及財務資源。

(2).對產品負責人提供指導。

(3).要參加發布與迭代審查，以查看團隊是否已交付增量成果。

(4).時刻關注價值和成本。

3.4? 仆人式領導

3.4.1 什么是仆人式領導

敏捷仆人式領導，運用快速迭代等積極的作法，擁抱變化，進行團隊激勵與團隊合作，做出最深度契合用戶需求的產品。仆人式領導者必須從解決問題轉換為提倡授權，幫助團隊成員成長和幫助他們解決實際的問題，不斷進化，逐漸具備自我組織、自主成長、自我修復的敏捷能力，達成迭代目標。

3.4.2? 積極傾聽：仆人式領導的詢問和傾聽

仆人式領導，最需要練習的是積極傾聽，也就是要學習如何問問題和停止解決問題。積極傾聽的有效步驟為：聽、了解、響應。

仆人式領導者要傾聽、要詢問讓團隊思索的問題，只問而不講答案，借由詢問問題，讓團隊學習思考解決問題的方法。這樣能加強團隊建設、找到雙贏解決方案、減少沖突及促進了解。仆人式領導者要引導并授權團隊去反應、思考、發現及讓他們自己做決定。

3.4.3? 開發高情商

EQ是了解與管理我們的情緒、社會互動及人際關系的競爭力，包括自我察覺、自我管理、社會察覺、人際關系管理。

3.5? 組建高效能團隊

1.團隊組建階段

(1).建立期。

(2).風暴期。

(3).規范期。

(4).高效期。

2.管理沖突

(1).很技巧的決定沖突的嚴重性。

(2).小心的決定是否需要介入。

(3).拒絕用逃避的方式來解決問題。

3.促進團隊會議技巧

(1).協作游戲

3.6? 溝通與團隊空間

1.面對面溝通

2.集中辦公

3.團隊空間

(1).信息發射源。

(2).討論環境。

(3).支持工具。

(4).視頻會議。

(5).空間安排。

4.虛擬團隊

3.7? 指導團隊

1.指導技巧

(1).培訓。

(2).教練。

(3).師徒輔導。

2.指導方式

(1).初期進行全隊指導。

(2).中期進行個別指導。

(3).后期進行全隊指導。

3.注意事項

(1).時區的不同。

(2).階層的不同。

(3).更多的文檔。

(4).文化的差異。

敏捷項目管理

在敏捷項目管理角色方面，大多數敏捷流程 - 特別是Scrum - 不包括項目經理。敏捷的“項目經理”角色和職責在項目中共享，即團隊，Scrum Master和產品所有者。

在敏捷開發，Scrum的擁有最談談 什么 ? 是 敏捷項目管理。因此，讓我們使用Scrum作為回答這個問題的模型。在Scrum項目中，有三個角色：產品所有者，Scrum Master和團隊。

產品所有者負責項目的業務方面，包括確保正確的產品構建和正確的順序。優秀的產品所有者可以平衡競爭優先級，可供團隊使用，并有權對產品做出決策。

Scrum Master擔任團隊的教練，幫助團隊成員以最有效的方式一起工作。一個優秀的Scrum Master將該角色視為向團隊提供服務，消除進度障礙，促進會議和討論以及執行典型項目管理職責（如跟蹤進度和問題）的角色。

在確定如何最好地實現產品目標時（由產品所有者建立），團隊自身承擔敏捷的項目管理角色。團隊成員將協作決定哪個人應該處理哪些任務，哪些技術實踐是實現既定質量目標所必需的，等等。

那么，關于這個過程的“敏捷”是什么？敏捷項目管理將責任分配給多個團隊成員。就Scrum而言，它是項目的產品所有者ScrumMaster和團隊的其他成員。

在敏捷項目管理中，世界可能會將Scrum Master視為項目經理的21世紀版本。但與傳統的項目經理不同，Scrum Master并不被視為對項目成功（或失敗）的信任（或責備）。

Scrum Master的權限僅限于該過程。Scrum Master是該流程的專家，并使用它來讓團隊達到最高水平。但是，Scrum Master并不具備項目經理所承擔的許多傳統職責 - 范圍，成本，人員，風險管理。

誰負責敏捷開發中的傳統項目經理職責？

傳統的項目經理通常承擔很大的責任。他們負責管理范圍，成本，質量，人員，溝通，風險，采購等。

敏捷項目管理經常使傳統的項目經理陷入困境。例如，他或她被告知做出范圍/進度權衡決策，知道如果項目進展不順，產品經理或客戶可能會猜測這些決策。

敏捷承認這一困難，并分配傳統項目經理的職責。這種新模式的敏捷之處在于，許多這些職責，例如任務分配和日常項目決策，都會回歸到他們理所當然的團隊。

范圍和進度權衡的責任歸產品所有者所有。質量管理成為團隊，產品所有者和Scrum Master共同承擔的責任。其他傳統任務也在團隊的敏捷項目管理角色中分發。

像Scrum這樣的敏捷流程絕對可以擴展。雖然典型的敏捷項目在一到三個團隊中有五到二十人，但敏捷實施在200到500甚至1,000人的項目上取得了成功。

正如您所料，這種規模的項目必須引入更多的協調點和敏捷的項目管理，而不是小規模的實施。

為了協調許多團隊的工作，較大的項目有時會包含一個名為“項目經理”的角色。雖然在項目中涉及此項目或背景的人員非常有幫助，但我們需要注意與項目經理職稱相關的行李。 。

即使是在一個非常大的敏捷項目中，團隊仍然會做很多項目管理。例如，團隊決定如何分配任務，而不是項目經理;?所以項目經理角色變得更像項目協調員。

職責包括分配和跟蹤預算;?與外部利益相關者，承包商和其他人溝通?在團隊，Scrum Masters和產品所有者的指導下維持風險普查;?等等。這是一個真正的敏捷項目管理角色。

項目經理 vs Scrum Master vs 項目負責人

For new contacts with Agile, project managers and scrum protagonists may look similar or even the same. But it is important to recognize the differences between the two, the possible overlap of certain tasks, and how they complement each other in large projects. ( 對于剛接觸Agile的人來說，項目經理和scrum主角可能看起來相似甚至相同。但重要的是要認識到兩者之間的差異，認識到某些任務可能重疊的地方，并認識到它們在大型項目中如何相互補充。)

Scrum: 什么是豬和雞的角色？

Roles are key in Agile: The business fable of The Chicken and the Pig explains breakfast: pigs and chickens in the Scrum process. It’s a way to differentiate between roles in the Scrum/Agile world. (角色是敏捷的關鍵：雞和豬的商業寓言解釋了早餐：在Scrum過程中的豬和雞。這是一種區分Scrum/Agile世界中角色的方法。)

敏捷開發：如何成為合格的Scrum Master？

Scrum Master is considered to be a project manager in many projects, which is actually a misunderstanding. At the same time, I often see people who argue that Scrum Master is completely different from project managers. So what is Scrum Master’s responsibility? What can we do to become a qualified Scrum Master? ( Scrum Master被認為是許多項目開發中的項目經理，這實際上是一種誤解。與此同時，我經常看到那些主張Scrum Master和項目經理完全區別的人。那么Scrum Master的責任是什么？我們可以做些什么來成為一名合格的Scrum Master？)

如何成為Scrum項目的優秀產品負責人？

Without a good product owner, the Scrum project will not succeed. It must be decisive, not only by referring to the required responsibilities, but also by embedding the following thinking patterns: 1) To continuously protect the best interests of customers in terms of functions provided. 2) Protect the organization as a whole in terms of strategic direction and return on investment. (如果沒有一個好的產品所有者，Scrum項目就不會成功，他必須具有決定性，不僅要求提到所要求的責任，而且還要嵌入以下思維模式：1) 在提供的功能方面不斷保護客戶的最佳利益，2) 在戰略方向和投資回報率方面保護整個組織。)

什么是產品負責人在Scrum中的角色？

Role and Responsibilities - The product owner who represents the company’s ownership of the product is a member of the Scrum team. However, the product owner has no authority over other members of the team, as is the case with Scrum Master. The product owner is responsible for the long-term care of the product and the success of the product. (代表公司擁有產品的產品負責人是Scrum團隊的一員。但是，產品所有者對團隊中的其他成員沒有權限，與Scrum Master相同。產品負責人負責長期照顧產品，并負責實現產品成功。)

Scrum團隊如何運作？ – 簡要指南

Scrum in a Nutshell: Scrum relies on which are periods of time when software development is actually done. A Sprint usually lasts from one week to one month to complete an item from the backlog. The goal of each Sprint is to create a potential shippable product. (Scrum依賴于軟件開發實際完成的時間段。沖刺通常持續一周到一個月，以完成積壓的項目。每個沖刺的目標都是創建一個潛在的可交付產品。)

如何成為Scrum項目的優秀產品負責人？

A product owner is the guardian of the product vision and goals, because it focuses on delivering business results and values for Scrum projects. So the question is how to be the best product owner? Based on our experience, we believe that the product owner should possess some key qualities. (產品所有者是產品遠景和目標的守護者，因為它專注于為Scrum項目提供業務結果和價值。所以問題是如何成為最好的產品擁有者？根據我們的經驗，我們認為產品所有者應該具備一些關鍵的品質。)

什麼是Scrum的自組織團隊？

A self-organizing team is a team that has the autonomy to choose how best to do its work, rather than being guided by others outside the team. ( 自組織團隊是一個團隊，擁有自主選擇如何最好地完成工作，而不是由團隊外的其他人指導。)

Scrum團隊是什麼？

The Scrum team shares different tasks and responsibilities related to product delivery. Every role is closely related. It is recommended that Scrum team members work together in the same place as possible. Let’s look at these roles from the perspective of responsibility, authority and characteristics. (Scrum團隊分享與產品交付相關的不同任務和職責。每個角色都密切相關。建議Scrum團隊成員盡可能在同一位置一起工作。讓我們從責任，權限和特徵的角度來看看這些角色。)

Scrum中最經常提到的10個基本規則

The main goal of Scrum rules is to optimize the development process and minimize waste of time. Scrum Master is responsible for ensuring that everyone follows Scrum project-related rules. These rules combine Scrum processes so that everyone knows how to play. (Scrum規則的主要目標是優化開發過程并最大限度地減少浪費的時間。在Scrum Master的是負責確保每個人都遵循的Scrum與項目相關的規則。這些規則將Scrum流程結合在一起，以便每個人都知道如何玩。)

Agile敏捷管理

目錄：

一、什么是Agile

二、什么樣的團隊適合Agile

三、敏捷開發的實施步驟（SCRUM）

四、Agile敏捷管理的具體實施

五、敏捷工作坊的體驗

六、結語

七、附：SCRUM在教育和政府領域的應用

從本質上講，敏捷（Agile）并不是開發方法，而是一種理念。對于項目管理而言，敏捷是一個全新的術語，敏捷強調在軟件研發過程中持續性的根據用戶反饋和需求優先級來發布新版本，不斷進行迭代，讓產品逐漸完善。

在數十年前，瀑布式項目管理是軟件研發的主流方法，在研發過程中，團隊成員將會花大把的時間和精力在項目前期去收集資源和信息，然后基于這些去做產品設想和研發規劃。

到了70年代，有先覺的研發人員發現瀑布式研發不僅在執行中各處受限，研發速度還很慢，顯然Out了。尤其到了90年代末期，開始出現黑客來搗亂，這就意味著前功盡棄、全部推倒重來，這簡直是研發的噩夢。

相比瀑布基于線性、可預測性地去開發產品，研發人員更想要能夠靈活管理用戶反饋、Bug和需求的方法。這也就是敏捷方法出來以后受歡迎的原因。

另外，你也可以通過這個視頻學習 什么是敏捷（Agile）

在2001年，17位研發人員共同探討出了《敏捷宣言》這份文檔，闡述了他們對于軟件研發的看法。文中他們定義了敏捷開發需要遵守的四項價值觀。

總結為：

盡管如此，這四項價值觀并不意味著我們就該放棄工具、文檔和計劃。因為它們對研發結果依然有非常重要的價值，只是相比之下，我們應該關注更核心的事物：人、產品模型、協作和迭代。為了讓這四項原則變得簡單易懂好執行，他們又將寫了 敏捷開發12項原則 作為指導：

如果我們把這些原則和遇到的問題對號入座，很快我們就會發現，這12項原則正是對應了客戶期望。比如，客戶不會關心開發文檔寫的怎么樣，他們更感興趣交付的成品能干什么；他們不在意你的開發計劃，他們希望你能立馬交付；昨天他們想要修個BUG，而不是等到下次版本更新。

我們總會遇到需求多樣化的客戶，而這時，敏捷能夠確保你在研發過程中始終將用戶需求作為核心。

敏捷雖然聽起來光鮮亮麗，但不是所有項目都能用敏捷來做。

敏捷在公司里投入使用后可能與預想的結果背道而馳。敏捷意味著快速推進項目，也就是說并不是所有事情都是按部就班。因此，我們得知道在這種快速變化的環境下，團隊是否能夠適應變化。

所以在部署使用敏捷前，需要團隊先明確幾個問題：

1.你是否會愿意接手目標不明確的項目？

敏捷項目管理中有句話叫做：快速失敗。比如我們接手了一個連最終產出都不明確的項目，首先我們會先交付最小模型產品，這時我們得做好被質疑的準備。畢竟沒人知道要做出怎么樣的產品，所以我們的最小模型的產品很可能是個怪胎。在與客戶反復測試后，我們才會逐步了解他們的真實需求，這時候我們離成功又近了一步。

2.你會如何規避項目風險？

就像我們前面提到的，敏捷提倡不斷從犯錯中積累學習并持續迭代。如果我們走老路，用傳統項目管理的方法來推進的話，我們會要承擔更大的風險。當然就算我們開始敏捷之后，也要準備好隨時響應未知問題。

3.你的團隊能有多靈活？

作為項目經理，我們的責任是和客戶一起把產品做的更好。這么做很可能和設計、研發、其他成員的想法背道而馳。這時我們需要找主心骨聊一聊，是否愿意放下老套路，根據用戶需求來調整想法、重新規劃方向。

4.公司階層制度嚴格嗎？

敏捷的其中一項原則不僅是和用戶一起工作，研發成員的身份也會發生變化。你們公司的文化開放嗎？是否能接受扁平和開放的管理方法？

5.你怎么衡量進度？怎么定義成功？

用敏捷來管理項目能夠幫我們逐漸進步的同時也督促我們將產品做得更好。如果因為突發靈感而放棄正在執行的任務，那么敏捷將毫無意義。我們先花些時間來看看團隊是怎么看待進步和成功。然后再來看我們是不是離最終目標一步步的更近了？

在Scrum中，產品經理和項目團隊緊密協作，一起定義目標、梳理產品需求清單。清單中通常會包含產品特性、修復bug、非必要功能需求以及其他要在交付時完成的工作。

有了產品清單，產品經理就會開始確定需求優先級，研發團隊通常會在接下來30天左右的迭代中產出“潛在可交付版本”。當研發團隊制定了迭代清單后，除了團隊成員外，任何人都不能再加入需求。當一輪迭代完成后，全員再次分析需求清單、劃分需求優先級，然后進入下一輪迭代。

1.三個角色

2.三種可視化文檔

另外，用戶故事要注意必須完整，遵循INVEST標準：

Independent——讓一個用戶故事獨立于其他用戶故事

Negotiable——可協商性，協商更多細節

Valuable——必須對客戶具有價值

Estimable——開發團隊需要衡量用戶故事，以便確定優先級和工作量，并便于安排工作計劃

Small——規模小，至少要確保在一個沖刺周期中能完成、

Teatable——可測試，便于確定它是可以完成的

3.三種不同形式的會議

1、確定敏捷開發中的3個角色：Product Owner, Scrum Master, Scrum Team。

2、擬定待辦事項清單，并確定優先級

3、改進和評估待辦事項清單：

·要完成這些事項，現有信息足夠嗎？

·是否細分到了可以評估的程度？

·是否成員都能接受，用于評定一個事項已完成的標準？

·用相對難度去評估，利用斐波那契數列的數字

4、沖刺規劃會：Product Owner, Scrum Master, Scrum Team一起規劃沖刺的內容，記錄每個沖刺完成事項的點數

5、將工作透明化：利用白板和燃盡圖更新進度

6、每日站會

7、沖刺評估和沖刺展示：將成果展現給產品負責人看，哪些事項可以移到“完成事項”一欄，并接受評價。

8、沖刺回顧會

9、上一個沖刺階段結束之后，立刻開始新的沖刺階段

在沖刺階段結束之際，把所有已完成的用戶故事列出來，將各項難度評分加在一起，最終的數字就告訴我們團隊的進度是多少。然后再看未完成用戶故事的難度分值總和，就可以知道什么時候可以完成項目。

速度 X 時間 =交付工作量

敏捷非常注重節奏，當你有多個任務要交付，團隊更需要注重節奏的把握。而身為項目經理，我們的職責是讓整個團隊通過協作最終交付產品。

敏捷是不斷規劃、執行、學習和迭代的過程，敏捷項目通常可以分解為一下7步：

第1步：通過戰略會議定義你的愿景

每當開始新項目時，第一件要做的事情是定義產品的業務需求，或者說想要達到的愿景。事實上，我們只需要回答一個問題：你為什么想要做這個產品。這是我們心中的藍圖，時時提醒我們不要跑偏。

作為一家產品公司，定義愿景的最佳方法之一是電梯演講：

用于：（哪部分目標客戶）

需求：（用戶的需求）

類別：（我的產品是哪種類型）

功能：（產品的價值、客戶為什么選我們）

競品：（主要的競爭對手有哪些）

差異化：（和競品的差異化描述）

即使我們做的不是軟件產品，我們也可以根據項目的目標來調整上述內容。

戰略會議的參與角色都有誰？

此時我們要讓更多人認同這個項目，所以很多關鍵的利益相關者自然不能缺席，包括相關主管、經理、主任和產品經理。

戰略會議該什么時候召開？

項目開始前我們就該來開戰略會，或者至少每年一次的定期會議來保證愿景依然不過時

戰略會議要召開多久？

這個就由你主觀來決定了，一般來講，花4-16小時來探討戰略已經足夠了。

第2步：繪制產品路線圖

當我們開完戰略會后，就該輪到產品經理把愿景變成產品路線圖。產品路線圖能幫助我們縱觀全局、理清思路，讓我們有寬松的時間來開發每個產品需求。“寬松”并不是說我們可以花數天或是數周的時間來推進每步計劃，而是輕量級的去定義產品、理清需求優先級和粗略估算產品每個需求的時間。

項目管理專家Roman Pichler認為：目標導向的產品線路圖能夠聚焦于目標和產出結果（比如：獲客、增加活躍度、滿足客戶需求）。而產品特性來自于這些目標，所以我們在制定目標時應謹慎，每個目標對應3-5個產品特征。

而每個目標，我們需要包含5個關鍵信息：時間、名稱、目標、產品特征和衡量標準，有了這些，我們就能清楚知道哪些該做、什么時候算做成功了以及我們如何取得了成功。

產品路線圖由產品負責人畫，同時聽取利益相關者的想法，如客戶、市場、研發代表等，并最好在戰略會議結束后著手畫產品路線圖。

第3步：制定發布計劃

當我們有了戰略和計劃，下一步我們就可以暫定幾個時間節點。

這個階段產品經理要嚴格按照計劃發布新版本。我們也不用擔心功能不齊全的問題，敏捷項目都會有多次發布的過程，所以我們只要優先發布核心功能的版本即可。

舉例來說，你的項目要在11月交付，而你可能在2月初就已經做好了最小模型，打算在5月左右發布完整版。這些時間節點的安排都將由你的項目難度和每次迭代時長（或者說每次達成目標需要的工作時長）決定。通常每次發布新版本都需要經歷3-5次迭代。

誰來制定發布計劃？

產品經理、項目經理和所有團隊成員都該來參與其中。當然，邀請少數利益相關者來加入其中也是對其他成員的鼓勵，讓團隊能夠盡早開始。

發布計劃什么時候來做？

越早越好，你的發布計劃應該在確認新產品后的第一天開始制定。在隨后的每個季度中至少記錄一次。

制定發布計劃要多久？

一般來說會需要4-8小時，實際時長由具體情況決定，但不能因為它拖進度。

第4步：制定迭代（Sprint）計劃

迭代（Sprints），我將其理解為通過短期研發完成具體任務來達到目標的一個過程，也是幫助產品經理和研發團隊逐漸切入項目細節的方法。

通常情況下，每次迭代大約要花費1-4周。具體的時長我們需要根據團隊過往的表現情況來制定，同時盡量保持每次迭代的時長相同。

哪些角色參與制定迭代計劃？

迭代是整個團隊的活，因此，產品經理、項目經理以及其他所有成員都該積極參與其中，表達自己的聲音和想法。

迭代計劃什么時候來制定？

在每次迭代周期開始前，我們就需要做好迭代計劃。比如說，你的計劃是每周迭代，那么就你就需要在每周一（或者你選好的某一天）告訴其他人迭代計劃。

制定迭代計劃要多久？

迭代計劃是迭代周期的基石，雖然如此，我們也不要在這上面浪費過多的時間，通常2-4小時足夠了。寫好了迭代計劃也就意味著我們已經踏上了正軌。

第5步：每日站會

在每次迭代過程中我們需要有時間來確認項目組沒有遇到阻礙，同時保證能準時完成既定目標。這時候我們就需要使用每日站會。

每日站會，如同字面意思一樣通俗易懂，每天花15分鐘左右的時間來討論下面3件事：

昨天我完成了哪些事情

今天我打算做哪些事情

我有遇到哪些問題，如何解決

或許討論這3件事，可能讓團隊的一部分人的臉掛不住。但這對推動敏捷項目管理的溝通有積極意義。敏捷之所以能夠跨團隊協作，主要依靠的就是團隊快速響應和有讓成員發聲表達的空間。

第6步：迭代（Sprint）結束了？那就進入評審階段吧

如果迭代中一切順利，那么迭代周期結束后，我們需要來檢測下軟件的功能。我們可以借評審的機會來向團隊成員和利益相關者展示成果。

作為產品經理，你對產品功能有選擇的權利。如果有哪步錯誤，嘗試多問幾個為什么？下次迭代時我該怎么調整才能讓團隊達成目標？敏捷是不斷學習和迭代的過程，你的流程管控和最終產出也是同一道理。

哪些角色參與評審？

團隊全員和利益相關者都應該參加迭代評審會來確認項目進度和表達他們的觀點。

什么時候執行評審？

每次迭代結束后就可以開始。

評審階段要多長久？

無需特意去準備PPT、功能說明，審查會最多1-2小時就夠了。

第7步：迭代（Sprint）回顧總結

為了讓敏捷項目管理能順利運作，我們在每個階段結束后需要知道下一步要做什么。這是我們在迭代回顧階段要做的事。當迭代和審查結束后，接下來該去決定下次要做哪些工作。我們需要回顧下，在迭代中是否發生了些事情改變了你的既定時間，甚至是項目愿景。

誰來參加回顧總結會議？

回顧總結是審查的延伸，這時利益相關者離開也沒有關系，而其他團隊成員則加入其中，給出自己的意見。

什么時候來做？

當然最好是在審查階段結束后，立刻開始迭代回顧總結。

這會花多長時間來做？

概括下來大概幾個詞：簡短明了、甜蜜溫馨，最多花1-2小時來總結和大致規劃下次計劃。

工作坊的體驗主要是讓學員大概體會一下運用敏捷的方式開發項目的流程，并通過一些敏捷工具深化在敏捷開發過程中的運用。

1、制作自行車項目

（1）分組并確定團隊內敏捷3個角色

（2）定沖刺周期（每10min1個sprint，3個sprint）

（3）在沖刺開始前，給每個組15分鐘開戰略規劃會，此期間驗收人對自行車提出需求，要滿足什么樣的功能，團隊開戰略會列出任務清單。

（4）每個sprint結束后給每個組7分鐘開站會

（5）每個組的SCRUM Master更新看板和燃盡圖

（6）進行項目驗收，對成果進行點評

（7）結束后小組內進行總結回顧會

2、樂高堆房子項目

（1）分組并確定團隊內敏捷3個角色

（2）定沖刺周期（每15min1個sprint，4個sprint）

（3）在沖刺開始前，給每個組15分鐘開戰略規劃會，此期間驗收人對自行車提出需求，要滿足什么樣的功能，團隊開戰略會列出任務清單。

（4）每個sprint結束后給每個組10分鐘開站會

（5）SCRUM Master更新看板和燃盡圖

（6）在第三個Sprint開始時，要求團隊內交換2名成員到其他組完成自己組的任務，期間不得交流，只能依據看板進行

（7）進行項目驗收，對成果進行點評

（8）結束后小組內進行總結回顧會

七、SCRUM的應用

1、SCRUM與教育

教師首先讓學生對自己的性格做評價，將自己劃分為不同類別，分為”勇敢類“，“喜歡數學類”，”關心他人感受類“，”勇往直前實現目標類“，將不同類型的學生組合在一起，形成多功能小組。教師擬好所有待學事項，讓各小組的學生每天將“所有事項”移到“待辦事項”中，然后開始動手，打開教材，自己學習，組內互教互學。教師從“完成事項”一欄隨機挑出一些事項問組內成員，以確定每個人都理解相關概念，只有當每個人都理解了之后，才符合所說的”完成的定義“，一切交給學生來做決定。

2、SCRUM與政府

制定政策：每周都去改變一件事情，采用增量方法，每周都會展示一種可交付的產品，每個機構都會切實感受到成果的存在。

書籍建議：

《敏捷革命：提升個人創造力與企業效率的全新協作模式》

SCRUM的一些工具：

Leangoo（領歌）——基于看板的可視化協作

Confluence——Jira

國外有Redmine，Axosoft，國內有禪道，一些自研工具（百度Icafe，阿里Aone，騰訊Tapd)

勞倫斯在《七根智慧之柱》中寫道：所有人都做夢，但是卻不盡相同，那些夜里在蒙灰的心靈角落做夢的人，早上醒來往往發現是空洞虛無的。而那些白日做夢的人，則是最危險的，因為他們會在睜著眼睛做夢的時候，把夢想變成現實。

看了這么多，不如試一試吧！此文由個人整理而來，主要來源于個人在敏捷團隊時敏捷開發的邏輯和思考，以及明道云博客和敏捷相關書籍、英文文檔翻譯等。如有疑問或補充，歡迎評論下方交流~