管理活動指南Sprint計劃會

Scrum管理活動指南-Sprint計劃會文檔編號：YY/PF/AGUI/06/G02文檔信息：組織級過程文件文檔名稱：Scrum開發(fā)活動指南-Sprint計劃會文檔類別：過程改進類密級：內部版本信息：1.0建立日期：2015/12/30創(chuàng)建人：張穎審核者：羅濤批準人：謝志華批準日期：2016/01/01文檔修訂記錄版本編號或者更改記錄編號*變化狀態(tài)簡要說明（變更內容和變更范圍）日期變更人批準日期批準人V0.5A新建2015/12/30張穎*變化狀態(tài)：A——增加，M——修改，D——刪除文檔評審記錄序號評審人角色評審日期簽字備注1羅濤開發(fā)管理部經理2016/0123文檔審批信息序號審批人角色審批日期簽字備注目錄1.簡介 41.1目的 41.2適用范圍 41.3術語與縮略語 41.4參考資料 42.指南概述 43.實施步驟指導 54.常見問題： 6

1.簡介1.1目的Sprint計劃會是敏捷流程scrum方法中的一條關鍵實踐，Sprint計劃會議的目的就是要為這個Sprint的工作做計劃。這份計劃是由整個Scrum團隊共同協作完成的，共同選擇和理解在即將到來的Sprint中要完成的工作。本指南主要指導敏捷教練或者敏捷開發(fā)團隊如何開好計劃會，發(fā)揮計劃會的真正作用。1.2適用范圍 本過程適用于：機構：適用于集團內各產品研發(fā)，運維運營組織業(yè)務：全生命周期研發(fā)及運維運營產品類型：全部產品類型1.3術語與縮略語團隊生產率：一輪迭代完成的故事點就是團隊生產率。項目做計劃時，可以參考之前迭代的生產率。因此生產率是一個有用的管理工具，在每輪迭代結束和迭代中監(jiān)控團隊的生產率是很重要的。1.4參考資料集團敏《集團敏捷研發(fā)管理體系V2.0》《硝煙中的Scrum和XP》《Scrum-Guide-CN》Scrum中文網2.指南概述敏捷的迭代實現始于計劃會議，所以一個好的計劃會議是每個迭代成功的基礎。這是一個固定時長的會議，推薦時長Sprint中的每周對應兩小時或者更少(例如，一個Sprint包含2個周，則Sprint計劃會議時長應為4個小時或者更少)。Sprint計劃會議的成功十分依賴于產品Backlog的質量，一個井然有序的產品backlog是Sprint計劃會成功的基礎。Sprint計劃會議有兩部分:1、決定在Sprint中需要完成哪些工作2、決定這些工作如何完成3.實施步驟指導會議準備邀請與會者：產品負責人、ScrumMaster、團隊所有成員在sprint計劃會議之前，要確保產品backlog的井然有序（已按優(yōu)先級排列的產品Backlog）把產品Backlog公開給會議中的每個人，保證其可被獲取保證房間環(huán)境適合小組討論，一個比較安靜的會議室，有投影儀每個人都可以獲取上次Sprint評審會議和Sprint回顧會議的結果用作計劃紙牌的卡片一個任務看板會議進程（2周的sprint，一般4個小時）第一部分：產品負責人和團隊一起，在產品backlog基礎上，定出Sprint目標和SprintBacklog，決定在Sprint中需要完成哪些工作。SM把Sprint完成周期公開給所有人。SM把上一次Sprint評審會議的結果公開給所有人。SM把上一次Sprint回顧會議的結果公開給所有人。PO向團隊產品闡述產品遠景，以及達成該遠景所需要完成的產品Backlog，讓團隊成員了解客戶的需求。整個Scrum團隊為了更好地了解Sprint的工作進行討論。PO和團隊一起確認sprint目標。估算本迭代團隊生產率。團隊確認要放入sprint中的Backlog。產品負責人在必要時修改重要性評分，理清每個條目的含義。產品負責人和團隊需要對“完成”有一致的定義。確定評審會日期。確定回顧會日期。確定每日站會時間和地點。第二部分：決定這些工作如何完成，并評估相應的完成時間。團隊從最重要的故事開始逐一討論每個故事，SM帶團隊拆分工作任務，將sprint中的Backlog轉換成可工作的產品增量所需要的工作，建議每個工作任務最好不要超過一天。Scrum團隊對Sprint需要完成工作的復雜度進行工作量估算，并達成共識。通常使用計劃紙牌做工作量估算，估算需要考慮到工作中所有的細節(jié):編碼、測試、代碼評審、會議、學習新技術、編寫文檔。當任務確定后，團隊成員可以自愿承擔任務，也可以由SM分配任務。Sprint計劃會議結束時，開發(fā)團隊解釋他們將如何以自組織團隊的形式完成Sprint目標。繪制任務看板和燃盡圖。會議輸出Sprint目標和SprintBacklog任務看板（含燃盡圖）確定好sprint演示日期確定好sprint回顧日期確定好時間地點，供舉行每日站會4.常見問題參會人員哪些是必須的？PO是必須的，產品需求，客戶價值就靠他了；SM必須的，他要保證流程，整個環(huán)節(jié)里面，他是最了解流程的，會議需要他把握節(jié)奏，風險等；團隊成員更是必須的。三種角色缺一不可。sprint應該多長才好？經驗證明一般2-4周比較合適，可以擁有足夠的敏捷性，又讓團隊進入“流”的狀態(tài)，團隊剛開始要確定sprint的長度，不要浪費太多時間做分析，選一個可以接受的長度先開始再說，等做完一兩個sprint再進行調整。不過，團隊確定了最合適長度之后，就要在長時間內堅持住。因為接下來的迭代過程有的時候會稍稍感覺有點長，有的時候感覺有點短。但保持住這個長度以后，它似乎變成了大家共同的心跳節(jié)奏，每個人都感覺很舒服。接下來無須討論發(fā)布日期之類的事情，因為大家都知道：每過三周都會有一個發(fā)布。如何計算團隊生產率？團隊生成率是團隊在迭代中完成的故事點，計算團隊生成率是用迭代開始前分配的故事點數。一旦迭代完成，就不要改變迭代中團隊獲得的任何故事點數。舉個例子來說，假如一個故事估算是4個故事點，但其實更大。后來團隊發(fā)現他們應該估7個故事點。在計算團隊生產率時，這個故事應該算4個點，而不是7個點。通常情況下，應鼓勵團隊在為下輪迭代生產率時，不要超過上輪迭代的生產率。然而，如果團隊確實認為有個故事被嚴重低估，在下輪迭代中他們能做更多，就應該讓他們計劃一個稍微高一些的生產率。通常最初的生產率往往不準確，而且生產率在初期的迭代中也很不穩(wěn)定?？赡苄枰獌扇齻€迭代之后，才能獲得一個長期的，比較穩(wěn)定的生產率。Sprint過程中，Sprintbacklog是否可以隨意添加？由SM進行風險把控，確保整個Sprint不被影響。需要判斷添加的backlog優(yōu)先級，是否緊急，sprint剩余工作量等進行綜合考慮。在sprint計劃會議之前，要確保產品backlog的井然有序，是什么意思？井然有序表示的意思是：所有重要的backlog條目都已經根據重要性被評過分，不同的重要程度對應不同的分數。無論任何故事，如果產品負責人認為它會在下一個sprint實現，那它就應該被劃分到一個特有的重要性層次。分數只是用來根據重要性對backlog條目排序。假如A的分數是20，而B的分數是100，那僅僅是說明B比A重要而已，絕不意味著B比A重要五倍。如果B的分數是21而不是100，含義也是一樣的。最好在分數之間留出適當間隔，以防后面出現一個C，比A重要而不如B重要。當然我們也可以給C打一個20.5分，但這樣看上去就很難看了，所以我們還是留出間隔來。是否可以把一個產品backlog當做一個Sprintbacklog？看情況而定，如果產品backlog就是一個比較小的特性來說，是可以的，如果產品backlog確實很大，那么作為Sprintbacklog來說，就不太合適了。如何使用計劃紙牌做時間估算?每個人都會得到一些紙牌，在估算故事的時候，每個人都選出一張紙牌來表示他的時間估算（例如以故事點或人天的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的紙牌會被同時揭開。這樣每個人都會被迫進行自我思考，而不是依賴于其他人估算的結果。如果在兩個估算之間有著巨大差異，團隊就會就此進行討論，并試圖讓大家對故事內容達成共識。他們也許會進行任務分解，之后再重新估算。這樣的循環(huán)會往復進行，直到時間估算趨于一致為止，也就是每個人對這個故事的估算都差不多相同。重要的是，團隊成員需要清楚，他們要對這個故事中所包含的全部工作進行估算。而不是“他們自己負責”的部分工作。估算需要考慮到工作中所有的細節(jié):編碼、測試、代碼評審、會議、學習新技術、編寫文檔。如何決定sprint要包含的故事？決定哪些故事需要在這個sprint中完成，是sprint計劃會議的一個主要活動。更具體地說，就是哪些故事需要從產品backlog拷貝到sprintbacklog中。每個矩形都表示一個故事，按重要性排序。最重要的故事在列表頂部。矩形尺寸表示故事大小（也就是以故事點估算的時間長短）。藍括號的高度表示團隊的估算生產率，也即團隊認為他們在下一個sprint中所能完成的故事點數。右側的sprintbacklog是產品backlog中的一個故事快照。它表示團隊在這個sprint中承諾要完成的故事。如果故事D不會被放到sprint里面，但是產品經理又認為故事D很重要，那團