敏捷簡介：什麼是敏捷開發？

時間 2019-12-11

標籤敏捷簡介什麼開發简体版

原文原文鏈接

敏捷軟件開發

敏捷是世界上使用最普遍，最受承認的軟件開發框架之一。大多數組織已經以某種形式採用了它，可是在採用計劃的成熟度方面還有很長的路要走。本系列教程的惟一目的是將技術和非技術專業人員融入敏捷世界。程序員

咱們將逐步引導您完成敏捷之旅，直到您瞭解使用敏捷背後的理念，優點以及如何實踐它。本系列旨在使讀者可以將敏捷和Scrum學習應用到他們的工做中。這個特別的教程專門向您解釋爲何須要敏捷以及如何建立它。這裏的基礎是讓您瞭解軟件開發行業中敏捷採用的概念。數據庫

敏捷的歷史

敏捷出生在一個晴朗的日子，當時有17我的具備不一樣的開發方法背景，在一塊兒探索可能的替代軟件開發解決方案，能夠共同進行頭腦風暴，尋求可能會縮短開發時間並減小文檔的需求量。編程

當時，軟件開發過去發生的時間太長，以致於當項目準備交付時，業務已經向前發展，需求已經發生變化。所以，即便項目可以實現其既定目標，也沒法知足業務需求。數組

所以，這些不一樣軟件工程技術的精英彙集在一塊兒，他們會議的最終結果就是他們所謂的「敏捷宣言」，咱們將在本系列的下一個教程中詳細討論。架構

可是那天出生的敏捷並非咱們今天在組織中看到的。專家們贊成的方法被稱爲「輕量級」且速度快。可是，本次會議的主要成果是認爲更快的產品交付和持續的反饋是實現軟件開發成功的關鍵。框架

現有的瀑布技術過於繁瑣，在最終產品準備交付以前沒有提供反饋。這意味着沒有進行要求修正的餘地，而且在整個產品準備好以前，客戶對進度沒有任何見解。這就是這些專家想要避免的。他們想要一個可以持續反饋的解決方案，以免後期返工的成本。ide

敏捷挑戰

當時現有的瀑布技術過於繁瑣，在最終產品準備交付以前沒有提供反饋。它被稱爲開發的瀑布模型，由於團隊首先完成了一步，而後才進入下一步。函數

這意味着沒有進行要求修正的餘地，而且在整個產品準備好以前，客戶對進度沒有任何見解。這就是這些專家想要避免的。他們想要一個能夠持續反饋的解決方案，以免在之後階段返工的成本。這就是爲何敏捷也是關於自適應和持續改進的緣由，同時也是關於持續反饋和交付速度的緣由。工具

什麼是敏捷承諾？

敏捷承諾單元測試

敏捷不只僅是在開發軟件時應用設定的實踐。它還帶來了團隊思惟方式的變化，這促使他們構建更好的軟件，協同工做並最終讓他們成爲一個滿意的客戶。

敏捷的價值觀和原則使團隊可以轉移他們的注意力並改變他們構建更好軟件的思惟過程。

敏捷究竟是什麼？

敏捷不是一套規則。敏捷不是一套指導方針。敏捷甚至不是一種方法論。相反，敏捷是一套原則，鼓勵靈活性，適應性，溝通和工做軟件超越計劃和流程。它在所謂的敏捷宣言中很是簡潔地被捕獲。

敏捷軟件開發使團隊可以在開發複雜項目時更有效地協同工做。它由練習迭代和增量技術的實踐組成，這些技術很容易被採用並顯示出很好的結果。

在將敏捷應用於行動中，咱們有各類基於敏捷的方法去知足軟件開發行業的全部需求，從軟件設計和架構，開發和測試到項目管理和交付。

不只如此，敏捷方法和方法還爲流程改進打開了一個範圍，做爲每一個交付的一個組成部分。

敏捷是一種軟件開發的實踐理念，建構一個自給自足且跨職能的團隊致力於經過迭代進行持續交付，並經過收集最終用戶的反饋在整個過程當中發展。

如何練習敏捷？

各類多樣化行業都有各類敏捷方法論。

然而，全部這些方法中最流行的方法是：

Scrum
看板 (Kanban)
極限編程 (XP)

全部這些方法都側重於精益 (Lean) 軟件開發，並有助於有效和高效地構建更好的軟件。

這就是敏捷引言的所有內容。該部分的結構旨在幫助您瞭解團隊在敏捷模式和思惟模式下工做時應採用的核心價值觀和原則。

敏捷方法論和模型

敏捷方法論簡介：

衆所周知，敏捷是一種軟件開發方法。咱們還了解了敏捷創始人在敏捷宣言中提到的價值觀和原則。在咱們最初的討論中，咱們還避開了敏捷和傳統瀑布模型之間的差別。在本教程中，咱們將瞭解敏捷方法的優缺點。

咱們會看到什麼是scrum？它與敏捷有何不一樣？而後咱們將瞭解不一樣組織正在使用的各類敏捷方法，以及如何使用它們實現敏捷。您還將可以理解這些方法的不一樣之處以及優缺點。

敏捷方法論的優勢

下面給出了敏捷方法的各類優勢：

客戶在每次迭代 (iterative) /衝刺 (Sprint) 結束時不斷得到項目進度的外觀和感受。
每一個sprint都爲客戶提供了一個工做軟件，該軟件根據他們提供的完成定義知足他們的指望。
開發團隊對不斷變化的需求作出了很好的響應，即便在開發的高級階段也能適應變化。
持續的雙向溝通 (feedback) 使客戶參與其中，所以全部利益相關者 (Stakeholders) - 業務和技術 - 都能清楚地瞭解項目的進展狀況。
產品設計高效，知足業務需求。

敏捷方法論的缺點

雖然敏捷方法有幾個優勢，但它也有一些缺點。

他們是：

＃1）不但願使用全面的文檔，這會致使敏捷團隊錯誤地解釋這一點，由於敏捷不須要文檔。所以嚴謹性會因文檔而丟失。應該經過不斷詢問本身這是不是足夠的信息來避免這種狀況。

＃2）有時，在項目開始時，要求並不十分清晰。團隊可能會繼續發現客戶的願景已經從新調整，在這種狀況下，團隊須要整合許多變動，並且很難衡量最終結果。

敏捷方法的類型

世界各地都有幾種敏捷方法。咱們將詳細瞭解最受歡迎的四個。

＃1）Scrum

Scrum很容易被認爲是最流行的敏捷框架。「scrum」一詞被大多數從業者認爲是「敏捷」的同義詞。但這是一種誤解。Scrum只是您能夠實現敏捷的框架之一。

Scrum這個詞來自體育橄欖球 (Rugby)。球員們在一個互鎖的位置擠在一塊兒推着對手。每一個球員在他們的位置上都有明確的角色，而且能夠根據狀況的需求發揮進攻和防守的做用。

一樣，IT中的Scrum相信賦予自我管理的開發團隊有三個具體且明肯定義的角色。這些角色包括 - 產品負責人（PO），Scrum Master（SM）以及由程序員和測試人員組成的開發團隊。它們在迭代時間盒裝持續時間中一塊兒工做，稱爲衝刺。

第一步是PO建立產品待辦事項。這是scrum團隊要作的事情的待辦事項列表。而後scrum團隊選擇優先級最高的項目並嘗試在稱爲sprint的時間框內完成它們。

記住全部這一切的更簡單方法是記住3-3-5框架。這意味着scrum項目有3個角色，3個工件，5價值和5個事件。

這些是 -

3 角色： PO，Scrum master和開發團隊。

3 工件：產品Backlog，Sprint Backlog和產品增量。

5 價值: 集中，勇氣，開放性，承諾，尊重。

5 事件： Sprint，Sprint計劃，Daily Scrum，Sprint評論和Sprint回顧。

咱們將在後續教程中更詳細地瞭解每一個內容。

＃2）看板 (Kanban)

看板是日語術語，意思是卡片。這些卡包含要在軟件上完成的工做的詳細信息。目的是可視化。每一個團隊成員都瞭解經過這些視覺輔助工做要完成的工做。

團隊使用這些看板卡進行持續交付。就像Scrum同樣，看板也能夠幫助團隊有效地工做，並促進自我管理和協做的團隊。

可是這二者之間也存在差別 - 好比在scrum sprint期間，團隊正在處理的項目是固定的，咱們沒法向sprint添加項目，而在看板中，若是有可用容量，咱們能夠添加項目。當需求常常變化時，這尤爲有用。

一樣，另外一個區別是，雖然scrum已經定義了PO，Scrum master和開發團隊的角色，可是在Kanban中沒有這樣的預約義角色。

另外一個不一樣之處在於，儘管scrum建議對產品待辦事項進行優先排序，但看板沒有這樣的要求，並且徹底是可選的。所以，看板須要較少的組織並避免非增值活動，而且適用於須要對變化作出響應的過程。

＃3）精益 (Lean)

精益是一種專一於減小浪費的理念。它是如何作到的？

在精簡中，您將流程劃分爲增值活動，非增值活動和基本的非增值活動。任何可歸類爲非增值活動的活動都是浪費，咱們應該嘗試在過程當中消除這種浪費，使其更加精簡。

更精簡的流程意味着更快的交付和更少的工做浪費在任務上，這無助於實現團隊目標。這有助於優化軟件開發週期中的每一個步驟。這就是精益原則從精益製造轉變爲軟件開發的緣由。

經過應用如下所示的七項精益原則，能夠在任何IT項目中使用精益軟件開發：

正如他們的名字所暗示的，這些都是不言自明的。消除浪費是第一個也是最重要的精益原則，咱們看到了如何作到這一點，咱們只是將活動分類爲價值和非增值。

非值添加活動能夠是代碼的任何部分，可能使其不那麼健壯，增長所涉及的工做量並佔用大量時間而不添加合理的業務價值。它也多是模糊的用戶故事或不良測試或添加大圖中不須要的功能。

第二個原則放大學習再次易於理解，由於團隊須要各類技能，以在快速變化的環境中提供產品，新技術能夠在短期內出現。

作出遲到的決定能夠在減小返工的狀況下得到回報，就像預期會有任何變動，而後更好地延遲，以便團隊沒必要在業務需求變化時重作工做。

可是這裏老是存在一種權衡，由於團隊須要平衡這一點與提供更快速的第四個原則。推遲決策不該影響總體交付，也不得減小工做節奏。一隻眼睛應該始終在完整的畫面上。

賦予權力的團隊如今也很是廣泛，這甚至是敏捷的建議。賦權團隊更負責任，能夠更快地作出決策。擁有權力的團隊的全部權意識能夠帶來更好的結果。爲了賦予團隊權力，應該容許他們本身組織並本身作出決定。

所以，咱們看到精益和敏捷有不少共同之處，只有一個明顯的區別 - 精益團隊能夠幫助改進產品，敏捷團隊就是實際構建產品的團隊。

＃4）極限編程（XP）

極限編程是另外一種最流行的敏捷技術。根據extremeprogramming.org，第一個XP項目於1996年3月6日開始。他們還提到XP以五種不一樣的方式影響軟件項目開發 - 溝通，簡單，反饋，尊重和勇氣。這些被稱爲XP的值。

其中，一切都始於溝通。XP團隊按期與業務團隊和其餘程序員協做，並從第一天開始構建代碼。這裏的重點是在其餘視覺輔助工具的幫助下儘量地進行面對面的交流。

極端程序員還會構建一個簡單的代碼，並從第一天開始得到反饋。重點是不要過度或預測還沒有共享的要求。這使設計簡單，只生產出知足要求的最小產品。

反饋有助於團隊改進並提升工做質量。這有助於他們在彼此學習的過程當中創建對彼此的尊重，並學習如何分享他們的觀點。

這也給了他們勇氣，由於他們知道他們已經收集了每一個人的最佳想法，並根據其餘人的反饋產生了一個好的產品。所以，他們也不懼怕包含變動或收到有關其工做的進一步反饋。

這在需求常常變化的項目中特別有用。持續的反饋將幫助團隊以勇氣包含這些變化。

所以，咱們已經看到了不一樣的敏捷方法，如Scrum，XP，看板和精益，以及它們各自的優缺點。

如今，咱們能夠輕鬆區分它們，也欣賞它們之間的微妙差別。咱們還了解了每種方法的基本原理，並瞭解瞭如何在須要時將它們應用於咱們的項目中。

在下一部分中，讓咱們瞭解Scrum的一切。

Scrum框架 (Scrum Framework)

SCRUM是敏捷方法中的一個過程，它是迭代模型和增量模型的組合。

傳統瀑布模型的主要障礙之一是 - 在第一階段完成以前，應用程序不會移動到另外一階段。並且，若是在週期的後期階段發生一些變化，那麼實施這些變化就變得很是具備挑戰性，由於這將涉及從新審視早期階段並重作變動。

SCRUM的一些關鍵特性包括：

自我組織和專一的團隊。
沒有巨大的要求文件，而是有一個很是精確和重點的故事。
跨職能團隊做爲一個單元一塊兒工做。
與用戶表明密切溝通以瞭解功能。
有一個最長一個月的明確時間表。
Scrum不是一次完成整個「事物」，而是以給定的間隔作一些事情。
在提交任何內容以前，會考慮資源功能和可用性。

要很好地理解這種方法，理解SCRUM中的關鍵術語很是重要。

重要的SCRUM術語

1）Scrum團隊

Scrum團隊由7人組成，其中包括+或 - 兩名成員。這些成員是能力的混合體，由開發人員，測試人員，數據庫人員，支持人員等組成，還包括產品全部者和Scrum主管。

全部這些成員經過緊密協做一塊兒工做，以遞歸和肯定的間隔，開發和實現所述特徵。SCRUM團隊的坐姿安排在他們的互動中起着很是重要的做用，他們從不坐在小隔間或小木屋裏，而是一張巨大的桌子。

2）衝刺 (Sprint)

Sprint是預約義的時間間隔或時間範圍，其中必須完成工做並使其準備好進行審查或準備進行生產部署。這個時間框一般在2周到1個月之間。

在咱們的平常生活中，當咱們說咱們遵循1個月的Sprint週期時，它只是意味着咱們在任務上工做了一個月，並準備好在該月底以前進行審覈。

3）產品負責人 (Product Owner)

產品全部者是要開發的應用程序的主要利益相關者或主要用戶。產品全部者是表明客戶方的人。他/她擁有最終權力，應始終爲團隊提供。

當任何人有任何須要澄清的疑問時，他/她應該能夠到達。對於產品全部者而言，瞭解而且不在sprint中間或sprint已經開始時分配任何新要求很是重要。

4）Scrum Master

Scrum Master是Scrum團隊的推進者。他/她確保Scrum團隊富有成效和進步。若有任何障礙，scrum master會跟進併爲團隊解決問題。SCRUM Master是PO和團隊之間的中介。

他/她讓PO瞭解Sprint的進展狀況。若是團隊存在任何障礙或問題，請與PO討論並解決問題。就像團隊的每日站立時同樣，天天都會有一個關於PO的SCRUM Master的站立。

5）業務分析師（BA）

業務分析師在SCRUM中扮演着很是重要的角色。此人負責完成要求並在需求文檔（基於其建立用戶素材）中起草。

若是用戶故事/接受標準中存在任何含糊之處，他/她是技術（SCRUM）團隊接洽的人，而後他將其接收到PO或者若是可能的話自行解決。在大型項目中，可能有超過1個BA，但在小規模項目中，SCRUM Master也可能做爲BA。

項目啓動時得到學士學位老是一個好習慣。

6）用戶故事 (User Story)

用戶故事只不過是必須實現的要求或功能。

在scrum中，咱們沒有那些巨大的需求文檔，而是需求在一個段落中定義，一般具備如下格式：

做爲<用戶/用戶類型>
我想<一些可實現的目標/目標>
實現<作某事的某些結果或理由>

例如：

做爲[管理員]，我想[要密碼鎖]，實現[以防用戶連續3次輸入錯誤的密碼以限制未經受權的訪問]。

應該遵照用戶故事的一些特徵。用戶故事應該簡短，逼真，能夠估計，完整，可協商和可測試。用戶故事永遠不會在Sprint中間被更改或更改。

SCRUM Master和BA（若是適用）負責確保PO使用適當的「驗收標準」正確起草用戶故事「。若是要進行任何會影響sprint發佈的更改，那麼這些故事將從sprint中撤出，或者按照可用時間完成。

每一個用戶故事都有一個驗收標準 (Acceptance Criteria)，應由團隊明肯定義和理解。

驗收標準詳細說明了提供支持文檔的用戶故事。它有助於進一步完善用戶故事。團隊中的任何人均可以寫下驗收標準。測試團隊根據這些驗收標準肯定測試用例/條件。

7）史詩 (Epic)

史詩是模棱兩可的用戶故事，或者咱們能夠說這些是未定義的用戶故事，並保留用於將來的衝刺。

試着把它與生活聯繫起來，假設你要去度假。當你下週去的時候，你已經準備好了全部的東西，好比你的酒店預訂，觀光，旅行支票等等。可是你明年的假期計劃呢？你只有一個模糊的想法，你可能會去XYZ的地方，但你沒有詳細的計劃。

史詩就像你明年的假期計劃同樣，在那裏你只知道你可能想去，可是在這個時間點你不知道全部這些細節的地點，時間，對象。

以相似的方式，存在未來須要實現的特徵，其細節尚不清楚。大部分功能都以Epic開頭，而後分解爲能夠實現的故事。

8）產品積壓 (Product Backlog)

產品待辦事項是一種存儲全部用戶故事的存儲桶或源。這由產品負責人維護。產品待辦事項能夠設想爲產品全部者的願望清單，產品全部者根據業務需求對其進行優先級排序。

在計劃會議期間（參見下一節），從產品待辦事項中獲取一個用戶故事，而後團隊進行頭腦風暴，理解並完善它，並在產品全部者的干預下共同決定要採起哪些用戶故事。

9）Sprint Backlog

根據優先級，用戶故事一次一個地從Product Backlog中獲取。Scrum團隊的頭腦風暴決定了它的可行性，並決定了在特定衝刺上工做的故事。Scrum團隊在特定sprint上工做的全部用戶故事的集合列表稱爲Sprint backlog。

10）故事點 (Story Point)

故事點是用戶故事複雜性的定量指示。基於故事點，肯定故事的估計和努力。

故事點是相對的而不是絕對的。爲了確保咱們的估計和努力是正確的，檢查用戶故事並不重要是很重要的。用戶故事越精確，越小，估計就越準確。

每一個用戶故事都根據Fibonacci系列（1,2,3,5,8,13和21）分配到故事點。數字越高，複雜就是故事。

確切地說

若是你給出1/2/3的故事點，那就意味着故事很小並且複雜度很低。
若是你給分數爲5/8，它是一箇中等複雜的
13和21很是複雜。

這裏的複雜性包括開發和測試工做。

爲了肯定一個故事點，頭腦風暴發生在Scrum團隊中，團隊共同決定一個故事點。

開發團隊可能會爲特定故事提供3個故事點，由於對於他們來講可能有3行代碼更改，但測試團隊給出了8個故事點，由於他們以爲這個代碼更改會影響更大的模塊因此測試工做量會更大。不管你給出什麼樣的故事，你都必須證實這一點。

所以，在這種狀況下，頭腦風暴發生，團隊集體贊成一個故事點。

不管什麼時候決定故事點，請記住如下因素：

故事與其餘應用程序/模塊的依賴關係。
資源的技能組合。
故事的複雜性。
歷史學習。
用戶故事的接受標準。

若是您不瞭解特定故事，請不要調整大小。

每當故事大於或等於8分時，它就被分解爲2個或更多故事。

11）燒掉圖表

刻錄圖表是一個圖表，顯示了scrum任務的估計v / s實際工做量。

它是一種跟蹤機制，經過該機制，對於特定的衝刺，跟蹤平常任務以檢查故事是否正在朝着完成提交的故事點的方向前進。

示例：要了解這一點，請查看下圖：

我假設：

2周衝刺（10天）
2個實際在衝刺上工做的資源。

「故事」 - >此列顯示爲sprint拍攝的用戶故事。

「任務」 - >此列顯示與用戶素材關聯的任務列表。

「努力」 - >此欄顯示了努力。如今，這項措施是完成任務的總工做量。它沒有描述任何特定我的的努力。

「第1天 - 第10天」 - >此列顯示完成故事的剩餘時間。請注意，小時不是已經完成的小時，但仍然是剩下的小時數。

「估計的努力」 - >是努力的總和。對於「開始」，它只是整個單獨任務的總和：SUM（C5：C15）

必須在1天內完成的總工做量是70/10 = 7.所以在第1天結束時，努力應該減小到70 - 7 = 63.以相似的方式，計算全部的直至第10天，估計的努力量應爲0（第16行）

「實際努力」 - >顧名思義，其實是完成故事的努力。也可能發生實際努力增長或減小的估計值。

您可使用內置函數和Excel中的圖表來建立此燃盡圖表。

刻錄圖表步驟將是：

輸入全部故事（A5列 - A15列）。
輸入全部任務（B5 - B15列）。
輸入天數（第1天 - 第10天）。
輸入起動工做（總結任務C5 - C15）。
應用公式計算天天（第1天至第10天）的「估計工做量」。在D15（C16- $ C $ 16/10）輸入公式並將其拖動一成天。
對於每一天，輸入實際的努力。在D17（SUM（D5：D15））輸入公式，用於總結剩餘的實際工做量，並將其拖動到全部其餘日期。
選擇它並按以下方式建立圖表：

12）速度

Scrum團隊在sprint中歸檔的故事點總數稱爲Velocity。Scrum團隊經過其速度來判斷或引用。話雖如此，但應該記住，這裏的目標不是達到最大的故事點，而是要得到高質量的交付，尊重Scrum團隊的溫馨程度。

例如：對於特定衝刺：用戶故事總數爲8，故事點以下所示。

因此這裏的速度將是故事點的總和= 30

完成的定義：

當全部故事都完成後，Sprint被標記爲完成，全部開發，研究，QA任務都標記爲「已完成」，全部錯誤都是固定關閉的，不然能夠在之後完成（如不徹底相關或不過重要）在備份日誌中提取並添加代碼審查和單元測試，估計的小時數已經達到了任務中的實際小時數，最重要的是，已經向PO和利益相關者提供了成功的演示。

在SCRUM方法論中完成的活動

＃1）規劃會議

計劃會議是Sprint的起點。這是整個Scrum團隊彙集的會議，SCRUM Master根據產品積壓和團隊頭腦風暴的優先級選擇用戶故事。

根據討論，Scrum團隊根據Fibonacci系列決定故事的複雜程度並根據其進行調整。團隊肯定任務以及完成用戶故事實施所需的工做（以小時爲單位）。

不少時候，計劃會議以前都是「預先計劃會議」。這就像scrum團隊在參加正式計劃會議以前所作的一項功課。團隊試圖在計劃會議中寫下他們想要討論的依賴關係或其餘因素。

＃2）執行Sprint任務

顧名思義，這些是scrum團隊完成任務並將用戶故事帶入「完成」狀態所作的實際工做。

＃3）每日站立

在衝刺週期中，scrum團隊天天都會遇到，不超過15分鐘（多是一個直接的電話，建議在一天開始時）和狀態3點：

昨天團隊成員作了什麼？
團隊成員今天計劃作什麼？
任何障礙（障礙）？

促進此次會議的是Scrum大師。若是任何團隊成員遇到任何困難，scrum master會跟進以解決問題。在Stand ups中，董事會也會進行審覈，並自行顯示團隊的進展狀況。

＃4）審覈會議

在每一個sprint週期結束時，SCRUM團隊再次會面並向產品全部者演示實現的用戶故事。產品全部者能夠根據其驗收標準交叉驗證故事。Scrum大師再次負責主持此次會議。

一樣在SCRUM工具中，Sprint關閉，任務標記完成。

＃5）回顧會議

回顧會議在審議會議以後召開。

SCRUM團隊會見，討論並記錄如下幾點：

Sprint（最佳實踐）期間進展順利？
什麼在Sprint中表現不佳？
獲得教訓
行動項目。

Scrum團隊應該繼續遵循最佳實踐，忽略「不是最佳實踐」，並在隨後的衝刺中實施經驗教訓。回顧會議有助於實施SCRUM流程的持續改進。

流程如何完成？一個例子！

閱讀了SCRUM的技術術語。讓我試着用一個例子來演示整個過程。

例：

步驟1：讓咱們擁有一個由9人組成的SCRUM團隊，其中包括1個產品全部者，1個Scrum master，2個測試人員，4個開發人員和1個DBA。

步驟2：Sprint決定遵循4周的週期。因此咱們從6月5日到 7 月4 日開始爲期一個月的Sprint 。

步驟3：產品全部者在產品待辦事項中具備優先級的用戶故事列表。

步驟＃4： 團隊決定於 6月4 日舉行「預先規劃」會議。

產品全部者從產品積壓中獲取1個故事，描述它並留給團隊進行頭腦風暴。
整個團隊直接與產品全部者討論並進行溝通，以便清楚地瞭解用戶故事。
以相似的方式，採用各類其餘用戶故事。若是可能的話，團隊也能夠繼續調整故事的大小。

在全部討論以後，我的團隊成員回到他們的工做站和

肯定每一個故事的各自任務。
計算他們將要工做的確切小時數。讓咱們來看看會員如何結束這些時間。

總工做小時數= 9
減1小時休息，減1小時會議，減去1小時電子郵件，討論，故障排除等
因此實際工做時間= 6.Sprint
期間的總工做天數= 21天。
總可用小時數= 21 * 6 = 126.
該成員休假2天= 12小時（每一個成員有所不一樣，有些可能請假，有些可能不休。）
實際小時數= 126 - 12 = 114小時。

這意味着該成員實際上能夠在此sprint中使用114小時。因此他將打破他的我的衝刺任務，總共達到114小時。

第五步： 6月5 日，整個Scrum團隊召開「規劃會議」。