敏捷式開發

一、敏捷開發的工具：Leangoo；Teambition

二、Scrum敏捷開發流程主要包擴三個角色、四個會議和個三物件。

(1) Scrum團隊中包括三個角色，他們分別是產品負責人、開發團隊和 項目的直接管理者（Scrum Master）。

Scrum角色之：產品負責人

產品負責人負責最大化產品以及開發團隊工做的價值。實現這一點的方式會隨着組 織、Scrum 團隊以及單個團隊成員的不一樣而不一樣。

產品負責人是管理產品待辦事項列表的惟一責任人。產品待辦事項列表的管理包括:

● 清晰地表達產品代辦事項列表條目

● 對產品代辦事項列表中的條目進行排序,最好地實現目標和使命

● 確保開發團隊所執行工做的價值

● 確保產品代辦事項列表對全部人可見、透明、清晰,而且顯示 Scrum 團隊的下一步工做

● 確保開發團隊對產品代辦事項列表中的條目達到必定程度的理解

產品負責人能夠親自完成上述工做,也可讓開發團隊來完成。然而,產品負責人是 負責任者。

產品負責人是一我的,而不是一個委員會。產品負責人可能會在產品代辦事項列表中 體現一個委員會的需求,但要想改變某條目的優先級必須先說服產品負責人。

爲保證產品負責人的工做取得成功,組織中的全部人員都必須尊重他的決定。產品負 責人所做的決定在產品待辦事項列表的內容和排序中要清晰可見。任何人都不得要求開發 團隊按照另外一套需求開展工做,開發團隊也不容許遵從任何其餘人的指令。

Scrum角色之：開發團隊

開發團隊包含了專業人員,負責在每一個 Sprint 的結尾交付潛在可發佈的「完成」產 品增量。只有開發團隊的成員才能創造增量。

開發團隊由組織構建並受權,來組織和管理他們的工做。所產生的協同工做能最大化 開發團隊的總體效率和效力。開發團隊有如下幾個特色:

他們是自組織的,沒有人(即便是 Scrum Master 都不能夠)告訴開發團隊如何把產品 代辦事項列表變成潛在可發佈的功能。

開發團隊是跨職能的,團隊做爲一個總體擁有創造產品增量所須要的所有技能。

Scrum 不承認開發團隊成員的頭銜,不管承擔哪一種工做他們都是開發者。此規則無一例外。

開發團隊中的每一個成員能夠有特長和專一領域,可是責任歸屬於整個開發團隊

開發團隊不包含如測試或業務分析等負責特定領域的子團隊。

Scrum角色之：Scrum Master

Scrum Master 負責確保 Scrum 被理解並實施。爲了達到這個目的,Scrum Master要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規則。Scrum Master是Scrum團隊中的服務式領導。

Scrum Master 幫助 Scrum 團隊外的人員瞭解他們如何與 Scrum 團隊交互是有益的。 Scrum Master 經過改變這些交互來最大化 Scrum 團隊所創造的價值。

Scrum Master 服務於產品負責人

Scrum Master 以各類方式服務於產品負責人,包括:

● 找到有效管理產品代辦事項列表的技巧

● 清晰地和開發團隊溝通願景、目標和產品表明事項列表條目

● 教導開發團隊建立清晰簡明的產品表明事項列表條目

● 在經驗主義環境中理解長期的產品規劃

● 理解並實踐敏捷

● 按需推進Scrum活動

Scrum Master 服務於開發團隊

Scrum Master 以各類方式服務於開發團隊,包括:

● 指導開發團隊自組織和跨職能

● 教導並領導開發團隊創造高價值的產品

● 移除開發團隊進展過程當中的障礙

● 按需推進Scrum活動

● 在 Scrum 還未徹底被採納和理解的組織環境下指導開發團隊

Scrum Master 服務於組織

Scrum Master 以各類方式服務於組織,包括:

● 領導並指導組織採用 Scrum

● 在組織範圍內計劃 Scrum 的實施

● 幫助員工及干係人理解並實施 Scrum 和經驗性產品開發

● 發起能提高Scrum 團隊生產力的變革

● 與其餘 Scrum Master 一塊兒工做,幫助組織更有效的應用Scrum

四個會議

四個會議指的是Sprint計劃會議、每日例會、Sprint評審會議和Sprint回顧會議。

Sprint計劃會議（Sprint Planning）

在Scrum中，Sprint計劃會議有兩部分：

1. 決定須要完成哪些工做？

2. 決定這些工做如何完成？

第一部分：須要完成哪些工做？

參會人員：團隊、項目負責人（Scrum Master）、產品負責人（Product Owner）

第一部分的會議，產品負責人向開發團隊介紹排好序的產品待辦事項，由整個Scrum團隊共同理解這些工做。

Sprint中須要完成的產品待辦事項數目徹底由開發團隊決定。作多少工做只能由開發團隊決定，產品負責人或任何其它人都不能給開發團隊強加更多的工做量。

第二部分：如何完成工做？

參會人員：Team 、Scrum Master

第二部分的會議，開發團隊須要根據當前的「完成的定義」一塊兒決定如何實現下一個產品增量。他們進行足夠的設計和計劃，從而有信心能夠在Sprint中完成全部工做。

決定如何完成工做是開發團隊的職責，決定作什麼則是產品負責人的職責。

Sprint計劃會議最終須要Scrum團隊對Sprint須要完成工做的數量和複雜度達成共識，最終產生的待辦事項列表就是「Sprint待辦事項列表（Sprint Backlog）」。

Sprint待辦事項列表是一個須要在當前Sprint完成的且梳理過的產品待辦事項，幷包括了一個團隊完成這些工做的計劃。

每日站會（Daily Scrum）

開發團隊是自組織的，經過每日站會來確認他們仍然能夠實現Sprint的目標。

每個開發團隊成員須要提供如下三點信息：

● 從昨天的站立會到如今，我完成了什麼；

● 從如今到明天的站立會，我計劃完成什麼；

● 有什麼阻礙了個人進展。

每日Scrum一般不超過15分鐘。

每日Scrum中可能有簡要的問題澄清和回答，可是不該該有任何話題的討論。

每日Scrum既不是向管理層彙報，也不是向產品負責人或者ScrumMaster彙報。它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的瞭解。

只有Scrum團隊的成員，包括ScrumMaster和產品負責人，能夠在會議中發言。其餘感興趣的人能夠來旁聽。

Sprint評審會議（Sprint Review）

Sprint結束時，Scrum團隊和相關人員一塊兒評審Sprint的產出。全部Scrum會議都是限定時長的，Sprint評審會議的推薦時長是Sprint中的每一週對應一個小時（好比，一個Sprint包含2個星期，則Sprint評審會議時長爲2個小時）。

每一個人均可以在Sprint評審會議上發表意見。產品負責人會對將來作出最終的決定，並適當地調整產品待辦事項列表（Product Backlog）。

Sprint評審會議向每一個人展現了當前產品增量的概況。一般都會在Sprint評審會議中調整產品待辦事項列表。

Sprint回頊會議（Sprint Retrospective）

在每一個Sprint結束後，Scrum團隊會聚在一塊兒開Sprint回顧會議，目的是回顧一下團隊在流程、人際關係以及工具方面作得如何。團隊識別出哪些作得好，哪些作得很差，並找出潛在的改進事項，爲未來的改進制定計劃。全部的Scrum會議都是限定時長的，Sprint回顧會議的推薦時長是Sprint中的每一週對應一個小時（譯者注：好比，一個Sprint包含2個星期，則Sprint回顧會議時長爲2個小時）。

Scrum團隊老是在Scrum的框架內，改進他們本身的流程。

SCRUM的三個物件

三個物件指的是產品待辦事項列表（Product Backlog）、Sprint Backlog和燃盡圖

Product Backlog – 產品待辦事項列表

產品待辦事項列表是一個排序的列表,包含全部產品須要的東西,也是產品需求變更的惟一來源。產品負責人負責產品待辦事項列表的內容、可用性和優先級。

產品待辦事項列表是一個持續完善的清單, 最初的版本只列出最初始的和衆所周知的需求。 產品待辦事項列表根據產品和開發環境的變化而演進。待辦事項列表是動態的,它常常發生變化以識別使產品合理、有競爭力和有用所必需的東西。只要產品存在,產品待辦事項列表就存在。

產品待辦事項列表列出了全部的特性、功能、需求、改進方法和缺陷修復等對將來發布產品進行的改變。產品待辦事項列表條目包含描述、次序和估算的特徵。

產品待辦事項列表一般以價值、風險、優先級和必須性排序。它是一個按照優先級由高到低排列的一個序列，每一個條目有惟一的順序。排在頂部的產品待辦事項列表條目須要當即進行開發。排序越高,產品待辦事項列表條目越緊急,就越須要仔細斟酌,而且對其價值的意見越一致。

排序越高的產品待辦事項列表條目比排序低的更清晰、更具體。根據更清晰的內容和 更詳盡的信息就能作出更準確的估算。優先級越低,細節信息越少。開發團隊在接下來的 Sprint 中將要進行開發的產品待辦事項列表條目是細粒度的,已經被分解過,所以,任何 一個條目在 Sprint 的時間盒內均可以被「完成」。開發團隊在一個 Sprint 中能夠「完 成」的產品待辦事項列表條目被認爲是「準備好的」或者「可執行的」,能在 Sprint 計 劃會議中被選擇。

隨着產品的使用、價值的獲取以及市場的反饋,產品待辦事項列表變成了更大、更詳 盡的列表。由於需求永遠不會中止改變,因此產品待辦事項列表是個不斷更新的工件。業 務需求、市場形勢和技術的變化都會引發產品待辦事項列表的變化。

若干個 Scrum 團隊經常會一塊兒開發某個產品。但描述下一步產品開發工做的產品待辦事項列表只能有一個。那麼這就須要使用對產品待辦事項列表條目進行分組的屬性。

經過產品Backlog地梳理來增添細節、估算和排序。這是一個持續不斷 的過程,產品負責人和開發團隊協做討論產品表明事項列表條目的細節。在產品待辦事項列表梳理的時候,條目會被評審和修改。然而, 產品負責人能夠隨時更新產品代辦事項列表條目或酌情決定。

梳理在 Sprint 中是一項兼職活動,在產品負責人和開發團隊之間展開。一般,開發 團隊有自行優化的領域知識。然而,什麼時候如何完成優化是 Scrum 團隊的決定。優化一般佔用不超過開發團隊 10%的時間。

開發團隊負責全部的估算工做。產品負責人能夠經過協助團隊權衡取捨來影響他們的 決定。可是,最後的估算是由執行工做的人來決定的。

SPRINT BACKLOG

Sprint 代辦事項列表是一組爲當前 Sprint 選出的產品代辦事項列表條目,外加交付 產品增量和實現 Sprint 目標的計劃。Sprint 代辦事項列表是開發團隊對於哪些功能要包 含在下個增量中,以及交付那些功能所需工做的預計。

Sprint 代辦事項列表定義了開發團隊把產品代辦事項列表條目轉換成「完成」的增量 所須要執行的工做。Sprint 代辦事項列表使開發團隊肯定的、達到 Sprint 目標所需的工 做清晰可見。

Sprint 代辦事項列表是一份足夠具體的計劃,使得進度上的改變能在每日例會中獲得 理解。開發團隊在整個 Sprint 中都會修改 Sprint 代辦事項列表,Sprint 代辦事項列表也 會在 Sprint 的進程中慢慢顯現,好比開發團隊按照計劃工做並對完成 Sprint 目標所需的 工做有更多的瞭解。

當出現新工做時,開發團隊須要將其追加到 Sprint 待辦事項列表中去。隨着任務進 行或者被完成,須要更新每項任務的估算剩餘工做量。若是計劃中某個部分失去開發的意 義,就能夠將其除去。在 Sprint 內只有開發團隊能夠對 Sprint 待辦事項列表進行修改。 Sprint 待辦事項列表是高度可見的,是對團隊計劃在當前 Sprint 內完成工做的實時反 映,而且,該列表只屬於開發團隊。

Product Backlog 功能點被放到Sprint的固定週期中，Sprint Backlog 會由於以下緣由發生變化:

❶隨着時間的變化，開發團隊對於需求有了更好的理解，有可能發現須要增長一些新的任務到Sprint Backlog中。

❷程序缺陷作爲新的任務加進來，這個都作爲承諾提交任務中未完成的工做。

Product Owner也許會和Scrum team一塊兒工做，以幫助team更好的理解Sprint的目標，ScrumMaster和team也許會以爲小的調整不會影響sprint的進度，但會給客戶帶來更多商業價值。

燃盡圖（BURN-DOWN CHART)

Sprint燃盡圖（Sprint Burn-down Chart)

Sprint Burndown Chart 顯示了Sprint中累積剩餘的工做量，它是一個反映工做量完成情況的趨勢圖。 圖中Y軸表明的是剩餘工做量，X軸表明的是Sprint的工做日。

在Sprint開始的時候，Scrum Team會標示和估計在這個Sprint須要完成的詳細的任務。全部這個Sprint中須要完成，但沒有完成的任務的工做量是累積工做量，團隊會根據進展狀況天天更新累積工做量，若是在Sprint結束時，累積工做量下降到0，Sprint就成功結束。

因爲在Sprint的剛開始的時候，增長的任務工做量可能大於完成的任務工做量，因此燃盡圖有可能略微呈上升趨勢。

發佈燃盡圖（Release Burn-down Chart）

在Scrum項目中，團隊經過每一個Sprint結束時更新的發佈燃盡圖來跟蹤整個發佈計劃的進展。發佈燃盡圖記錄了在一段時間內產品Backlog的總剩餘估算工做量的變化趨勢。X軸表明的項目週期，以Sprint爲單位， Y軸表明的是剩餘工做量，一般以用戶故事點、理想人天或者team-days爲單位。