敏捷學習筆記【一】——硝煙中的Scrum和XP(上)【產品backlog、sprint計劃】

圖書封面

Scrum不是方法學，它是一個框架。也就是說Scrum不會告訴你到底該做些什麼。

產品backlog

---

產品 backlog 是 Scrum 的核心，也是一切的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序。

Initial estimate（初始估算） ——團隊的初步估算，表示與其他故事相比，完成該故事所需的工作量。最小的單位是故事點（story point），一般大致相當於一個“理想的人天（man-day）”。

sprint 計劃

---

在 sprint 計劃會議之前，要確保產品 backlog 的井然有序。

• 只能有一個產品 backlog 和一個產品負責人（對於一個產品而言）
• 所有重要的 backlog 條目都已經根據重要性被評過分，不同的重要程度對應不同的分數。
• 產品負責人應當理解每個故事的含義

注意： 產品負責人之外的人也可以向產品 backlog 中新增故事，但是他們不能說這個故事有多重要，這是產品負責人獨有的權利。他們也不能新增時間估算，這是開發團隊獨有的權利。

Sprint 計劃會議非常關鍵，應該算是 Scrum 中最重要的活動
舉辦 Sprint 計劃會議，是為了讓團隊獲得足夠的資訊，能夠在幾個星期內不受干擾地工作，也是為了讓產品負責人能對此有充分的信心。
Sprint計劃會的產出成果： 

 

• sprint 目標。
•  團隊成員名單（以及他們的投入程度，如果不是 100%的話）。
• sprint backlog（即 sprint 中包括的故事列表）。
• 確定好 sprint 演示日期。
• 確定好時間地點，供舉行每日 scrum 會議。
   

為什麼產品負責人必須參加
	範圍（scope）和重要性（importance）由產品負責人設定。估算（estimate）由團隊設定。在 sprint 計劃會議上，經過團隊和產品負 責人面對面的對話，這三個變數會逐步得到調整優化。

會議啟動以後，產品負責人一般會先概括一下希望在這個 sprint 中達成的目標，還有他認為最重要的故事。接下來，團隊從最重要的故事開始逐一討論每個故事，一一估算時間。在這個過程中，他們會針對範圍提出些重要問題：“‘刪除使用者’這個故事，需不需要遍歷這個使用者所有尚未執行的事務，把它們統統取消？”有時答覆會讓他們感到驚訝，促使他們調整估算。
           在某些情況下，團隊對故事做出的時間估算，跟產品負責人的想法不太一樣。這可能會讓他調整故事的重要性；或者修改故事的範圍，導致團隊重新估算，然後一連串諸如此類的後續反應。這種直接的協作形式是 Scrum 的基礎，也是所有敏捷軟體開發的基礎。
注意：如果產品負責人不能參加：

• 讓產品指定替代人員，且產品負責人在會議前與替代人員充分溝通到位。
• 推遲spring的啟動日期，直到產品負責人找到時間參會為止。同時拒絕承諾任何交付。
   

 為什麼不能在質量上讓步

•  外部質量是系統使用者可以感知的。執行緩慢、讓人迷糊的使用者介面就屬於外部質量低劣。
•  內部質量一般指使用者看不到的要素，它們對系統的可維護性有深遠影響。可維護性包括系統設計的一致性、測試覆蓋率、程式碼可讀性和重構等等
   

一般來說，系統內部質量優秀，外部質量仍有可能很差。而內部質量差的系統，外部質量肯定也不怎麼樣。鬆散的沙灘上怎麼可能建起精美的樓閣？

經驗告訴我：犧牲內部質量是一個糟糕透頂的想法。現在節省下來一點時間，接下來的日子裡你就要一直為它付出代價。一旦我們放鬆要求，允許程式碼庫中暗藏問題，後面就很難恢復質量了。
Scrum 中的一切事情都有時間盒。

 確定 sprint 長度

Sprint 演示日期是 sprint 計劃會議的產出物，它被確定下來以後，也就確定了 sprint 的長度。
不過，確定了自己最喜歡的長度之後，就要在長時間內堅持住。

確定 sprint 目標

Sprint 目標需要回答這個根本的問題，“我們為什麼要進行這個sprint？為什麼我們不直接放假算了？”要想從產品負責人的口中
哄騙出 sprint 目標，你不妨一字不差的問他這個問題看看。

決定 sprint 要包含的故事

決定哪些故事需要在這個 sprint 中完成，是 sprint 計劃會議的一個主要活動。更具體地說，就是哪些故事需要從產品 backlog 拷貝到sprint backlog 中。

注意：在 sprint 中包含多少故事由團隊決定，而不是產品負責人或其他人。

產品負責人如何對 sprint 放哪些故事產生影響？

 假設在 sprint 計劃會議中我們遇到下面的情況。產品負責人很失望，因為故事 D 不會被放到 sprint 裡面。那他在sprint 計劃會議上能做些什麼?

那麼如何才能把D放入當前迭代呢？

雖然產品負責人在正常情況下不能控制團隊的估算生產率，他依然有很多種方式，對 sprint 中放入哪些故事施加影響

如果產品負責人想把D放入到sprint,那他在sprint 計劃會議上能做些什麼?	首先，他可以重新設定優先順序。如果他給故事 D 賦予最高的重要級別，團隊就不得不把它先放到 sprint 裡面來	其次，他可以更改範圍——縮小故事 A 的範圍，直到團隊相信故事 D 能在這個 sprint 裡完成為止。	最後，他還可以拆分故事。產品負責人判斷出故事 A 中某些方面實際並不重要，所以他把 A 分成兩個故事 A1 和 A2，賦給它們不同的重要級別。

 

團隊怎樣決定把哪些故事放到 sprint 裡面？

 我們在這裡使用兩個技術：

• 1. 本能反應
• 2. 生產率計算

用生產率計算來估算
這項技術包括兩步：
1. 得出估算生產率
2. 計算在不超出估算生產率的情況下可以加入多少故事。
生產率是“已完成工作總量”的一個衡量方式，其中每一個條目都是用它的原始估算進行衡量的。

下圖中，左邊是 sprint 啟動時的估算生產率，右邊是 sprint 結束時的實際生產率。每個矩形都是一個故事，裡面的數字表示這個故事的原始估算。

為什麼我們在實際生產率裡面沒把它的部分故事點數算進來？這就突出表現了 Scrum 的要求（實際上也是敏捷軟體開發和精益製造的要求）：把事情完全做完！達到可以交付的狀態！事情只做了一半，它的價值就是 0（也許還會是負數）。

資源計算：

 假設我們在計劃一個4人團隊3個星期的sprint（15個工作日）。Lisa 會休假兩天。 Dave只能投入 50%的時間，另外還會休假一天。把這些加到一起……

這個 sprint 一共有 50 個可用的人-天。我們估算的單位是故事點，差不多可以對應於“理想化的人-天”。一個理想化的人-天是完美、高效、不受打擾的一天，但這種情況太少見了。我們還必須考慮到各種因素，例如要把未計劃到的工作新增到 sprint 中、人們患病不能工作等等。
那我們的估算生產率肯定要比 50 少了。少多少呢？我們引入“投入程度（focus factor）”這個詞來看一下。

投入程度（focus factor）= 實際生產率(actval velocity)(完成的故事點數) / 可用人天（Available Man-days）

投入程度用來估算團隊會在 sprint 中投入多少精力。投入程度低，就表示團隊估計會受到很大干擾，或者他們覺得自己的時間估算太過理想化。要想得出一個合理的投入程度，最好的辦法就是看看上一個 sprint的值（對前幾個 sprint 取平均值自然更好）。

假設在上個 sprint 裡面，由 Tom， Lisa 和 Sam 組成的 3 人團隊在 3個星期內工作了 45 個人-天，一共完成 18 個故事點。現在我們要為下一個 sprint 估算一下生產率。新夥計 Dave 的加入讓情況更復雜了。把假期和新成員算上，我們在下個 sprint 中一共有 50 個人-天。

從上面的公式中可以看出，下個 sprint 的估算生產率是 20 個故事點。這表明團隊這個 sprint 中所能做的故事點數之和不能超過 20。
在新團隊中使用的“預設”投入程度通常是 70%，因為這是其他大多數團隊都能達到的數值。
 

我們為何使用索引卡

在大多數 sprint 計劃會議上，大家都會討論產品 backlog 中的故事細節。對故事進行估算、重定優先順序、進一步確認細節、拆分，等等都會在會議上完成。要想收到好的效果，不妨建立一些索引卡， 把它們放到牆上（或一張大桌子上）。

 這種使用者體驗比計算機和投影儀好得多。原因是：

• 大家站起來四處走動=> 他們可以更長時間地保持清醒，並留心會議進展。
• 他們有更多的個人參與感（而不是隻有那個拿著鍵盤的傢伙才有）。
• 多個故事可以同時編輯。
• 重新劃分優先順序變得易如反掌——挪動索引卡就行。
• 會議結束後，索引卡可以拿出會議室，貼在牆上的任務板上。

 定義“完成”

 有一點很重要：產品負責人和團隊需要對“完成”有一致的定義。
所有程式碼被 check in 以後，故事就算完成了嗎？還是被部署到測試環境中，經過整合測試組的驗證以後才算完成？我們儘可能使用這樣的定義：“隨時可以上線”，不過有時候我們也這樣說：“已經部署到測試伺服器上，準備進行驗收測試”。

 使用計劃紙牌做時間估算

 估算是一項團隊活動——通常每個成員都會參與所有故事的估算。

•  在計劃的時候，我們一般都還不知道到底誰會來實現哪個故事的哪個部分。
•  每個故事一般有好幾個人蔘與，也包括不同型別的專長（使用者介面設計、程式設計、測試、等等）。
•  團隊成員必須要對故事內容有一定的理解才能進行估算。要求每個人都做估算，我們就可以確保他們都理解了每個
• 條目的內容。這樣就為大家在 sprint 中相互幫助夯實了基礎，也有助於故事中的重要問題被儘早發現。
• 如果要求每個人都對故事做估算，我們就會常常發現兩個人對同一個故事的估算結果差異很大。我們應該儘早發現這種問題並就此進行討論

計劃撲克能夠避免成員之間對估算時間的相互影響

 有些卡片比較特殊：

• 0 = “這個故事已經完成了”或者“這個故事根本沒啥東西，幾分鐘就能搞定”。
• ? = “我一點概念都沒有。沒想法。”
•  咖啡杯 = “我太累了，先歇會吧。”

 把故事拆分成任務

 “任務”和“故事”的區別是什麼呢？故事是可以交付的東西，是產品負責人所關心的。任務是不可交付的東西，產品負責人對它也不關心

 

定下每日例會的時間地點

 Sprint 計劃會議有一個產物常常被人們忽略：“確定的時間和地點，以供舉辦每日例會”。沒有這一點，你的 sprint 就會有個“開門黑”。實際上，每個人都是在當前 sprint 的第一個每日例會上決定怎樣開始工作。

我們的預設做法是選一個大家都不會有異議的最早時間。一般是9:00， 9:30 或者 10:00。最關鍵的是，這必須是每個人都能完全接受的時間。

 生成sprint 資訊頁

如果需要，可以生成本次sprint的資訊頁發給部門其他團隊和相關人員，好讓公司知道我們在什麼。

“sprint資訊頁”包括本次迭代的目的、待辦事項列表、計劃速率、關鍵節點計劃、團隊成員及參與度說明

 到次sprint會試就結束了。