Scrum：兼顧計劃與靈活的敏捷開發

　　Scrum是一種兼顧計劃性與靈活性的敏捷開發過程，原詞來自於橄欖球中的“帶球過人”。在橄欖球比賽的每次衝刺前，都將有一個計劃安排的過程，但衝刺開始後則由隊員在原計劃的基礎上隨機應變。

　　不同於瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，衝刺）。

　　在日常工作時，產品負責人會維護一個按優先順序排序的“產品待開發項”（Product Backlog），即從客戶價值理解和描述的產品功能條目，通常產品經理承擔這一角色。 在每次迭代的第一天，召開Sprint計劃會(Sprint Planning Meeting)。產品負責人會逐一挑選最高優先順序的部分進行講解。團隊可就需求細節、完成標準等進行詢問，並逐條估算，放入本次迭代的開發任務中，直至任務量飽和。一旦迭代開始，這些任務將不會發生大的發化。

　　在迭代期內，團隊將決定任務分配、所需的技術等，逐一完成任務。每天團隊會進行一個簡短的站立會議即每日站會 Daily Stand-up Meeting，溝通當前進度、下一步任務和當前存在的問題，以藉助團隊的力量解決。團隊還維護一張“燃燒圖”（Burn Down Chart），即所有任務的累積剩餘時間隨開發程式與日遞減的圖形，以觀察和預測所有任務是否會按期完成。

　　在每個迭代的最後一天，團隊會召集評審會(Review Meeting)，邀請產品負責人等參加，對已經完成的產品功能條目進行評審，後者做出判斷並給出改進反饋。當天還會召開回顧會(Retrospective Meeting)，對本次迭代的成功與失敗之處做出總結，並在以後迭代中進行改進。

　Scrum中的三個角色

　　產品負責人(Product Owner)

　　主要由產品經理擔任，其為確定產品的方向和願景，定義產品釋出的內容、優先順序及交付時間，為產品ROI（profitability of product）負責。

　　主要職責包括：確定產品的功能；決定釋出的日期和 釋出內容；為產品的ROI負責；根據市場價值確定功能優先順序；每個sprint中，根據需要調整功能和優先順序（每個sprint開始前調整）；接受或拒絕開發團隊的工作成果；參與會議。

　　領隊（Scrum Master）

　　擔當團隊leader，可以是開發Leader或者Team Leader, 和Product owner緊密合作，及時為團隊成員提供幫助。

　　主要職責包括：保證團隊資源合理利用；保證各個角色及職責良好協作；解決團隊開發中的障礙；作為團隊和團隊外部的介面，協調解決溝通中的問題；保證開發過程按計劃進行，組織會議 。

　　團隊（Team）

　　一般情況人數在5-9人。團隊成員包括產品經理、開發人員、測試人員、前端開發、UED等。

　　團隊成員最好都是在專案的一個sprint中是全職的， 在一個Sprint中成員不容許更換。在專案範圍內有權利做任何事情已確保達到sprint的目標；向Product owner演示產品功能。

　Scrum的四個會議

　　Sprint計劃會議

　　在每個Sprint之初，由產品負責人講解需求，並由開發團隊進行估算的計劃會議。 在會議上需要： 排列需求優先順序；分析和評估產品Backlog並確定Sprint目標；計劃會議上還需要制定Sprint計劃，包括： 根據產品Backlog（User story或功能點）建立Sprint Backlog（即任務）；然後為Sprint backlog中的任務做估算，以小時計算；團隊成員從產品Backlog中挑選他們承諾完成的條目。

　　每日站會（Daily Stand-up Meeting）

　　團隊每天進行溝通的內部短會，因一般只有15分鐘且站立進行而得名，Team成員通常會在會議上講述如下3點內容：

1) 昨天我做了什麼

2) 今天我計劃要做什麼

3) 我遇到了什麼問題，妨礙了我儘可能有效地工作

　　ScrumMaster記錄會議上提出的問題，但是不要在會議上討論和解決問題，而是要會後在找相關人員進行討論和解決。

　　Sprint評審會議

　　在Sprint結束前給產品負責人及客戶演示並接受評價的會議。

　　Sprint回顧會議

　　在Sprint結束後召開的關於自我持續改進的會議,圍繞如下三個問題進行討論：

1) 本次迭代有哪些做得好

2) 本次迭代我們在哪些方面還能做得更好

3) 我們在下次迭代準備在哪些方面改進

　　團隊確定問題優先順序，並根據優先順序確定Team能夠解決的Top問題；團隊討論Top問題的措施，並選擇在下一個迭代可以完成措施，分配責任人進行跟蹤

　Scrum的三個關鍵WorkItem

　　產品Backlog

　　產品Backlog是從客戶價值角度理解的產品功能列表。

1. 功能、缺陷、增強等都可以是待開發項。
2. 一般以條目化的方式描述。
3. 客戶和使用者必須能夠理覽。
4. 描述怎樣使用而非怎樣製造。
5. 整體上從客戶價值優先順序排序。
6. 總工作量一般需要0.5～10人天。
7. 高優先順序的條目應有較詳盡的描述，低優先順序的條目可只有一個名稱。

　　衝刺（Sprint）Backlog

　　Sprint Backlog是從開發技術角度理解的迭代開發仸務。在簡單的純軟體環境，可以直接把產品Backlog當作衝刺待開發項分配到迭代中。在複雜的開發環境中，可以把一個產品Backlog分覽為Web/後臺……軟體/硬體……程式/美工……等開發任務。

　　燃盡圖（Burndown Chart）

　　圖形化的方式展現了剩餘的工作量（y軸）與時間（x軸）的關係。剩下的工作量應該有節奏的增加或減少，並最終顯現下降的趨勢。

　　真的敏捷起來的話是非常有好處的，這對於產品經理來說也是一個考驗，需要將所有業務需求清單梳理清楚，排定優先順序，預估工作量，迭代驗證。

　　之前也在創意馬拉松ideathon2012上，國外的敏捷團隊做汽車，真正的產品敏捷確實效果非常好，不過國外的模式是否適合國內的產品研發環境，是否應該照搬，還是應該有自己特色的敏捷，需要根據實際情況來衡量，為了敏捷而敏捷反而會打亂整個產品流程，工具或者方法都得找到適合成長的土壤才能生根發芽。

　　想要敏捷起來，首先得讓整個產品團隊都有敏捷的意識，否則就容易形式主義。