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