第四次做業

時間 2019-11-29

標籤第四简体版

原文原文鏈接

最近把以前學習 Scrum 的資料整理爲一篇文檔，在接下來的團隊和項目開發中，根據項目的狀況引入 Scrum 的一些實踐，提升團隊成員之間的協做能力和項目的交付質量。前端

參考資料：架構

《輕鬆Scrum之旅—敏捷開發故事》、《敏捷無敵》
硝煙中的Scrum 和 XP
火星人敏捷開發手冊
Scrum-Checklists
維基百科：http://zh.wikipedia.org/wiki/Scrum

Scrum 工具運維

禪道
JIRA+GreenHopper

Scrum 中的角色工具

Scrum Master——項目負責人、項目經理性能

保護團隊不受外界干擾，是團隊的領導和推動者，負責提高 Scrum 團隊的工做效率，控制 Scrum 中的「檢視和適應」週期過程。與 Product Owner 一塊兒將投資產出最大化，他確保全部的利益相關者均可以理解敏捷和尊重敏捷的理念。學習

Team——開發人員、測試人員、美工設計、DBA等全職能性團隊測試

團隊負責交付產品並對其質量負責，團隊與全部提出產品需求的人一塊兒工做，包括客戶和最終用戶，並共同建立 Product Backlog 。團隊按照你們的共識來建立功能設計、測試 Backlog 條目交付產品。spa

Product Owner——產品負責人、產品經理、運營人員.net

從業務角度驅動項目，傳播產品的明確願景，並定義其主要特性。Product Owner 的主要職責是確保團隊只開發對於組織最重要的 Backlog 條目，在 Sprint 中幫助團隊完成本身的工做，不干擾團隊成員，並迅速提供團隊須要的全部信息。設計

User——最終用戶、運營人員、系統使用人員

不少人均可能成爲最終用戶，好比市場部人員、真正的最終用戶、最好的領域專家，也多是因其專業知識而被僱傭的資訊顧問。最終用戶會根據本身的業務知識定義產品，並告知團隊本身的指望，提出請求。

Manager——管理層、投資人

管理層要爲 Scrum 團隊搭建良好的環境，以確保團隊可以出色工做，必要的時候，他們也會與 Scrum Master 一塊兒從新組織結構和指導原則。

Customer——客戶、系統使用人員、運營人員

客戶是爲 Scrum 團隊提出產品需求的人，她會與組織簽定合同，以開發產品。通常來講，這些人是組織中的高級管理人員，負責從外部軟件開發公司購買軟件開發能力。在爲內部產品的公司中，負責批准項目預算的人就是客戶。

Scrum 中的產出物

Product Backlog——Backlog 待開發項，積壓的任務。

產品 Backlog 包括了全部須要交付的內容，其內容根據業務需求的價值順序排列，每一個 Backlog 的優先級是能夠調整的，需求是能夠增減的，所以產品 Backlog 將根據不斷增加來持續驅動維護。

Sprint Backlog——Sprint 本意爲「衝刺」，指迭代週期，長度一般是一至六週。

在 Sprint 開始前，定義本次 Sprint 要討論的「Sprint Backlog」，從中產生本次 Sprint 要完成的「已定 Product Backlog」。

已定 Sprint Backlog

Sprint 計劃會議的產物，它定義了團隊所接受的工做量，在整個 Sprint 過程當中它將保持不變。

User Story、Task——用戶故事、任務

用 User Story 來描述 Sprint Backlog 裏的項目，User Story 是從用戶的角度對系統的某個功能模塊所做的簡短描述。一個 User Story 描述了項目中的一個小功能，以及這個功能完成以後將會產生什麼效果，或者說能爲客戶創造什麼價值。一個 User Story 的大小和複雜度應該以能在一個 Sprint 中完成爲宜。若是 User Story 太大，可能會致使對它的開發橫跨幾個 Sprint，此時就應該將這個 User Story 分解。

爲了可以及時，高效地完成每一個 Story，Scrum 團隊會把每一個 Story 分解成若干個 Task。每一個Task 的時間最好不要超過8小時，保證在1個工做日內完成，若是 Task 的時間超過了8個小時，就說明Task的劃分有問題，須要特別注意。

障礙 Backlog——問題列表，積壓的待處理事務。

列舉了全部團隊內部和團隊相關的和阻礙項目的進度的問題，Scrum Master 須要確保全部的障礙 Backlog 中的問題都已分配並能夠獲得解決。

通用會議規則

基本要求

每次會議都要準時開始、準時結束。
每次會議都採起開放形式，全部人均可以參加。

會前準備

提早邀請全部必須參會的人，讓他們有時間準備。
發送帶有會議目標和意圖的會議綱要。
預訂會議所需的所有資源：房間、投影儀、掛圖、主持設備，以及此會議須要的其餘東西。
會前24小時發送提醒。
準備帶有會議規則的掛圖。

會議推動

展開討論時，會議的推動人必須在場。他不能參與到具體討論中，可是他須要注意討論進程，若是討論參與者失去重點，他還要將討論帶回正規。
推動人展現會議的目標和意圖。
有必要時，推動人能夠商定由某個撰寫會議記錄。
推動人能夠記錄團隊的意見，或是教授團隊如何本身記錄文檔；並且推動人可能會在掛圖上進行記錄，將對話可視化。
推動人會對會議進行收尾，並進行很是簡短的回顧。

會議輸出

使用手寫或掛圖說明來記錄文檔，給白板和掛圖上的內容拍照。
必須傳達會議記錄和你們對會議結果的明確共同認知。

讓團隊坐在一塊兒！

你們都懶的動，儘可能讓「產品負責人」和「全功能團隊」都坐在一塊兒！
互相聽到：全部人均可以彼此交談，沒必要大聲喊，沒必要離開座位。
互相看到：全部人均可以看到彼此，都能看到任務板——不用非得近到能夠看清楚內容，但至少能夠看到個大概。
隔離：若是大家整個團隊忽然站起來，自發造成一個激烈的設計討論，團隊外的任何人都不會被打擾到，反之亦然。

團隊建設

Scrum 團隊最佳人數控制在「5～9」人。
全職能性團隊：開發組（後臺開發、前端開發、測試人員——3~8人）、Scrum Master（項目經理）、產品負責人
兼職團隊成員：美工、DBA、運維

每日立會（Daily Standup Meeting）——建議下班前開始

會議目的

團隊在會議中做計劃，協調其每日活動，還能夠報告和討論遇到的障礙。
任務板可以幫助團隊聚焦於每日活動之上，要在這個時候更新任務板和燃盡圖。

構成部分

任務板、即時貼、馬克筆
提示：ScrumMaster 不要站在團隊前面或是任務板旁邊，不要營造相似於師生教學的氣氛。

基本要求

成員：團隊、Scrum Master
沒法出席的團隊成員要由同伴表明。
持續時間/舉辦地點：天天15分鐘，一樣時間，一樣地點。
提示：團隊成員在聆聽他人發言時，都應該想這個問題：「我該怎麼幫他作得更快？」

會議輸出

團隊彼此明確知道各自的工做，最新的工做進度圖。
獲得最新的「障礙 Backlog」
獲得最新的「Sprint Backlog」

會議過程

團隊聚在故事板旁邊，能夠圍成環形。
從左邊第一個開始，向團隊夥伴說明他到如今完成的工做。
而後該成員將任務板上的任務放到正確的列中。
若是能夠的話，該成員能夠選取新的任務，交將其放入「進行中工做」列。
若是該成員遇到問題或障礙，就要將其報告給 Scrum Master。
每一個團隊成員重複步驟2到步驟5。

每一個人三個問題：

上次會議時的任務哪些已經完成？：把任務從「正在處理」狀態轉爲「已完成」狀態。——今天完成了什麼？
下次會議以前，你計劃完成什麼任務？：若是任務狀態爲「待處理」，轉爲「正在處理」狀態。若是任務不在 Sprint Backlog 上，則添加這個任務。若是任務不能在一天成，把這任務細分紅多個任務。若是任務能夠在一天內完成，把任務狀態設爲「正在處理」。若是任務狀態已是「正在處理」，詢問是否存在阻礙任務完成得問題。——明天作什麼？
有什麼問題阻礙了你的開發？：若是有阻礙你的開發進度的問題，把該障礙加入到障礙 Backlog中。——今天遇到了什麼問題？

注意事項

不要遲到
不要超出限制時間
不要討論技術問題
不要轉變會議話題
不要在沒有準備的狀況下參加
Scrum Master 不要替團隊成員移動任務卡片，不要替團隊更新燃盡圖。
Scrum Master 不要提出問題，團隊成員不要向 Scrum Master 或管理層人員報告。
若是不能出席會議，須要通知團隊，並找一名錶明參加。

任務板

任務板集合了選擇好的 Product Backlog 和 Sprint Backlog，並以可視化方式展現。
任務板只能由團隊維護，使用不一樣顏色的「即時貼」來區分開發人員，或者在「即時貼」寫上接受任務的姓名。
儘可能使用大白板，也可使用軟件。

任務板有4列：

選擇好的 Product Backlog：按照優先級，將團隊在當前 Sprint 中要着手的 Product Backlog 條目或是故事放在該列中。
待完成的任務：要完成一個故事，你得完成一些任務。在 Sprint 規劃會議中，或是在進行當前 Sprint 中，收集全部特定 Backlog 條目須要完成的新任務，並將它們放入該列。
進行中的工做：當團隊成員開始某個任務後，他會將該任務對應的卡片放到「進行中的工做」列中。從上個每日 Scrum 例會開始，沒有完成的任務都會放在該列中，並在上面作標記（一般是個紅點）。若是某個任務在「待完成任務」列中所處時間超過一天，就儘可能將該任務分爲更小的部分，而後把新任務放到那一列，移除其所屬大任務卡片。若是一個新任務由於某個障礙沒法完成，就會獲得一個紅點標記，Scrum Master 就會記下一個障礙。
完成：當一個任務卡完成後，完成此任務的成員將其放入「完成」列，並開始選取下一張任務卡。

燃盡圖（Burn Down Chart）

跟蹤進度要由團隊來完成，燃盡圖的橫軸表示整個Sprint 的總時間，縱軸表示 Sprint 中全部的任務，其單位能夠是小時，人天等。通常來講，燃盡圖有」Sprint燃盡圖」和」Release燃盡圖」之分。
團隊天天更新燃盡圖。
若是燃盡圖一直是上升狀態，或當 Sprint 進行一段時間以後，Sprint 燃盡圖上的Y值仍然與 Sprint 剛開始時相差無幾，就說明這個 Sprint 中的 Story 過多，要拿掉一些 Story 以保證這個 Sprint 能順利完成。若是Sprint 燃盡圖降低得很快，例如 Sprint 剛過半時Y值已經接近0了，則說明這個 Sprint 分配的任務太少，還要多加一些任務進來。在 Sprint 計劃會議上，若是團隊對即將要作的任務理解和認識不充分，就極可能致使這兩種狀況的出現。（鍛鍊團隊人員的自我估算時間）
燃盡圖要便於團隊更新，不必讓它看起來很炫，也不要過於複雜，難以維護。

Release 燃盡圖：記錄整個Scurm項目的進度，它的橫軸表示這個項目的全部Sprint，縱軸表示各個Sprint開始前，還沒有完成的工做，它的單位能夠是個（Story 的數量），人天等。

Sprint 規劃會議——第一部分（上午）

會議目的

該會議的工做以分析爲主，目的是要詳細理解最終用戶到底要什麼，產品開發團隊能夠從該會議中詳細瞭解最終用戶的真實須要。在會議的結束，團隊將會決定他們可以交付哪些東西。
產品負責人在會前準備：條目化的需求（用戶故事），優先級排序，最近1~2個迭代最但願看到的功能。會前準備相當重要，可幫助產品負責人理清頭緒，不至於在迭代期內頻繁提出變動、增長或刪除故事。

基本要求

迭代計劃會在每一個迭代第一天召開，目的是選擇和估算本次迭代的工做項。
只有團隊成員才能決定團隊在當前 Sprint 中可以領取多少個 Backlog 條目的工做。

構成部分：

通過估算和排序的 Product Backlog。
掛圖、馬克筆、剪刀、膠水、即時貼、白板、鉛筆和蠟筆。
假期計劃表、重要人員的詳細聯繫信息。
參會成員：團隊成員、Scrum Master、產品負責人

持續時間：在 Sprint 中，每週該會議佔用時間爲 60 分鐘，在早上召開該會議，這樣還有可能在同一天召開 Sprint 規劃會議的第二部分。

會議輸出

選擇好的 Product Backlog 條目。
各個 Backlog 條目的需求。
各個 Backlog 條目的用戶驗收測試。

會議過程

從第一個 Product Backlog 條目（故事）開始。
討論該 Product Backlog 條目，以深刻理解。
分析、明確用戶驗收測試。
找到非功能性需求（性能、穩定性...）
找到驗收條件。
弄清楚須要「完成」到何種水平。
得到 Backlog 條目各個方面的清晰瞭解。
繪製出所需交付物的相關圖表，包括流程圖、UML圖、手繪草圖、屏幕 UI 設計等。
回到步驟1，選取下一個 Backlog 條目。

流程檢查：詢問團隊可否快速回答下列問題，只須要簡要回答便可：「咱們能在這個 Sprint 中完成第一個 Backlog 條目嗎？」若是能獲得確定的回答，那麼繼續詢問下一個 Backlog 條目，一直到已經分析完的最後一個 Backlog 條目。——接下來，休息一下。在休息後，對下一個 Backlog 條目展開上述流程。

結束流程：