Scrum敏捷開發(fā)培訓分享（二）
Scrum是一種兼顧計劃性與靈活性的敏捷開發(fā)過程，原詞來自于橄欖球中的“帶球過人”。在橄欖球比賽的每次沖刺前，都將有一個計劃安排的過程，但沖刺開始后則由隊員在原計劃的基礎上隨機應變。不同于瀑布模型將開發(fā)過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發(fā)過程分為多次迭代（稱為Sprint，沖刺），一般為期2～4周。
在日常工作時，產品負責人會維護一個按優(yōu)先級排序的“產品待開發(fā)項”（Product Backlog），即從客戶價值理解和描述的產品功能條目，通常產品經理承擔這一角色。 在每次迭代的第一天，召開Sprint計劃會(Sprint Planning Meeting)。產品負責人會逐一挑選最高優(yōu)先級的部分進行講解。團隊可就需求細節(jié)、完成標準等進行詢問，并逐條估算，放入本次迭代的開發(fā)任務中，直至任務量飽和。一旦迭代開始，這些任務將不會發(fā)生大的發(fā)化。
在迭代期內，團隊將決定任務分配、所需的技術等，逐一完成任務。每天團隊會進行一個簡短的站立會議即每日站會 Daily Stand-up Meeting，溝通當前進度、下一步任務和當前存在的問題，以借助團隊的力量解決。團隊還維護一張“燃燒圖”（Burn Down Chart），即所有任務的累積剩余時間隨開發(fā)進程與日遞減的圖形，以觀察和預測所有任務是否會按期完成。
在每個迭代的最后一天，團隊會召集評審會(Review Meeting)，邀請產品負責人等參加，對已經完成的產品功能條目進行評審，后者做出判斷并給出改進反饋。當天還會召開回顧會 (Retrospective Meeting)，對本次迭代的成功與失敗之處做出總結，并在以后迭代中進行改進。
Scrum中的三個角色
產品負責人(Product Owner)
主要由產品經理擔任，其為確定產品的方向和愿景，定義產品發(fā)布的內容、優(yōu)先級及交付時間，為產品ROI（profitability of product）負責。主要職責包括：確定產品的功能；決定發(fā)布的日期和 發(fā)布內容；為產品的ROI負責；根據市場價值確定功能優(yōu)先級；每個sprint中，根據需要調整功能和優(yōu)先級（每個sprint開始前調整）；接受或拒絕開發(fā)團隊的工作成果；參與Scrum Planning Meetings（Sprint計劃會議），Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）。
Scrum Master
擔當團隊leader，可以是開發(fā)Leader或者Team Leader, 和Product owner緊密合作，及時為團隊成員提供幫助。主要職責包括：保證團隊資源合理利用；保證各個角色及職責良好協作；解決團隊開發(fā)中的障礙；作為團隊和團隊外部的接口，協調解決溝通中的問題；保證開發(fā)過程按計劃進行，組織Scrum Planning Meetings（Sprint計劃會議）, Daily Stand-up Meeting（每日站會）, Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會） 。
團隊（Team）
一般情況人數在5-9人。團隊成員包括產品經理、開發(fā)人員、測試人員、前端開發(fā)、UED等。團隊成員最好都是在項目的一個sprint中是全職的， 在一個Sprint中成員不容許更換。在項目范圍內有權利做任何事情已確保達到sprint的目標；向Product owner演示產品功能。
Scrum的四個會議
Sprint計劃會議
在每個Sprint之初，由產品負責人講解需求，并由開發(fā)團隊進行估算的計劃會議。 在會議上需要： 排列需求優(yōu)先級；分析和評估產品Backlog并確定Sprint目標；計劃會議上還需要制定Sprint計劃，包括： 根據產品Backlog（User story或功能點）創(chuàng)建Sprint Backlog（即任務）；然后為Sprint backlog中的任務做估算，以小時計算；團隊成員從產品Backlog中挑選他們承諾完成的條目。
每日站會（Daily Stand-up Meeting）
團隊每天進行溝通的內部短會，因一般只有15分鐘且站立進行而得名，Team成員通常會在會議上講述如下3點內容：
1) 昨天我做了什么
2) 今天我計劃要做什么
3) 我遇到了什么問題，妨礙了我盡可能有效地工作
ScrumMaster記錄會議上提出的問題，但是不要在會議上討論和解決問題，而是要會后在找相關人員進行討論和解決。
Sprint評審會議
在Sprint結束前給產品負責人及客戶演示并接受評價的會議。
Sprint回顧會議
在Sprint結束后召開的關于自我持續(xù)改進的會議,圍繞如下三個問題進行討論：
1) 本次迭代有哪些做得好
2) 本次迭代我們在哪些方面還能做得更好
3) 我們在下次迭代準備在哪些方面改進
團隊確定問題優(yōu)先級，并根據優(yōu)先級確定Team能夠解決的Top問題；團隊討論Top問題的措施，并選擇在下一個迭代可以完成措施，分配責任人進行跟蹤
Scrum的三個關鍵WorkItem
產品Backlog
產品Backlog是從客戶價值角度理解的產品功能列表。
1) 功能、缺陷、增強等都可以是待開發(fā)項。
2) 一般以條目化的方式描述。
3) 客戶和用戶必須能夠理覽。
4) 描述怎樣使用而非怎樣制造。
5) 整體上從客戶價值優(yōu)先級排序。
6) 總工作量一般需要0.5～10人天。
7) 高優(yōu)先級的條目應有較詳盡的描述，低優(yōu)先級的條目可只有一個名稱。
沖刺（Sprint）Backlog
Sprint Backlog是從開發(fā)技術角度理解的迭代開發(fā)仸務。在簡單的純軟件環(huán)境，可以直接把產品Backlog當作沖刺待開發(fā)項分配到迭代中。在復雜的開發(fā)環(huán)境中，可以把一個產品Backlog分覽為Web/后臺……軟件/硬件……程序/美工……等開發(fā)任務。
燃盡圖（Burndown Chart）
圖形化的方式展現了剩余的工作量（y軸）與時間（x軸）的關系。剩下的工作量應該有節(jié)奏的增加或減少，并最終顯現下降的趨勢。
個人感覺要是真的敏捷起來的話是非常有好處的，這對于產品經理來說也是一個考驗，需要將所有業(yè)務需求清單梳理清楚，排定優(yōu)先級，預估工作量，迭代驗證，之前也在創(chuàng)意馬拉松ideathon2012上看到過國外的敏捷團隊如何做汽車，真正的產品敏捷確實效果非常好，不過國外的模式是否適合國內的產品研發(fā)環(huán)境，是否應該照搬，還是應該有自己特色的敏捷，需要根據實際情況來衡量，為了敏捷而敏捷反而會打亂整個產品流程，工具或者方法都得找到適合成長的土壤才能生根發(fā)芽，想要敏捷起來，首先得讓整個產品團隊都有敏捷的意識，否則就容易形式主義。個人觀點僅供參考，結合之前的《敏捷開發(fā)培訓分享》，相信大家能對敏捷有一個初步的了解了。感覺有點像先進的SAP ERP系統，卻不是每個國內企業(yè)都能用起來的。
