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上，國外的靈活團隊做汽車，真正的産品靈活确實效果非常好，不過國外的模式是否适合國内的産品研發環境，是否應該照搬，還是應該有自己特色的靈活，需要根據實際情況來衡量，為了靈活而靈活反而會打亂整個産品流程，工具或者方法都得找到适合成長的土壤才能生根發芽。

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