初學者簡易Scrum教程

Agile是一種軟件開發方法，可使用1至4周的短迭代逐步構建軟件，以便開發過程與不斷變化的業務需求保持一致。而不是預先預測全部要求和風險的6到18個月的單程開發，敏捷採用頻繁反饋的過程，其中在1到4周的迭代後交付可行的產品。

敏捷中的角色

Scrum Master

Scrum Master是團隊領導者和推進者，幫助團隊成員遵循敏捷實踐，以便他們可以履行承諾。Scrum master的職責以下 -

• 實現全部角色和功能之間的緊密合做。
• 刪除任何塊。
• 保護團隊免受任何干擾。
• 與組織合做以跟蹤公司的進度和流程。

• 確保Agile Inspect＆Adapt流程獲得適當利用，包括

  • 每日站立，
  • 計劃會議，
  • 演示，
  • 評論，
  • 回顧會議，和
  • 促進團隊會議和決策過程。

產品擁有者

產品負責人是從業務角度推進產品的人。職責或產品負責人以下 -

• 定義需求並肯定其值的優先級。
• 肯定發佈日期和內容。
• 在迭代計劃和發佈計劃會議中發揮積極做用。
• 確保團隊致力於最有價值的要求。
• 表明客戶的聲音。
• 接受符合完成和已定義驗收標準定義的用戶故事。

跨職能團隊

每一個敏捷團隊都應該是一個自給自足的團隊，擁有5到9名團隊成員，平均經驗爲6到10年。一般，敏捷團隊由3到4名開發人員，1名測試人員，1名技術主管，1名產品全部者和1名Scrum主人組成。

產品負責人和Scrum master被認爲是Team Interface的一部分，而其餘成員則是Technical Interface的一部分。

敏捷團隊如何規劃其工做？

敏捷團隊在迭代中工做，以提供每次迭代爲10到15天的用戶故事。每一個用戶故事都是根據其積壓優先級和大小來規劃的。團隊使用其能力 - 團隊可使用多少小時來完成任務 - 來決定他們計劃的範圍。

Story Point 點

Point定義了團隊能夠提交多少。一點一般指8小時。每一個故事都以分數估算。

容量

容量定義了我的能夠提交多少。容量估計爲小時。

什麼是用戶故事？

用戶故事是定義用戶須要什麼做爲功能的要求。用戶故事能夠有兩種形式 -

• 做爲<用戶角色>我想要<功能>以便<業務價值>
• 爲了<業務價值>做爲<用戶角色>我想要<功能>

在發佈計劃期間，使用相對比例做爲點對用戶故事進行粗略估計。在迭代計劃期間，故事被分解爲任務。

用戶故事與任務的關係

• 用戶故事講述了要作什麼。它定義了用戶須要的內容。
• 任務談論如何完成。它定義瞭如何實現功能。
• 故事由任務實現。每一個故事都是一系列任務。
• 用戶故事在當前迭代中計劃時分爲任務。
• 任務以小時計算，一般爲2至12小時。
• 使用驗收測試驗證故事。

當一個故事完成

團隊決定作什麼意味着什麼。標準多是 -

• 全部任務（開發，測試）都已完成。
• 全部驗收測試都在運行並經過。
• 沒有缺陷是開放的。
• 產品全部者已經接受了這個故事
• 可交付給最終用戶。

什麼是驗收標準？

Criteria定義功能所需的功能，行爲和性能，以便產品全部者能夠接受。它定義了要作什麼，以便開發人員知道用戶故事什麼時候完成。

如何定義需求？

要求定義爲

• 用戶故事，
• 有了驗收標準，和
• 實現故事的任務。

敏捷 - 宣言

2001年2月，在猶他州的Snowbird度假村，17位軟件開發人員開會討論輕量級開發方法。他們會議的結果是如下用於軟件開發的敏捷宣言 -

咱們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此咱們創建了以下價值觀： -

• 個體和互動 高於 流程和工具
• 工做的軟件 高於 詳盡的文檔
• 客戶合做 高於 合同談判
• 響應變化 高於 遵循計劃

也就是說，儘管右項有其價值，咱們更重視左項的價值。

敏捷宣言的十二項原則

• 客戶滿意度 - 經過早期和持續交付有價值的軟件，最高優先級知足客戶的要求。
• 歡迎變革 - 軟件開發過程當中不可避免的變化。即便在開發階段的後期，也應該歡迎不斷變化的要求。敏捷流程應該有助於提升客戶的競爭優點。
• 提供可運行的軟件 - 考慮到更短的時間尺度，常常提供一個工做軟件，範圍從幾周到幾個月不等。
• 協做 - 業務人員和開發人員必須在項目的整個生命週期中協同工做。
• 動機 - 項目應圍繞有動力的我的創建。提供一個支持我的團隊成員並信任他們的環境，使他們對完成工做感到負責。
• 面對面交談 - 面對面交談是向開發團隊內部和內部傳達信息的最有效和最有效的方法。
• 根據工做軟件衡量進度 - 工做軟件是關鍵，它應該是進步的主要衡量標準。
• 保持不變的步伐 - 敏捷流程旨在實現可持續發展。業務，開發人員和用戶應該可以與項目保持一致的步伐。
• 監控 - 按期關注技術卓越和良好的設計，以提升靈活性。
• 簡單 - 保持簡單，並使用簡單的術語來衡量未完成的工做。
• 自組織團隊 - 敏捷團隊應該是自我組織的，不該該嚴重依賴其餘團隊，由於最好的架構，要求和設計來自自組織團隊。
• 按期審查工做 - 按期審查工做，以便團隊能夠反思如何提升效率並相應地調整其行爲。

敏捷 - 特徵

迭代/增量和準備進化

大多數敏捷開發方法都將問題分解爲較小的任務。任何要求都沒有直接的長期規劃。一般，計劃的迭代具備變化的短期段，例如1至4周。爲每一個迭代建立一個跨職能團隊，該團隊適用於軟件開發的全部功能，如規劃，需求分析，設計，編碼，單元測試和驗收測試。迭代結束時的結果是一個工做產品，它在迭代結束時向利益相關者展現。

演示以後，將審覈評論並計劃根據須要合併到工做軟件中。

面對面交流

每一個敏捷團隊都應該有一個客戶表明，例如scrum方法中的產品全部者。該表明被受權表明利益相關者行事，他能夠在迭代之間回答開發人員的查詢。

信息輻射器（物理顯示器）一般位於辦公室的顯眼位置，路人能夠看到敏捷團隊的進度。此信息散熱器顯示項目狀態的最新摘要。

反饋迴路

每日站立是任何敏捷開發的共同文化; 它也被稱爲每日Scrum。這是一種簡短的會話，每一個團隊成員互相報告他們所作的事情，下一步該作什麼以及他們面臨的任何問題。

敏捷 - 每日站立

顧名思義，每日站立是敏捷團隊全部成員之間的每日狀態會議。它不只提供按期更新的論壇，並且還將團隊成員的問題集中在一塊兒，以便快速解決。不管辦公地點如何，不管如何創建敏捷團隊，每日站立都是必須的作法。

什麼是每日站立？

• 每日站立是全部團隊成員之間的每日狀態會議，大約持續15分鐘。

• 每一個成員都必須回答三個重要問題 -

  • 我昨天作了什麼？
  • 我今天要作什麼？
  • 我面臨的任何障礙...... /我因......而被封鎖
• 每日站立是爲了狀態更新，而不是任何討論。對於討論，團隊成員應該在不一樣的時間安排另外一次會議。
• 參與者一般站立而不是坐着，以便會議快速結束。

爲何站立是重要的？

每日站立敏捷的好處以下 -

• 團隊能夠天天評估進度，看看他們是否能夠按照迭代計劃進行交付。
• 每一個團隊成員都會告知他/她當天的承諾。
• 它可讓團隊瞭解任何延遲或障礙。

誰出席了站立？

• Scrum主管，產品全部者和交付團隊應天天參加站立。
• 鼓勵利益相關者和客戶參加會議，他們能夠做爲觀察員，但他們不該該參加站立。
• Scrum主管有責任記錄每一個團隊成員的疑問及他們面臨的問題。

地理位置分散的團隊

若是敏捷團隊成員在不一樣的時區運營，能夠經過多種方式進行站立 -

• 輪流選擇會員，誰能夠參加位於不一樣時區的團隊的站立會議。
• 每一個團隊單獨站立，在Rally，SharePoint，Wikis等工具中更新站立狀態。
• 擁有各類各樣的通訊工具，如電話會議，視頻會議，即時消息或任何其餘第三方知識共享工具。

敏捷 - 完成的定義

用戶故事，迭代和發佈的完成定義以下。

用戶故事

用戶故事是在用戶的平常用語中用幾句話表達的要求，而且應該在迭代內完成。用戶故事在什麼時候完成

• 全部相關代碼都已簽入。
• 全部單元測試用例都已經過。
• 全部驗收測試用例均已經過。
• 幫助文本已寫入。
• 產品負責人接受了這個故事。

迭代

迭代是在產品發佈中處理和接受的用戶故事/缺陷的時間盒裝集合。迭代在迭代計劃會議期間定義，並經過迭代演示和審閱會議完成。迭代也稱爲衝刺。迭代完成時

• 產品備份完成。
• 性能已通過測試。
• 用戶故事已被接受或移至下一次迭代。
• 缺陷已被修復或推遲到下一次迭代。

發佈

版本是一個重要的里程碑，表明產品/系統的工做，測試版本的內部或外部交付。發佈時就完成了

• 系統通過壓力測試。
• 性能獲得了調整。
• 進行安全驗證。
• 災難恢復計劃已通過測試。

敏捷 - 發佈計劃

發佈計劃的目的是建立一個計劃，以便爲產品提供增量。每2至3個月完成一次。

![圖片上傳中...]
)

誰參與了？

• Scrum Master - Scrum master是敏捷交付團隊的推進者。
• 產品負責人 - 產品負責人表明產品待辦事項的通常視圖。
• 敏捷團隊 - 敏捷交付團隊提供有關技術可行性或任何依賴關係的看法。
• 利益相關者 - 像客戶，項目經理，主題專家這樣的利益相關者擔任顧問，由於決策是圍繞發佈計劃作出的。

規劃的先決條件

發佈計劃的先決條件以下 -

• 由產品負責人管理的排名產品積壓。一般採用五到十個特徵，產品全部者認爲能夠包含在版本中
• 團隊關於能力，已知速度或任何技術挑戰的意見
• 高層願景
• 市場和業務目標
• 確認是否須要新產品積壓項目

所需材料

發佈計劃所需的材料清單以下 -

• 發表議程，目的
• 翻轉圖表，白板，標記
• 投影儀，在計劃會議期間共享具備所需數據/工具的計算機的方式
• 規劃數據

規劃數據

進行發佈計劃所需的數據列表以下 -

• 之前的迭代或發佈計劃結果
• 各利益相關方對產品，市場情況和截止日期的反饋
• 先前版本/迭代的行動計劃
• 要考慮的特徵或缺陷
• 先前版本/估計的速度。
• 組織和我的日曆
• 來自其餘團隊和主題專家的輸入，以管理任何依賴關係

產量

發佈計劃的輸出能夠是如下 -

• 發佈計劃
• 承諾
• 要監控的問題，顧慮，依賴關係和假設
• 建議改進將來的發佈計劃

議程

發佈計劃的議程能夠是 -

• 開幕式 - 歡迎辭，審查目的和議程，組織工具和商業贊助商介紹。
• 產品願景，路線圖 - 展現產品的大圖。
• 查看之前的版本 - 討論可能影響計劃的任何項目。
• 發佈名稱/主題 - 檢查路線圖主題的當前狀態並執行所需的調整（若是有）。
• 速度 - 顯示當前版本和先前版本的速度。
• 發佈計劃 - 審覈關鍵里程碑並決定發佈時的發佈和迭代時間框。
• 問題和顧慮 - 檢查任何問題或問題並記錄下來。
• 回顧和更新所作的定義 -回顧的定義完成，並根據技術，技能或團隊成員自上次迭代/釋放變化做適當的改變。
• 要考慮的故事和項目 - 顯示產品待辦事項中的用戶故事和功能，以便在當前版本中進行安排。
• 肯定大小調整值 - 若是速度未知，則計劃要在發佈計劃中使用的大小調整值。
• 粗略的故事大小 - 交付團隊肯定所考慮故事的適當大小，並在故事太大時將故事分紅多個迭代。產品全部者和主題專家澄清疑慮，詳細說明驗收標準，並進行適當的故事分割。Scrum master促進了協做。
• 將故事映射到迭代 - 交付團隊和產品全部者根據大小和速度移動迭代中的故事/缺陷。Scrum master促進了協做。
• 新的顧慮或問題 - 根據以往的經驗檢查任何新問題並記錄相同的問題。
• 依賴關係和假設 - 檢查在發佈計劃期間計劃的任何依賴關係/假設。
• 提交 - Scrum master要求進行規劃。交付團隊和產品負責人將其視爲最佳計劃，而後承諾進入下一級計劃，即迭代計劃。
• 溝通和物流規劃 - 審覈/更新發布的溝通和後勤規劃。
• 停車場 - 處理停車場意味着全部項目都應該被解決或設置爲行動項目。
• 分發行動項目和行動計劃 - 在其全部者之間分配行動項目，處理行動計劃。
• 回顧 - 徵求參與者的反饋意見，使會議取得成功。
• 關閉 - 慶祝成功。

敏捷 - 迭代計劃

迭代計劃的目的是讓團隊完成一系列排名靠前的產品積壓項目。此承諾是基於迭代長度和團隊速度的時間框。

誰參與了？

• Scrum Master - Scrum master是敏捷交付團隊的推進者。
• 產品負責人 - 產品負責人處理產品待辦事項的詳細視圖及其驗收標準。
• 敏捷團隊 - 敏捷交付定義了他們的任務，並設置了履行承諾所需的工做量估算。

規劃的先決條件

• 產品待辦事項中的項目已調整大小並分配了相對故事點。
• 產品全部者已對產品組合項進行了排名。
• 已爲每一個項目組合項目明確說明了接受標準。

規劃過程

如下是迭代計劃中涉及的步驟 -

• 肯定迭代中能夠容納多少個故事。
• 將這些故事分解爲任務並將每一個任務分配給其全部者。
• 每項任務都以小時爲單位進行估算。
• 這些估計值可幫助團隊成員檢查每一個成員爲迭代執行的任務小時數。
• 考慮到團隊成員的速度或能力，他們會被分配任務，以避免他們負擔太重。

速度計算

敏捷團隊根據過去的迭代計算速度。Velocity是在迭代中完成用戶故事所需的平均單位數。例如，若是團隊在最後三次迭代中在每次迭代中花費了12,14,10個故事點，則團隊能夠將12做爲下一次迭代的速度。

計劃速度告訴團隊在當前迭代中能夠完成多少用戶故事。若是團隊快速完成分配的任務，則能夠提取更多用戶故事。不然，故事也能夠移出到下一次迭代。

任務能力

團隊的能力來自如下三個事實 -

• 一天中理想的工做時數
• 迭代中的人的可用天數
• 成員專門爲團隊提供的時間百分比。

假設一個團隊有5名成員，他們致力於在項目中全職工做（天天8小時），而且在迭代期間沒有人休假，那麼兩週迭代的任務能力將是 -

5×8×10 = 400小時

規劃步驟

• 產品負責人描述了排名最高的產品待辦事項。
• 團隊描述完成項目所需的任務。
• 團隊成員擁有這些任務。
• 團隊成員估計完成每項任務的時間。
• 對迭代中的全部項重複這些步驟。
• 若是任何我的的任務過載，那麼他/她的任務將分配給其餘團隊成員。

敏捷 - 產品Backlog

產品待辦事項是要完成的項目列表。項目按功能描述排名。在理想狀況下，項目應分解爲用戶故事。

產品Backlog爲什麼重要？

• 它是通過準備的，能夠對每一個特徵進行估算。
• 它有助於規劃產品的路線圖。
• 它有助於對功能進行從新排名，從而能夠爲產品添加更多價值。
• 它有助於肯定優先排序的內容。團隊對項目進行排名，而後創建價值。

產品積壓的特徵

• 每一個產品應該有一個產品積壓，能夠有一組大到大的功能。
• 多個團隊能夠處理單個產品待辦事項。
• 功能排名基於業務價值，技術價值，風險管理或戰略適應性。
• 在發佈計劃期間，排名最高的項目會被分解爲較小的故事，以便在未來的迭代中完成。

敏捷 - 實用術語

驗收標準

這是產品全部者或客戶設定的條件，以便接受有效且符合其要求的功能。

積壓修飾

這是一個持續的過程，產品經理或客戶經過從敏捷團隊得到反饋來管理產品待辦事項。這個過程包括對項目組合項目進行優先排序，將它們分解爲較小的項目，爲未來的迭代計劃它們，建立新的故事，更新驗收標準或詳細闡述驗收標準。

容量

這是團隊在一次迭代中完成的工做量。

特徵

對產品或對利益相關者有價值的能力的改進，能夠在發佈中開發。

迭代

基於主題的工做項，可在時間框內完成，並在產品發佈中接受。迭代工做在迭代計劃期間定義，並經過演示和審閱會議結束。它也被稱爲Sprint。

增量

增量是產品在逐漸發展時的變化狀態。它一般由里程碑或固定迭代次數表示。

產品擁有者

產品全部者是敏捷交付團隊的成員，負責收集產品待辦事項中的業務需求並對其進行排名。產品全部者在發佈/迭代中傳達要執行的操做。他/她設定承諾並負責保護團隊在迭代期間不受任何需求變化的影響。

產品積壓

一套功能性和非功能性產品要求。

產品待辦事項

多是敏捷團隊要開發的用戶故事，缺陷和功能。

點

用於設置用戶故事，功能或任何其餘項目組合項的相對大小的經常使用單位。

發佈

一個時間框，用於完成工做以支持向軟件提供可測試的增量。在scrum中，發佈包含屢次迭代。

需求

知足所述合同或功能的軟件產品規範。用戶故事和項目組合項目是需求類型。

故事點

敏捷團隊用於估計用戶故事和功能的相對大小的單元。

短跑

與迭代相同。

時間盒

肯定可交付成果的固定持續時間。一般，隨着時間框的修復開始和結束日期，資源的數量也是固定的。

任務

它是一個工做單元，有助於在迭代中完成用戶故事。用戶故事被分解爲多個任務，每一個任務能夠在團隊成員之間劃分，並將其標記爲任務的全部者。團隊成員能夠根據須要負責每項任務，更新估算，記錄已完成的工做或待辦事項。

用戶故事

列出的驗收標準，以知足用戶的某些要求。它一般是從最終用戶的角度編寫的。

速度

在迭代或時間框中對接受的工做進行加權的度量。一般它是迭代中接受的故事點的總和。