Nokia的Scrum標準：

迭代要有固定的時長（TimeBox），不能超過六個星期。

每一次迭代的結尾，代碼必須經過QA的測試。

Scrum團隊必須有產品負責人，而且團隊都清楚這個人是誰。

產品負責人必須有產品的Backlog，其中包括團隊對它進行的估算。

團隊必須有一個燃盡圖，而且要了解他們自己的生產效率。

在一個Sprint中，外人不能干涉團隊的工作。

Backlog是Scrum的核心，從根本上說，他就是一個需求、或故事，或特性組成的列表，并且按照重要性進行了排序，一定是客戶想要的東西，并且用客戶的語音進行描述，沒一個條目是一個故事（Story），建議每個故事包含這些字段：

ID（統一標示）

Name（名稱）

Imp（重要程度）

Est（初始估算）

How to demo（如何做演示）

Notes（其它）

每一個故事有3+1個變量（范圍、重要性、估算）+質量，無論如何不能在質量上讓步。

質量分為內部質量和外部質量：

外部質量是用戶可以感知的，如運行緩慢，讓人迷糊的界面等。

內部質量一般指用戶看不見的原素，它對系統的可維護性有深遠的影響，如系統設計的一致性、測試覆蓋率、代碼可讀性等。

記住，在松散的沙灘上永遠不能建立起精美的樓閣，經驗證明犧牲內部質量是一個糟糕透頂的想法，現在省下來的一點時間，接下來的日子，你就要一直為它付出代價。

在Scrum中一切事情都是有時間盒的，到時必須交貨。

“這個Sprint讓大家不太好過，但是我們應該看到它的正面影響，整個團隊從中獲益匪淺，下個迭代會議會更有效率?！?br />
學會按照時間盒安排工作，學會制定各種合乎情理的時間盒，這對sprint會議的長度同樣有效。

典型的Sprint時間表，每一個小時休息10分鐘：

30分鐘的總體介紹，概括產品的Backlog。

20分鐘的時間估算。

1個小時的Story選擇，計算生產率。

1個小時的站立會議安排和將故事拆分為任務。

比較理想的一個Sprint長度為3個星期，（目前公司每日的Build版本，發布到測試部進行測試，應該是一個自動化測試的過程，而人工測試的應該是每個月發布的正常版本）

半死不活的目標比什么都沒有強。

在Sprint中包含多少個故事由團隊決定，而不是產品的負責人或其它人，但是產品負責人要對sprint中放入哪些Story產生影響。

自動生成故事卡的腳本下載地址：http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html

計劃指派的點數：0、1/2、1、2、3、5、8、13、20、40、100、？、Coffee。

總結

以上是生活随笔為你收集整理的《硝烟中的Scrum和XP》书摘（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。