2012年10月27-28日參加了優普豐組織的在北京為期2天的Certified(不是Certificated) Scrum Master認證培訓（CSM認證），收穫多多。培訓前郵件中介紹Vernon Stinebaker(史文林)老師是個精通中文的美國人，一開始以為這場培訓註定是一個老外講上一堆英文，然後有個中國人在旁邊翻譯的講座了，沒想到這個vernon中文水平真是好，正常的語速的中國話他聽得一點問題也沒有，漢語說的也是相當清楚，只有少數的字有點口音。vernon老師渾身散發著巨大的熱量（他自稱的Passion），當熱到一定程度後，vernon就把鞋拖掉，一雙白襪子開始在會議室裡走來走去。

敏捷宣言與Scrum

以前對敏捷開發有一些瞭解，最早接觸的是極限程式設計XP，知道有17位愛好滑雪的軟體人士琢磨出了著名的敏捷宣言，對一些傳統的龐大的軟體開發提出了挑戰。

敏捷Agile就像一把大傘，Scrum、XP、FDD等等都是其中的一員，Scrum是一種框架，更注重於一些過程，XP更注重於實踐。

為了明白敏捷的幾個要點，Vernon老師專門設計了一個傳遞紙球的小遊戲，準備一堆用報紙揉成的小球，參加培訓的8人為一組，圍成一圈站立，規則很簡單，只能用手傳球，球從一個人手到另一個人手之間必須有空中時間，球必須傳遞給不相鄰的人，一個球經過所有成員後才算1分，1分鐘之內傳遞小球的個數為總成績。遊戲進行了5-7輪，每輪中間有1分鐘的討論時間。

遊戲雖簡單，但卻能深刻地體會以下要點：

1）每輪的討論都能提高下一次的成績，第一輪好像只傳了6個，最後一輪傳了100多個，最後的改進幅度之大讓我們自己都無法想像

2）設計再周密的方案不如馬上動手，只有實踐起來才能提出有針對性的改進建議

3）短時間內的決策也是相當有作用的，1分鐘雖短，但短時間也同樣能激發出的大腦無窮的創造力。

4）減少每個人空閒等待的時間，並行作業讓球不停地在多個人之間快速流動，大大減少了等待的時間

5）當成績提高到一定水平後，如果不在方法或工具上出現革命性的變革，成績就不會再有多大的提高

6）把30分鐘的總時間分解為多次迭代，每個迭代中進行實踐和總結，遠遠比進行29分鐘的周密設計討論和1分鐘的實踐要有效得多。

Scrum總結起來就是3355，實際上應該稱為3455：3種角色，3種工件，4種儀式（活動）和5個價值觀。2天的課程實際上就是圍繞著334來介紹的，當然講解的過程不斷地涉及到5種價值觀的討論。

三個角色

Scrum Team由三種角色構成。

關於三種角色與龍舟比賽的類比：PO相當於舵手，把握團隊前進的方向；TEAM相當於划槳運動員；SM相當於鼓手，負責協調團隊。

1）Product Owner

客戶代表，決定產品的發展方向vision，對ROI負責（投資回報率return on investment），本身最好就是個customer，PO是一個人，負責給PBI(Product Backlog Increments）排序，負責維護Backlog，確認Sprint的結果（Accept Sprint Results），PO有權利決定是否產品可以釋出，PO不一定寫全部的使用者故事，PO要不斷與團隊溝通，PO有決定權Authority。

2）SCRUM Master

這個名稱相當有份量，參加2天的培訓，還沒有Scrum的實踐經驗，通過了認證考試，就可以稱為Scrum Master了。

我們普遍認為這個SM最沒有事情可做，但老師一再強調這個角色很忙，特別對於不成熟的團隊以及在專案的前期，我們把以前專案經理負責的事情一一寫下來，貼在這個白板上，發現這個SM好像就是事情不多，他在整個過程中就是一個教練、一個諮詢師的角色，他實際上就是輔導你如何開始正確的Scrum各個過程、會議等等。

SM在整個團隊中起到一種老師、教練、促進的作用，要保證團隊不受干擾、保證團隊高效地開展工作，移除一些障礙。他幾乎沒有什麼權利，但要有影響力。

Vernon關於在一些會議上ScrumMaster為什麼可選參加的註解：

While the ScrumMaster is optional at many meetings they are responsible for assuring the Scrum framework is being effectively applied, so as you note in the area discussing the ScrumMaster role they are likely to be quite involved in all meetings, especially initially as the team needs to be trained and coached to understand how to effectively conduct the meetings: to understand their structure and purpose.

3）DEV Team

軟體還是要由一群程式設計師一行一行寫出來，這就是Team的任務了，這裡Team中每個人的技能要掌握得全面（有專長，但不能只擅長的事），要會自我組織管理、跨職能、人數控制在5-9人之間、最好全職（可能有少量例外）、No Title（沒有嚴格的分工，沒有需求、編碼和測試的分工）。

Scrum中沒有專案經理的角色，沒有上下級的關係，vernon打了一個比喻，說Scrum有點共產主義，但共產主義中最常見的是上下級領導關係。感覺根據我們當前的現狀，三個角色最難找的是Product Owner，這個角色代表著使用者利益，但要經常與開發團隊混在一起。

三個工件

1）Product Backlog

Product Backlog = a dynamic list of features that might appear in our product.

Vernon老師的註解：

PBI=feature, A bunch of PBIs = product Backlog

It might also be worth noting that PBIs don’t have to be software. The Scrum framework can be applied to areas outside of software, so PBIs could be other product features as well; for example the introduction in a book, or a chapter in a book.

值得注意的是：PBIs並不一定專指軟體。Scrum框架可以應用於軟體之外的其它領域，因此PBIs也可以是其它產品特性，例如在出版業，可以是書的一個章節。

這個Product Backlog就是軟體產品的功能列表，由許多PBI（Product Backlog Item）組織，一個PBI又由許多SBI（Sprint Backlog Item）組成，這個Backlog要貼在一面大牆上，上課時曾經問了vernon老師，這個東西全用工具放在開發團隊的網站首頁上行不行？vernon說可以，但只用電子的backlog會影響開發效率，所以他們公司還是用大牆和便利貼，一些內容會錄入到電子backlog中。

25個小星星積木的遊戲讓人明白了優先順序的重要作用，要在最短的時間內得到的最大的收益，就是要先完成那些黑星星。

2）Sprint Backlog

這個Backlog感覺可以稱為任務了，通常PBI顆粒太大，無法執行，只有分解為SBI（小於2天的工作量）才能開始動手做。感覺這東西好像GTD裡將Project分解為Action的過程，不過任何專案也都是這樣來分解的。

3）Tracking/Increment

這個東西在以前就是指燃盡圖，現在好像說也不是必須的了，實際上Backlog也完全可以體現出專案的進展情況。

四個活動

Scrum就是由一堆的Sprint組成的，這個Sprint實際上就是迭代，每個Sprint最少為1天，最長為4周，由4個活動組成。

Vernon的註解：

In theory there is no minimum sprint duration, one day is just the shortest I’ve seen in a production environment. Sometimes in training we use 1/2 day sprints. A key concept, however, is that for a sprint to be a sprint, it must include the 4 meetings.

理論上沒有最小的sprint長度限制，一天的sprint長度是我在產品開發中看到過的最小的長度，在培訓時有時可以用1/2天作為sprint的長度。然後，一個sprint可以稱為sprint的關鍵是它必須包含4個會議。

Sprint是固定長短的，有可能第一次迭代之後，週期有點調整，但後來採用一個穩定的天數，這就是Scrum的rythym節奏。

在Sprint期間，功能範圍不再變化，即PBI從左側拿到Sprint Backlog區後，不再接受新的SBI。

Vernon的註解：

SBIs are emergent, and defined by the team, so it is quite possible that new SBIs will be added during the sprint. This is just to say that the team has developed a deeper understanding of how they will complete the PBI. So, during a sprint the SBIs can change, but the PBIs that the team has committed to cannot change. “No change” during the sprint refers to PBIs.

SBIs具有湧現性，是由團隊來定義的，因此在sprint之間會出現新的SBI。也就是說，團隊對於如何完成PBI已經有了深刻的理解，因此在sprint期間SBI是可以變化的，但團隊已經承諾的PBI不能變化。在sprint中的”No Change”是指PBI而言的。

1）Sprint Planning

這個過程有點需求分析的作用，實際上也是一種承諾Commitment。這個會議又由2個階段組成，第一階段稱為Selection，第二階段稱為Planning。

第一階段由PO、TEAM參加，SM可選。對於1周的sprint，這個階段不超過1小時。

在這一步是根據PBI的優先順序拿到Sprint backlog中，對於較大的粒度，還要分解。

第二階段由TEAM參加，PO和SM可選，但PO要隨叫隨到。對於1周的sprint，這個階段不超過1小時。

2）Daily Scrum

這就是著名的站立會議，要在每天相同的時間、相同的地點舉行，少於15分鐘。

Scrum(由於它不是一個縮寫單詞，所以一般不用大寫所有字母)的術語也是來源於橄欖球中的碰頭開球儀式，在rugby這種運動中，每個運動員都是自組織的、跨職能的，需要根據場上的動態地調整計劃。

會上要回答3個問題：

What did I get done in the last work period?

What will I get done in the next period?

Any impediment（障礙）?

通過這三個問題，團隊進行廣播式的溝通，跟蹤專案的進度，分享一些知識，更重要的是給團隊做出一種承諾Commitment。

3）Sprint Review

這種回顧對於長度為1周的sprint，不超過1小時，不需要PPT，非正式的交流。整個過程也是TEAM和PO參加，SM可選。最好還要請一些stakeholder參加。

Vernon的註解：

PO and team are required, ScrumMaster is optional. Stakeholders are encouraged to attend this meeting. Since this meeting is a key means of the PO soliciting feedback from stakeholders, their participation in this meeting is essential. The PO might even be the host/driver in this meeting.

4）Sprint Retrospective

這個會議對於長度為1周的sprint，不超過45分鐘。整個過程TEAM參加，SM和PO可選。

這個過程是為了將來的持續改進，不講壞訊息，提出1-3個改進建議，然後就是celebrate。

Vernon的註解：

The Sprint Review is the meeting where the working results of the team are shared with the stakeholders and the PO. The Sprint Retrospective is the meeting where the team considers how they can continuously improve.

The Sprint Retrospective is the meeting where the team considers how they can continuously improve. The team is required and the PO and ScrumMaster are optional (at the discretion of the team). Typically the team would encourage their participation unless the PO or ScrumMaster themselves are in some way an impediment to the team improving.

使用者故事

User Story並不是SCRUM中的內容，但可以用於SCRUM中。

PBI相當於User Story，而SBI相當於任務Task，SBI的顆粒度要小於0.5天。

Vernon的註解：

1/2 SBIs are a practice my company uses, but not a formal definition included anywhere related to either User Stories or Scrum. As you correctly note earlier in your blog, SBIs are typically 1 – 16 hours (less than 2 days) in duration. 1/2 day is just our practice.

PBI要寫到什麼程度？DEEP原則：

Detailed Appropritly 比較清晰的

Emergent 湧現性

Estimated 被估算的（以團隊的方式來估算）

Prioritized / Order 被排序的

估算

vernon老師由於散發著巨大的熱量，所以需要不停地補充水份，每天帶著一大瓶（搞不清楚2升還是3升）基本上都喝得差不多。一個遊戲就是估算他喝剩下的水的體積，8個人的估算從400ml到1600ml不等，相差如此巨大，說明了人不擅長使用絕對的數量來評估事物，而使用百分比來估算時，範圍就統一在55-65%之間。

優普豐的計劃撲克可以用於團隊對任務工作量進行評估。

—-==== Email: slofslb (GTD) qq.com 請將(GTD)換成@ ====—-
版權宣告：自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）
作者：申龍斌的程式人生

http://www.cnblogs.com/speeding/archive/2012/10/30/2746532.html