Scrum和XP團隊沒有時間進行理論研究。不花時間用建模工具來畫UML圖、編寫完美的需求文件，也不為了應對在可預計的未來中所有可能發生的變化而去寫程式碼。

Scrum和XP都關注如何把事情做好。

Ken Schwaber說，Scrum不是方法學，而是一個框架。

Scrum團隊尺寸（3-12人）、sprint長度（2-6個星期）；定義“完成”的不同方式；不同形式的產品backlog和sprint backlog（Excel、Jira、索引卡）；多種測試策略、演示方式、多個Scrum團隊的資訊同步方式……。 

XP實踐：每日構建，結對程式設計，測試驅動開發，等等。 

產品backlog是Scrum的核心,是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序，包含客戶想要的東西，用客戶的術語描述。通常存放在共享的Excel文件裡面，使多個使用者可以同時編輯它。其它所有的製品都放在版本控制倉庫。

故事（story），也稱backlog項，包括欄位：

ID——統一識別符號;

Name（名稱）——簡短的、描述性的故事名;

Importance（重要性）——產品負責人評出一個數值（僅指故事的重要性）;

Initial estimate（初始估算）——團隊的初步估算，最小的單位故事點（story point）,相當於一個“理想的人天（man-day）”;

How to demo（如何做演示）——描述了這個故事應該如何在sprint中演示，一個簡單的測試規範；

Notes（註解）——相關資訊、解釋說明和對其它資料的引用等；

準備Sprint計劃

1）必須存在產品backlog；

2）一個產品只能有一個產品backlog和一個產品負責人；

3）所有重要的backlog條目都已經根據重要性被評過分；

4）產品負責人應當理解每個故事的含義； 

Sprint計劃評估方式

1）可使用Jira（bug跟蹤系統）存放產品backlog；

2）可使用Excel簡單方便，直截了當；

3）可使用VersionOne、ScrumWorks、XPlanner敏捷過程工具

制定Sprint計劃（Scrum中最重要的活動），應產生的成果：

1）Sprint目標；

2）Scrum Team成員名單；

3）Sprint backlog（Sprint中包括的Story列表）；

4）Sprint演示日期；

5）Daily Scrum Meeting的時間和地點；

每個Story都含有三個變數：Scope（範圍）、Estimate（估算）、Importance（重要性），其中：

Scrum Owner：負責Scope和Importance；

Scrum Team：負責Estimate；

第四個變數Quantity（質量），包括外部質量和內部質量：

外部質量：使用者可以感知的；

內部質量：使用者看不到的要素，可維護性等問題； 

打斷沒有成果的Sprint計劃會議；

Sprint長度：就是Sprint演示日期（Sprint 計劃會議的產出），時間越短越好，公司就越來越“Agile”，時間最長為三週。

短的Sprint=短反饋週期=更頻繁的交付=更頻繁的客戶反饋=在錯誤方向上花的時間更少=學習和改進的速度更快。 

故事是可以交付的東西，是產品負責人所關心的。

任務是不可交付的東西，產品負責人對它也不關心。 

處理“我不知道今天干什麼”的情況:

1）羞辱式做法： “如果你不知道怎麼幫助團隊，我建議你還是回家去，或者看書，或者怎麼都行。要不也可以找個地方坐下，等別人需要幫忙的時候你就過去。”

2）守舊式做法：簡單給他們分配個任務了事。

3）施加同事壓力的做法： 對他們說，“Joe，還有Lisa，你們兩個可以放鬆點，我們會站在這裡慢慢等，直到你們找到幫助我們完成目標的事情為止。”

4）奴役式做法：對他們說，“你們今天可以給大夥兒乾乾雜活。倒咖啡、做按摩、清理垃圾、做午飯，一切一切大家今天讓你們做的事情。”你會驚訝的發現Joe和Lisa在霎那之間就找出了有用的技術任務

演示也叫回顧； 

堅持所有的sprint演示的理由：

1）團隊的成果得到認可；

2）其他人瞭解你的團隊在做些什麼；

3）演示可以吸引相關干係人的注意，並得到重要反饋；

4）促進不同的團隊相互交流，討論各自的工作；

5）做演示會迫使團隊真正完成一些工作，併發布。

 

Sprint演示時的注意項：

1）清晰闡述sprint目標；

2）集中精力演示實際工作的程式碼，少講廢話；

3）演示時節奏要快；

4）只說業務功能，不說技術細節；

5）可讓觀眾自己體驗一下產品；

6）儘可能少演示細碎的bug修復和微不足道的feature。

如果沒有演示，你就會發現團隊在不斷重犯同樣的錯誤。

如何組織演示：

1）根據要討論的內容範圍，設定時間為1至3個小時；

2）owner，master，team；

3）在不受干擾的地方框圖討論；

4）指定某人做祕書；

5）master展示sprint backlog，團隊幫助對sprint做總結；

6）輪流發言；

7）對比預估生產率和實際生產率，並分析差異原因；

8）master總結並給出下一sprint的改進。

可將sprint backlog分為三類，並進行討論：

1）Good；

2）Could have done better；

3）Improvement；

其中，1）和2）是回顧，3）是展望未來。

團隊通過頭腦風暴決定下一個sprint將進行哪些改進，根據最終結果選出合適的數量，不然得不償失，不一定要完成所有的改進；

在團隊間傳播經驗

1）指定一個人會參加所有的sprint回顧會議，充當知識橋樑；

2）讓每個Scrum團隊都發布sprint回顧報告。

 

學習中…

《硝煙中的Scrum和XP》下載地址：http://down.51cto.com/data/205762