Jen-Chieh Ko, profile picture
Uploaded byJen-Chieh Ko
445 views

Scrum和XP 的實戰經驗 (第二版)

本书由Henrik Kniberg撰写，详细描述了Scrum与XP的实践经验，旨在帮助团队有效实施敏捷软件开发。书中提供了实际案例和最佳实践，强调团队如何管理产品Backlog、进行Sprint规划以及展示成果。通过遵循这些实践，团队能够提高工作效率，并吸引投资者的关注。

Embed presentation

Download to read offline
1 / 168
2 / 168
3 / 168
4 / 168
5 / 168
6 / 168
7 / 168
8 / 168
9 / 168
10 / 168
11 / 168
12 / 168
13 / 168
14 / 168
15 / 168
16 / 168
17 / 168
18 / 168
19 / 168
20 / 168
21 / 168
22 / 168
23 / 168
24 / 168
25 / 168
26 / 168
27 / 168
28 / 168
29 / 168
30 / 168
31 / 168
32 / 168
33 / 168
34 / 168
35 / 168
36 / 168
37 / 168
38 / 168
39 / 168
40 / 168
41 / 168
42 / 168
43 / 168
44 / 168
45 / 168
46 / 168
47 / 168
48 / 168
49 / 168
50 / 168
51 / 168
52 / 168
53 / 168
54 / 168
55 / 168
56 / 168
57 / 168
58 / 168
59 / 168
60 / 168
61 / 168
62 / 168
63 / 168
64 / 168
65 / 168
66 / 168
67 / 168
68 / 168
69 / 168
70 / 168
71 / 168
72 / 168
73 / 168
74 / 168
75 / 168
76 / 168
77 / 168
78 / 168
79 / 168
80 / 168
81 / 168
82 / 168
83 / 168
84 / 168
85 / 168
86 / 168
87 / 168
88 / 168
89 / 168
90 / 168
91 / 168
92 / 168
93 / 168
94 / 168
95 / 168
96 / 168
97 / 168
98 / 168
99 / 168
100 / 168
101 / 168
102 / 168
103 / 168
104 / 168
105 / 168
106 / 168
107 / 168
108 / 168
109 / 168
110 / 168
111 / 168
112 / 168
113 / 168
114 / 168
115 / 168
116 / 168
117 / 168
118 / 168
119 / 168
120 / 168
121 / 168
122 / 168
123 / 168
124 / 168
125 / 168
126 / 168
127 / 168
128 / 168
129 / 168
130 / 168
131 / 168
132 / 168
133 / 168
134 / 168
135 / 168
136 / 168
137 / 168
138 / 168
139 / 168
140 / 168
141 / 168
142 / 168
143 / 168
144 / 168
145 / 168
146 / 168
147 / 168
148 / 168
149 / 168
150 / 168
151 / 168
152 / 168
153 / 168
154 / 168
155 / 168
156 / 168
157 / 168
158 / 168
159 / 168
160 / 168
161 / 168
162 / 168
163 / 168
164 / 168
165 / 168
166 / 168
167 / 168
168 / 168
Scrum 和 XP 的實戰經驗 我們如何進行 Scrum 第⼆版 - 導演完整版 Henrik Kniberg 著
© 2007 C4Media Inc 版權所有 C4Media，是 InfoQ.com 的一家出版商。 這本書是 InfoQ 所出版企業軟體開發叢書的一部分。 如果要購買這本書籍或是其他 InfoQ 的書籍，請聯絡 books@c4media.com。 根據第 107 或 108 條的 1976 年美國版權法，未經過出版商事先書 面允許，本書任何部份不得用於再印刷，或是儲存於可重複使用的 系統，或者以任何方式進行電子、機械、影印、錄製、掃描、或其他形 式的傳播。 公司使用的名稱來區分他們的產品，這些名稱往往被稱作為商標。 在所有情況下，C4Media 公司要求，產品名稱需要第一個字大寫或 全部大寫。然而，讀者應聯絡適當的公司，去得到更完整的資料、 商標及註冊。 英文責任編輯： Diana Plesa 美國國會圖書館編目中，出版物資訊： ISBN： 978-1-4303-2264-1 本書在美國印製
致謝 這本書的初稿僅花了一個週末去打字，但是這是一個工作密集的週 末！ 150%的投入程度 :o) 感謝我的老婆 Sophia， 和我的小孩 Dave 與 Jenny，忍受我那個週末 要工作。同時也感謝 Sophia 的父母 Eva 和 Jörgen，過來幫忙照顧我 們家。 還要感謝我在斯德哥爾摩 Crisp 工作的同事，還有在 Yahoo 的 scrumdevelopment group 中的人們，一起校稿並且幫忙改進這本書。 最後，感謝我所有的讀者，長期提供一些有用的回饋。我特別高興 地聽到，本文引起這麼多人，對於敏捷軟體開發的熱情！
目錄 序 - JEFF SUTHERLAND i 序 - MIKE COHN iii 第⼆版 - 導演完整版 1 簡介 9 免責聲明 10 為什麼我要寫這本書 10 但是什麼是 Scrum？ 10 我們如何紀錄產品的 Backlog 11 故事中其他的欄位 13 如何讓我們的產品 Backlog 保留在商業應用層次 14 我們如何準備 Sprint 的規劃 16 我們如何產生 Sprint 計畫 18 為什麼產品負責人需要參加 18 為什麼品質是不可被談判的 20 永無止境的 Sprint 規劃會議… 21 Sprint 規劃會議的議程 23 訂定 Sprint 的長度 24 定義 Sprint 的目標 25 決定在這次 Sprint 要做哪些故事 26 產品負責人如何影響哪些故事要放在這次 Sprint 中？ 27 團隊如何決定哪些故事要放到這個 Sprint 中？ 28 我們為什麼要使用索引卡 34 “做完”的定義 38 使用計畫紙牌來做時間規劃 38 釐清故事內容 41 把故事拆解成更小的故事 42 把故事拆解成任務 43 定義每日會議的時間和地點 44 哪裡是最後的底限 45
技術性的故事 46 錯誤追蹤系統 vs. 產品 backlog 48 Sprint 規劃會議終於結束了！ 49 我們如何溝通我們的 Sprints 52 我們怎麼撰寫 Sprint backlogs 55 Sprint backlog 的存放方式 55 如何讓任務板發揮作用 57 範例 1 – 在每日會議結束後 58 範例 2 – 在幾天之後 59 任務板上的警訊 62 嘿，要如何追蹤？！ 64 用天數來評估 vs. 用小時來評估 64 我們如何安排團隊的座位和空間 66 設計的角落 66 讓團隊坐在一起！ 68 讓產品負責人坐在隔壁間 69 讓經理和教練坐在隔壁間 69 我們怎麼進行每日會議 72 我們如何更新任務板 72 處理遲到的傢伙 73 處理"我不知道今天要做什麼"的狀況 74 我們怎樣進行 Sprint 的展示 77 為什麼我們堅持所有的 Sprint 在結束前都要展示 77 Sprint 展示的檢查清單 78 處理"無法展示"的項目 79 我們如何做 Sprint 回顧 80 為什麼我們堅持所有團隊都要做回顧會議呢？ 80 我們如何組織回顧會議 81 在團隊間散播所學到的教訓 83 改變，或不改變 84 在回顧會議中，所發現問題的範例 84 Sprint 之間的休息時間 88 我們如何做發佈計畫和處理固定價格的合約 91
定義你的驗收門檻 91 對最重要的項目作時間的估算 92 估算速度 94 在發佈計畫中考量所有因素 95 調適發佈計畫 96 我們如何結合 Scrum 和 XP 98 搭檔編程 98 測試驅動開發(TDD) 99 漸進式設計 102 持續整合 102 程式碼集體共有權 103 資訊化工作場所 103 編碼規範 104 可持續的開發速度/精力充沛的工作 104 我們怎樣做測試 106 您可能無法擺脫驗收階段 106 縮短驗收測試階段 107 藉由把測試人員放到 Scrum 團隊中來提高品質 108 藉由在 Sprint 中做較少的工作來提高品質 111 驗收測試應該是 Sprint 的一部分嗎？ 111 Sprint 週期 v.s. 驗收測試週期 112 不要讓最慢的一個連結從你的環節中斷掉 116 回到現實 117 我們怎樣處理多個 Scrum 團隊 120 要建立多少團隊 120 為什麼我們要導入"團隊領導"的角色 125 我們如何配置人手到團隊中 126 要不要有特別的團隊？ 128 是否在 Sprints 之間重新組織團隊？ 131 兼職的團隊成員 132 我們如何進行 Scrum-of-Scrums 133 交錯的每日會議 135 救火團隊 136 是否要拆解產品 backlog？ 137
程式碼分支 142 多個團隊的回顧會議 143 我們如何管理分散在不同地理位置上的團隊 146 境外經營 147 在家工作的團隊成員 149 Scrum master 的檢查清單 151 Sprint 開始階段 151 每一天 151 在 Sprint 結束的時候 152 臨別贈言 153 推薦閱讀 156 關於作者 158
序 - Jeff Sutherland 團隊需要知道 Scrum 的基本知識。像是如何建立和估算一個產品 backlog？如何把它轉換成 Sprint 的 backlog？如何管理燃燒圖和計算 你團隊的速度？ Henrik 的書可當作一個基本實踐的入門工具，幫助 團隊從嘗試 Scrum 的程度，到可以把 Scrum 執行的很好的地步。 對於要投資軟體團隊的公司，良好的 Scrum 執行狀況變得很重要。 身為一個創業投資集團的敏捷教練，我為了幫助他們達成投資的目 標，我建議只投資執行敏捷方法情況良好的公司。集團中的資深合 夥人，向所有待投資的公司詢問，他們是否知道他們團隊目前的速 度，目前他們都很難回答這個問題。為了要得到能進一步被投資的 機會，開發團隊需要了解，他們自己軟體生產率的速度。 為什麼這件事這麼重要？如果團隊不知道自己的速度，產品負責人 無法公佈產品的路線，及其可靠的發佈時間。如果沒有可靠的發佈 日期，該公司可能會失敗，投資者可能會失去他們的錢！ 不管你的公司是大是小，是新是舊，有資金或沒資金，都會面臨這 個問題。最近在倫敦的會議中，有討論 Google 實施 Scrum 的狀況。 那時我詢問 135 個聽眾，有多少人在使用 Scrum，只有 30 個人舉手。 接著我問他們是否根據 Nokia 的標準來做反覆式開發。反覆式開發 是敏捷宣言的基礎，能及早並頻繁地交付可運作的軟體。Nokia 花了 幾年的時間，和幾百個 Scrum 團隊進行了許多回顧會議，對反覆式 開發規範出許多基本的需求： • 每次循環必須有固定的時間框(time boxes)，並且要小於 6 個 禮拜。 • 在每個循環結束後，程式必須被 QA 測試過並且能運作正常。
ii | SCRUM 和 XP 的實戰經驗 在 30 個有使用過 Scrum 的人中，只有一半的人說，他們有滿足 Nokia 標準，以及敏捷宣言的第一個準則。然後我問他們是否滿足 Nokia 的 Scrum 標準： • Scrum 團隊必須要有產品負責人，並且大家都知道他是誰。 • 產品負責人必須有一個產品 backlog，並且已經由團隊估算 過。 • 團隊必須有燃燒圖，可以知道他們的速度。 • 在 Sprint 的過程中，必須沒有外面的團隊來干擾他們。 在 30 位有使用過 Scrum 的人中，只有 3 位滿足 Nokia 對 Scrum 團隊 的測試。所以只有這些團隊，可以在將來得到我合資夥伴的錢了。 Henrik 這本書的價值在於，如果你遵照他所提出的實踐，你將會有 產品 backlog，產品 backlog 的估算，燃燒圖，並且知道你團隊的速 度，與其他許多重要的實踐。然後你將會通過 Nokia 對 Scrum 團隊 的測試，並且值得對你的工作做出投資。假如你是一個剛創業的公 司，可能還會收到創投集團的資金。你或許會是軟體開發的未來， 成為下一代領導軟體產品的創建者。 Jeff Sutherland, Ph.D.，Scrum 的共同創始人
序 - Mike Cohn Scrum 和 XP 都要求團隊在每次循環結束後，都完成某些實際可交付 的工作片段。這個循環被設計成要短，要有時間框。在短時間內， 將火力集中去交付可運作的程式碼，這意味著 Scrum 和 XP 沒有時間 研究理論。他們不致力於用工具去繪製完美的 UML 模型，或是撰寫 完美的需求文件，或編寫能應付所有未來變化的程式碼。反而， Scrum 和 XP 團隊著重於把事情做完，他們可以接受過程中有犯錯， 但是他們知道找到錯誤最好的方法，就是實際去做它，開始去建構 產品，而不是停留在理論階段的分析和設計。 這本書與眾不同之處，就著重在實踐而不是理論。Henrik Kniberg 知 道這些對初學者來說特別有用。他並不對 Scrum 是什麼，提供長篇 大論的描述，他只是提供一些網站給我們參考。反之，Henrik 一開 始就立即描述他的團隊如何管理，如何處理產品 backlog。從這裡他 又接著述說成功的敏捷專案，其他所有要素和實踐。沒有任何理論， 沒有任何參考的東西，沒有註腳，沒有廢話。Henrik 的書不是從哲 學的角度上來做解釋 Scrum 為什麼可行，或是為什麼你可以嘗試這 樣做或那樣做。它只是描述成功的敏捷團隊如何運作。 這是為什麼這本書的副標題 - "我們如何進行 Scrum" - 是如此洽當。 它可能不是你執行 Scrum 的方式，它只是 Henrik 的團隊進行 Scrum 的方式。你可能會問，為什麼你應該關心其他團隊如何進行 Scrum。 你是應該關心的，因為藉由聽到別人如何進行的故事，尤其是做的 很成功的案例，我們可以學習如何做的更好。這不是，也永遠不會 是"Scrum 最佳實踐"清單，因為團隊和專案的背景勝過其他一切考量。 與其是最佳實踐，我們應該要知道什麼是好的實踐，以及在什麼狀 況下它可以適用。讀過夠多成功團隊的故事，以及他們如何做事， 你將會準備好，去面對你實施 Scrum 和 XP 所面臨的困難。 Henrik 提供了很多好的實踐，以及對應使用的狀況。幫助我們學習 如何更有效地，在我們的專案中執行 Scrum 和 XP。 Mike Cohn "Agile Estimating and Planning"和"User Stories Applied for Agile Software Development"的作者
前言 - 嘿，Scrum 是可行的！ Scrum 是可行的！至少在我們這裡是這樣的(這裡是指我們在斯德哥 爾摩的客戶，但是我在這裡不會提到他們的名字)。希望它對你們也 一樣可行的！也許這篇文章能一路上幫助著你。 這是第一次，我看到一個開發方法論(抱歉，Ken，它是一個框架)， 離開書本後仍可以運作的很好，拿來就可以直接使用。所有人- 開發 人員，測試人員，經理 - 都很高興，它幫助我們脫離了困難的狀況， 儘管市場動盪嚴重和不斷地裁減人員，我們仍能集中精神在要處理 的事情上。 我不應該說我為此感到很驚訝，但是，是的，我確實是這樣。一開 始看了幾本書之後，覺得 Scrum 看起來挺好的，但是太好到不像是 真的(我們都知道"當某些事情看起來好到不像是真的…"，是在說什 麼 )，所以我有理由去懷疑它。但是在使用 Scrum 一年後，我充分地 被它吸引注了(大部分我的團隊成員也是如此)。如果沒有足夠的理由， 我之後新的專案，預設都會繼續使用 Scrum。
前言 – 第二版 八年已經過了，這本書仍然受到歡迎。哇，我從沒想過，這本小書 能產生這麼大的影響。在很多地方，我仍然遇到很多團隊，經理， 教練，和訓練師，把它當成敏捷軟體開發的主要指南。 但是，這本書是我在 2007 年所學到的東西，所以這本書需要更新。 看因為出版了這本書，讓我有機會和許多敏捷和精實思維的領袖一 起工作，甚至有些變成我個人的心靈導師。特別感謝 Jeff Sutherland， Mary and Tom Poppendieck，Jerry Weinberg,，Alistair Cockburn， Kent Beck，Ron Jeffries，以及 Jeff Patton - 我不能想到有更好的顧問 團體。 此外，我還有些機會去幫助許多公司，去把這些想法實際上給做出 來: 不管是處於危機中的公司，或是超級成功的公司都一樣，都想要 變成更好。總而言之，它是一個非常令人興奮的旅程！ 當我重讀這本書時，我很驚訝有不少地方我還是認同。但是還是有 些頁面我想要拿掉。想說”當初是見鬼了，為什麼我會這樣想，不應 該這樣做，應該還有更好的方法 !” 因為這本書是真實世界的案例，我無法改變故事內容，怎麼發生就 是怎樣發生。但是我可對它給些註解！ 所以這就是第二版要講的 - 原先版本的註解版。就像是導演完整版。 把它想成當你在讀這本書時，我站在你肩膀後面，對這些內容解釋， 對你歡呼，偶而參雜著笑聲和抱怨聲。 這裏讓你知道這個註解版看起來會是怎樣。在陰影框中是我對第二 版的註解和反思。其他的部分(除了這個前言外) 則是跟原先一樣， 沒有修改。
vi | SCRUM 和 XP 的實戰經驗 我還列了一些別的公司的範例，大部份是 Spotify (因為我大部份的 時間都花在那邊) ，但是還有其他公司的。 好好享受 Henrik，三月 2015
1簡介 你即將在你的組織中開始使用 Scrum，可能你已經使用了 Scrum 好 幾個月，或者你已經有些基本知識，也許你已經讀過幾本書，更或 者可能你已經拿到 Scrum Master 的認證。恭喜！ 但是你可能還是感到非常困惑。 用 Ken Schwaber 的話來說，Scrum 不是一個方法學，它是一個框架 (Framework)。也就是說 Scrum 不會馬上告訴你，你要做什麼。該死！ 好消息是我將告訴你，我如何來執行 Scrum，以及詳細痛苦折磨的 過程。壞消息則是，這只是我執行 Scrum 的方式，這並不意味你應 該和我做的方法一樣。事實上，如果我遇到不同的狀況，我可能會 用不同的方法來實踐。 Scrum 的強處和痛苦的地方，就是你被迫需要根據你自己特殊的狀 況，來進行調整。 我目前的方法，是過去一年來，大約四十人的開發團隊對 Scrum 的 實驗結果。公司那時處於艱苦的狀態，大家一直加班，產品有品質 的問題，很多人持續救火，一直錯失交付日期。公司已經決定使用 Scrum，但是並沒有真正的實行。對他們來說，那只是我的工作而已。 那時對於開發團隊的大部分人來說，Scrum 只是一個陌生的時髦術 語，可以常常在走廊上聽到它。但是對他們的日常工作來說，並沒 有任何關連或影響。 經過一年以上的時間，在公司中各個階層裡，我們都實踐了 Scrum。 我們試過不同的團隊大小(3-12 人)，不同的 Sprint 長短 (2-6 個禮拜)， 不同定義"作完"的方式，不同產品 backlog 和 Sprint backlog 的紀錄格 式(Excel，Jira，索引卡)，不同的測試策略，不同的方式進行展示， 不同的方法來同步多個 Scrum 團隊的訊息，等等。我們還嘗試了 XP 的實踐 - 各種不同方式來進行持續建構，搭檔編程，測試驅動開發 等等，以及如何把 XP 和 Scrum 結合。
10 | SCRUM 和 XP 的實戰經驗 這是一個持續學習的過程，所以故事不是到這裡就結。我相信如果 公司保持學習(如果他們持續進行 Sprint 回顧會議)，則在他們各自的 環境下，要如何執行 Scrum 才會最佳，他們將會獲得新的見解。 免責聲明 這份文件並不是告訴你如何以"正確"的方式來做 Scrum，它只是說明 某一種方式去做 Scrum，並且這是我們一年來，持續調整的結果。 當然你也可以說，我們作法完全是錯的。 在書中所說的每件事情，都是我個人的觀點，不代表 Crisp 或是我目 前客戶的官方意見。為此我避免提到任何產品或是人名。 為什麼我要寫這本書 在學習 Scrum 的時候，我讀過了幾本 Scrum 和 XP 書籍，瀏覽了許 多 Scrum 的網站和論壇，參加 Ken Schwaber 的 Scrum 認證課程，用 許多問題刁難他，花很多時間和我的同事進行討論。然而，在許多 資訊來源中，我感到最有價值的，是來自真正實戰的故事。這些實 戰的經驗把準則和實踐變成…嗯…你怎麼真的動手去做它。他們幫 助我去辨識出(有時候是避免)Scrum 新手容易犯的錯誤。 所以，這次該我做些事情來回饋了，以下就是我的實戰經驗。 我希望這本書，對於有相同經驗的人，可以促使他們提出一些回饋， 請記得要啟發我！ 但是什麼是 Scrum？ 哦，對不起，你完全對 Scrum 或 XP 很陌生嗎？ 那你可能要先去看 一下這些的連結： • http：//agilemanifesto.org/ • http：//www.mountaingoatsoftware.com/scrum • http：//www.xprogramming.com/xpmag/whatisxp.htm 看一下 Scrum Guide，它現在是 Scrum 的官方說明書，由 Jeff Sutherland 和 Ken Schwaber 所維護。 http://www.scrumguides.org 如果你沒有耐心去看它們，哪就隨你的意繼續往下看吧。大部分 Scrum 的術語，會在中間的過程中解釋，所以你仍然會感興趣的。
2我們如何紀錄產品的 Backlog 產品的 backlog 是整個 Scrum 中的核心，也是所有東西的起源。 嗯，不，產品 backlog 並不是起源。一個好的產品開始於客戶的需 求，以及如何解決它的願景。產品的 backlog 是將願景提煉成具體 交付項目的結果。這個從願景轉換成 backlog 的旅程，是相當複雜 的，需要用到許多技巧來填補這個差距。像是使用者故事地圖(唸 一下 Jeff Patton 的書，非常棒!)、精實用戶體驗、影響地圖等等。 但是不要因此藉故要做大規模的事前設計! 讓產品 backlog 是逐漸 地被浮現出來，就像其他東西一樣。 基本上來說，它是由需求、故事或是功能等，所組成的一個依重要 性排列的列表。它裡面是用客戶的術語，來描述客戶所想要的東西。 我們稱這些叫做故事(Stories)，有時候也叫做 backlog 項目。 我們的故事包含以下欄位： § 編號(ID) – 一個唯一的識別號碼，號碼會自動增加。若是我 們之後改變故事名稱，它可以避免我們找不到。 § 名稱(Name) – 由簡潔、有敘述性的句子來表示故事。例如： “查看交易的歷史紀錄”。它必須要夠清楚，才能讓程式設 計師和產品負責人，大致了解我們講的東西是什麼，並且也 可清楚區分和其它故事的差別。正常來說，大約是由 2~10 字所組成。 § 重要性(Importance) – 產品負責人評估故事的重要性。例如： 10 或是 150，數字越高代表越重要。 o 企圖避免使用"優先順序(Priority)"這個說法。通常 1 代表最高優先順序，可是後來如果有其它更重要的 事情，那它的優先順序應該要是什麼？ 要給 0 或是-1？
12 | SCRUM 和 XP 的實戰經驗 § 初始估算(Initial estimate) – 只是團隊最初對它的估算。認為 與其它故事相比，完成這個故事所需要付出的代價為何。最 小單位是用故事點數 (story point) 來表示。通常會用多少人 天來約略估算。 o “如果有適當的人員來開發這個故事(不會太多也不 會太少，通常是兩位)，並且把他們關到一間房間， 有很多食物，然後沒有打攪。那需要幾天才能交出 一個完整、可以展示、並且已經經過驗證的、可以 交付的實作結果呢？”如果答案是“把三個人關在 一起，大約需要 4 天”，則故事點數的初估值就是 12。 o 重要的是，這裡並不是絕對值(也就是 2 個故事點數 就是代表要花兩天)，而是一個相對值。(也就是說， 2 個故事點數所要花的時間，會是 4 個故事點數的一 半)。 § 如何展示 (How to demo) –大略描述這個故事，在 Sprint 的展 示會議上要如何被展示。它基本上是一個簡單的測試規格書。 “先做這個，再做那個，然後這個功能就完成”。 o 如果你有實作測試驅動的開發方式(TDD) ，那麼這段 說明就可以變成你驗收測試程式的虛擬碼(pseudo code) 。 § 註解(Noes) – 其他相關的資訊、解釋、參考資料等等， 一般 來說都很簡短。 產品 BACKLOG (範例) ID Name Imp Est How to demo Notes 1 存款 30 5 Log in，登入，打 看存款頁面，存入 €10 歐元，到帳戶 餘額頁面，檢查是 否已增加€10 歐 元。 需要 UML 的循序圖。 目前不需要 考慮加密的 問題。 2 查看交易的 歷史紀錄 10 8 登入，點選“交 易”，存入一筆款 項，回交易頁面， 檢查是否有新的交 易顯示。 使用分頁的 技術以避免 大量資料的 查詢。查看 使用者資料
我們如何紀錄產品的 Backlog | 13 的頁面也有 類似的設 計。 我們嘗試過很多欄位，但是最後發現，上面這六個欄位，是我們實 際上有一直採用下去。 有兩件事情我現在幾乎以不同方式來進行。首先，沒有 ”重要性” 這個欄位。取而代之的，我只對這個清單排序。所有的 backlog 管 理工具都有拖拉排序的功能。(即使 Excel 和 Google 電子表格都有 這功能，只要你知道它神秘的加速鍵為何) 這樣比較簡單又快速。 其次，沒有人天。評估是用故事點數，或是 T-shirt size (S/M/L)來 表示，或是都不做評估。但是後者比較多。 通常我們會把它存放在共享的 Excel 中 (這樣可以多個使用者，同時 去編輯它)。依官方說法，產品負責人擁有和負責這份文件，但是我 們並不想讓其他人不能接觸它。因為很多時候，測試開發人員需要 查詢這份文件，以釐清一些事情，或是改變原先的估算。 同理，我們並沒有把它放在版本控制工具的資料庫中。相反的，我 們把它放到共用的檔案夾中。這樣是最簡單方法，可以避免在同時 編輯下，造成 lock 或是 merge 的問題。 但是，大部分其他文件，我們都有還是有保留在版本控制工具的資 料庫中。 Excel，哈? 喔，那已經是過去的日子了。我現在已經不會再考慮 使用 Excel 來管理 backlog，除非它是一個不確定的版本。產品 backlog 需要以線上文件的方式存在，好讓每個人可以同時存取和 容易修改。可以從眾多的backlog 管理工具中找個來用 (Trello， LeanKit 和 Jira 都很流行)，或者 Google 的電子表單也可以 (非常 務實！)。 故事中其他的欄位 有時候我們會使用其他欄位，方便讓產品負責人來判斷優先順序。
14 | SCRUM 和 XP 的實戰經驗 § 軌道(Track) – 對這故事的簡單分類，像是：“後端系統”、 或是“最佳化”。產品負責人可以容易過濾出，屬於“最佳 化”種類的故事出來，然後把他們的優先順序設定比較低。 § 元件(Components) – 通常會利用 Excel 中的 checkboxes 來實 現。例如：“database，server，client”。這裡整個團隊或是 產品負責人，可以標示哪個技術元件可以用來實作這個故事。 當你有多個 Scrum 團隊時，這是非常有用的一個技巧。像是， 後端系統的團隊，客戶端系統的團隊，可以很方便讓每個團 隊知道，他們需要實作哪些故事。 § 請求者 (Requestor) – 產品負責人可以記錄，起初是哪個客 戶，或是關係厲害人提出這項需求，以方便日後回報目前處 理的進度。 § 錯誤追蹤代碼 (Bug tracking ID) – 如果你有錯誤追蹤系統， 像是我們用 Jira 一樣，方便讓你追蹤故事和錯誤案例之間的 關連。 如何讓我們的產品 Backlog 保留在商業應用層次 如果產品負責人有技術的背景，那他可以添加一個故事：“把 Event 表格增加索引”。為什麼他需要這個呢？背後真正的原因，可能是 希望在後端系統中，加快搜尋事件表單的反應速度。 但也有可能完全並不是那麼回事，表單變慢的瓶頸不見得是索引的 問題。所以產品負責人還是只關注在商業的需求上面，而開發團隊 才是解決這些技術問題的合適人選。 當我看到一些技術導向的故事出現，我一般都會問產品負責人，一 些“但是為什麼呢？(but why)”的問題，直到我們真正了解潛在的目 地為止。然後才用真正的目的，來改寫這個故事(加快後端系統中， 搜尋事件表單的反應速度)。原先技術導向的敘述只會放在註解中以 供參考 ("對 event 表格增加索引可能會解決這個問題")。 有一個古老但是行之有年的樣板：“身為 X 角色，我想要 Y，所以 Z” 。例如 “身為一個購物者，我想要儲存我的購物車內容，所以我 明天可以繼續購物”。我很驚訝我在 2007 年時沒有知道這個！如 果有知道就太方便了。是的，現今已經有很多精心設計的樣板，但 是這個簡易的做法是一個很好起始點，特別是當團隊還對敏捷不熟 悉時。這個樣板可以迫使你問些正確的問題，減少你陷在技術細節 的風險裡。
我們如何紀錄產品的 Backlog | 15
3我們如何準備 Sprint 的規劃 是的，Sprint 規劃會議這一天很快的到來。我們有個一而再學到的教 訓是： 教訓：在 Sprint 規劃會議之前，要確認產品 backlog 是井井有條的。 但願如此！我看過許多 sprint 規劃會議炸掉，是因為產品 backlog 是一個爛攤子。你知道這個名言 ”垃圾進 = 垃圾出” 嗎？沒錯。 這是代表什麼意思呢？是要所有的故事都必須被完美的定義嗎？還 是所有的估算都必須準確無誤？或者是所有優先順序都要被固定下 來？不，不，並不是這樣的！它的意思是： § 產品的 backlog 必須存在！(你能想像的到這一點嗎？) § 要有一個產品 backlog 和一個產品負責人 (對於每個產品而 言)。 § 所有重要的 backlog 項目，應該要被設定其重要等級，不同 重要程度有不同的等級。 o 事實上，如果所有不重要的項目，有相同的評定分 數，這是不要緊的。因為目前這次的 Sprint 規劃會議 上，它們並沒有機會被提出來。 o 任何故事，只要產品負責人相信它們最終會在下一 個 Sprint 出現，那就應該有某一特定的重要程度。 o 分數只是讓我們依重要性排序。如果 A 的分數是 20， B 的分數是 100，那只是簡單說明 B 比 A 重要，並不 是代表 B 比 A 重要五倍。如果 B 的分數是 21，也是 代表同樣的意義：B 比 A 重要！ o 最好在分數之間留下一些間隔，以防之後出現另一 個故事 C，它比 A 重要，但是比 B 還不重要，可是 卻沒有分數可以使用。當然啦，你可以給 C 評定成 20.5，但是看起來有點醜陋，所以我們還是留點空隙 比較好！
我們如何紀錄產品的 Backlog | 17 呸！這只是對這個清單排序，你不需要亂動重要等級。 § 產品負責人應該要知道每個故事的意義(通常他是作者，但是 有時候其他人會提出一些需求，因此他需要排優先順序) 。 他並不需要知道它們是如何被實踐的，但是他需要知道為什 麼這個故事會出現在這裡。 註記： 產品負責人以外的人，可能也會增加故事到產品的 backlog 中，但是他們不能指定它有多重要，這是產品負責人才能有的權力。 他們也不能設定時間估算(time estimates)的值，這是整個團隊的權力。 我們還嘗試，或評估過其他方法： § 使用 Jira(我們的錯誤案例追蹤系統)來存放產品的 backlog。 大部分的產品負責人覺得用起來太麻煩了。但是，Excel 是 一個不錯和方便直接使用的工具。你可以容易去使用不同顏 色表示、重新安排項目、任意增加新的欄位、添加註解、和 匯進/匯出資料等等。 Google 電子表單也一樣，只不過 Google 表單是雲端版，可 以多個使用者同時編輯。 § 像 VersionOne、ScrumWorks、XPlanner 等，這些 Agile 的輔 助工具，我們還沒有嘗試過它們，不過或許以後會用吧。
4我們如何產生 Sprint 計畫 Sprint 規劃是非常重要的會議，應該算是 Scrum 中最重要活動(當然 啦，這是我個人的意見)。執行不好的 sprint 規劃會議，將會毀掉整 個 Sprint。 重要嗎？是的。是 Scrum 中最重要的東西嗎? 不是！回顧會議更 重要！因為運作良好的回顧會議，會幫助你修復有問題的事情。如 果其他事情都到位(好的產品 backlog，很積極的產品負責人和團隊 等等)，Sprint 規劃會議可以只關心相當瑣碎的事情。此外，迭代 不是敏捷的唯一方法 – 許多團隊用看板來取代。我甚至寫過一本 有關於它的小書：” Kanban and Scrum: Making the Most of Both” 。 http://www.infoq.com/minibooks/kanban-scrum-minibook Sprint 規劃會議的目的，是要給團隊足夠的資訊，好讓他們能在之後 幾個星期內，能不受干擾地工作，同時也是給產品負責人能對此有 充分的信心。 好吧！你可能會說這樣還是相當模糊。其實，Sprint 規劃會議會產生 出一些有用的成果： § Sprint 的目標 § 團隊成員的名單(如果他們不是 100%投入，則需要列出他們 投入的程度) § Sprint backlog (也就是在 Sprint 中所包含的故事列表) § 事前訂好的展示時間 § 對於 Scrum 的每日會議，事前訂好舉行的時間和地點 為什麼產品負責人需要參加 有時候產品負責人不願意花數個小時，和團隊一起討論 Sprint 的規 劃。“同事們，我已經列出我所想要的，我沒有時間一直呆在 Sprint 的規劃會議中”，這是相當嚴重的問題。
我們如何產生 SPRINT 計畫| 19 為什麼整個團隊和產品負責人都需要參加 Sprint 規劃會議，原因是 因為每個故事包含三項變數，彼此之間都有高度的關連。 範圍(scope)和重要性(importance)是由產品負責人決定的，但是估算 是由團隊決定的。在 Sprint 規劃會議期間，經由團隊和產品負責人 面對面討論，這三個變數才能逐漸調整到理想的結果。 一般來說，會議一開始產品負責人會簡述，對於 Sprint 和重要的故 事而言，他想要達成的目標是什麼。接著，從最重要的故事開始， 團隊逐一討論和評估每個故事。在他們做這事情的時候，他們必須 對範圍提出重要的問題：“刪除使用者這個故事，需不需要把所有 使用者還沒處理處理完的交易也一並刪除？”有時候答案可能會讓 團隊很吃驚，因此而讓他們調整他們的估算。 在某些狀況下，對某個故事的時間估算，可能不是產品負責人所期 待的。這可能會讓他調整這個故事的重要性，或是改變故事的範圍， 因此而導致一連串的重新估算，等等。 像這樣直接合作的形式是 Scrum 的基本，事實上也是敏捷軟體開發 的基礎。 如果產品負責人堅持，他並沒有時間去參加 Sprint 規劃會議，那該 怎麼辦？我通常會根據以下的順序，來嘗試其中一個策略： § 嘗試幫助產品負責人了解到，為什麼他的直接參與是非常關 鍵，希望能夠改變他的心意。 § 嘗試讓團隊中某個成員，志願在會議過程中，扮演產品負責 人的代理人。然後告訴產品負責人：“因為你不能參與我們 的會議，我們會讓 Jeff 在這裡當你的代理人。在會議中，他 會被充分授權，去修改故事的優先順序和範圍。我會建議你 和他在會議之前，儘可能讓你們的想法一致。如果你不喜歡
20 | SCRUM 和 XP 的實戰經驗 Jeff 當你的代理人，你可以換其他人，只要這個人可以全程 參加我們的會議就可以。” § 試著說服管理團隊指派一個新的產品負責人。 § 在產品負責人找到時間來參加會議之前，會先暫緩 Sprint 開 始的時間。同時，拒絕承諾任何交付項目。讓團隊每天都可 以做他們最想要做的事情。 這個章節寫得不錯！<給自己一些掌聲> 只有一件事情 – 我強烈建議把 backlog 精進(refinement)會議(評 估、故事的拆解等等)，變成一個單獨的會議，所以 sprint 規劃會 議可以更專注。在這兩個會議中，產品負責人的參與仍然是相當關 鍵的。 為什麼品質是不可被談判的 在上面那個三角形中，我刻意忽略了第四個變數： 品質。 我企圖去把品質區分成內部品質和外部品質。 • 外部品質是系統的使用者可以感覺到的，一個緩慢和不直覺 的使用者介面，便是一個很明顯的例子。 • 內部品質是指一般使用者看不到的問題，但是它會深深影響 到系統的可維護性。像系統設計的一致性、測試涵蓋度、程 式的可讀性和重構等等。 一般說來，若是一個系統內部品質很高，仍然有可能會外部品質還 是很差。但是若是內部品質差的系統，很少會有很好的外部品質。 試想，在鬆軟的沙灘上，如何建立堅固精緻的大樓。 我把外部品質也視為範圍的一部份。有時在商業的考量下，可能會 發佈一版，它的使用介面比較簡陋，並且反應速度也比較慢。不過 隨後發行一版比較乾淨的版本。我會把這些做或不做的決定權留給 產品負責人，畢竟他是負責決定範圍的人。 然而，內部品質就沒有得談了，不管在怎樣的狀況，團隊都要維護 系統的品質，這是無庸置疑的，沒有可以討價還價的，向來都是這 樣的。
我們如何產生 SPRINT 計畫| 21 (好吧，差不多是直到永遠) 所以我們如何區分哪些是內部品質，哪些是外部品質的問題？ 假如說，產品負責人說：“我尊重妳們所估算的 6 個故事點數，但 是如果你們能花點心思，你們一定找到一些快速解(quick-fix)的方法， 來節省一半的時間”。 哈！他想把內部品質當作一個變數。你會想說我怎麼會知道呢？因 為他要我們縮短所評估出來的時間，可是卻沒有要對縮小範圍這件 事情來“買單”。所謂“快速解”這件事會敲響你的腦中警 鐘﹒﹒﹒ 為什麼我們不允許這樣做？ 我的經驗告訴我，犧牲內部品質是一個很糟、很糟的想法。所省下 來的時間，在之後的日子會不斷為它付出代價。一旦我們允許這樣 做，後面就很難恢復品質了。 相反地，我會試圖把話題回到範圍上面來，“既然你覺得早一點達 到這個功能是很重要的，我們能不能縮小這個範圍，好讓我們能縮 短實作時間？或者我們可以簡化錯誤處理的的方式，讓完整的錯誤 處理方式變成另一個故事，讓我們之後再去處理它？或是我們降低 其它故事的優先順序，讓我們先集中精神處理這一個？” 一旦產品負責人學到內部品質是不能被討價還價的，那對於其他變 數，反而他將會處理的很好。 原則上，是的。但是實務上不見得，現在我比較務實。有時候短期 犧牲品質，可以產生很好的商業效果 – 例如，我們在下個 sprint 之後有個超大的商業展覽，或是我們只需要一個雛型來驗證使用者 行為的假設。但是在這兩個狀況下，產品負責人需要明確解釋，為 什麼我們要做這件事，並且承諾讓團隊之後回來彌補這些技術債 (有時團隊可以在產品 backlog 中，補上一個”清理”的故事，來當作 提醒)。高水準的內部品質應該是標準，異常事件應該被視為例 外。 永無止境的 Sprint 規劃會議…
22 | SCRUM 和 XP 的實戰經驗 在 Sprint 規劃會議中，最困難的事情是： 1) 人們不認為他們會花這麼多時間 2) ﹒﹒﹒但是他們會的！ 不用，他們不用花這麼多時間，如果你在另一個會議中對 backlog 進行精進。我見過許多團隊，每週花一個小時進行 backlog 精進， 所以 sprint 規劃會議就可以專心在，是的，sprint 的規劃！這也讓 產品負責人，在 sprint 規劃會議前，有更多機會去討論和改進產 品的 backlog，這將會使會議變得更短。 指導方針：如果 sprint 長度是一週，sprint 規劃會議正常應該不 要超過一個小時(有經驗的團隊可能更短)。如果 sprint 長度是 3 週，則是小於或等於 3 個小時。 Scrum 中每件事情都是有時間框的(time-boxed)。我喜歡它簡單、一 致的規則，我們會試圖去貫徹到底。 如果 Sprint 規劃會議時間快要用完，但是還沒有 Sprint 的目標或是 backlog 產生，那要怎麼辦呢？我們要打斷它嗎？還是要延長一個小 時嗎？或是準時結束明天再繼續？ 這種事常常一再發生，特別是新上手的團隊。那你會怎麼做？我也 不知道。但是我們的作法是什麼呢？嗯﹒﹒﹒好的，通常我會直接 打斷它，結束它。讓這個 Sprint 去承受這個沒有結果的事情。更具 體一點，我會告訴團隊和產品負責人：“會議會在十分鐘後結束， 我們還沒有一個真正的 Sprint 計畫。我們是要照已經有結論的部份 先作，還是要明天早上 8 點，再來個 4 小時的 Sprint 規劃會議？”" 你猜他們會怎麼回答﹒﹒﹒：o) 我也嘗試讓會議繼續下去，但是通常還是沒有完成什麼事情，因為 大家都太累了。如果他們在 2~8 小時內(不管你的時間長度是多少)沒 有產生還可以的 Sprint 計畫，即使再一小時他們也不會有結果。隔 天再另外安排一個會議，或許是一個還不錯的主意。但是大家已經 失去耐心，只想開始這個 Sprint，不想再花另外的時間去做歸劃。 所以我會打斷它。是的，這個 Sprint 中，大家會承受這個問題。但 是，正面來說，團隊學到非常寶貴的經驗，下次會讓 Sprint 規劃會 議更有效率。此外，如果之前他們覺得你訂下的會議時間過長，這 時候大家便不會抱怨說時間太多。
我們如何產生 SPRINT 計畫| 23 學習去遵守你的時間框，並且學習設定合理的時間框長度。那對會 議長度和 Sprint 長度的設定也有幫助。 我曾經見過一個團隊，他們說 ”我們嘗試過 Scrum，但很討厭它， 不想要再用它！“ 我問為什麼，他們說 ”花太多時間在會議上面！ 我們從來沒有做完任何事情”。我問哪個會議花最多時間，他們說 是 sprint 規劃會議。我問說要花多久，他們說”要兩到三天！” 每 次 sprint 要花兩到三天規劃？！怪不得他們會討厭 Scrum！他們 遺漏了時間盒的規則：先決定你願意投資多少時間，然後就堅持下 去！Scrum 就像其他工具 – 你可以用鐵鎚去建造一些東西，或是 敲碎你的拇指。不管哪一種，不要去責怪工具。 Sprint 規劃會議的議程 對於 sprint 規劃會議，若是有事前制定好的時間表，可以減少違反時 間框的風險。 這裡有一個我們曾用過的，典型的時間表： Sprint 規劃會議：13：00-17：00 (每個小時休息 10 分鐘) • 13：00 – 13：30 產品負責人會介紹 Sprint 的目標和簡述產品 的 backlog，訂定要展示的地點和時間。 • 13：30 – 15：00 團隊評估所需時間，必要時，進一步拆解 backlog 項目。有需要的話，產品負責人也更新重要性欄位的 估算。所有項目都被釐清。對於所有高重要性的項目，“如 何展示”的欄位都需要被填寫。 • 15：00 – 16：00 團隊選擇哪些故事要被放入這次 Sprint 當中。 並計算團隊的速度，來檢查工作進行的狀況。 • 16：00 – 17：00 為了每日 Scrum 會議，安排固定的時間和地 點(如果和上次不同)，並進一步把故事拆解成工作項目。 從 13:30 到 15:00 這部分，那是產品 backlog 精進(refinement)會 議 (我以前叫它 “backlog 梳理(grooming)會議” ，但後來知道在某 些文化中，梳理意味者壞事) 。把它切割成另外一個會議，嘿嘿， 你可以有較短和令人喜歡的 sprint 規劃會議。是的，有些小的調 整可能是需要，但是大部分的 backlog 精進會議應該在 sprint 規 劃會議前完成。
24 | SCRUM 和 XP 的實戰經驗 這個時間表並不是要完全固定不變，Scrum master 可以根據會議的進 程，來延長或是縮短某個子項目的時間。 訂定 Sprint 的長度 Sprint 規劃會議的其中一個產出，就是定出 Sprint 展示的時間。這意 味你必須決定 Sprint 的長度。 所以 Sprint 的長度要多長比較好？ 好的，短的 Sprint 會比較好。它可以讓公司更敏捷，也就是說方便 於改變方向。短的 Sprint = 短的回饋週期 = 更頻繁的交付 = 更頻繁 的客戶回饋 = 在錯誤的方向上不會花太多時間 = 學習和改進的更快 速，等等。 但是，長的 Sprint 也不錯。團隊能有更有時間累積能量，更多空間 去解決問題，進而達成 Sprint 的目標。不會被一堆 Sprint 規劃會議或 展示，忙得不可開交。 一般說來，產品負責人喜歡短的 Sprint，而程式設計師喜歡長的 Sprint。所以 Sprint 的長度是可以討論的。我們實驗了許多次，最後 總結我們最喜歡的長度： 3 個星期。大部分我們的團隊(但不是全 部)Sprint 長度都是三週。對我們來說，它短的讓我們有足夠的敏捷 性; 也長的足夠讓我們完成在 Sprint 中，所要完成的事情和所要解決 的問題。 我們得到一個結論：在剛開始時，就要做 Sprint 長度的實驗。不要 浪費太多時間去做分析，先選一個還不錯的長度，做個一兩次 Sprint， 然後再調整長度。 不過，一旦你已經決定哪個長度最適合你，之後就要長時間堅持住。 經過幾個月後的實驗，我們發現 3 個禮拜很好，所以我們就用 3 週， 進行了一段時間。有時候可能會感覺有點長，有時候可能會感覺有 點短。不過只要保持住相同的時間，就會變成大家共同的心跳節奏， 會覺得很舒服。並且對於發佈日期不會有任何爭論，每個人都知道 每三週會有一個版本。 大部份我所遇到的 Scrum 團隊(事實上，幾乎都是) ，最終是兩週
我們如何產生 SPRINT 計畫| 25 或三週的 sprints。只有一週幾乎是太短 (我們才剛開始 sprint，馬 上我們就要規劃展示！壓力太大了！我們無法做到可以這麼快，然 後又可以享受開發過程！)。而四周則是太長 (我們的規劃會議會是 種折磨，而我們的 sprint 老是被中斷)。這只是我的觀察。 定義 Sprint 的目標 定義 Sprint 的目標，這是每次都要做的事情。在 Sprint 規劃會議中的 某個時間點，當我問“這次 Sprint 的目標是什麼？”，大家都會一 臉茫然的看著我，產品負責人也會皺起眉頭，開始搔著下巴。 基於某種原因，要訂出 Sprint 的目標是件很困難的事。但是我發現 是值得去把它找出來。半吊子的目標也比沒有好。這個目標可能是 “賺更多的錢”，或是“完成前三件重要的故事”，或是“打動 CEO”，或是“把系統做好到可以給真正的 beta 客戶來使用”，甚 至是"增加基本後台系統的支援"等等。重要的是，它必須用商業的用 詞來表示，而不是用技術的用語來表示。這意味著需要連團隊以外 的人都能了解。 Sprint 的目標需要來回答這個基本的問題：“為什麼要進行這個 Sprint？ 為什麼我們不去放假呢？”為了要能拐騙產品負責人說出 Sprint 的目標，其中一種方法就是問他這個問題。 Sprint 的目標應該是尚未達成的。“打動 CEO”可能是不錯的目標， 但如果他已經留下深刻的印象，在這種狀況下， 即使大家回家休息， Sprint 的目標仍然可以達成。 在 Sprint 規劃過程中，或許所訂出的 Sprint 的目標看起很愚蠢，或是 很作做。但是當大家開始對於他們該做什麼感到困惑時，它經常會 被拿出來提醒大家。如果你有很多 Scrum 的團隊(想我們一樣) ，可 以把所有團隊的目標列在一個 wiki 的網頁上(或是其他系統) ，並且 把它放在一個明顯的地方，讓公司內所有人(不只是高階主管)知道公 司在做什麼，以及為什麼要這樣做。 是的。甚至 Scrum Guide 也同意這點，認為所有的 sprint 應該都 要有 sprint 的目標。我個人覺得有個 sprint 層次的目標並不重 要，但有個較高層次的目標，去涵蓋多個 sprint 或下個發佈的循 環，這可能還不錯。我只是要確定 sprint 應該不只是 ”把一堆使用
26 | SCRUM 和 XP 的實戰經驗 者故事解決”，否則你的團隊會覺得超級無聊。 決定在這次 Sprint 要做哪些故事 在 Sprint 規劃會議中，一個主要的活動是決定哪些故事要在這個 Sprint 中完成。更具體的說，哪些產品 backlog 中的故事，要被放到 Sprint backlog 中。 看一下上面那個圖，每個長方形代表一個故事，並且依重要性排序。 最重要的故事是放在最上面。每個長方形的大小代表故事的大小(也 就是故事時間點數的估算) 。藍色括號的高度代表團隊評估的速度， 也就是團隊認為多少故事點數，他們可以在下一個 Sprint 中完成。 在右邊的 Sprint backlog，是產品 backlog 的一個故事快照(snapshot) 。 它代表團隊承諾要在這次 Sprint 中，所要完成的故事列表。 是團隊決定多少故事要在這個 Sprint 中被完成，而不是產品負責人 或是其他人所決定的。 這會引起兩個問題： 1。 團隊如何決定哪些故事要被放到這次 Sprint 中？ 2。 產品負責人如何影響他們的決定？ 我先回答第二個問題。
我們如何產生 SPRINT 計畫| 27 產品負責人如何影響哪些故事要放在這次 Sprint 中？ 在 Sprint 規劃會議中，假設我們遇到以下狀況。 產品負責人很失望，故事 D 沒有被排入這次的 Sprint 中。那在 Sprint 規劃會議中，他的選擇是什麼？ 有一個選擇是他能重新設定優先順序。假如他賦予故事 D 較高的優 先順序，那團隊就不得不把它先加入 Sprint 中 (在這裡需要把故事 C 給丟掉)。 第二的選擇是他可以改變換範圍。縮小故事 A 的範圍，直到團隊認 為故事 D 可以放到這個 sprint 為止。
28 | SCRUM 和 XP 的實戰經驗 第三的選擇是他可以拆解故事。產品負責人可能可以決定故事 A 中 某些部分不重要，所以把故事 A 分成故事 A1 和 A2，並且賦予不同 的重要程度。 就如你所看到的，雖然產品負責人在正常的狀況下不能控制團隊所 評估出來的速度，但是他還是有很多方法，可以影響哪些故事要放 到 Sprint 裡面。 團隊如何決定哪些故事要放到這個 Sprint 中？ 我們這裡使用兩種技術： 1. 憑感覺 2. 團隊速度的計算 憑感覺來評估 § Scrum master：“嘿，大夥們，我們能在這次 Sprint 中完成 故事 A 嗎？” (指向產品 backlog 中最重要的項目) § Lisa：“嗯，當然可以，我們有三週，這只是微不足道的功 能”
我們如何產生 SPRINT 計畫| 29 § Scrum master：“OK，如果我們加上故事 B 呢？” (指向第 二重要的項目) § Tom 和 Lisa 一起回答：“應該沒問題” § Scrum master： “好的，那故事 A、B、C 一起呢？” § Sam (對產品負責人說)：“故事 C 需要包含一些複雜的錯誤 處理嗎？” § 產品負責人：“不，你現在可以先跳過它，只需要有一些基 本的錯誤處理。” § Sam：“那故事 C 應該沒有問題” § Scrum master：“好的，那我們加上故事 D 呢？” § Lisa： “嗯…” § Tom：“我想我們應該可以完成它” § Scrum master：“90%的信心？或是 50%？” § Lisa & Tom：“大約 90%” § Scrum master：“好的，D 也包含在裡面，如果再加上 E 呢？” § Sam：“或許吧” § Scrum master：“90%或 50%？” § Sam：“我認為差不多 50%” § Lisa：“我很懷疑” § Scrum master：“好，那先不去管它。我們要做完 A、B、C、 和 D。如果還有空的話，當然我們我們可以做完 E。但是沒 人認為它應該被算到這次裡面，所以我們會先把它排除在這 次 Sprint 計畫外，大家覺得如何？” § 所有人：“沒問題！” 對於小的團隊或是短的 Sprint 來說，憑感覺的評估方式還運作的不 錯。 利用團隊速度的計算來評估 這個技術包含兩個步驟： 1. 決定估算的速度 2. 在沒有超過估算的速度下，計算有多少故事你可以加入 速度是一種“已經完成的工作的總量”的衡量方式，這裡每個項目 是根據原始估算來進行衡量的。
30 | SCRUM 和 XP 的實戰經驗 在下面的圖形中，左邊是一開始估算的速度，和右邊是 Sprint 最後 實際的速度。每個長方形代表一個故事，裡面的數字代表這故事初 始的估算。 注意，這裡實際的估算是根據初始估算為基礎的，在 Sprint 過程中， 任何有關故事時間的更新都被忽略了。 我已經可以聽到你的抱怨了，“這怎麼會有用？速度的快或慢可能 取決於一大堆的因素！愚笨的程式設計師、不正確的初步估算、範 圍的改變、或是在 Sprint 期間無預警的干擾等等。” 我同意，這不是準確的數字。但是它仍然很有用，尤其是跟什麼都 沒有比的話。它可以給你一些不容懷疑的事實：“不管原因為何， 我們以為我們可以完成的，和真正我們做的完的，還是有些差別 的。” 在 Sprint 中，對於幾乎快要完成的故事，那又該如何處理？為什麼 我們不能因此加部分點數到我們的速度中？呵呵，這裡必須要強調 Scrum 的 精 神 ( 事 實 上 ， 這 也 是 敏 捷 開 發 和 精 實 生 產 (lean manufacturing) 所強調的)，那就是要全部做完，可以出貨，才算是真 正做完。事情做一半，它的速度只能算是 0 (也許還可能是負值) 。 你 可 以 參 考 Donald Reinertsen 所 寫 的 “ Managing the Design Factory”，或是 Poppendieck 的書，便可以知道為什麼會這樣說。 所以，我們是透過什麼神秘的魔力來估算速度？ 有一個非常簡單的方法去評估速度，那就是查看團隊的歷史資料。 在過去幾個 Sprint 中，他們的速度是多少？然後再假設下一個 Sprint 的速度也差不多。
我們如何產生 SPRINT 計畫| 31 這個技術就是有名的昨日氣象(yesterday’s weather)。團隊若要使用這 項技術，必須滿足兩個條件：團隊已經做過幾次 Sprint(所以有些統 計資料可以得到)。以及在下個 Sprint 中，用大致相同方式來開發(也 就是相同的團隊大小，相同工作狀況等等)。當然啦，並不是每次都 能如此。 另一個較複雜的方法，是去做簡單的資源計算(resource calculation)。 假設我們規劃一個由四個人組成的團隊，要去進行一個為期三週的 Sprint。其中 Lisa 將會請兩天假，Dave 只能投入 50%的時間，並且 會休一天假。所以讓我們把這些加在一起… …將會得到這個 Sprint 會有 50 個可用的人天。 警告：這部分我真的不喜歡。我真的想要把下面幾頁撕掉！但是， 如果你很好奇的話，請繼續閱讀它，我後面會解釋為什麼。 那這是我們所估出來的速度嗎？不是的，我們估算的單位是故事點 數，雖然是可差不多對應到“理想化的人天”。一個理想化的人天 是指能工作有效率，不受打擾的一天。但是這種狀況太少見了。我 們還需要進一步考慮一些事情，像是把沒有規劃到的工作進去，員 工生病不能工作等等。 所以我們的估計的速度一定小於 50，但是到底少多少呢？我們利用 了“投入程度” (focus factor)來解決這個問題。 投入程度是指能投入多少精力的估算。投入程度低，表示團隊預計 將有許多干擾，或預期自己的時間估算是樂觀的。
32 | SCRUM 和 XP 的實戰經驗 廢話一堆。一些神奇的數學公式。只要使用昨日氣象就好，忽 略投入程度這個沒意義的東西吧。 想要決定一個合理的投入程度，最好的方法是去看看上一次 Sprint 的狀況 (或是前幾次 Sprints 的平均值更好)。 把上次 Sprint 中，所有故事的初始估算的值的總和，就是真實速度 的值。 假設上次 Sprint 中，由 Tom、Lisa 和 Sam 三個人所組成的團隊，在 三個星期內工作了 45 個人天，一共完成 18 個故事點數。現在我們 試圖要算出下一個 Sprint 的估算速度，為了更複雜一點，有一個新 的同事 Dave 要加入這個 Sprint。把假期和新成員一起加起來，我們 在下一個 Sprint 會有 50 個人天。 所以根據上面的公式，下一個 Sprint 的估算速度是 20 個故事點數。 這意味著這個團隊，在這次的 Sprint 中，所能做的故事點數總和不 能超過 20。
我們如何產生 SPRINT 計畫| 33 在這個狀況下，團隊可能選了前四個故事，加起來一共 19 個故事點 數。或是選了前五個故事，加起來一共 24 個故事點數。假設他們選 了四個故事，因為最靠近 20。如果沒有保握，那就再選少一點。 因為這四個故事加起來一共 19 故事點數，所以最後他們所估算的速 度就是 19。 “昨日氣象”是一個方便使用的技術，但是需要一點常識。如果上 一個 Sprint，因為大部份的成員都生病了一周，是一個執行的很糟的 Sprint。你可以安全的假設你應該不會這麼慘，所以你可以評估下次 的 Sprint 會有較高的投入程度。如果團隊最近安裝了新的 CI (持續整 合)系統，你可能可以假設投入的程度會比較高。如果有新人加入這 次 Sprint，你需要考慮會因為要訓練他，因而減低投入程度。 只要狀況允許，你應該看看前幾個 Sprint，算出平均值，這樣會得到 更合理的估算。 但如果是全新的團隊，你沒有任何之前的統計數據，那該怎麼辦呢？ 你可以看一下其他有類似狀況的團隊，他們投入的狀況是怎樣。 如果你沒有其他團隊可以參考呢？那就隨便猜一下。好消息是你所 猜的值，只用在第一次的 Sprint。之後你就會有歷史資料可以分析， 以用來不斷地分析和改進你的投入程度和估算的速度。 我自己對於新的團隊，所使用的“預設”投入程度是 70%，因為大 部分其他團隊都能達到相同的數值。 那我們用哪一個評估的技術呢？ 上面我們提到好幾個技術–憑感覺、根據昨日氣象來做團隊速度的 計算、以及根據人日和預估的投入程度來做團隊速度的計算。 所以我們到底用哪一個？ 我們通常的是結合起來使用，這並不會花我們太多時間。 我們會檢查上個 Sprint 的投入程度和真實的速度。接著，我們會檢 查我們這次 Sprint 中所有可用的資源，並估算投入程度。然後，我 們會討論這兩次投入程度之間的差別，必要時作出適當的調整。
34 | SCRUM 和 XP 的實戰經驗 好的，這個痛苦部分已經結束。我從未使用投入程度，因為它很花 時間，產生出誤以為很精準的感覺，並且迫使你用理想人天的方式 來評估故事。 此外，投入程度帶來一個假設：更多人 ＝ 更快的速度，有時候這 是對的，但有時候不是。如果我們增加一個新人到這個團隊，在第 一個或第二個 sprint，這個速度通常會變慢，因為人們需要花時間 帶這個新人。如果團隊太大(像是超過 10 個人)，這個速度必定更 慢。同樣地，投入程度這個詞，意味著這個值小於 100％，團隊並 沒有全心投入，這會給管理高層一個非常誤導的訊息。 所以忽略投入程度和人天這些東西吧，只藉由計算故事點數，或是 如果你都沒作估算的話，那我們只計算完成的故事個數，看看你在 上幾個 sprint 能做多少。這樣可以大致抓出，這個 sprint 可以完 成多少個故事。如果在這個 sprint 中，你有些已知的干擾 (像是有 兩個人要去上課)，可以移除一些故事，直到你感覺可以為止。如 果你沒有太多歷史資料，則大多時間需要靠你的直覺。 以這樣的方式去進行，你的 sprint 規劃會議會變得更短，更有效 率，以及更有趣。並且，出乎意料地，你的計畫結果可能更加準 確。 一旦我們根據上次的速度和投入程度，算出這次 Sprint 該包含哪些 故事，接著我會用“憑感覺”的方法再做一次檢查。我會要求團隊 忘記之前算出來的數字，只要想像一下，是否這些這東西在一次的 Sprint 中，會太大而咬不下去。如果感覺太多了，我們就移掉一兩個 故事。反之亦然。 在這天結束以前，只要決定出哪些故事要在這個 Sprint 內完成，我 們就算達成目標。投入的程度、可使用的資源、以及評估速度的方 法，這些都是達成目標的手段。 我們為什麼要使用索引卡 大部分 Sprint 的規劃會議，會花很多時間在討論產品 backlog 中故事 的細節。要去評估它們，排定優先順序，釐清它們，以及進一步分 解它們等等。
我們如何產生 SPRINT 計畫| 35 那我們是怎麼做這些事情呢？ 好的，基本上，有些團隊是利用投影機，把 Excel 中的 backlog 投影 在牆上，然後有一個人(通常是產品負責人或是 Scrum master)操作鍵 盤，咭哩咕嚕講解每個故事，並要求大家進行討論。當團隊和產品 負責人討論過優先順序和故事細節後，拿著鍵盤的這個人會直接在 Excel 更新討論後的結果。 聽起來不錯吧？好的，事實上不是這樣的，大多只是在高談闊論。 更糟的是，團隊不會注意到在會議結束之前，他們都只是在高談闊 論，可能連所有故事都沒有看完過一遍！ 哦，這個痛苦…. 一個比較有效果的作法，是去建立一些索引卡，把他們放到牆壁上 (或是一張大桌子上)。 和使用電腦或是投影機比較起來，這是比較好的使用者互動方式， 因為︰ § 大家必須站起來並四處走動 => 讓大家可以較長時間的保持 清醒，並會留意會議的進行 § 每個人會感覺到有參與感 (而不是只有拿著鍵盤的那個人) § 有多個故事可以同時被編輯 § 要重新規劃優先順序變得比較容易–只要移動索引卡就可以 § 會議結束後，索引卡可以被拿出會議室，被放到牆壁上的任 務版上 (可參考後面第六章“我們怎麼撰寫 Sprint backlog”) 你可以手寫索引卡(像我們一樣)；或是利用一些簡單的腳本，從產品 backlog 中，直接來產生可被印出的索引卡。
36 | SCRUM 和 XP 的實戰經驗 附註–這個腳本在我的blog中可以拿到︰ http：//blog.crisp.se/henrikkniberg 最簡單去找到這個腳本的方式是去 Google “index card generator”。不要相信舊的方法還仍然可行！有些好心人士已經把 它轉到 Google 電子表單上面。任何像樣的 backlog 管理工具都有 類似的列表功能。可嘗試不同的工具，找出最合適你環境的一個。 並且確認你是在調整工具去配合你的流程，而不是相反。 重要事項︰在 Sprint 規劃會議結束後，我們的 Scrum master 會手動 更新 Excel 上的產品 backlog，以反映故事索引卡中的任何變化。是 的，這確實帶給管理者一些麻煩，但是我們考量在使用索引卡後， 所帶來 Sprint 規劃會議效率的提升，這樣的做法是完全可以接受的。 這裡有個地方要注意：“重要性”這個欄位。它和 Excel 中的產品 backlog 所記錄的重要性是一樣的。把它放到卡片上，可以方便我們 根據重要性來排序(一般我們把較重要的項目放在左邊，比較不重要 的放在右邊)。不過，一旦卡片被放到牆壁上，我們可以忽略它的重 要性評分，只要注意他在牆壁上在左在右的位置，來指出它相關的 重要性。如果產品負責人交換某兩個項目的位置，先不要去更新 Excel 上的資料，只要在會議後去更新就可以。 或者是放棄重要性這個欄位。哎呀，我已經說過了好幾次。我是不 是在重複？我是不是在重複？
我們如何產生 SPRINT 計畫| 37 如果把一個故事拆解成更小的任務(task)，那將會更容易評估時間了 (也更容易準確) 。事實上，我們是使用”activity”，因為在瑞典”task” 有完全不同的意義：o) 用索引卡來處理既方便又容易，你可以把團隊拆成兩個人一組，讓 他們同時拆解各一個故事。 實際上，我們在每個故事下面貼上一張便利貼，每張便利貼表示故 事中的一個任務。 我們不會把拆解出來的任務，更新到 Excel 中的產品 backlog。理由 有兩個： § 任務的拆解通常是比較反覆無常，也就是說，在 Sprint 的過 程中，它經常會改變，會不斷調整，所以若要保持和 Excel 內的產品 backlog 同步，將是一件非常麻煩的事。 § 產品負責人不需要去知道這種程度的細節。 拆解出來的任務可以和故事索引卡貼在一起，在 Sprint backlog 中直 接被使用。(參見後面第六章“我們怎麼撰寫 Sprint backlog”)
38 | SCRUM 和 XP 的實戰經驗 “做完”的定義 這一點是非常重要的，產品負責人和團隊必須同意，要對“做完” 有一致的定義。 非常重要！ 是所有程式碼被 check-in 就算故事做完了嗎？或是要被放到測試環 境，並被整合測試的團隊驗證過，才叫作做完嗎？有時候可能我們 使用這樣的定義：“隨時可以上線”，但有時候我們可能這樣說： “已經部署到測試的機器上，準備好要做驗收測試”。 在最開始的時候，我們曾使用詳細的的檢查清單。但現在我們則會 說：“如果測試人員說可以了，那這個故事就是做完了”然後就由 測試人員去確保，產品負責人所想要的事情，已經被團隊充分理解， 並且此項目已經"完成"到，足夠通過大家以認可的做完定義。 是的，這是有點沒有說服力。一個具體的檢查清單是有幫助的 — 只要確定它不會太長。把它視為是預定要做的，而不是像聖經一樣 供著。專注於人們可能會忘記的部分 (像是 ”更新發佈日誌”，或者 “沒有新增的技術債”，或是 ”獲得真實用戶回饋”） 我們慢慢瞭解到，並非所有故事能用相同方法來對待。“查詢用戶 表單”和“操作手冊”這兩個故事處理方式就差異很大。後者， “做完”的定義可能只是被運作團隊接受就可以。所以有時候用一 些常識就可以確認了，不必用到正式的檢查清單。 如果你經常對“做完”的定義感到困惑(就像我們一開始一樣)，你應 該在每個故事上，增加一個的欄位：“做完的定義”。 使用計畫紙牌來做時間規劃 估算是一項團體活動，每個團隊成員通常都要參加所有故事的估算， 為什麼大家都要參加呢？ § 在規劃的時候，我們通常都不知道誰要負責實作故事中的哪 個部份。
我們如何產生 SPRINT 計畫| 39 § 每個故事要求好幾人參加，並且要包括不同類型專長的人(使 用者介面設計、程式撰寫、測試等等) 。 § 為了要能提供一個估算值，團隊成員必須要對故事的內容， 有一定程度的了解。藉由要求每個人去估算每個項目，可確 保每個人知道每個項目是什麼。此外在 Sprint 中，也會增加 大家相互幫忙的機率。同時也增加重要的問題提早浮現的可 能性。 § 在要求每個人對一個故事評估時，我們常發現對同一個故事， 可能有兩個人的估算結果相差很大，像這樣的狀況我們應該 儘早發現，並儘早討論。 如果你要求對團隊提供一個評估的結果，通常來說最了解故事的人 會第一個發言。不過不幸的，這通常會嚴重影響其他人的估算。 這裡有一個很棒的方式可以去避免這件事 - 它叫做計畫紙牌(Planning Poker) (我記得是由 Mike Cohn 所創造出來的)。 事實上，Mike 說他是從 James Grenning 學來的。James 說他應該 是從某人身上得到一些想法。沒關係，我們都是站在巨人的肩膀 上。也許我們是一群侏儒站在彼此的肩膀上。嗯，無論如何 … - 你知道我的意思。 每個人都會拿到如上圖中的 13 張卡片， <推銷> 我們在 planningpoker.crisp.se 網站上賣這副牌。他們現在 看起來比照片中的更棒，雖然你可能可以在 Google 上找到更便宜
40 | SCRUM 和 XP 的實戰經驗 的。喔，在那個網站，我們還有賣其他更酷的東西，叫 Jimmy Cards，這是我的同事 Jimmy 做的（是的，我們在取名上有遇到麻 煩）快來看看吧。</推銷> 每當在估算一個故事時，每個成員選擇一張卡片，來表示他的時間 估算(以故事點數方式來表示)，並且把它的正面朝下放在桌子上。所 有的成員都放完以後，桌上的紙牌在同時掀開。這個方法要求每個 成員要自行思考，而不是依賴別人估算的結果。 如果有兩個估算之間有很大的差異，這時候團隊需要討論這之間的 差異，試圖讓大家對這故事的內容去達成共識。他們可能會做一些 任務拆解，然後再重新估算。這樣的事情會反覆進行，直到這個估 算收斂到一致。也就是所有的估算對這個故事是差不多的。 還有一件重要的事情，那就是提醒所有成員，他們是要對這個故事 中所有的工作做評估，而不是只是對“他們自己”負責的部份做估 算。測試人員不能只是估算測試的工作而已。 要注意到，這裡的數字順序不是線性的。例如在 40 和 100 之間是沒 有任何數字，為什麼會這樣呢？ 這是因為，一旦時間估算的值比較大時，很難估的很準確，這樣可 避免對於估算精確度產生錯誤的印象。例如，如果一個故事被估算 後，大約是 20 個故事點數，那它到底應該是 20，還是 18，還是 21， 這都並不重要。重要的是，我們知道它是一個很大的故事，很難被 估算的很準。所以 20 只是一個大約的估算。 那需要更準確的估算嗎？要就要把故事拆解成更小的故事，然後去 評估那些故事。 此外，你不能玩那種 5 + 2 = 7 哪種把戲。要嘛就是 5，要嘛就是 8， 沒有 7 這種事。 有些卡片比較特殊： § 0 = “這個故事已經完成了" 或是 "這個故事沒什麼，只要幾 分鐘就能搞定。” § ？ = “我一點概念都沒有，沒有主意。” § 咖啡杯 = “我已經太累了，先休息一下吧。”
我們如何產生 SPRINT 計畫| 41 另外一家公司想到一個更酷的撲克牌：不鬼扯的估算撲克牌。 (estimation.lunarlogic.io) 它只有三種牌： - 1 (一點) - TFB (太他媽的大) - NFC (他媽的沒有線索) 相當酷！我希望我能想到這個。我只想到咖啡杯這個東西。 釐清故事內容 當團隊會自豪地，在 Sprint 展示會議中展示一個新的功能，最糟糕 的事是產品負責人皺著眉頭，並說：“是的，看起來不錯，但是那 不是我要的。” 你如何確認產品負責人和團隊有相同的認知呢？或是團隊中每個人 對故事有相同的理解呢？嗯，你可能無法確定。但是有一些簡單的 方式，可以幫忙找出最明顯的誤解。最簡單的方式就是確保故事中， 所有的欄位都被填寫(或是更具體地說，對於那些有高優先順序，需 要在這個 Sprint 中完成的故事，都需要填寫)。 有些人稱之為 ”準備好的定義”。所以，做完的定義，是當故事完成 時的檢查清單。而準備好的定義，是當故事準備好可以被拉到 sprint 時的檢查清單。非常有用。 範例 1： 團隊和產品負責人對於 Sprint 的計畫很滿意，打算結束會議。這時 候 Scrum master 問說：“等一下，這裡有個“增加使用者”的故事 還沒有估算時間，讓我們來評估吧！經過幾次計畫紙牌投票，團隊 同意它的故事點數是 20。這時候產品負責人站起來，大聲說道： “什…什…什麼？”在經過幾分鐘的爭吵，最後發現是團隊誤解了 故事的範圍，他們認為這只是要“提供一個漂亮的使用者介面，來 增加，移除，刪除，和搜尋使用者”，但是產品負責人認為它只是 “手動透過 SQL 指令去增加使用者到資料庫中”，所以他們再評估 一次，給了這個故事 5 個故事點數。 範例 2： 團隊和產品負責人對於 Sprint 的計畫很滿意，打算結束會議。這時 候 Scrum master 問說：“等一下，這裡有個“增加使用者”的故事
42 | SCRUM 和 XP 的實戰經驗 還沒有說它要如何展示？”在一陣七嘴八舌之後，某個人站起來說： “嗯，首先我們登入網站，然後…”，這時候產品負責人打斷說： “登入網站？”不，不，不，這個功能並不包含在這網站裡面，應 該只要給有技術背景的管理者，一些簡單的 SQL，它就能夠執行了。 故事中"如何展示"的描述，需要(最好應該)非常精簡！ 否則你就沒辦 法準時結束 Sprint 規劃會議。基本上，它應該是非常平鋪簡單的敘 述，來描述如何手動執行最具代表的測試流程。"先做這個，然後那 個，最後再確認這個" 我發現，這種簡單的敘述，往往可以發現到，團隊對故事嚴重的誤 解。這種事早點發現會比較好，不是嗎？ 我仍然喜歡這個技巧。每當有故事很模糊時就會使用它，可以讓事 情具體化。另一種做法，是畫出低真度的草圖，或是準備驗收標準 的列表。把故事想像成一個高層次的問題敘述，而做完的定義，則 是當它完成後，看起來會長怎樣的具體範例。 把故事拆解成更小的故事 故事不應該太小或是太大(以評估的角度來看)。如果你有一堆 0.5 故 事點數的故事，你可能會是微觀管理的受害者。另一方面，若是你 有 40 故事點數的故事，則代表你有高度風險會只做完一部分的故事 而已。那對你公司是沒有價值的，並增加管理上的負擔。進一步來 說。如果你們所評估的速度是 70，可是有兩個高優先順序的故事是 40，那這個規劃就非常困難。你可能有兩種選擇：承諾不足，意味 你只選擇一個；或過度承諾，意味你選擇都做。 我發現多數大的故事可以拆解成小的故事。只要確認小的故事依然 能有商業價值即可 我們一般都確保故事在 2-8 人天內可以做完，我們的速度通常大約是 在 40-60 之間，所以我們大約在每個 Sprint 中可以完成 10 個故事左 右。有時候少到 5 個，有時候多到 15 個左右。不過這些數量都是用 索引卡來管理可以負荷的 一個 sprint 中做 5 到 15 個故事，是一個有用的準則。小於 5 個 通常表示故事太大了。而多餘 15 個，則表示團隊拉太多故事，會
我們如何產生 SPRINT 計畫| 43 無法完成每件事情。(或是故事太小，造成微觀管理) 把故事拆解成任務 等一下，故事和任務的區別是什麼？ 這是一個非常好的問題。 這個區別很簡單。故事是可以交付的東西，是產品負責人所關心的。 任務不是可以交付的項目，並且產品負責人也不在乎。 這裡是把一個故事拆解成更小的故事的例子： 這裡是把一個故事拆解成任務的例子： 這裡我們看到一些有趣的事情： • 新的 Scrum 團隊通常不願意花時間，事先把一堆故事拆解成 任務。有些人覺得這像是 waterfall 的方法。 • 對於了解非常清楚的故事，事前拆解或是之後拆解都是一樣 容易的。 • 這樣的拆解，通常會找出一些額外的工作，讓原先估算的時 間變長，但可以讓 Sprint 計畫更接近真實。 • 這種事先的拆解，可以讓每日的 Scrum 會議有顯著的效率 (可參考第八章 我們怎樣進行每日會議)。
44 | SCRUM 和 XP 的實戰經驗 • 即使這樣的拆解不夠準確，開始進行後也許馬上就要被修正， 但是以上所提到的好處還是可以獲得的。 所以，我們試圖將 Sprint 規劃會議的時間拉到夠長，以確保有時間 進行任務的拆解。如果時間不夠了，我們可能就不做了 (請看後面的 "最後的底限在哪裡")。 任務拆解是一個很好的機會，去找出之間的相依性–像是 ”我們需 要存取生產線上的日誌” 或 “我們需要 HR Jim 的幫助”–並且來找 出對付這些相依性的方法。也許是打個電話給 Jim，看看他是否能 在這個 sprint 中保留時間給我們。越早發現這些相依性，越有可 能避免讓它搞砸你的 sprint。 注意 - 我們在實踐 TDD(Test Driven Development)，也就是對於每個 故事，第一件任務就是"撰寫一個失敗的測試"，而最後一個任務是" 重構" (= 改進程式的可讀性和移除重複的地方)。 定義每日會議的時間和地點 Sprint 規劃會議有一個經常被遺忘的產出，就是"事先規劃好的每日 會議時間和地點"。第一次每日會議是非常重要的開始，每個成員會 決定要怎麼開始工作。沒有這樣，你的 sprint 將會有一個不好的開始。 我比較喜歡早上開會，但是，我必須承認，我們並沒有嘗試過在中 午或是下午，進行過每日會議。 現在我有中午或下午的每日會議，運行的還不錯。就讓團隊來決定 吧。如果不確定，就做實驗吧。雖然大部份的團隊比較喜歡早上。 在下午開每日會的缺點是： 當你早上開始工作，你必須試圖去回想， 你昨天告訴別人你今天要做什麼。 在上午開每日會的缺點是： 當你早上開始工作，你必須試圖去回想， 你昨天做了什麼，這樣才能告訴別人。 我的看法是，第一個缺點比較糟，因為重要的事是要知道你今天要 做什麼，而不是你已經做了什麼。
我們如何產生 SPRINT 計畫| 45 我們預設的作法是選擇一個大家都不會有意見的最早時間。通常是 9： 00，9：30 或是 10：00。最重要事情是，這是每個人都能接受的時 間。 哪裡是最後的底限 好的，現在時間已經用完了。照理說，所有事情要在 Sprint 規劃會 議中完成，如果我們時間不夠，那麼我們應該要把哪些事情砍掉呢？ 嗯，我會使用以下規則，來決定要做事情的優先順序： 順序 1： Sprint 的目標和展示的時間。這是你開始一個 Sprint 最基本 該有的東西。團隊需要有個目標，和一個結束的日期，然後他們就 可以根據產品 backlog 正確運作。是的，有點扯。你應該考慮規劃一 下明天再開一次 Sprint 規劃會議。但是如果你真的需要馬上開始 Sprint，或許這樣就可以。不過，老實說，我從來沒有試過在這麼少 資訊下開始 Sprint 的。 順序 2： 列出哪些故事是團隊接受要在這個 Sprint 中處理的。 順序 3： 填寫 Sprint 中每個故事的估算值 順序 4： 填寫 Sprint 中每個故事的"如何展示" 。 順序 5： 速度和資源計算，當作你 Sprint 計畫中的實現檢查(reality check)。包括團隊成員的清單，以及他們的承諾。(否則你就無法計 算速度)。 保持簡單，以及在較高層次，最多花五分鐘來做。詢問：”從人員 配置的角度來看，這次的 sprint 和上次的 sprint，主要不同的地 方在哪?” 如果沒有，就使用昨日氣象。如果有，就根據現狀加以 調整。 順序 6： 描述每日會議的時間和地點。它將會花點時間去決定，如 果你時間不夠用，Scrum master 可以先決定，在會議後以 mail 通知 所有人。 順序 7： 把故事拆解成任務。這個拆解也可以在每日會議上去做， 不過它會有點影響到 Sprint 進行的流程。
46 | SCRUM 和 XP 的實戰經驗 技術性的故事 這裡有個很複雜得問題： 技術性的故事。或者非功能性項目，或者 你想怎麼稱呼它都行。 每當某些人提到 ”非功能性需求”，我就不禁咯咯地笑。聽起來好像 這個東西不是個功能 :o) 我所指的是需要完成，但是不屬於交付項目，和任何故事沒有直接 的關連，並且不會帶給產品負責人直接的價值。 我們稱它做 "技術性的故事"。 例如： § 安裝 continuous build server o 為什麼需要完成它：因為它可以節省開發人員許多 時間，並且降低在循環結束時，大規模整合所帶來 的風險。 § 撰寫系統設計概述 o 為什麼需要完成它：因為開發人員常常忘記整體設 計的方向，因此而寫出不一致的程式碼。所以需要 有描述整體方向的文件，讓每個人都對設計有相同 的認知。 § 重構 DAO 層的程式 o 為什麼需要完成它： 因為 DAO 層的程式已經相當混 亂，每個人都因為無謂的困惑，或是 bug 浪費不少時 間。整理這些程式碼可以節省大家的時間，並且改 進系統的強健性(robustness)。 § 升級 Jira (錯誤追蹤系統) o 為什麼需要完成它：目前的版本太多 bugs，並且速 度又慢。升級後可以節省大家的時間 這些故事是正常的狀況嗎？ 或是這些任務和其他故事沒有任何關聯 嗎？ 誰要來排優先順序？ 產品負責人需要參與其中嗎？ 我們曾嘗試過許多不同的方法來處理技術性的故事。我們曾經把他 們視為第一級的(first-class)故事，就像其他故事一樣。但是這樣不好， 因為當產品負責人在排產品 backlog 的優先順序，它就好像拿蘋果和
我們如何產生 SPRINT 計畫| 47 橘子在比較一樣。事實上，基於某些明顯原因，技術性的故事通常 會是比較低的優先順序，因為有人可能會說： "喂，大夥們，我知道 continuous build server 是非常重要，但是我們先完成一些可以帶來收 入的功能，之後我們再來處理這些技術性的補強，好嗎？" 有些時候，產品負責人是正確的，但是，通常這只是少數狀況。我 們得到的結論是，產品負責人通常無法勝任的，去做出這方面正確 的判斷。所以我們會這樣做： 1) 試著避免技術性的故事。努力尋找一種方式，把技術性的故 事轉換成一個正常的故事，和可衡量的商業價值。這樣的方 法會幫助產品負責人，有更好的機會去做出正確的決定。 2) 如果我們不能把技術性故事轉換成一般的故事，看看是否這 項工作能夠被當作另一項故事中的某個任務。例如： "重構 DAO 層"應該可以當作"編輯使用者"這個故事中的一項任務， 因為這個故事包含到 DAO 層。 3) 如果以上兩種都不行，那就把它定義成一個技術性的故事， 並且用另一個列表來放這些故事。讓產品負責人可以看到它， 但不能編輯它。使用"投入程度"和"估算速度" 這兩個參數， 來跟產品負責人協商，從 Sprint 中偷一些時間來完成這些技 術性的故事。 我仍然認為技術性故事是一個很好的樣式(pattern)，並且常常使用 這樣的說法。較小的技術性故事可以放在日常的工作中，而較大的 故事會放到技術性的 backlog 中。讓產品負責人知道這件事，但這 個 backlog 是由團隊來管理它。團隊和產品負責人都同意這樣的準 則：”10-20% 的時間花在技術性故事上面”。不需要用投入程度或 工時報告這種精緻的追蹤機制，只要憑感覺就好。在回顧會議時詢 問，“在 sprint 中，我們大約花多少精力在技術性故事上面，那樣 的感覺對嗎？” 下面是一個例子 (這個對話類似我們之前某一個 Sprint 規劃會議中的 談話)。 § 團隊： "我們有一些內部的技術性工作需要被完成，我們要 抽出 10%的時間來處理它，也就是把投入程度從 75%降到 65%，你覺得可以嗎？" § 產品負責人： "不行，我們沒有時間"
48 | SCRUM 和 XP 的實戰經驗 § 團隊： "好的‥那看一下上次的 Sprint(所有人轉向看板上的 生產率草圖)。我們估算的速度是 80，但是我們只有 30，對 嗎？" § 產品負責人："相當正確，所以我們沒有時間做那些內部技 術的工作，我們需要新的功能！" § 團隊： "嗯，之所以我們速度變得這麼糟的原因，是我們花 太多時間，試圖去弄出一個穩定的版本，以供測試使用。” § 產品負責人： "嗯，然後呢？" § 團隊： "好的，如果我們不做些事情，我們的速度還會繼續 便糟下去" § 產品負責人： "嗯，接下來呢？" § 團隊： "所以，在這個 Sprint 中，我們打算大約花 10%的時 間，來建立一個 continuous build server，這樣我們就可以擺 脫整合時所帶來的痛苦。這樣接下來的每個 Sprint，我們的 速度大概會至少提高 20%左右" § 產品負責人： "哦，真的嗎？ 那為什麼上個 Sprint 我們沒有 這樣做？" § 團隊： "嗯……因為你不要我們這樣做……" § 產品負責人： "哦，嗯，好吧，這主意聽起來不錯，就這樣 做吧。" 當然，另外一種選擇是把產品負責人排除在外，或是給他一個無法 協商的投入程度。但是，沒有理由不去和產品負責人先達成共識， 就自己蠻幹。 如果產品負責人能力比較強，並且通情達理(這點，我們比較幸運)。 我會建議讓他盡可能知道所有事情，並且讓他決定所有的優先順序。 透明化也是 Scrum 的核心價值，不是嗎？ 如果你無法和產品負責人坦誠交談，討論有關於技術性故事，品質 和技術債的問題，那你有很大的問題需要解決！這個徵狀顯示出， 你刻意對產品負責人隱瞞訊息。當然啦，你不需要每次的對話都邀 請產品負責人加入，但是能這樣做是基於信任和尊重。沒有這些的 話，無論你打算建造什麼，你都不可能會成功。 錯誤追蹤系統 vs. 產品 backlog
我們如何產生 SPRINT 計畫| 49 這裡有一個詭異的地方，Excel 雖然是一個管理產品 backlog 的好工 具，但是你還是需要一個 bug 追蹤系統，Excel 可能不適合。我們使 用的是 Jira。 那我們如何把 Jira 上的問題帶到 Sprint 規劃會議中？ 我的意思是， 我們不能只注意故事，而忽略了這些 bugs。 我們嘗試過幾種策略： 1) 產品負責人列印出 Jira 中，最高優先順序的項目，把他們帶 到 Sprint 規劃會議中，把它們和其他故事一起貼到牆壁上(因 此，就暗地裡說明了這些錯誤，和其他故事的比較後的優先 順序為何)。 2) 產品負責人建立一些參考到 Jira 項目的故事。例如： "修理 最嚴重的後端系統報表的 bug，代碼是 Jira-124，Jira-126， 和 Jira-180"。 3) Bug 的修復被考慮當做 Sprint 以外的工作，也就是，團隊保 持較低的投入程度(例如 50%)，讓剩餘的時間來確保他們有 空去修復錯誤。所以可以單純假設，團隊在每個 Sprint 中， 會花一些時間來修復 Jira 上報告的錯誤。 4) 把產品的 backlog 放到 Jura(也就是拋棄 Excel)。把 bugs 和其 他故事同等看待。 我們還沒有結論，那一種策略對我們最好。事實上，不同團隊，不 同 Sprint，會有不同的作法。我傾向使用第一個策略，它又好又簡單。 八年後我只能同意，沒有單一最佳的做法。上面每個做法，在某些 環境下可能是很好的。保持實驗，直到你發現那個對你最好的。 Sprint 規劃會議終於結束了！ 哇啊，我從沒想過，Sprint 規劃會議這一章會是這麼的長！ 我想這 應該會反映我的想法，Sprint 規劃會議真的是 Scrum 中最重要的事。 花很多精力在這裡是對的，這樣之後的工作才會比較簡單。 或者反之亦然 – 其他的東西準備好，則 sprint 規劃會議就只是小 菜一碟。:o)
50 | SCRUM 和 XP 的實戰經驗 如果每個人都帶著微笑離開會議，並且隔天起來時也面帶微笑，或 是在第一次每日會議中面帶微笑，這樣 Sprint 規劃會議就是成功的。 當然，所有事情都有可能會出現問題，但是至少你不能都歸咎於 Sprint 計畫 ：o)
5我們如何溝通我們的 Sprints 讓整個公司知道我們現在做什麼，這是非常重要的事情，否則其他 人會抱怨。甚至更糟的事，會對我們做的事情做出錯誤的假設。 我們會使用"Sprint 訊息頁"來處理這件事。 有時候我們會將每個故事如何被展示，加到這裡面來。 當 Sprint 規劃會議一結束，Scrum master 就建立這個頁面，把它放到 wiki 上，並且 spam 給公司所有的人。
我們如何產生 SPRINT 計畫| 53 我們在 wiki 上也有一個"數位儀表板"，將會連結所有目前正在進行 的 Sprints。 此外，Scrum master 印出 Sprint 訊息頁，把它貼在團隊外面的牆壁上。 所以所有經過的人，都能藉由看到這個訊息頁，知道這團隊目前在 做什麼。因為這包含了每日會議和 Sprint 展示的時間和地點，每個 人知道他要去哪裡，可以得到更多訊息。 當 Sprint 接近尾聲的時候，Scrum master 會提醒所有人，有關於即將 到來的展示。 有了這個，沒有人會有藉口會說不知道你們的工作狀態。 嘿嘿，真是個好主意！我應該經常這樣做！
54 | SCRUM 和 XP 的實戰經驗
6我們怎麼撰寫 Sprint backlogs 你們已經走了這麼遠啊？ 喔，幹得好。 現在我們已經完成 Sprint 規劃會議，並告訴大家我們下一個閃閃發 光的新 Sprint 是什麼。接著是時候，讓 Scrum master 建立 Sprint backlog。當 Sprint 規劃會議結束後，和第一次每日會議前，並需要 把 Sprint backlog 給建立完。 Sprint backlog 的存放方式 我們曾經嘗試過用不同格式來保存 Sprint backlog，像是 Jira，Excel 和牆壁上的任務板(taskboard)。剛開始，我們主要是使用 Excel，有 很多公開的 Excel 模板，可以用來存放 Sprint backlog，還包括可以 自動產生的 burn-down chart 等等。我可以告訴你很多我們怎樣調整 Excel 為主的 Sprint backlog。但是這裡我先不提，我也不會舉任何例 子。 代替的，我將要詳細描述，我們發現存放 Sprint backlog 最有效率的 方法 - 掛在牆上的任務板！ 是的，實體牆壁為主的任務板(又叫做 Scrum 板)是我首選工具！它 的效果是令人驚訝地強大。對於分散在各地的團隊，則是利用電子 工具來提供 Scrum 板的概念，並且在各地都用一個大的螢幕來呈 現。在每日會議時，每個人站在牆壁的螢幕前，利用 Skype (或是 其他工具)來交談。 找一面尚未使用或是充滿了沒用訊息的大牆(像是公司的 logo，舊日 的圖表，或是醜陋的塗鴉)。把它清理乾淨(如果必要的，先請求許可 這樣做)。貼上一張大的白紙(至少 2 x 2 平方公尺，大的團隊可能需 要 3 x 2 平方公尺)，然後這樣做：
56 | SCRUM 和 XP 的實戰經驗 你當然可以使用白板，但是多少有點浪費。如果可能，把白板省下 去劃設計的草圖，用沒有白板的牆壁來做任務板。 或者更好的是，把整面牆弄成白板，這是一個值得的投資！ 注意 - 如果你使用便利貼來記錄任務，不要忘記用真的膠帶把他們 黏好，否則你有一天會發現，所有便利貼會掉在地板上，堆成一堆。 或者買一個超級黏的便利貼，稍微有點貴，但是他們不會容易掉下 來！(不，我不是贊助者，真的)
我們怎麼撰寫 SPRINT BACKLOGS | 57 如何讓任務板發揮作用 當然，你可以加上許多欄位，像是 "等待去做整合測試"，或是 "已取 消"等等。但是，在你把事情變複雜之前，多想一下，這些增加的欄 位是否真的需要？ 我發現對於這類事情，簡單是極端有用的。所以當不做會真的很不 好時，我才會增加這些額外的複雜度進來。
58 | SCRUM 和 XP 的實戰經驗 範例 1 – 在每日會議結束後 在每日會議結束後，任務板可能會變成這樣： 你可能會看到，有三個任務被放到"checked out"欄位中，也就是，團 隊今天將會處理這些項目。 有時候，對於比較大的團隊，任務可能會一直停在"checked out"狀態 中，因為已經沒有人記得，是誰要負責這個項目。如果這種狀況一 再發生，他們通常會導入這樣的規則，在每個 checked out 的任務上， 標上是誰負責這個項目。 現在幾乎所有團隊都使用替身。每個團隊成員挑選他們的替身 (像 是南方四賤客或是其他)，印出來，把它們放在磁鐵上面。這是很 棒的方式可以知道誰正在做什麼。並且，如果每個人只有兩個磁 鐵，間接限制同時處理的工作數目，和避免多工。“真他媽的見鬼 了，我用完了磁鐵！” 是的，所以停止做新的任務，把正在做的任 務給完成！
我們怎麼撰寫 SPRINT BACKLOGS | 59 範例 2 – 在幾天之後 在幾天之後，任務板可能看起來像這樣： 你可以看到我們已經完成"deposit"這個故事(也就是，它已經被 checked in 到原始碼資料庫，被測試過，和重構過等等) 這 migration tool 只完成了一部份，"back office login"已經開始，"back office user admin"還沒開始。 你可以看到右下角，我們已經有三個未計畫到的項目。當你在進行 Sprint 回顧會議，它非常有用，可以幫助你記住有過這些事。
60 | SCRUM 和 XP 的實戰經驗 這裡有一個真實 Sprint backlog 的例子，這個例子已經接近 Sprint 的 尾聲了。在 Sprint 的過程中，這個表變得有點亂，但是還好，因為 這樣的時間不長。每次新的 Sprint 開始，我們會建立一個全新，乾 淨的 Sprint backlog。
我們怎麼撰寫 SPRINT BACKLOGS | 61 燃燒圖如何運作 讓我們放大燃燒圖： 這張圖表可以告訴我們： § 在 Sprint 的第一天 ，8 月 1 日，團隊評估大約有 70 個故事點 數的工作要完成。這就是實際上整個 Sprint 的估算速度。 § 在 Sprint 的第十六天，團隊評估大約剩 15 個故事點數的工作 要完成。虛線顯示出他們目前進度大約是在控制中，也就是， 以這樣的速度，他們在 Sprint 結束前，會完成每件事情。 我們沒有把週末放到 X 軸上，因為很少人會在週末工作。我們曾經 把週末放進去，但這將使得燃燒圖看起來很奇怪，因為在週末都是 平的，看起來會好像是一個危險的徵兆。 Scrum 最初是被設計給團隊進行一個月的 sprint，並且使用 Excel 來追蹤任務的。在那個情形下，對於我們怎麼做事，燃燒圖是一個 非常有用的視覺化總結。現在，雖然大部份的團隊採用較短的 sprint，並且有更好的視覺化 Scrum 板。因此，他們越來越多人完 全忽略了燃燒圖，因為只需要看一眼，他們就得到他們想要的。試 著忽略燃燒圖，看看你會失去什麼！
62 | SCRUM 和 XP 的實戰經驗 任務板上的警訊 在任務板上快速瀏覽一下，應該就可以知道，目前 Sprint 進行的狀 況如何。Scrum master 要負責確認，團隊會對這些警訊採取行動：
我們怎麼撰寫 SPRINT BACKLOGS | 63
64 | SCRUM 和 XP 的實戰經驗 嘿，要如何追蹤？！ 在這種狀況下，如果你需要可追蹤性，我所能提供的最佳可追蹤性 的方法，就是每天對任務板拍一張數位照片。我有時候這樣做，但 是我從來沒有用到這些照片。 如果可追蹤性對你是非常重要，那任務板可能不適合你。 但是我會建議你去評估一下，詳細的 Sprint 可追蹤性，對你的實際 的價值是什麼。一旦 Sprint 完成，可以運作的程式碼被交付，文件 也被 checked in。那還有人會關心有多少故事，在 Sprint 的第五天被 完成？ 又有誰會真的關心"為 Deposit 實作測試先行"這個故事，原先 估算的時間是多少？ 我仍然覺得可追溯性被過度高估，有些工具有提供這類型的資訊， 但是基本上沒有人用它。你的程式碼版本控制系統，就可以提供大 部份你需要的資訊。(真他媽的見鬼了？誰做了這個修改？！)。規 定一些公約，像是增加故事 ID 到你提交的註解中，這樣在大多的 狀況下，你就可以有足夠的可追溯性。 用天數來評估 vs. 用小時來評估 在大部分有關 Scrum 的書籍或是文章，你會看到任務大部分是用小 時來做時間的評估的。我們曾經也這樣做過。我們一般的作法是： 一個有效的人天 = 大約是 6 個人時(man-hours)。 現在我們已經不這樣做，至少在我們大部分的團隊已經是這樣，原 因如下： § 人時的評估太過精細了，這會導致很多 1~2 小時的任務，因 而引發微觀管理(micromanagement)。 § 通常結果證明是，人們的思考始以人天為單位，只是把它乘 以 6 得到了人時。"嗯……這個任務需要花大概一天。哦， 我必須要寫小時數，那我寫 6 小時就好了"。 § 兩個不同單位會導致混亂，"這是使用人天，還是人時評估 的呢？"。 所以我們現在使用人天，當做所有時間估算的單位(雖然我們叫它故 事點數)。我們最小的值是 0.5，也就是，只要任何任務小於 0.5，要
我們怎麼撰寫 SPRINT BACKLOGS | 65 嘛不把它移掉，要不然就是把它和其它任務合在一起，或者就是給 它 0.5 的估算值(稍微超過估算不會有太大的影響)。這樣比較單純， 比較好。 可以更簡單：完全跳過任務評估！大部份的團隊最終將學習如何將 工作拆解成，大約是一天或兩天的任務。如果你可以做到那樣，你 不需要受到評估任務的干擾，可以排除很多浪費。燃燒圖仍然有用 (如果你一定要的話)–在那種狀況下，只要數有多少任務，而不用 去加總時數。
7我們如何安排團隊的座位和空間 設計的角落 我發現到，大部分最有趣和最有價值的設計討論，通常自然而然發 生在任務板前面。 基於這個理由，我們試圖把這個地方安排成一個明顯的"設計的角落 "(design corner)。 這是真的相當有用，如果想要知道系統的概況，沒有比站在設計的 角落前，看看牆壁上的內容，有更好的方法。然後再回來電腦面前， 並嘗試一下最新版本的系統。(如果你很幸運的有持續整合的版本， 請參見之後 "我們如何結合 Scrum 和 XP")。
我們如何安排團隊的座位和空間| 67 這個"設計牆"只是大的白板，它包含大部分重要的設計草圖，還有一 些印出來的最重要的設計文件(循序圖(sequence charts)，GUI 的原型， 領域模型(domain models)等等)。 上圖：每日會議將發生在上述角落。 嗯……這個燃燒圖看起來太好，曲線看起來太直。但是團隊堅持說 它是反映真實的狀況 ：o) 邪惡的教練提供了假的燃燒圖直尺，對於高度失控的環境來說非常 方便。:o) http://blog.crisp.se/2013/02/15/evil-coach/fake-burndown-ruler
68 | SCRUM 和 XP 的實戰經驗 讓團隊坐在一起！ 在安排座位和桌椅佈置時，有一件事情再怎麼強調也不為過。 讓團隊坐在一起！ 說的更清楚一點，我所說的就是 讓團隊坐在一起！ 經過八年幫助其他公司導入 Scrum，我只想補充: 讓團隊坐在一起！ 大家都懶得動，至少我工作的地方是這樣。他們不要去收拾他們的 東西，拔下電腦插座，把所有東西搬到新的座位，再插上電腦電源。 當距離越短，他們越懶得去搬。"拜託，老闆，搬這這 5 公尺的作用 是什麼？" 然而，為了建立有效率的 Scrum 團隊，沒有其他選擇。就是要團隊 坐在一起。即使你必須親自威脅每個人，幫他們搬他們的裝備，清 除他們的咖啡污漬，也要搬在一起。如果空間不夠，那就創造空間。 就算你必須把團隊放到地下室，也要去做。把桌子搬在一起，賄賂 辦公室管理員，竭盡所能，只要團隊能在一起。 一旦團隊坐在一起，好處就馬上出現。只要一個 Sprint 完後，團隊 會同意搬在一起是一個好的主意(從我個人經驗來看，你的團隊有可 能因為太固執，而不承認這一點)。 現在，"坐在一起"是代表什麼意思？ 桌子應該要怎麼擺？ 好的，我 沒有太多意見怎樣擺最好。即使我有，我會假設大多數的團隊沒有 這麼有錢，可以決定桌子可以怎麼擺。通常會有一些空間上的限制 - 鄰近的團隊，廁所的門，在房間中大型的自動販賣機，等等。 "坐在一起"代表： • 互相看到： 團隊中所有人都能彼此交談，不需要大聲喊叫， 或是離開座位。
我們如何安排團隊的座位和空間| 69 • 互相聽到：所有人都可以看到彼此，看到任務版。不需要靠 的太近也能夠看到上面的內容，至少可以看到大概的樣子。 • 隔離： 如果你的團隊突然站起來，會自動地進行熱烈的設計 討論。沒有團隊以外的人會被打擾到，反之亦然。 "隔離"並不是意味著團隊需要被完全的分隔起來。在一個隔間式的辦 公環境中，只要團隊有他自己的隔間，並且夠大，可以去屏障大部 份外面的噪音，那這樣就足夠了。 如果你是一個分散式的團隊呢？ 好的，那就沒那麼幸運了。可以用 一些高科技工具來幫你降低傷害 - 視訊會議，網路攝影機(Webcams)， 桌面分享工具(desktop sharing tools)等等。 讓產品負責人坐在隔壁間 產品負責人應該坐的離團隊很近，所以團隊可以走過去問問題，產 品負責人也可以走過來看看任務版。但是他不應該和團隊坐在一起。 為什麼呢？ 因為他可能無法控制自己，去管一些更進一步的細節， 導致團隊無法"凝結"的很好(也就是，無法達到合作無間，自我管理， 有超高生產力的狀態)。 老實說，這是我自己的猜測。我並沒有實際遇到過，產品負責人和 團隊坐在一起的狀況，所以我沒有實際根據去說，那是一個不好的 主意，只是個人直覺和聽別的 Scrum master 的訴說。 好的，你猜怎樣。我錯了，大錯特錯。我看過最棒的團隊，是產品 負責人是坐在一起的。如果產品負責人坐太遠的話，團隊會遇到很 多問題，會比坐太近還要麻煩許多。然而，產品負責人需要平衡和 團隊與利害關係人相處的時間，所以他不需要把所有時間花在團隊 身上。但是，一般而言，和團隊越近越好。 讓經理和教練坐在隔壁間 這時候，對我來說有點困難去提到這件事，因為我既是經理，又是 教練… 我的職責是盡可能和團隊緊密工作，我建立數個團隊，在團隊之間 切換，和成員搭檔編程(pair programmed)，培訓 Scrum master，組織
70 | SCRUM 和 XP 的實戰經驗 Sprint 規劃會議，等等。事後，大部分的人認為這是件好事，因為我 在敏捷軟體開發方面很有經驗。 但是，另一方面，我同時(這時星際大戰中，黑武士出場的音樂響起) 也是開發團隊的主管，在行政上是經理的角色。也就是說，每當我 來到團隊時，自主性會自動降低。"好討厭，老闆來了，他可能又很 多意見，是有關於我們應該做什麼，或是誰應該做什麼，讓他去說 吧" 我的觀點是：如果你是 Scrum 的教練(可能也是經理)，就應該盡可能 貼近團隊。但是只是有限的一段時間，之後就離開，讓團隊凝聚在 一起和自我管理。每隔一段時間(不要太頻繁)，藉由參加 Sprint 展示 來查看團隊的狀況，看看任務板，參加他們每天早上的每日會議。 如果你看到可以改進的地方，把 Scrum master 叫到一旁去指導他， 記得不是在團隊的面前這樣做。如果你的團隊非常相信你，不會看 到你就不說話，那就去參加他們的 Sprint 回顧會議，這是另外一個 好的方法。(請參考後面的章節"我們怎樣做 Sprint 的回顧") 對於運作良好的 Scrum 團隊，確認他們可以得到一切他們所需要的 東西，然後就可以讓他們自行處理 (除了 Sprint 展示會議除外)。 對於在敏捷環境下的經理們，上面的最後一句話，仍然是我能說的 最佳綜合建議。有一位好的經理是關鍵的成功因素。但是身為一位 經理，你應該試著讓你自己是多餘的。你可能不會因為那樣做而成 功，但是在嘗試的過程，會把你推向對的方向。多詢問 ”團隊需要 什麼，才能讓他們自管理？”，而非 ”我如何可以管理這個團隊？” 這可能需要有透明度，明確的目的，有趣和激勵的工作環境，適當 的保護，以及遇到問題時可以向上反映的管道。
8我們怎麼進行每日會議 我們每日會議都按照書中進行。它們每天會在同一個地方，同一時 間進行。在剛開始的時候，我們都是在一間單獨的房間中，舉行 Sprint 規劃會議(在那個時候，我們還使用電子板的 Sprint backlogs)。 然而，現在我們都在任務板前面舉行每日會議，沒有什麼能比它有 更好的效果。 我們通常都是站著舉行會議，因為它可降低會議時間超過 15 分鐘的 風險。 每日會議真的很重要！它是一個時機來讓大部分的同步訊息發生， 以及讓團隊提出重要的障礙。無疑地，如果做得不好，它可能會真 的真的很無聊 – 一堆人在那邊閒聊，可是卻沒人真的在聽。 Scrum Guide 最近更新了這三個問題，去反擊這樣狀況： - 我昨天做了什麼，來幫助我們團隊去達成這個 sprint 的目標？ - 我今天打算做什麼，好幫助我們團隊去達成這個 sprint 的目標？ - 我發現了什麼障礙，會阻止我或是團隊去達成這個 sprint 的目標？ 注意把重點放在 sprint 的目標，團隊所共享的高層次議題！如果 你的每日會議開始感到單調時，嘗試詢問以下的問題或是 Dan North 版本的問題：“我們 ’今天’ 最棒的事情是什麼？”，然後以開 放方式進行討論。無論你怎麼做，不要讓每日會議很無聊。保持不 斷嘗試！ 我們如何更新任務板 我們通常在每日會議中更新任務板。每一個人都會說明他昨天做了 什麼，今天要做什麼，然後一邊移動任務板上的便利貼。如果他有 提到一個沒有規劃到的項目，他會加一張便利貼到任務版上面。如 果他需要更新時間的估算，他會寫新的時間到便利貼上面，然後槓
我們怎麼進行每日會議| 73 掉舊的。有時候 Scrum master 會在大家說話的時候，同時更新這些 便利貼。 有些團隊會規定，每個人需要在會議之前更新任務板上的東西。這 個方法也不錯。只要決定好規則後，堅持執行就可以。 在每日會議中，許多團隊花了很多時間在更新便利貼上的數字。真 浪費！每日會議的目的是在取得同步，所以我發現最好的方式是 ” 即時” 更新白板(也就是，在事情發生時更新)，並且完全忽略任務 的估算。以這種方式進行，每日會議就變成是真的在溝通，而不是 管理或監督。 不管你用什麼形式存放你的 Sprint backlog，試圖讓整個團隊，一起 保持 Sprint backlog 的內容是及時更新的。我們曾試過讓 Scrum master 扮演 Sprint backlog 的唯一維護者，因此他必須每天詢問大家， 各自剩餘的時間估算為何。這個方法的缺點是： § Scrum master 花太多時間在管理工作上，而不是對團隊提供 支持，和消除他們障礙。 § 團隊的成員不再關心 Sprint backlog 的狀態，所以他們不再知 道 Sprint 的狀態。缺少回饋，將會降低整體的敏捷性和團隊 專注的程度。 如果 Sprint backlog 設計的很好，團隊中的每個人，都應該很容易去 更新它。 在每日會議一結束後，要有人算出所有剩餘時間估算的總和，然後 在 Sprint 的燃燒圖上畫上一個新的點。 處理遲到的傢伙 有些團隊會準備一個存錢筒。當你遲到時，即使只有遲到一分鐘， 你也要投錢到筒子裡頭，沒有人會關心為什麼。如果你在會議前打 電話，說你會晚一點到，你也是要投錢。
74 | SCRUM 和 XP 的實戰經驗 除非你有很好的理由，像是預約去看醫生，或是你自己的婚禮等等， 否則是無法倖免。 在筒中的錢，可以被使用在團隊中的一些活動，像是我們會在遊戲 之夜，用這些錢來買些漢堡吃 ：o) 這個方法效果不錯，但是，只有在有人常常遲到的團隊才需要，有 些團隊不需要這樣的東西。 團隊使用各種方式來互相取笑，好讓大家可以準時出現 (如果需要 的話)。只要確定是團隊他們自己想出來的，而不是強迫他們用上 面或是外面人的方法。要確定它很有趣。在某個團隊，遲到的人必 須唱一首很白癡的歌。如果你遲到第二次，你必須還要加上跳 舞。:o) 處理"我不知道今天要做什麼"的狀況 有時候，有人會說"昨天我做了這個那個，但是今天不知道該做什麼"， 這種狀況並不常見。那現在該怎麼辦？ 讓我們假設 Joe 和 Lisa 兩個人都不知道今天要做什麼。 如果我是 Scrum master，我會讓下個人繼續講下去，但是會先記起來 哪個人沒有事做。在每個人都說完後，我會和團隊從上到下檢視一 下任務板，確認每件事已經同步，也就是確保每個人都知道，每個 項目所代表的意思是什麼，等等。然後我會請人加上更多的便利貼。 接下來我會跟那些覺得沒事做的人說： "現在我們已經看過任務板了， 你們是否會對今天要做的事有些概念呢？"，我希望他們會知道了。 如果還沒，我會考慮是否有採用搭檔編程(pair programming)的機會。 假設 Niklas 將要去實做後端系統的使用者管理系統的 GUI。我會有 禮貌地建議，Joe 和 Lisa 可能可以和 Niklas 去撘檔編程。通常這都會 有效果。 要是這樣還不行，應該會採取下面的技巧。 Scrum master："好的，誰要展示有 Beta 水準的這個版本給我們看一 下？" (假設這是 Sprint 的目標)
我們怎麼進行每日會議| 75 團隊：感到困惑，並保持沉默 Scrum master："我們還沒有做完嗎？" 團隊： "嗯……還沒" Scrum master："哦，該死，為什麼還沒？ 還剩什麼？" 團隊："我們還沒有一個測試的伺服器，此外建構的腳本(build script) 也有問題" Scrum master："哈" (在任務的牆壁上加上兩張便利貼) "Joe 和 Lisa， 你們今天可以幫我們什麼呢？" Joe："哦……我想我可以試著去找找，有沒有測試的伺服器"。 Lisa："……我可以試著去解決建構腳本的問題"。 如果你很幸運的話，會有某個人真的展示出，你所要求的 beta 水準 的版本給你看，那真的是太好了，你已經達到 Sprint 的目標。但是 如果你的 Sprint 只進行到一半呢？ 很簡單，先恭喜團隊做的不錯。 然後從任務板中右下角的"next"區域，找出一到兩個故事，放到左邊 "not checked out"的欄位中。然後重新開始每日會議，通知產品負責 人，你已經加了一些項目到這個 Sprint 中。 或是利用時間去償還一些技術債，或者是做些技術上的探索。並確 保產品負責人在這個訊息迴圈中。 但是如果團隊還沒有達到目標，Joe 和 Lisa 仍然拒絕去做些有用的工 作。我通常會考慮以下幾種方法(沒有一種是令人愉快的，但是已經 是最後的手段了)： • 羞辱的方法："如果你不知道你怎樣可以幫助團隊，我建議 你回家去吧，或是看些書，或是怎樣都行。要不坐在旁邊， 等到有人需要幫忙就過去幫忙"。 • 保守的方法：隨便指派一個任務給他們。 • 同事間施壓的方法：告訴他們： "Joe 和 Lisa，放輕鬆來選擇， 我們大家站在這裡等你，直到你們找出可以幫助我們達成目 標的工作為止" • 奴役的方法："你們可以幫忙做一些雜役,像是倒咖啡，幫人 按摩，清理垃圾，煮午餐，或是一些我們可能要你們幫忙的 事"(你可能很驚訝，一聽到這裡，Joe 和 Lisa 在一瞬間就找 出要做的技術性任務：o)
76 | SCRUM 和 XP 的實戰經驗 如果有人經常逼得你這樣做，你應該要把她叫到一旁，給他一些指 導。如果這個問題持續存在，你需要評估一下，是否這個人對你的 團隊很重要。 如果他不是太重要，試圖把他從你的團隊中移走。 如果他很重要，就試圖讓他和別人搭檔，讓那個人當他的"牧羊者"。 Joe 可能是一個優秀的開發人員和架構師，只是他比較需要讓其他人 告訴他該做什麼。好的，給 Niklas 當 Joe 的牧羊者，或者你自己來 做這件事。如果 Joe 在你的團隊是非常重要，那這樣做非常值得。 我們有過這樣的例子，多少有點效果。 對於剛接觸 Scrum 的團隊，”我不知道今天要做什麼” 是常見的典 型問題，因為過去是由其他人為他們決定事情。當他們對於自組織 有更多經驗後，這個問題就會消失。人們會學習去找出要做什麼。 所以如果你是一個 Scrum master，並且發現你常常依賴上面那些 方法，你應該考慮後退一步。儘管你有想幫忙的意圖，但你可能會 是阻礙團隊學習去變成自組織的最大絆腳石！
9我們怎樣進行 Sprint 的展示 Sprint 展示(有些叫它 Sprint review)是 Scrum 中重要的一部份，但是 人們都低估它。 "哦！ 我們真的需要去展示嗎？ 沒有啥好東西可以展示" "我們沒有時間去準備&%$#的展示" "我沒有時間去參加其他團隊的展示！" 我無法了解為什麼我會叫它 “sprint 展示(demo)”！我倒底在想什 麼？官方名字是叫做”sprint 檢視(review)會議” ，這是比較好的名 字。展示意味著單向溝通 (”來這裡一下，這是我們所建造出來 的”)。而檢視則意味這雙向溝通 (”這是我們所建造出來的，你認為 如何？”)。Sprint 檢視是有關於回饋的事情！所以當你下面看到”展 示”時，把它想成”檢視”，好嗎？ 為什麼我們堅持所有的 Sprint 在結束前都要展示 一次做得不錯的展示，即使可能看起來很一般，也會帶來深遠的影 響。 § 團隊因所完成的結果而得到認可，他們會感覺很棒。 § 其他人可以知道你們團隊現在正在做什麼。 § 這個展示可以吸引關係利害人給予重要的回饋。 § 展示是(或應該是)一個社交的活動，不同團隊可以相互交流， 和討論各自的工作。這是有價值的。 § 有展示會促使團隊真正完成一些東西，並發行它(即使是在測 試環境中)。沒有展示，我們總是會得到一個 99%完成的東 西。有了展示，或許我們完成的東西變少，但是這些東西是 真正的完成。這(以我們的例子來說)會比得到一堆看似完成 的東西好的多，而且他們將會影響到下一個 Sprint 的進行。
78 | SCRUM 和 XP 的實戰經驗 如果團隊是有點被半強迫去進行展示，尤其他們沒有太多東西是真 正的完成，這樣的展示將會令人感到很尷尬。團隊在展示過程中， 可能會結結巴巴的，之後的掌聲也可能是稀稀落落的。人們會對這 團隊感到有點難過，也有人感到不太高興，因為他們浪費時間在一 場很爛的展示上面。 這會傷害到一些人，但是就像良藥苦口一樣。下一次的 Sprint，團隊 會真的試圖去完成一些事情。他們會感覺 "好的，也許下個 Sprint 我 們只能展示 2 件事情，而不是 5 件。但是這些該死的功能一定會正 常運作！" 團隊知道，無論如何他們必須展示。讓一些真正有用的東 西被展示的機會，會變得大的很多。這種情況我已經看過很多次了。 對於多個團隊的環境下，這是十分重要的。每隔固定一段時間，被 邀請的每個人都需要看看產品的整合狀況。總是會有些整合上的問 題，但是你越早發現它們，就越容易被解決。自組織的團隊總是利 用透明度和回饋迴圈在運行，而一個運作良好的 sprint 檢視會 議，則提供了以上兩個機制在裡面。 Sprint 展示的檢查清單 • 確保你已清楚地描述 Sprint 的目標。在展示中，如果有人對 你的產品一無所知，花幾分鐘簡介一下產品。 • 不要花太多時間去準備展示，特別不要去做些花俏的展示。 把那些玩意放到一邊，只要集中精神在真正可運作的程式碼 上面。 • 保持快速的結奏，也就是集中精神，讓簡報能保持快結奏， 而不是好看。 • 讓展示是保持在商業導向的層次，不要有太多技術性的細節。 著重於"我們做了什麼"，而不是"我們如何做到它"。 • 如果可能，讓觀眾自己試用一下產品。 • 不要展示一堆小的錯誤修復，或是微不足道的功能。可以提 到他們，但不用展示他們，因為通常會花很多時間，並且讓 大家不能專注於更重要的故事中。 有些團隊進行兩種檢視：短暫的公開檢視，目標瞄準外在的利害關 係人。之後再接著內部的檢視，來看更多細節，像是關鍵的挑戰和 技術決策等等。這是很好的做法，可以讓知識在團隊間散播，又避 免利害關係人聽到他們不在乎的技術細節。
我們如何做 SPRINT 回顧| 79 處理"無法展示"的項目 團隊成員： "我不打算去展示這個項目，因為它無法被展示出來。這 個故事是'改進延展性，因此系統可以處理 10,000 同時上線的使用者' 我拼了老命也無法讓 10,000 使用者同時上線來展示，不是嗎？" Scrum master： "那你已經做完了嗎？" 團隊成員： "是的，當然"。 Scrum master： "那你怎麼知道？" 團隊成員： "我在效能測試環境中架設好系統，啟動 8 個負載伺服器， 對系統同時發出請求 "。 Scrum master： "但是你有任何指標能顯示出系統可以處理 10,000 使用者？"。 團隊成員： "嗯，這個測試機器挺爛的，但是在我的測試過程中，它 還是可以處理到 50,000 使用者同時上線"。 Scrum master： "你怎麼知道？" 團隊成員(快失去耐性)： "好的，我有份報告，你可以自己看啊，上 面有如何設定這個測試，以及多少請求被發出！" Scrum master： "嗯，太棒了，這就是你的"展示"啊。只要給大家看 這份報告就可以了，這比什麼都沒有強，對嗎？"。 團隊成員： "哦，這樣就夠了嗎？ 但是這報告有點難看，需要去美 化一下"。 Scrum master： OK，"好的，但不要花太多時間。不需要很好看， 只要能表達訊息就可以"
10我們如何做 Sprint 回顧 為什麼我們堅持所有團隊都要做回顧會議呢？ 有關回顧最重要的事情，就是確保回顧會發生。 基於某種原因，團隊傾向不太願意去做回顧。沒有些溫柔的刺激， 我們大部分的團隊通常會跳過回顧，然後移向下一個 Sprint。或許這 是瑞典文化的問題，但我不太確定。 不是的，我在許多國家都看到相同狀況，所以那是人的本性，我們 總是想要跳到下一件事情。諷刺的是，你越有壓力，你越可能跳過 回顧會議。但是，就是因為你越有壓力，你越迫切需要回顧會議！ 這有點像是 ”我急著想把樹木砍倒，所以我沒有時間停下來把斧頭 磨利！” 所以 Scrum Master 真的要堅持進行回顧會議！它不會要 花太久時間。對於一個兩週的 sprint，回顧會議固定的長度是一小 時。但是每隔幾個月，你可以進行比較長的回顧會議 (半天或整 天)，用來處理比較棘手的問題。 不過，每個人看起來是同意，回顧是極端有用的。事實上，我想說 的回顧是 Scrum 中第二重要的事件(最重要的是 Sprint 規劃會議)，因 為這是你去改進的最佳機會！ 沒錯。這是為什麼回顧會議是 Scrum 頭號最重要的事情，而不是 第二重要的事！ 當然，你不用需要回顧會議去得到好的點子，你在家裡的洗澡盆中 就能想到！ 但是團隊能接受你的想法嗎？ 可能吧！ 但是如果這想法 "來自團隊"，也就是在回顧會議上，每個人都可以貢獻和討論一些主 意，這樣得到的想法會讓大家容易接受。 如果沒有回顧，你會發現團隊，會一而再的，再犯同樣的錯誤。
我們如何做 SPRINT 回顧| 81 我們如何組織回顧會議 或許大家的做法會稍有不同，但是我們通常會這樣做： • 根據討論的範圍有多少，我們會安排 1-3 個小時。 • 參與者： 產品負責人，整個團隊，和我自己。 • 我們會到一個封閉的房間，或是有舒適的沙發的角落，或屋 頂庭院，或是類似的地方。只要我們能夠不受干擾的討論就 好。 • 我們通常不會在團隊的房間內做回顧，因為人們的注意力很 容易被分散。 • 會指定某個人當秘書。 • Scrum master 會展示 Sprint backlog，在團隊的幫助下，對 Sprint 做出總結。包括重要的事件或是決定等等。 • 我們會輪流發言。每個成員在不被打斷的狀況下，會有機會 說出他認為什麼是好的，什麼是可以做的更好，以及什麼是 下個 Sprint 可以做的不一樣的。 • 我們會檢視預估和實際的速度。如果有太大的差異，我們會 分析為什麼。 • 當時間快要結束的時候，Scrum master 會試圖去總結出具體 的建議，有關於下次 Sprint 中我們什麼地方可以做的更好。 我們的回顧會議一般來說不會太結構化，太嚴謹。但是潛在的主題 都是一樣的： "下次 Sprint 中，什麼事情我們能做的更好？"。 這裡是我們最近一次回顧會議的白板：
82 | SCRUM 和 XP 的實戰經驗 這裡有三行： § Good： 假如我們再做一次相同的 Sprint，我們哪些事情可以 保持相同的作法。 § Could have done better： 假如我們再做一次相同的 Sprint， 我們哪些事情的做法可以改變。 § Improvements： 有關未來我們如何改進的具體方法。 所以第一行和第二行是回顧過去，而第三行是展望未來。 在團隊集思廣益，列出所有的想法後，他們會用"計點投摽"去決定， 哪些改進是下個 Sprint 需要注重的。每個團隊成員會有三塊小磁鐵， 可用來決定在下一個 Sprint 中，要改進項目的優先順序。每個團隊 成可以自行決定磁鐵要放在哪個項目，或是三個都放在同一個項目 上也可以。 根據投票的結果，選出 5 個要著重的項目。在下一個回顧會議中， 他們會追蹤這些項目的改進狀況。。 重要的是，不要過度貪多。在每個 Sprint 中，只要著重幾個改進項 目就可以了。 有很多有趣的方式，可來進行回顧會議。有各式各樣的形式，所以 會議不該了無新意。你可以在 Agile Retrospectives 一書中發現很 多想法。或者試試 Retromat，它是一個回顧方式的隨機產生器， 也很有趣。(www.plans-for-retrospectives.com)。 :o) 然而，我注意到，對於大多數的案例，我持續使用上述簡單的方
我們如何做 SPRINT 回顧| 83 式，仍然可以運作的很好。或者以更簡單的方法，花二十分鐘的休 息時間，進行兩個討論主題：“什麼要保持下去” 和 “什麼應該改 變” 。雖然簡單，但是總比沒有好！ 在團隊間散播所學到的教訓 在 Sprint 回顧會議中，所得的資訊通常是極度有價值的。團隊很難 集中火力，是因為銷售經理強押開發人員，在銷售會議上充當技術 專家？ 這是非常重要的資訊。是否其他團隊可能也有相同的問題？ 我們是否應該教育產品經理更多有關於產品的知識？ 因此讓他們自 己可以做銷售支持(sales support)。 或者更好的方式，邀請銷售經理來參加會議，從中學習他們的需 求，一起討論可能的解法！ 一個 Sprint 回顧會議，不只有關如何讓團隊在下個 sprint 中能做得更 好，它還有更大的涵義。 我們處理的策略是十分簡單的。有個人(目前是我)參加所有 Sprints 的回顧會議，充當經驗知識的橋樑。這是相當不正式的作法。 另外一種方法，是讓每個 Scrum 團隊公佈一份 Sprint 回顧報告。我 們曾經試過這個方法，但是發現沒有很多人去看這些報告，更不用 講因此展開行動的更少。所以我們只是用上面這種簡單的方式。 對於充當"經驗知識橋樑"的這個人，有些重要的規則： § 他應該是一個好的傾聽者。 § 如果回顧會議太安靜，他應該準備去問些簡單，但是目標明 確的問題，可以刺激團隊的討論。例如："如果時間可以到 轉，重新從第一天開始這個 Sprint，那些事情你會用不同的 方法進行？"。 § 他應該自願花時間去參與所有團隊的所有回顧會議。 § 他應該具有某種權力地位，所以在一些團隊無法控制的改進 建議，他可以幫忙推動。 這種方法運作的相當好，不過也許有其它方法能做的更好。如果有 的話，請告訴我。
84 | SCRUM 和 XP 的實戰經驗 互換引導者是不錯的模式。像是 “我會引導你團隊的回顧會議，如 果你可以引導我的團隊”。讓簡單的雙向知識傳播可以發生，也讓 身為 Scrum master 的你，可以專心參與你團隊的回顧會議 (而不 是只能引導而已) 改變，或不改變 假設說，團隊總結出"我們團隊內部溝通太少了，所以總是重覆著彼 此做過的工作，並且搞亂對方的設計" 那我們應該怎麼呢？導入每日會議？或是導入新的功具來促進溝通？ 還是更多 wiki 的頁面？嗯，也許吧。也許會再發生，也許不會。 我們發現，在許多狀況下，只要能清楚的指出問題所在就足夠了， 在下個 Sprint 中會自動地被解決。特別是，如果你在團隊房間的牆 壁上，貼上 Sprint 回顧的結果(我們常常忘記去做，還蠻丟臉的！)， 這樣會更有效。你所導入的每個改變，都會要付出一些代價。因此 在導入改變之前，先考慮什麼都不做，然後希望問題會自行消失(或 是變小)。 上面這個例子("我們團隊內部溝通太少了…")是一個很典型的例子， 說明若是什麼都不做的狀況下，這問題有可能被解決。 如果每次你都導入一些改變，可能有些人會開始抱怨。人們會變成 不太願意去提出一些小問題，這將會很麻煩。 在回顧會議中，所發現問題的範例 這裡有些在回顧會議中所找出的一些問題，以及相對的典型處理動 作。 "我們應該花更多的時間，把故事拆解成更多的小項目和任 務"
我們如何做 SPRINT 回顧| 85 這個問題相當普遍。在每次的每日會議上，團隊成員自己會說"我真 的不知道今天要做什麼"。所以之後每次每日會議上，你需要花時間 去找出具體要做的任務。通常這些事情會前做，會更有效率。 典型處理動作： 無。團隊會在下次 Sprint 規劃會議中自行解決這個 問題。如果它重複發生，延長 Sprint 規劃會議的時間。 "太多外界的干擾" 典型處理動作： • 要求團隊在下一個 Sprint 中，減低他們的投入程度，所以他們會有 比較合理的計畫 • 要求團隊在下一個 Sprint 中，紀錄干擾的狀況更清楚一點，誰干擾， 花多久時間。可以幫助我們之後更容易解決問題。 • 要求團隊將所有干擾都轉給 Scrum master 或是產品負責人 • 要求團隊指定某個人當"守門員"，所有的干擾都要經過他，所以剩 餘的人都可以集中精力在要做的事情上面。Scrum master 或是大家輪 流來扮演這個角色。 守門員輪流的模式相當常見，並且通常運行的不錯。試試看吧！ "我們過度承諾，最後只做完了一半" 典型處理動作： 無。團隊可能在下個 Sprint 中不會過度承諾。或是 至少不會像這次承諾這麼多。 順便一提，在 2014 年時，“sprint 承諾(commitmment)” 一詞從 Scrum Guide 中移走。相對地，它更名為 “sprint 預測(forecast)”。 好多了！承諾這個詞會造成多大的誤解。許多團隊認為 sprint 規 劃是某種形式的允諾 (有點傻，想想敏捷宣言中四個主要價值之 一：“回應變化 重於 遵循計劃” )。Spint 規劃不是一種承諾，它是 一個預測和假設 –“這是我們認為如何達成 sprint 目標的最好方 式”。 無疑地，能交付的東西持續少於預測的，會令人覺得很討厭。如果 這是問題，可嚴格採用昨日天氣的做法，根據上次 sprint 做完的 量，來拉多少個故事點數 (如果你想要有些變化，可以用過去三個 sprint 的平均值)。這樣簡單而強大的技巧，可以讓問題消失，因 為你的速度變成可自我調適。
86 | SCRUM 和 XP 的實戰經驗 "我們辦公室環境太吵或是太混亂了" 典型處理動作： • 試圖去建立一個較好的環境，或是把團隊搬到辦公室外面去， 租一旅館的房間，怎樣都行。請看"我們怎樣佈置團隊的房間 "。 • 如果不可能，告訴團隊在下次 Sprint 中減低他們的投入程度， 並且清楚註明這是因為太吵和太混亂環境的緣故。希望這會 使團隊負責人，開始去向上層主管去反映這件事。 幸運地，我從來不用糟到要威脅團隊搬到辦公室外面去。但是如果 需要的話，我會這樣做 ：o)。
11Sprint 之間的休息時間 在實際生活中，你不能總是在衝刺。你需要在衝刺之間休息。如果 你都是在做衝刺，你的效果可能只是像在慢跑。 這也適用於生活，不只是 Scrum！例如，如果我生活中沒有鬆懈 的時間，本書就不會出現 (更不用講第二版，或是我其他的書籍， 文章，和視頻等等)。鬆弛對於生產力和個人福祉兩者來說，是超 級重要的！如果你是行事曆老是滿檔的人，試試看這個：打開你的 行事曆，每週凍結半天，寫下 ”鬆弛” 或是 ”不可預定” 或是其他。 不要事先決定你在那個時候要做什麼，看看會發生什麼事 :o) 同樣地，Scrum 和軟體開發也一樣。Sprint 安排的相當密集。身為開 發人員，你可能沒有機會休息，每天你必須站在那該死的會議中， 告訴大家你昨天完成什麼。而沒有人願意說"我昨天把腳翹在桌子上， 都在逛 blog，和喝卡布基諾"。 除了真正的休息外，還有另外一個好的理由，讓我們在 Sprint 之間 有些休息。在 Sprint 展示和回顧會議之後，團隊和產品負責人將會 有一堆資訊和想法需要消化。如果他們立即開始規劃下一個 Sprint， 將沒有人有機會去消化現有的資訊，或是上次所學到的教訓。在 Sprint 展示完後，產品負責人沒有時間去調整它的優先順序。 較差的安排：
我們如何做發佈計畫和處理固定價格的合約|89 我們試圖在開始新的 Sprint 之前(更準確地說，在 Sprint 回顧會議後 和下個 Sprint 規劃會議之前)，導入某種形式的休息。但是我們並不 是每次都成功。 但是最起碼，我們試圖去確保 Sprint 回顧會議和接下來的 Sprint 規劃 會議不會在同一天發生。在開始下一個 Sprint 前，每個人應該至少 可以有個晚上，不用去想 Sprint 的事。 好一點： 更好些： 有一種方式叫"實驗室之日(lab days)" (或你愛叫什麼都行)。那也是， 在這個日子裡，開發人員可被允許去做任何他想做的事情(嗯，我承 認，是從 Google 抄來的)。例如，研究最新的工具或是 API，準備認 證，和同事討論一些有的沒的，或是寫些自己有興趣的程式，等等。 我們的目標是在每個 Sprint 之間有個實驗室之日。這樣你在 Sprint 之 間會得到自然的休息，你讓團隊有機會，能讓他們的知識能持續跟 得上潮流。這也是一項能吸引人的員工福利。 最好的方式？ 目前我們每個月有一個實驗室之日，在每個月的第一個禮拜五。為 什麼不是在每個 Sprint 之間呢？ 好的，因為我覺得，整個公司應該 有相同的實驗室之日，這是非常重要的事情。否則人們不會把它當
90 | SCRUM 和 XP 的實戰經驗 作一回事。我們(到目前為止)還沒有把所有的產品的 Sprints 都調整 一致，因此我必須選擇一個和 Sprint 無關的實驗室之日來代替。 也許有一天，我們會嘗試去同步所有產品的 Sprints(也就是，所有產 品和團隊，Sprint 都有相同的開始和結束時間)。在這種狀況下，我 們絕對能在 Sprint 之間，擺個實驗室之日。 在 Spotify 公司，經過大量的實驗後，我們最終實現了全公司的黑 客松週。每年兩次，我們在一週內，可以做任何你想要做的，然後 在星期五會有個展示的宴會。全公司的人都會參加，不只是技術的 人員。這樣觸發的創新數量是非常驚人的！並且因為每個人都是相 同時間，團隊不會因為有相依性而出問題。我做了一個影片，來描 述 Spotify 的工程師文化，並提到了黑客松週和其他事情。可以在 http://tinyurl.com/spotifyagile 看到這個影片。
12 我們如何做發佈計畫和處理固定價格的合約 有時候，一次只規劃一個 Sprint 要做的事情是不夠的，我們需要提 前做更多計畫。尤其是處理固定價格的合約，我們必須事先規劃， 否則我們將會有無法準時交付的風險。 對我們來說，發佈計畫是試圖去回答這樣的問題："最晚是什麼時候， 我們才能交付這個新系統的 1.0 版本"。 如果你需要去學有關發佈計畫的事，我建議你跳過這個章節，去看 Mike Cohn 的書： "Agile Estimating and Planning"。我真的希望，我 能更早就讀到這本書(我是在我自己已經解決這些問題後才讀到它)。 我的發布計畫版本有點簡單，但是對於入門來說已經足夠了。 並且還需要看 Eric Ries 所寫的精實創業。最大的問題，是大多數 的專案，都企圖打造大規模的發佈，而不是交付小的增量，然後再 看看是否在正確的道路上。精實創業，如果使用的合宜，可以徹底 地降低風險和失敗的代價。 定義你的驗收門檻 除了一般的產品 backlog 外，產品負責人需要定義一些驗收門檻，它 是從合約的角度，將產品 backlog 的重要性層級，做出簡單的分類。 這裡有些驗收門檻規則的範例： § 所有重要性 >=100 的項目，都需要被放到 1.0 版本中，否則 我們將會罰款到死。 § 所有重要性在 50-99 間的項目，應該要被放到 1.0 版本中。 不過或許我們可以在下一個緊接快速發行的版本中，完成他 們。
92 | SCRUM 和 XP 的實戰經驗 § 重要性在 25-49 之間的項目也是需要的，但是他們可以在緊 接的 1.1 版本中被完成。 § 重要性 < 25 的項目是不確定的，可以永遠不會需要。 這裡有一個產品 backlog 的範例，根據上面的規則，用了不同顏色來 標示。 紅色= 必須被包含在 1.0 版本中 (banana – pear) 黃色= 應該在 1.0 版本中 (raisin – onion) 綠色= 可能可以之後完成 (grapefruit – peach) 所以如果我們可以在期限前，交付從 banana 到 onion 的每個項目， 我們就安全了。如果時間不夠用，我們可能跳過 raisin，peanut， donut 或 onion。Onion 以下的東西都是額外的。 當然啦，如果可以的話，不需要用這些數字優先等級來做分析！只 需列出順序，但是對你來說已經足夠。 對最重要的項目作時間的估算 為了要去產生發佈計畫，產品負責人需要估算，至少對於合約中， 所包含的所有故事都要算。就像 Sprint 規劃會議一樣，需要產品負 責人和團隊一起共同完成 - 團隊一起估算，產品負責人描述項目內 容，並回答問題。 Importance Name 130 banana 120 apple 115 orange 110 guava 100 pear 95 raisin 80 peanut 70 donut 60 onion 40 grapefruit 35 papaya 10 blueberry 10 peach
我們如何做發佈計畫和處理固定價格的合約|93 如果事實證明這樣可以更接近正確的結果，那這個時間估算是有價 值的。但如果結果證明是有所差距的，例如像是偏差了 30%，這樣 會比較沒價值。可是如果它跟事實一點關係都沒有，那就完全沒有 用了。 這裡，我根據做估算的人，做估算所用的時間，以及估算的價值， 三者間的關係畫了一張圖。 若是用文字來解說，這就有點冗長： § 讓團隊來做估算。 § 不要讓他們花太多時間。 § 確定他們了解到時間估算只是粗略的估算，並不是承諾。 通常產品負責人會把團隊放到一個房間中，提供一些點心飲料，並 且告訴他們這個會議的目的，是把產品 backlog 中前 20 個(或多少都 可以)故事作時間估算。他會把所有故事講過一遍，然後再讓團隊開 始工作。產品負責人會待在房間裡，回答大家的問題，有需要時釐 清每個項目的範圍。就像在做 Sprint 規劃會議一樣，"如何展示"這個 欄位是非常有用的方法，可減低產生誤解的風險。 這個會議必須嚴格控制時間長度，否則團隊會試圖花太多時間，在 少數的故事上。 如果產品負責人要他們花更多的時間，他可以之後再安排另一個會 議。團隊必須確保這個會議，對於目前這個 Sprint 的影響，可以讓 產品負責人感到非常明顯的。所以他能理解，他們時間估算的活動 是有代價的。 下面這個例子，說明了時間估算最終的結果 (用故事點數表示)：
94 | SCRUM 和 XP 的實戰經驗 把這個叫做 ”時間估算” 非常容易搞混。相反地，叫 ”大小估算” 比 較好。我不知道 “banana” 要多久能完成，但是我相當確定它 比 ”apple” 長一點，並且比 “orange” 短一點。大致對會比確定錯 好多了！ 估算速度 好的，所以我們對於最重要的故事，已經有了一些粗略的估算。 下一步就是估算每個Sprint平均的速度。 這意味著我們需要去決定我們的投入程度。請參見"團隊如何決定哪 些故事要被放到 Sprint 中"。 噢，不，不要再提到該死的投入程度 … 投入程度基本上表示："團隊有多少時間，可花在目前所承諾的故事 上"。它不可能是 100%，因為團隊會花時間，在做一些沒有規劃到 的項目，或是切換工作內容，幫助其他團隊，檢查 mail，修理他們 出問題的電腦，在茶水間討論一些政治等等。 假設我們決定團隊的投入程度是 50%(相當低，我們一般都是 70%左 右)。並且 Sprint 的長度假設是 3 周(15 天)長，然後團隊是 6 個人。 Imp Name Estimate 130 banana 12 120 apple 9 115 orange 20 110 guava 8 100 pear 20 95 raisin 12 80 peanut 10 70 donut 8 60 onion 10 40 grapefruit 14 35 papaya 4 10 blueberry 10 peach
我們如何做發佈計畫和處理固定價格的合約|95 每個 Sprint 都是 90 人天，但是只能被預期產出 45 人天的故事 (因為 投入程度是 50%)。 所以我們估算的速度是45個故事點數。 忽略投入程度。要求團隊查看這個列表，根據經驗來猜在一個 sprint 內可以做多少，然後算出點數。那會比投入程度還快，不管 準確或不準確。大致對會比 … 好 – 噢，等等，我已經講過了。 如果每個故事的時間估算都是 5 天(但實際上不是)，那團隊差不多能 在一個 Sprint 中完成 9 個故事。 在發佈計畫中考量所有因素 現在我們有時間估算和速度(45)，我們可以很容易把產品 backlog 中 拆解到 sprint 中： Imp Name Estimate Sprint 1 130 banana 12 120 apple 9 115 orange 20 Sprint 2 110 guava 8 100 pear 20 95 raisin 12 Sprint 3 80 peanut 10 70 donut 8 60 onion 10 40 grapefruit 14 Sprint 4 35 papaya 4 10 blueberry 10 peach 在沒有超過 45 的估算速度下，每個 Sprint 盡可能塞下很多的故事。
96 | SCRUM 和 XP 的實戰經驗 現在我們知道我們大約需要三次 Sprint，才能完成所有"必須要做"和 "應該要做"的。 3 個 Sprint = 9 個星期 = 2 個月。這是我們要承諾客戶的最後期限嗎？ 這要視合約的性質而定，以及範圍有多固定，等等。我們通常會增 加蠻多的緩衝，來保護糟糕的時間估算，無法預期的問題，以及無 法預期的功能等等。所以在這種狀況下，我們可能會同意會"保留"1 個月，然後設定交付日期在三個月後。 這裏有另一個替代方案，也運作得不錯。用一個範圍(30-50 點)來 評估速度。把 backlog 分成三堆： 所有：這些故事都要被做完，即使我們的速度不快 (30) 。 某些：某些故事將要被完成，但不是全部。 沒有：沒有一個故事要被完成，即使我們的速度很快(50)。 最棒的事情是，我們能每三個星期，展示一些有用的事情給客戶。 並且在我們進行中，邀請他們更改需求(當然啦，這要看這是什麼合 約而定)。 調適發佈計畫 現實不會調整自己去適應計畫，所以我們必須削足適履。 在每個 Sprint 後，我們會檢查一下這個 Sprint 的實際速度。如果實際 的速度和估算速度差距很大，我們會調整下一個 Sprint 的估算速度， 並且更新發佈計畫。如果這會帶來麻煩，產品負責人會開始和顧客 談判，或是檢查一下是否可以在不違反合約下調整範圍。或者他跟 團隊想出一些方法，藉由消除在 Sprint 過程中，所發現的某些嚴重 障礙，以增加團隊的速度或是投入程度。 產品負責人可能打電話給顧客說 "嘿，我們進度有點落後，但是我相 信，如果把'embedded Pacman'給拿掉的話，我們一定可以趕上期限， 因為它會花我們許多時間去建構它。如果你接受的話，我們可以在 第一次發佈後，在三週後的下一個發佈中，把它加進去"。
我們如何做發佈計畫和處理固定價格的合約|97 可能這對顧客來說並不是好消息，但是至少我們是很有誠意，並且 給顧客一條容易的選擇 - 我們應該要準時交付最重要的功能，還是 延遲一段時間後交付出所有功能？ 通常這不是很困難的選擇 ：o) 我做了一個十五分鐘的視頻，叫做 “Agile Product Ownership in a Nutshell”。它包含了一堆有用的提示和技巧，是和 Scrum 的發佈 計畫和 backlog 管理有關的。來看看吧！ http://tinyurl.com/ponutshell
13我們如何結合 Scrum 和 XP Scrum 和 XP 結合後，可以帶來很多好處，這點是無須爭議的。網路 上，我看到大部分的資料都支持這個論點，所以我不用再花時間去 爭論為什麼。 好的，我注意到一件事。Scrum 著重在管理以及組織的實踐。而 XP 大多著重於實際的編程實踐。那是為什麼它們可以一起運作的很好 - 它們解決不同領域的問題，並且互補對方的不足。 因此，我要在現有的經驗證據中，加上我的聲音：Scrum 和 XP 組合 起來是很有成效的！ 我從 Jeff Sutherland 那裡了解到，一開始 Scrum 是有實施 XP 的 實務。但是 Ken Schwaber 說服了他，把工程實踐從 Scrum 中移 除，以保持整個模型的單純，讓團隊自己去負責技術實務的部分。 或許，這可以幫助 Scrum 傳播的很快。但是，缺點是許多團隊因 此而受難。因為缺乏技術實務，而導致無法建立可持續的敏捷開 發。 我將要介紹某些較有價值的 XP 實踐，以及他們如何套用到我們每日 的工作中。我們並沒有要求所有團隊，去採用所有的實踐。但是總 歸來說，我們已經在大多數的方面，嘗試過 XP 和 Scrum 的組合。有 些 XP 的實踐，可以直接被 Scrum 解決掉，因此可被視為重疊的實踐。 例如： "完整團隊"、"坐在一起"、"故事"、和"計畫遊戲"。在這樣的 狀況下，我們已經直接採用 Scrum。 搭檔編程 我們最近在某一個團隊開始採用搭檔編程，運作的相當好。我們大 部分的其他團隊，仍然沒有嘗試太多的搭檔編程。但是在某個團隊
我們如何結合 SCRUM 和 XP | 99 實際運用它，跑幾次 Sprint 後，我因此而被啟發，願意試著指導更 多團隊去試試看。 到目前為止，有些關於搭檔編程的結論： § 搭檔編程可以改進程式碼的品質。 § 搭檔編程可以改進團隊的注意力(例如，坐在你後面的人說" 嘿，這個東西在這個 Sprint 中真的需要嗎？")。 § 令人驚訝的，那些強烈反對搭檔編程的開發人員，實際上根 本沒有嘗試過它。可是一旦嘗試過，便很快喜歡上它。 § 搭檔編程會讓人精疲力盡，不應該整天都這樣做。 § 經常更換夥伴是有好處的。 § 搭檔編程可以增進團隊間知識的傳播。會令人想不到的快速。 § 有些人就是對搭檔編程感到不舒服。不要因為他不想搭檔編 程，就否決一個優秀的程式設計師。 § 檢視程式可以當作搭檔編程的替代方案。 § "領航員"(不使用鍵盤的傢伙)應該也要有他自己的電腦。並 不是用來開發，而是需要作一些嘗試，或是當"司機"遭遇到 問題的時候查看文件，等等。 § 不要強迫人們採用搭檔編程。而是鼓勵他們並提供正確的工 具，讓他們根據他們自己的步調去實驗。 測試驅動開發(TDD) 阿們，對我來說，TDD 是比 Scrum 和 XP 還要重要。你可以拿走我 的房子，我的電視，和我的狗。但是不要試圖阻止我去做 TDD！如 果你不喜歡 TDD，那不要讓我到你的地盤，因為我會想盡各種方法 偷偷去嘗試它：o) 好吧，我已經不再對它這麼狂熱。我了解到 TDD 只是一個相當小 眾的技術，只有少數的人有耐心去精通它。相反地，我會教授這些 技術，但是讓團隊決定要用多少，以及何時去用。 這裡有個 TDD 的 10 秒總結： 測試驅動開發意味著，你要先寫自動化測試，然後你 再寫足夠的程式碼去通過測試，接著重構你的程式碼， 主要是去改進可讀性和移除重複的地方。一直反覆進 行這樣的事。。
100 | SCRUM 和 XP 的實戰經驗 這裡有些對測試驅動開發的看法。 § TDD 很難，程式設計師要花一段時間才能掌握它。事實上， 在很多狀況，問題不在於你教多少，指導多少或是展示多少。 唯一有效的方法，是讓一個擅長 TDD 的人，讓他和你一起 搭檔編程。一但知道怎麼做以後，他將會受到很大的影響， 並且不會再去用其他方法工作。 § TDD 對系統設計有相當深遠且正面的影響。 § 在新產品中，需要花一段時間，才能讓 TDD 被應用的很有 效率。特別是黑箱整合測試，但是投資報酬率相當好。 § 確認你投資的時間，足夠到讓大家能很容易撰寫測試。這意 味著要有適當的工具，受過訓練的人，以及提供合適的 utility classes 或是 base classes 等等。 因為 TDD 還蠻難的，我並不打算強迫人們去用它。相反地，我指 導他們以下準則： 1) 確保每個關鍵的功能，都至少有一個端點到端點的驗收測試。可 透過畫面，或是畫面下一層來操作。 2) 確保每個複雜或是關鍵的業務之程式片段，都有進行單元測試。 3) 這會遺留某些程式碼沒有被涵蓋，那沒有關係。但是要知道哪些 沒有被涵蓋，確定這是經過深思熟慮後的取捨，而不是只是被忽略 了。 4) 當你開發到哪裡，就要撰寫測試到哪裡，不要留著之後才做（因 為你之後可能跟你現在一樣忙）。 在沒有要求全面 TDD 的狀況下，看起來仍然有足夠的維護能力。 因為報酬遞減的關係，測試涵蓋度最終只達到 70%。簡單來說， 測試自動化是關鍵，而 TDD 是可有可無。 我們在測試驅動開發過程中，使用了以下工具： § jUnit / httpUnit / jWebUnit 我 們 正 考 慮 去 用 TestNG 和 Selenium。 § HSQLDB 在測試中，被當成一個嵌入式的 in-memory 資料庫。 § Jetty 在測試中，被當成一個嵌入式的 in-memory 的 web container。 § Cobertura 用來做測試涵蓋度度量。 § Spring framework 用 來 連 接 不 同 型 態 的 測 試 裝 置 (test fixture)(帶有 mock，不帶 mock，連接外部資料庫，連接 in memory 資料庫等等)。
我們如何結合 SCRUM 和 XP | 101 在我們最複雜的產品中(從 TDD 的觀點來看)，我們都有自動化黑箱 驗收測試。這些測試會在記憶體中啟動整個系統，包括資料庫和網 頁伺服器，並且透過它的公開介面去存取這個系統(例如像是 HTTP)。 這樣的運作方式，比之前用的還要容易，因為有很多靈巧的測試工 具或是框架可以用。他們非常有用，不論你是否要做 TDD。 這樣會使開發-建構-測試的循環變得很快。這也可當作一張安全網， 讓開發人員有足夠的信心常常去重構，即使當系統成長後，設計也 能保持乾淨和簡單。 在新的程式碼上做 TDD 對於所有新開發的程式，我們都會做 TDD。即使這意味著最初的專 案建置，需要花費較長的時間(因為我們需要更多工具，以及和支援 一些測試的裝置等等)。這是有點不容易，但是它的好處很大，因此 沒有任何理由不去用它。 在舊的程式碼上做 TDD TDD 是有點難的，但是試圖在一開始沒有用 TDD 的程式碼上要去做 TDD，那是更加困難…為什麼？ 嗯，事實上，關於這個主題，我可 以寫出一堆文章，所以我想我先到這裡為止。我將保留到我下一本 書"TDD 的實戰經驗"中再談。：o) 一直都抽不出時間寫這些東西 … 但是，從來都不缺乏 TDD 的書 籍！有一本很棒的書是有關於處理遺留代碼的，叫做 Working Effectively with Legacy Code，作者是 Michael Feathers，非常經 典。我也寫過一些有關於技術債的文章，可以參考我的部落格。 http://blog.crisp.se/tag/technical-debt 我們花相當多的時間，試圖對一個較複雜的系統，自動化其整合測 試。它的程式碼已經存在很長一段時間，並且處於嚴重混亂狀態， 完全沒有測試程式。 每次系統的發佈前，我們會有一個專門的測試人員，去執行大量、 複雜的回歸測試和效能測試。回歸測試大多數是手動進行，因此嚴 重地減緩開發和發佈的週期。我們的目標是去自動化這些測試，但 是，在幾個月的痛不欲生後，我們還是無法能有更多進展。
102 | SCRUM 和 XP 的實戰經驗 之後我們改變我們的方法。我們承認這個事實，那就是我們身陷於 必須手動進行回歸測試的麻煩。然後相反地問自己："我們如何使手 動測試流程，花費的時間比較少？" 當時有一個賭博遊戲的系統，我 們意識到，許多測試團隊的時間是花在繁瑣的安裝工作，像是瀏覽 後台系統去建立牌局來進行測試，或是等待一個安排好的牌局啟動。 所以我們為了這樣寫了一些工具，他們是一個很小，容易被使用的 腳本(script)，並且會處理掉一些瑣碎繁雜的工作，好讓測試人員可 以專注於真正的測試工作。 這些努力確實收到效果！ 事實上，我們一開始就應該要這樣做。我 們過去太急著去自動化它，卻忘記要按部就班來。剛開始的第一步 應該是建立一些東西，讓手動測試能更有效率。 學到的教訓：如果你身陷於必須手動進行回歸測試的麻煩，並且想 要把它自動化，還是放棄吧(除非它很容易去做到)。相反地，想些方 法來讓手動回歸測試容易點，然後再考慮將真正的測試給自動化。 漸進式設計 這意味著一開始設計就要保持簡單，然後持續去改進它。而不是一 開始就試圖要所有的事情都正確，然後就凍結它。 我們這點上做的相當好，也就是，我們花了可觀的時間去重構，改 進現有的設計。並且我們很少花時間去大規模的預先設計。當然， 有時我們也會搞砸了。例如，允許一個搖搖欲墜的設計"陷入"的太深， 導致後來的重構變成是一個大工程。但是整體來說，我們還相當滿 意。 持續設計的改進，很大程度是做 TDD 所自動帶來的副作用。 持續整合 我們大部分的產品在持續整合方面已經相當成熟，它是利用 Maven 和 QuickBuild 來達成的。這是相當有用，並且節省時間。對於"嘿， 它在我的電腦上是可以的"這個問題，持續整合是終極解決方案。若 是要判斷所有程式碼的健康狀況，我們把持續建構的伺服器當作是" 仲裁者"，或是參考點。每次有人 checkin 東西到版本控制系統，持 續建構系統會醒來，在共用的伺服器上，重新建立每件事情，然後 再執行所有的測試。如果有出現問題，它將會寄郵件去通知整個團
我們如何結合 SCRUM 和 XP | 103 隊，告訴他們這個版本是有問題的，包括準確地告知哪些修改的程 式碼造成建構失敗，以及指向相關的測試報告的連結，等等。 在每個晚上，持續建構伺服器將會重新建構產品，並發佈執行程式 碼(ears，wars，等等)、文件、測試報告、測試涵蓋度報告、相依性 報告，等等，把他們放到我們內部的 portal 上面。有些產品也會自動 部署到測試環境中。 設定這件事情需要花費大量的工作，但是每一分鐘都是值得的。 如果你再走的更遠一點，你會達到持續交付的境界。每個提交的版 本，都是一個可發行的候選者，所以發佈只是一個按鍵的操作。我 看到越來越多的團隊做到這樣，我自己帶領的專案也是這樣在做。 它讓你感到非常神奇地的有效！我建議你可以研讀 (或者至少瀏覽 一下) Continuous Delivery 這本書。建置它需要做很多事情，但是 在新產品開始時，這絕對是值得去做的，幾乎可以馬上得到回報， 並且現在有很多工具都支援這件事情。 程式碼集體共有權 我們鼓勵程式碼集體共有，但是並不是所有團隊都已經採用它。我 們發現到，搭檔編程中經常更換搭檔，會自動形成高度的程式碼集 體共有權。若團隊有高度的程式碼集體共有權，這個團隊就會非常 強壯。例如，他們的 Sprint 不會因為某個關鍵的人員生病而有所影 響。 Spotify (和其他所多快速發展的公司)有個 “內部開源” 的運作方 式。所有的程式碼都放在內部的 GitHub 上面，所有人都可以複製 儲存庫，以及提出 pull request，就像任何公開的開源專案，非常 方便。 資訊化工作場所 所有團隊可以善加利用白板和空白牆壁的空間。在大部分的房間， 你將會發現到牆壁上，貼滿了產品或是專案的各式各樣資訊。最大 的問題是，舊的訊息也積累在牆壁上。我們可能需要在每個團隊中， 導入一個"管家"的角色。
104 | SCRUM 和 XP 的實戰經驗 我們鼓勵使用任務版，但是不是所有團隊都已經採用它。請看"我們 如何安排團隊的座位和空間"。 編碼規範 最近我們已經開始定義編碼規範，它非常有用。要是我們能早點這 樣就好了。它一點都不花時間，只要從簡單開始，然後讓它慢慢增 加。只要寫下不是所有人都明顯知道的事，如果可能的話，連結到 現存的資料上。 大部分的程式設計師有他們自己的編碼風格。細節像是他們如何做 例外處理，他們如何註解程式碼，什麼時候要傳回 null，等等。在某 些狀況下，這些差異是沒有關係。可是在某些狀況下，可能會導致 嚴重的系統設計不一致，以及很難閱讀的程式碼。此時編碼規範就 非常有用，只要你關注在一些重要的事項上面。 這裡有些我們編碼規範的範例： § 你可以打破裡面任何一個規則，但是要確認有個好的理由， 並且要記錄下來。 § 預 設 使 用 Sun 的 編 碼 規 範 ： http ： //java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html § 永遠，永遠，永遠不要在，沒有記錄 stack trace 的情況下， 或是重新丟出 exception 的狀況下，去抓住 exception。用 log.debug()是可以的，只是不要忘記 stack trace 就可以。 § 使用 setter 為主的依賴性注入(dependency injection)，來減低 類別之間的關連(當然，如果緊密耦合是適用的話，那就另當 別論)。 § 避免縮寫。但是為人熟知的縮寫則是可以，像是 DAO。 § 需要傳回 collection 或是陣列的函式，不能夠傳回 null。而是 要用空的 collection 或是陣列來代替 null。 程式碼規範和風格指南是非常有用的。但是沒有必要去重新發明輪 子 – 你可以從我的好友 Google 中複製一份： http://google-styleguide.googlecode.com 可持續的開發速度/精力充沛的工作 許多敏捷開發的書籍宣稱，加班在軟體開發過程中會降低生產力。
我們如何結合 SCRUM 和 XP | 105 在幾次不情願的試驗後，我非常同意這件事！ 大約幾年前，我們其中一個團隊(最大的團隊)大量瘋狂的加班，現存 程式碼的品質令人沮喪，他們必須花大量的時間在救火。測試團隊 (也同樣在加班)沒有機會，認真地去做品質確認的工作。我們的使用 者很生氣，很多八卦都快把我們給吃掉。。 在幾個月後，我們成功地將工作時間降到適當的範圍。人們正常上 下班(除了專案關鍵時期例外)。令人驚訝的事發生了，生產力和品質 有明顯的改進。 當然，減少工作時間，絕對不是唯一會導致改善的原因，但是我們 都相信它佔很重要的因素。 我再看了幾遍，認為在軟體開發中 (或是其他任何複雜和有創意的 工作) ，交付的價值和所花費的時間，其實是沒有什麼關聯性。真 正重要的是有多少專注和有動力的時間。我們大多數曾經經歷過這 樣的感受，在星期六上午工作的很平順，好幾個小時很安靜，並且 在那時間似乎完成了一整個禮拜的工作！這就是我說的專注和有動 力的時間。所以不要強迫人們超時工作，除了極少數例外的狀況是 真的需要這些時間。另外，讓人們精疲力盡是不道德的。
14我們怎樣做測試 這是最困難的部份。我不確定是否它是 Scrum 中，最難的一部份。 還是它在軟體開發中，通常也是最困難的部份。 在不同組織之間，測試可能是差異最大的部份。它依賴你有多少測 試人員，有多少自動化，哪些型態的系統(只是伺服器+網頁應用程 式？)發佈週期的長短，軟體的關鍵性(blog 伺服器 v.s 飛行控制系統) 等等。 在 Scrum 中，我們試過很多如何去測試的方法。我會試著描述我們 曾經做過的方法，以及目前我們得到的經驗。 您可能無法擺脫驗收階段 在理想的 Scrum 世界，每次的 Sprint 會產生一個可以部署的系統版 本。所以只要部署它就好，是嗎？ 沒錯！ 不是。 嘿？
我們怎樣做測試 | 107 根據我們的經驗，這通常是不可行的，都會有很嚴重的錯誤。如果 品質對你來說還有價值的話，某種手動測試的階段是需要的。 滿口胡言！我不敢相信我會這樣寫！這本書已流傳到各地，並且有 很多人唸過和相信它，我真的感到羞愧！好爛的作者，不要再寫這 些錯誤的東西了！＊啪啪＊ 是的，手動測試是非常重要的，並且有些環境是無可避免的。但 是，應該是由團隊在 sprint 中進行，而不是交由另一個獨立的團 隊來進行，或是保留到未來的測試階段來進行。這不就是為什麼我 們會拋棄瀑布式模型的原因嗎？ 還記得吧？ 對於不隸屬於團隊的專職測試人員，他們必需利用 Scrum 團隊，沒 有想過、沒時間做、或是沒有硬體配備去做的方式，去攻擊系統。 測試必須和真正使用者一樣的方式，來存取系統。也就是說他們必 須手動進行(假設你系統是給人使用)。 測試團隊發現錯誤(bug)，Scrum 團隊必須要發佈錯誤修復(bug-fix)的 版本，遲早(希望會快一點)你將會為使用者發佈 1.0.1 的錯誤修復版 本，而不是出問題的 1.0.0 版本。 當我說"驗收測試階段"，我是指整個在做測試、除錯、以及重新發佈 的階段。直到有個版本，可以好到做生產版本(production release)為 止。 縮短驗收測試階段 驗收測試階段帶來很大的痛苦，它感覺相當地不太敏捷。 是的，所以不用。 嗯，好的，我知道。在某些環境它看起是不可避免的。但是我的觀 點是，我過去曾經認為它是不可避免的。但是，現在我看到許多真 的敏捷的公司，藉由放棄單獨的驗收測試階段，把它合併到 sprint
108 | SCRUM 和 XP 的實戰經驗 中，以達到行動迅速和提高品質。所以如果你還認為它是不可避免 的，這可能是因為你被你的現狀所蒙蔽了 (就像我以前一樣)。然 而，這個章節提供了一些有用的樣式，讓你知道如何處理獨立的驗 收測試，把它當作一個臨時的作法，直到你可以合併的 sprint 裡 面。:o) 雖然我們無法擺脫它，我們可以(並)盡量減少它。更具體一點的說， 縮短驗收測試階段所需要的時間。我們的作法是： § 提高 Scrum 團隊所交付程式碼的品質 § 提高手動測試工作的效率(也就是，挑選最好的測試人員，給 他們最好的工具。確保他們所說的很浪費時間的工作，能夠 被自動化) 所以那我們如何提高從 Scrum 團隊所交付程式碼的品質呢？ 嗯，方 法有很多。這裡有兩個方法是我們發現非常有用的： § 把測試人員放到 Scrum 團隊中 § 每個 Sprint 中做較少的工作 藉由把測試人員放到 Scrum 團隊中來提高品質 是的，我聽過完全不同的說法： • "但是，那很明顯啊！ Scrum 團隊理應是 跨功能職務的" • "Scrum 團隊裡應該是沒有角色的！ 我們 不能有一個人僅僅只是在做測試" 讓我澄清一下，在這裡我所謂的"測試人員"是指"一個主要技能是測 試的人"，而不是"一個它的角色只是在做測試的人"。 這是一個重要的觀點。“跨職能” 並不意味著每個人要會所有的東 西。它的意思只是每個人願意去做，超過他們所負責的部分。我們 需要的是專業化與跨職能化，取得一個合適的平衡。所以，整個團
我們怎樣做測試 | 109 隊共同為他們的產品的品質負責，所以每個人都被要求要做測試。 然而，測試人員需要指導這工作的進行，和開發人員配對去做測試 自動化，自己則執行更複雜的手動測試。 開發人員通常是相當差勁的測試人員，特別是在測試他們自己的程 式碼的時候。 測試人員就是"驗收的傢伙" 除了"只是"團隊的一員外，測試人員有一個重要的工作，他是驗收的 傢伙。在 Scrum 中，要直到他說完成才算完成，否則沒有事情能算" 完成"。我曾經發現，開發人員常常說某件事情已經完成，但是實際 上還沒有。即使你有非常清楚"完成"的定義(你應該如此，請看"'完成 '的定義")，開發人員還是經常忘記。我們這些程式設計師常是沒有 耐心的人，只想要很快的進到下一個 Sprint。。 那我們的測試先生如何知道某些事情已經做完呢？ 嗯，首先，他應 該(很驚訝吧)測試它！ 在許多狀況下，那些開發人員認為已經做完 的項目，結果是不可能被測試的。因為那些東西還沒被 check-in，或 是還沒被部署到測試伺服器中。一但測試先生開始測試時，他應該 和開發人員，從頭到尾確認過那份"做完"的清單(如果你有的話)。例 如，如果在"做完"的定義中，描述應該有個發佈說明，那測試先生要 檢查是不是有個發佈說明。如果這個功能有某種更為正式的規格， 那測試先生也要檢查，等等。 這裡有一個很好的副作用，因為團隊現在有一個傢伙，非常適合安 排做 Sprint 展示的工作。 我不再是簽核這種模式的粉絲了。這將會產生瓶頸，並且將太多責 任放到一個人的手上。但是，我認為在某些環境下，簽核還是有用 的(在某些時間，它一定有用)。此外，如果有任何人必須要對品質 簽核的話，那個人一定是真實客戶。 當沒有東西要測試時，測試人員要做什麼？ 這個問題常常被提出來。測試先生說： "嗨，Scrum master 現在沒有 東西要測試，所以我要做什麼？" 團隊可能需要一個禮拜，才能完成 第一個故事。那這時候測試人員應該做什麼？
110 | SCRUM 和 XP 的實戰經驗 好的，首先，他應該要為測試做些準備。那就是撰寫測試規格書， 準備測試環境，等等。所以當開發人員已經有東西可以被測試時， 就不用再等待，測試先生可以立即開始測試。 如果團隊有做 TDD，那大家從第一天開始，就會花時間撰寫測試程 式碼。測試人員應該和開發人員撘檔編程，一起撰寫測試程式。如 果測試人員一點都不會寫程式，他也應該和開發人員撘檔編程。即 使他只能瀏覽，而開發人員去敲鍵盤。一個好的測試人員總是會比 好的開發人員，想出更多不同種類的測試，所以他們可以互相互補。 如果團隊沒有採用 TDD，或是沒有足夠的測試個案需要去撰寫，他 應該完全地盡他所能，幫助團隊實現 Sprint 的目標。就像團隊其他 成員一樣，如果測試人員會寫程式，那很好。如果不會，你的團隊 必須找出需要在 Sprint 中完成，但不用寫程式的工作。 在 Sprint 規劃會議中，把故事拆解成任務時，團隊著重於編程的工 作。然而，通常還有許多非編程的工作，需要在 Sprint 中完成。在 Sprint 規劃會議中，如果你花時間，企圖找出非編程的工作，測試先 生將會有機會去貢獻許多，即使他不會寫程式，或者目前沒有測試 工作要進行。 這裡有些非編程的任務，需要在 Sprint 中被完成： § 建置測試環境。 § 釐清需求。 § 和營運部門討論佈署的細節。 § 撰寫部署的文件(發佈說明，RFC，或是任何你組織中要寫的 東西)。 § 和外部資源進行聯繫 (例如 GUI 設計師) § 改善建構腳本(build scripts) § 進一步將故事拆解成任務 § 從開發人員中找出關鍵的問題，並解決他們。 從另一個角度來看，如果測試先生變成是瓶頸，那我們該怎麼辦？ 假設我們現在在 Sprint 的最後一天，突然間有很多工作被完成，導 致測試先生沒有去測試完所有事情，那我們要怎麼辦？ 嗯，我們應 該叫團隊中所有人去測試先生當助手。他來決定哪些事情他自己要 做，然後把一些平凡的測試交給團隊中其他人來做。這就是跨功能 職務團隊所該做的事情！
我們怎樣做測試 | 111 所以，是的，測試先生在團隊中，確實是一個特別的角色，但是他 仍然可以去做其他工作，其他團隊成員也被允許去做他的工作。 說得好！(我可以被允許有時候誇獎一下自己嗎？) 這是一個觀察團 隊成員其他能力的好方法。 藉由在 Sprint 中做較少的工作來提高品質 讓我們回到 Sprint 規劃會議中。簡單地說，不要把太多故事放到同 一個 Sprint 裏！ 如果你有品質的問題，或是要很長的驗收測試週期， 那就在每個 Sprint 中做較少的事情！ 這將自動地導致較高的品質， 較短的驗收測試週期，較少影響使用者的錯誤。長期來說會有較高 的生產力，因為團隊可以所有時間都著重於新的東西。不會因為要 修復舊的東西，而打斷目前工作的進行。 與其建構許多東西，但是需要出些 hot-fixes 來補救；還不如建構少 一點，但是建構的比較穩定，這樣會比較划算點。 這是完全正確！我一直在世界各地重複看到這樣的狀況。 驗收測試應該是 Sprint 的一部分嗎？ 我們在這裡差距很大。有些團隊把驗收測試當做 Sprint 的一部份， 但大部分的團隊則沒有。主要有兩個原因： § Sprint 是有時間框的限制，驗收測試(根據我的定義，它包含 了除錯和再次發佈're-releasing')的時間是非常困難去固定的。 如果時間用完了，你還有一些關鍵的錯誤，那你要怎麼辦？ 你要去發佈一個有嚴重錯誤的產品嗎？ 還是你要等到下一個 Sprint 才發佈？ 在大部分的狀況，這兩種作法都無法接受。 所以我們把手動驗收測試不視為 Sprint 的一部份。 § 如果你有多個 Scrum 團隊一起開發一個產品，必須把這些團 隊的工作結果結合在一起，再進行手動驗收測試。如果這些 團隊各自把驗收測試放在自己的 Sprint 中，你還是需要一個 團隊去測試最後版本，也就是最後整合所有團隊工作結果的 版本。
112 | SCRUM 和 XP 的實戰經驗 這並不是一個完美的解法，但是在大部分的狀況下，對我們來說已 經足夠了。 再次強調，努力去把驗收測試變成 sprint 的一部分。它會需要花 一段時間才能做到，但是你不會後悔去做這件事。即使你無法達到 這種境界，你所做的嘗試，都能讓你的工作有很大的改進。 Sprint 週期 v.s. 驗收測試週期 在完美的 Scrum 世界中，你不會需要驗收測試階段，因為每個 Scrum 團隊，在每次 Sprint 結束後，會發佈一個新的、已經產品化就 緒的版本。 這是可以做到的！我已經看過世界上有許多團隊每天可發佈到線 上，有時候是每天好幾次。每次當 Scrum 的講師告訴他們 ”在 sprint 結束時，你需要產生出一個有完整的測試，可能交付的產品
我們怎樣做測試 | 113 增量”，他們的反應是 ”啥？為甚麼要等這麼久？” 所以，不用，你 不需要等到完美的 Scrum 境界。只要捲起你的袖子，指出在每次 sprint 中，阻擋你拿到可發行程式的原因，並且一個個地修復它 們。當然，這可能或多或少在你的領域中有點困難，但是仍然值得 嘗試。只要從你現在的發佈週期開始 (無論它是一個月，一年或是 多少都可以)，然後逐漸且持續的縮短它。 嗯，這裡有張更真實的圖片： 在 Sprint 1 後，一個充滿錯誤的版本 1.0.0 被發佈。在 Sprint 2 期間， 錯誤報告開始大量湧入，團隊花大量的時間在除錯，並且在 Sprint 中期，被迫發佈了錯誤修復的版本 1.0.1。然後在 Sprint 2 結束後， 他們發佈一個有新功能的版本 1.1.0， 當然啦，會有更多的錯誤，因 為他們受到上次發佈版本錯誤的干擾，這次他們只有較少的時間去 確保品質。這樣的情形會一直重複發生。 在 Sprint 2 中紅色斜線代表混亂的狀況。 並不怎麼好吧？ 嗯，悲慘的是這問題會持續下去，即使你有一個驗 收測試團隊。差別僅是大部分的錯誤報告來自於測試團隊，而不是 生氣的使用者。從商業的角度來看，兩者有很大的差別，但是從開 發人員的角度來看，它們是相同的。不過測試人員沒有像使用者那 樣積極，通常是這樣。
114 | SCRUM 和 XP 的實戰經驗 對於這個問題，我們還沒有發現任何簡單的解法。不過我們試過許 多不同的模型。 首先，再一次強調，還是要提高 Scrum 團隊所發佈程式碼的品質。 在 Sprint 中，早一點找出和修復錯誤的費用，會比在 Sprint 結束後， 找出和修復錯誤的費用，要低的很多。 但是事實仍然是事實，即使我們能減少錯誤的數目，在 Sprint 結束 後，仍然有錯誤報告被產生，那我們是如何處理呢？ 方式 1： "不要開始建立新的東西，直到舊的東西已經產品 化了" 聽起來不錯，不是嗎？ 你是否也有溫暖、模糊的感覺？ 是的，它很棒！ 我們好幾次差點採用這個方法，還畫出想像我們如何進行的模型。 然而，當我們了解到它的缺點後，我們就改變了心意。如果我們採 用這個方法，我們必須在 Sprint 之間，加了一段沒有時間框的發佈 時段，在這段時間內我們只做測試和除錯，直到我們能發佈一個產 品為止。
我們怎樣做測試 | 115 如果你做完的定義是部署到生產環境，在這個狀況下，你可以立即 開始下一個 sprint，因為上個 sprint 的程式碼已經部署到生產環 境了。它可以在sprint 中持續發佈，是有點極端，但是它是可以做 得到的。 我們不喜歡在 Sprint 之間，有一個沒有時間框的發佈時段，主要是 因為它打破正常的 Sprint 心跳節奏。我們不再能號稱"我們每三周會 開始一個新的 Sprint"。此外，它不能完全地解決問題，即使我們有 一個發佈的時段，但是隨時還是會有緊急的錯誤報告出現，我們必 須準備好去處理它。 這是真的。即使你做到持續發佈，你仍然需要一個方式來處理進來 的重要 bug。因為它們有時候會發生，並且沒有一個團隊可以厲害 到不會發生。因此處理這件事情的最好的方式，就是在 sprint 中 保留一些鬆弛的時間。 方法 2： "可以開始去建構新的東西，但是要對舊有功能的 產品化這件事給排出優先順序" 這是我們比較喜歡的方法，至少現在是這樣。 基本上，我們完成一個 Sprint 後接下一個 Sprint。但是我們希望在下 一個 Sprint 中，能花些時間去修復上一個 Sprint 中的錯誤。如果我們 花太多時間去修復上一個 Sprint 所產生的錯誤，那下個 Sprint 將會被 嚴重的破壞。我們會評估為什麼會發生這樣的事情，以及我們如何 改善品質。我們會確認 Sprint 的時間，是長的足夠去完成上個 Sprint 中，相當數量錯誤的修復。 一般來說，經過幾個月後，花在修復上個 Sprint 所產生錯誤的時間 會減少。此外，當錯誤發生時，我們要參與的人員變少，所以整個 團隊不需要每次都被干擾。現在我們已經到一個較可以接受的程度。
116 | SCRUM 和 XP 的實戰經驗 在 Sprint 規劃會議期間，我們設定較低的投入程度，讓我們能夠有 時間去處理上個 Sprint 來的錯誤。經過一段時間後，團隊已經相當 擅長去評估這樣的事情。速度的度量可以幫助我們做的更好(請看"團 隊如何決定哪些故事要被放到這次 Sprint 中？")。 或是使用昨日天氣 – 只拉跟你上個 sprint，所完成的數量一樣多 的故事。或者是過往三個 sprint，所完成量的平均值。這樣你的 sprint 就自動會有內建的鬆弛機制，可以讓你去處理中斷事務和程 式補丁。你會自動地避免想做很多事，而改成盡快產生出結果 (如 果你需要相信負擔過重的 sprint 是不好的，那你可看一下任何有 關精實和排隊理論的書籍) 。 不好的方式 - "著重於建構新的東西" "著重於建構新的東西，而不去讓舊的東西能產品化"。誰會去做這樣 的事呢？ 我們一開始就經常犯這樣的錯誤，我確定其他公司也是這 樣。它是一種和壓力有關的病狀。許多經理實際上並不了解它：即 使所有的程式碼都已經完成，你通常還是離產品化很遠。至少複雜 的系統是這樣。所以經理(或是產品負責人)會要求團隊繼續增加新的 東西，可是那些舊的”接近快要發佈”的程式碼的越來越多，那將會 拖垮之後每件事的進行。 我一直驚訝有多少公司掉入這個陷阱中。他們應該做的，就是限制 同時處理的專案或是功能的數目。我曾經看過某些案例，這些公司 就是限制了同時處理的數目，效率毫不誇張地變成了七倍快。想像 一下，同樣多的東西被交付，但是七倍快，沒有更辛苦的工作或是 找更多人，並且品質更好，這都是因為較短的回饋迴圈的緣故。有 點瘋狂，但是這是真的。 不要讓最慢的一個連結從你的環節中斷掉 假設驗收測試是你最慢的連結，你沒有很多測試人員。或是因為令 人沮喪的程式碼品質，導致驗收測試的時間過長。
我們怎樣做測試 | 117 假設你驗收測試的團隊，每週最多能測試三個功能(不，我們不用"每 週多少個功能"來衡量，我只是使用它來當作例子)。而你的開發人員 能每週開發 6 個功能。 它會誘使經理或產品負責人，去規劃每週六個新功能的開發。 千萬不行，最終現實將會讓你嚐到苦頭，並且帶來傷害。 相反的，我們規劃每週做 3 個功能，剩下的時間花在減輕測試的瓶 頸。例如： § 讓一些開發人員作測試人員的工作(哦，他們一定會喜歡你 的…)。 § 實作一些工具和腳本讓測試更容易。 § 增加更多自動化程式。 § 增加 Sprint 的長度，把驗收測試加到 Sprint 中。 § 把有些 Sprint 定義成"測試的 Sprint"，當中所有團隊都變成 驗收測試團隊在做事。 § 僱用更多的測試人員(即使這意味著減少開發人員) 我們曾試過這些解決方案(除了最後一個以外)。最好的長期解決方案 當然是第二和第三點，也就是有更好的工具、腳本和測試自動化。 回顧會議是一個很好的檢討時機點，可以找出你環節中最慢的連結。 如果驗收測試被包含在 sprint 中，那會變成可以自我調整，會比 分開做好。試試看 – 在你的做完的定義中包含驗收測試，看看一 段時間後會怎樣。 回到現實 或許我給你一個錯覺，我們在所有 Scrum 團隊中都有測試人員。並 且我們對每個產品，有一個很大的驗收測試團隊。在每個 Sprint 完 後我們都會發佈，等等。 嗯，事實上我們並沒有。 我們曾經有做到這樣的地步，也看過它的正面影響。但是我們離驗 收品質保證流程所要求的，還差的很遠，我們仍然還有很多東西要 學習。
118 | SCRUM 和 XP 的實戰經驗 的確，我們還有很多要學。
15我們怎樣處理多個 Scrum 團隊 當你有許多 Scrum 的團隊工作在同一個產品時，許多事情會變得比 較困難。這問題是眾所周知的，和 Scrum 實際上沒有太多關係。更 多的開發人員 = 更複雜的狀況。 當在寫這本書時，我已經有許多大型團隊的經驗。可以在 Lean from the Trenches 這本書中，找到詳細的案例。那本書跟我這本 書的風格非常相像。它描述一個 60 人的政府專案，如何組合 Scrum，Kanban 和 XP 的方法來執行。 https://pragprog.com/book/hklean/lean-from-the-trenches 我們(和以前一樣)遭遇過這種狀況。最多的時候，我們大約有 40 個 人在做同一個產品。 主要的問題是： • 要建立多少團隊 • 要如何分配人員到團隊當中 並且，當然還包括團隊之間如何保持同步。 要建立多少團隊 如果處理多個 Scrum 團隊是這麼困難，我們為什麼要這麼做呢？ 為 什麼不把所有人都放到同一個團隊中呢？ 我們曾經有過最大的 Scrum 團隊，大約是 11 個人。它是可以運作的， 但是無法運作的很好。每日的 Scrum 會議往往會拖超過 15 分鐘。團 隊成員不知道其他成員在做什麼，所以有點混亂。Scrum master 很難 讓其他成員都朝著相同目標前進，也不容易找到時間去解決所有回 報的問題。
我們怎樣處理多個 SCRUM 團隊| 121 另外一個方法是把它拆成兩個團隊，但會比較好嗎？ 不一定。 如果團隊對 Scrum 很有經驗並且也很適應，可以用邏輯的方式將產 品規劃藍圖，切割成兩個不同的行動路線，並且他們不會使用到相 同的程式碼。那我會說把它分成兩個團隊是個好的主意。否則我會 考慮把它合成一個團隊，不管大的團隊會有怎樣的缺點。 我的經驗是，寧可團隊數量較少，人數較多。因為團隊個數多，但 人數少，會容易相互干擾。因此要成立小團隊，必須確保他們不會 相互干擾！ 虛擬團隊 對於"大團隊"與"很多團隊"之間的權衡，你怎麼知道您做出了正確還 是錯誤的決定？ 如果你一直持續觀察和仔細聆聽，你可能會注意到"虛擬團隊"的存在。 範例 1：你選擇大的團隊。但是在 Sprint 過程中，從誰和誰在講話的 過程中，你會注意到團隊有效地自行分成兩個小團隊。 範例 2： 你選擇成立三個小團隊。但是在 Sprint 過程中，觀察誰和 誰在講話的過程中，你注意到團隊 1 和團隊 2 會一直在交談，而團 隊 3 工作上比較孤立。
122 | SCRUM 和 XP 的實戰經驗 所以，這代表什麼意思？ 是你團隊切割策略不正確嗎？ 如果不正確， 這樣的虛擬團隊似乎會一直存在下去。如果正確的話，這樣的虛擬 團隊會只是暫時的。 讓我們再看一次範例 1。如果兩個虛擬子團隊一直在改變(也就是， 大家在虛擬子團隊間移動)，那你可以決定把他們放到同一個 Scrum 團隊。如果兩個虛擬子團隊，在整個 Sprint 過程中都待在相同的地 方，你可以在下一個 Sprint 中，把他們拆解成兩個真正的 Scrum 團 隊。 現在再看看範例 2。如果團隊 1 和團隊 2 在整個 Sprint 中都一直在交 談(不是和團隊 3)，你可能在下一個 Sprint 中，要去把團隊 1 和團隊 2 結合成一個團隊。如果在 Sprint 前半段，團隊 1 和團隊 2 一直在交 談; 在 Sprint 後半段，團隊 1 和團隊 3 則一直在交談，你可以考慮把 三個團隊變成一個，或是還是保留原先三個團隊。把這個問題帶到 回顧會議中，讓團隊自己決定。 團隊切割，是 Scrum 其中一個困難的部份。不要想太多，或是花太 多精力去最佳化。先做實驗，對虛擬團隊保持觀察，確認你在回顧 會議中，有足夠的時間去討論這類議題。遲早你會根據你的狀況， 發現最佳的解決方案。最重要的事情是團隊會覺得舒適，不會常常 互相干擾到。 有一個逐漸流行的新進技術：團隊可以根據需要，動態地來改變自 己。我有時候把這個叫做”超級團隊” 模式，或是 ”動態子團隊” 模 式。這個方法最適合以下狀況：當你有 12-16 個人，大家坐在一 起，彼此相互熟悉，一起為相同的產品來努力。給他們一個共享的 產品需求清單，某些人會針對某個故事成立一個小組 (”Pat，Tom 和我現在要處理故事 X” )，當故事處理完後，又動態地重新組成另 外的小組。在實務上，需要有些引導來幫助這件事情發生。當你不 需要一個大的團隊，而且又不能以一個固定的方式，來拆解小團 隊，這樣的作法是最好的。 最佳的團隊大小 在大部分我所讀過的書中，都宣稱最佳團隊的大小大約是 5-9 人。
我們怎樣處理多個 SCRUM 團隊| 123 到目前為止，我所觀察的團隊來說，我同意這個說法。不過我會建 議是 3-8 人。事實上，我相信值得花些代價，去達到這樣的團隊大小。 假設你有一個團隊是 10 個人。考慮把兩個最弱的成員趕出去吧。哦， 我真的有那樣說嗎？ 哈哈。我要怎麼才能避免這樣見鬼的狀況? :o) 然而，我注意到當某些成員放假去後，這個大的團隊進度十分神 速。這並不是因為沒有來的人是很差的成員，而是因為團隊的大小 變成是可管理的，所以溝通和混亂的程度已經減少。 假設你有兩個產品，每個產品都有一個 3 個人的團隊，兩個都進行 的很緩慢。把它變成一個 6 個人的團隊去負責兩個產品，或許是個 好主意。在這個情況，讓其中一個產品負責人離開(或是給他顧問之 類的角色)。 假設你有一個 12 個人的團隊，因為程式碼處於很糟糕的狀況，沒有 方法讓兩個不同的團隊，獨立在上面工作。所以需要認真投入一些 精力，去改進這些程式碼(而不是建立新功能)，直到你可以拆解他們 為止。這些投資你很快就可以得到回報。 這是值得強調的。如果你掙扎於找出對的團隊結構，真正的罪魁禍 首通常會是系統組織的問題。好的系統組織，可以讓團隊移動快 速，並且獨立自主。不好的系統組織，會讓團隊絆倒別的團隊，並 且因為依賴的關係而陷入困境。所以你應該不斷質疑和發展你的組 織和團隊結構。
124 | SCRUM 和 XP 的實戰經驗 是否要同步多個 Sprint？ 假設你有三個 Scrum 團隊，都為同一個產品工作。他們的 Sprint 應 該要被同步嗎？也就是，開始和結束都相同嗎？或是他們應該重疊 嗎？ 我們一開始的方法是有重疊的 Sprints(因為各自時間考量的關係)。 聽起來不錯。在任何一個時間點上，會有一個正在進行的 Sprint 要 結束，或是有一個新的 Sprint 正要開始。產品負責人的工作量，隨 著時間的演進，將會均勻地分佈各個 Sprint 中。系統將會持續不斷 地被發佈，每一週都有展示，哈利路亞！！ 耶，我知道你要說什麼，但是那時候聽起來是蠻有說服力的！ 我們之前一直是這樣做的，直到有一天，我有機會和 Ken Schwaber 對談時(在我 Scrum 認證的時候)。他指出這不是一個好的主意，比較 好的方法是去同步 Sprints。我已經不記得他確切的理由，但是在幾 次討論後，我被說服了。 這是我們後來使用的解決方案，之後沒有覺得後悔或不好。我永遠 不會知道，是否重疊的 Sprint 終究會失敗。但是我認為應該要這麼 做。同步 Sprints 會有以下的好處： § 這裡自然有時間去重新組織團隊 - 在 Sprint 之間的時間！ 在 重疊的 Sprint 中，沒有任何方法可以重新組織團隊，而不干 擾到某一個正在進行 Sprint 的團隊。 § 所有的團隊可以在同一個 Sprint 中，朝著相同目標努力，可 以一起做 Sprint 規劃會議，導致團隊間會有較好的協同合作。
我們怎樣處理多個 SCRUM 團隊| 125 § 較少的管理花費，也就是，較少的 Sprint 規劃會議，Sprint 展示，和發佈。 在 Spotify，雖然我們曾經使用同步 sprint 但後來我們決定讓每個 團隊依它自己速度來運作，可以選擇自己的 sprint 長度 (有些團隊 適用 Kanban 來取代 sprints)。當我們團隊間有很多相依性時，我 們會每天會進行 Scrum-of-Scrums 型態的同步會議，不管每個團隊 原先的節奏是什麼。很難說那一種做法 (同步 sprint 跟非同步的 sprint) 比較好，因為這是跟環境有關的。 為什麼我們要導入"團隊領導"的角色 假設我們一個產品有三個團隊。 那個標記 P，紅色的傢伙是產品負責人。標記 S，黑色的傢伙是 Scrum master。其餘的都是咕噥著…呃…尊敬的團隊成員。 在這樣群星聚集的團隊中，誰要決定哪些人應該在哪個團隊中？產 品負責人是誰？ 這三個 Scrum master 一起搞定嗎？或是讓每個人選 擇他要參加的團隊？ 如果每個人都要待在團隊 1 要怎麼辦？(因為 Scrum master 1 看起太帥了嗎？) 如果後來證明，這確實是不可能有超過兩個以上的團隊，並行處理 這份的程式碼。所以我們必須把 3 個 6 人的團隊，轉變成 2 個 9 人的 團隊。意味著只要 2 個 Scrum masters。所以哪一個 Scrum master 要 被免除頭銜呢？ 這在許多公司都是非常敏感的問題。
126 | SCRUM 和 XP 的實戰經驗 讓產品負責人去作人員的配置或重新分配，是乎很誘人。但是這不 是產品負責人該做的事，對吧？ 產品負責人他是領域的專家，可以 告訴團隊他們應該朝哪個方向運行。他不應該介入這些內部的細節。 尤其是他是"chicken"的話(如果你沒有聽過 chicken 和 pig 的隱喻，可 以 google 一下""chickens and pigs")。 嗯，我討厭那個愚蠢的隱喻 (如果必要的話，你可以 Google 去了 解一下)。由於某些特殊的緣故，以前 Scrum 的世界裏，很流行把 產品負責人視為是局外人，認為他不會去承諾他該做的事。非常令 人反感。儘管如此，我仍然認為產品負責人，不應該去主導團隊結 構的人，因為產品負責人的工作已經夠艱難了。所以，誰應該做這 件事呢？讓我們繼續看下去 … 我們藉由導入"團隊領導"這個角色去解決問題。你可能叫他"Scrum of Scrums master"，"老大" 或是 "首席 Scrum master"等等。他不用去 領導單一團隊，不過他必須負責跨團隊的問題，像是誰應該是團隊 的 Scrum master，人員應該如何被拆解到不同團隊中，等等。 我們花了一段時間，才為這個角色想出好的名稱。"團隊領導"已經是 我們能想出最不糟糕的名稱。 這個解決方案運作的很好，我向你大力推薦一下 (不管你決定要叫這 個角色什麼)。 在我看過的大部分公司，部門經理是負責調整團隊結構的人，所以 沒有需要有個團隊領導的角色 (此外，團隊領導是一個相當混淆的 名稱，它聽起像是只有一個團隊)。然而，最好的方式是經理會找 出一個方法，讓團隊自己組出一個合適的結構，而非是高層指派一 個結構出來。 我們如何配置人手到團隊中 當你有多個團隊在同一個產品工作時，這裡有兩個普遍的策略，來 分配人員到團隊中。 • 讓某個指定的人來分配，例如，我前面所提到的"團隊領導"， 產品負責人，或是功能經理人(functional manager)(如果他參 與的夠深入，他就能做出正確的決定)。 • 讓團隊以某種方式自己進行。
我們怎樣處理多個 SCRUM 團隊| 127 我們嘗試過以上三種方法。三種？ 是的。策略 1 ，策略 2，和兩者 的組合。 我們發現兩者組合的效果最好。 經過多年的實驗，我只能同意。 在 Sprint 規劃會議前，團隊領導需要和產品負責人，以及所有 Scrum master 一起開團隊配置會議。我們討論上一個 Sprint 的狀況，並決定 是否需要重新配置。可能我們要整合兩個團隊，或是把某些人從某 個團隊移動到另一個團隊。我們決定某些事情，把它寫下來，當做 所提議的團隊配置，並把它帶回到 Sprint 規劃會議討論。 在 Sprint 規劃會議中，第一件事就是檢視產品 backlog 中，最高優先 順序的項目。團隊領導可能會說： "嗨，各位，在下一個 Sprint，我們建議以下的團隊配置" "就你們所看到的，這樣意味我們從 4 個團隊減到 3 個團隊。我們已 經列出每個團隊中成員。請大家聚在一起，自己在牆上佔一塊區域" (人們來回在房間內走動，團隊領導耐心地等待。過了一段時間，這 三組人馬，每一個團隊站在一面空牆前面)。 "目前團隊這樣的拆解只是開端！它只是一個起點，以節省大家的時 間。在 Sprint 規劃會議的過程，你可以自由地換到另一個團隊，把 你的團隊猜解成兩個，或是和另一個團隊整合在一起，或怎樣都可 以。根據產品負責人的優先順序，來當作處理事情的基本常識"
128 | SCRUM 和 XP 的實戰經驗 我們發現這樣處理的效果最好。一開始某種程度的中央集權控制， 之後再某種程度的個別最佳化。 這是一個很棒的模式。只是要記住，有很多方法可以做到這件事 – 結合 sprint 規劃會議只是其中一種，並不是最好的。現在，我 通常把團隊配置重組會議和 sprint 規劃會議分開，讓 sprint 規劃 會議更專注 (也就是說，當在規劃 sprint 時，我已經有個穩定的團 隊結構，和穩定的產品需求清單) 。然而，對於大型的專案來說， 把所有 sprint 規劃會議同時在一間大房間內舉行，這是非常有用 的。有時候，一個繁雜的相依關係，藉由把某個人換到某個團隊 (暫時或是長期)，事情就很簡單地被解決了。 要不要有特別的團隊？ 假設你的技術由三個主要元件所組成： 並且假設你有 15 個人為這個產品工作，若是你不想把他們都放在同 一個團隊，那你會怎樣組織你的團隊呢？ 方法 1： 特定元件的團隊 有一個方法是建立特定元件的團隊，像是"用戶端團隊"，"伺服器端 團隊"，和"資料庫團隊"。
我們怎樣處理多個 SCRUM 團隊| 129 我們一開始這樣做，不過運作的不是很好，至少當大部分的故事包 含許多元件時，就不太好。 例如，假設我們有一個故事叫"留言板，使用者可以留下訊息給其他 人"。這個留言板的功能，包括更新用戶端使用者界面，在伺服器端 新增邏輯，在資料庫內加些表格。 這意味著所有三個團隊 - 用戶端團隊，伺服器端團隊，和資料庫團 隊 - 必須協同合作去完成這個故事。所以並不是太好。 在很多公司裡，這是一個超級常見的問題！
130 | SCRUM 和 XP 的實戰經驗 方法 2： 跨元件的團隊 第二個方法是建立一個跨元件的團隊，也就是，團隊不會被約束在 任何特定的元件上面。 如果你的許多故事都包含多個元件，這種形式的團隊切割策略都可 以運作的不錯。每個團對可能實作一個完整的故事，包含用戶端， 伺服器端，以及資料庫端。所以團隊可以運作地更獨立，那是一件 好事。 當我們實施 Scrum 時，其中第一件事就是把現存特定元件的團隊打 散(方法 1)，並且建立跨元件的團隊(方法 2)。減少了像這種狀況的 發生次數："我們無法完成這個項目，因為我們必須等待伺服器端的 人完成" 在我工作過的每家公司，幾乎都有相同的故事發生。把特定元件團 隊重組成跨元件團隊是相當有破壞性，但是好處會是相當大的！ 然而，當真的有強烈的需求時，我們有時候也會成立，臨時的特定 元件的團隊。 有時候，特定元件團隊是合理的，即使是長期來說也是。但是，這 應該是例外，並且正常。一個好的檢驗問題：“誰是我們的客戶？ 我們可以實現他們的需求，並且不會阻礙了其他團隊嗎？“ 在大部
我們怎樣處理多個 SCRUM 團隊| 131 分的狀況，跨元件團隊不會有問題，而特定元件團隊則會有問題。 最常見的案例是內部導向的團隊，像是工具或是平台團隊 (例如： 伺服器端的基礎架構團隊)，他們把其他團隊(跨元件團隊)視為是 他們客戶。較大的公司通常這兩者的混合體：也就是對外是跨元件 團隊，但是對內是特定元件團隊。因此沒有所謂的銀製子彈，需要 持續不斷地實驗！ 是否在 Sprints 之間重新組織團隊？ 每個 Sprint 基本上都是相當不一樣的，這是因為在每個階段時，所 擁有的較高優先順序的故事並不相同。因此，在每個 Sprint 中，最 佳的團隊組成也就不同。 事實上，幾乎在大部分的 Sprint 中，我們發現我們自己，可能會說 像這樣的話："這個 Sprint 不是一般的 Sprint，因為…"。在一段時間 後，我們放棄了"一般"Sprint 的概念。沒有所謂的一般 Sprint，就像 沒有所謂的"一般"家庭或"一般"人一樣。 在這個 Sprint 中，有一個用戶端團隊隊可能是件好的主意，它由非 常懂用戶端程式的人所組成。下一個 Sprint，有兩個跨元件的團隊也 可能是件好的主意，把懂用戶端的人拆散到這兩個團隊中。 "團隊凝聚力"是 Scrum 重要的關鍵之一，也就是，如果團隊要一起 工作好幾個 Sprints，他們通常會變得非常緊密。他們會學習到如何 達成團體心流(group flow)，並達到令人難以置信的生產力水準。但 是需要花幾個 Sprint 才能做到。如果你持續變換組織，你將無法達 到真正的團隊凝聚力。 所以，如果你要重新組織團隊，請確認你考慮過後果。它是長期的 改變還是短期的改變？如果它是短期的改變，那就考慮忽略它。如 果它是長期的改變，那就進行吧。 這裡會有個例外︰當你對大型的團隊，第一次開始進行 Scrum。在 這種情況下，值得對團隊的拆解做些實驗，直到你找到每個人都滿 意的答案。並且要確認每個人都了解，在前幾次犯些錯誤是可以被 接受的，只要你能持續改進。
132 | SCRUM 和 XP 的實戰經驗 經驗法則：經過幾次迭代後，你團隊的組成應該相當穩定。也就是 說，對於任何團隊，至少一季的時間，他們的關係不會改變 (沒有 人加入或移出)。如果團隊組織常常改變，他們可能無法達到 Scrum 想要的超級生產力。然而，如果改變來自內部 (由團隊成員 提出)，通常殺傷力比上面的狀況(外部提出)小。因此，如果你是 部門經理，試圖拒絕干擾團隊的誘惑。讓大家專注於工作，鼓勵團 隊組織穩定。但是要讓大家可以在有需求時，自己決定轉調團隊。 你將會很驚訝這樣所帶來的成效！ 兼職的團隊成員 我可以確認很多 Scrum 的書上說 - 一般而言，Scrum 團隊中有兼職的 成員，這並不是一個好的主意。 … 就像上面說的，它真的是糟！ 假設 Joe 是 Scrum 團隊的兼職成員。在他進來之前，請先仔細考慮 一下，你真的需要 Joe 到你的團隊嗎？你確定 Joe 不能作全職嗎？那 他其它時間在做什麼？有人能幫忙他做他的其它工作嗎？好讓 Joe 在 其他工作中變成被動或是支援的角色？在下個 Sprint 中，能讓 Joe 在 你的團隊中是全職，並且同時把他的其他工作轉給別人嗎？ 有時候就是沒有其他方法。你非常需要 Joe，因為他是目前這棟大樓 唯一的 DBA，但是其他團隊也非常需要他，因此他很難把所有時間 都用在你們團隊上面。此外公司也沒有辦法僱用更多的 DBA。好的， 這種狀況下只好讓他可以兼職工作(這剛好是發生在我們身上)。但是， 要確定每次你都有做這樣的評估。 一般而言，我寧可要一個團隊中有 3 個專職，也不要有 8 個兼職。 如果有一個人需要把它的時間分配到多個團隊，像是上面提到的 DBA，最好讓他主要隸屬於某一個團隊。找出哪一個團隊最需要他， 把它當作他的"主要團隊"。當沒有人急著需要他，他可參加這個團隊 的每日 Scrum 會議、Sprint 規劃會議、回顧會議等等。 經驗法則：專職意味著至少有 90% 的時間專注於這個團隊上面， 兼職則大約是 50-90% (”這是我的主要團隊，但是我還有別的承 諾”)。小於 50% 不能算是團隊的一份子 ( ”我可以偶爾支援你們，
我們怎樣處理多個 SCRUM 團隊| 133 但是我並不是你們團隊的一份子，不要老是依賴我”)。如果團隊中 只有一個兼職，其他都是專職，那就不用擔心。然而，如果有超過 一個以上的兼職，你需要考慮重新組織，或是減少同時在進行的工 作量，讓一些兼職員工可以變成專職。多工是一頭怪獸，它會讓殺 死生產力，積極性和品質，所以盡量保持最小的同時工作量吧！ 我們如何進行 Scrum-of-Scrums Scrum-of-Scrums 基本上是一個經常性的會議，所有的 scrum master 聚在一起談話。 在某個時間點，我們曾經有 4 個產品，其中 3 個產品都各自有一個 Scrum 團隊，最後一個產品有 25 個人，分成好幾個 Scrum 團隊。像 是以下的狀況： 這意味著我們有兩個層次的 Scrum-of-Scrums。我們有一個"產品層次 "的 Scrum-of-Scrums，由產品 D 中的所有團隊組成。另外有一個"群 體層次"的 Scrum-of-Scrums，由所有產品組成。 產品層次的 Scrum-of-Scrums 這個會議非常重要。我們每週舉行一次，有時候可能頻率更高。我 們討論整合的問題，團隊平衡的問題，為了下次 Sprint 規劃會議的 準備，等等。我們保留了 30 分鐘，但是經常超過。另外一個方法是 每天都有 Scrum-of-Scrums，但是我們沒有試過這樣。
134 | SCRUM 和 XP 的實戰經驗 我們 Scrum-of-Scrums 的議程 1)圍繞著桌子，每個人描述他們團隊上週完成什麼，什麼計劃將要 本週完成，以及他們遇到什麼困難。 2)任何其他需要被提到的跨團隊的問題，例如整合的問題。 對我來說，Scrum-of-Scrums 的議程不是很重要，重要的事情是你要 定期舉行 Scrum-of-Scrums 會議。 在 Spotify 公司，在不同團隊間，通常我們為了某件事情大家聚在 一起，以 “每日同步” 的方式來實踐 Scrum-of-Scrums。這是一個簡 短的會議，通常最長是 15 分鐘。會議的議程是著重於團隊間相關 的問題，而非是狀態更新。例如，某個團隊遇到阻礙時，會有人說 他需要另一個團隊幫忙什麼之類的等等。我們有時會一個簡單的白 板，上面有些便利貼，來追蹤一些未解決的跨團隊問題。這個會議 變成像是一個小型的市集，用來找出需要同步的需求。同步的需求 本身各自發生的 – 這個會議只是幫助我們找出，誰需要跟誰去談 談，以解決目前這個關聯性的問題。 群體層次的 Scrum-of-Scrums 我們稱這會議叫做"脈動"。我們曾經試過各種不同的形式，邀請不同 的參與者。後來，我們已經放棄整個概念，而是用每週所有人開會 來代替(是的，所有一起開發的人)，15 分鐘長的會。 什麼？ 15 分鐘？ 所有人？ 所有產品，所有團隊的所有人？ 這可行 嗎？ 是的，只要你(或是其他主持會議的人)嚴格確保會議不要太長，那就 可行。 會議的形式像是： 1) 由開發主管來更新或公佈訊息。像是即將發生的事件。 2) 依序報告，每個產品小組有個人報告他們上週完成什麼，他們本 周計劃完成什麼，以及有什麼問題。其他人也會報告(建構管理的 lead，QA Lead 等等)。 3)任何人自由去補充任何訊息，或是問問題。
我們怎樣處理多個 SCRUM 團隊| 135 這裡是用來簡述團隊訊息的論壇，不是用來進行討論，或是反思的。 只要只剩這件事，15 分鐘通常夠用。有時候我們會超過，但是很少 超過 30 分鐘。如果有些熱烈的討論出現，我會中斷它，請有興趣的 人在會議結束後繼續這個討論。 為什麼我們要舉行全體的脈動會議？ 因為我們注意到，"群體層次" 的 Scrum-of-Scrums 內容大多是報告而已。我們很少有真正的討論。 此外，許多其他團隊組織外面的人，很渴望知道這類型的資訊。基 本上，每個團隊想知道其他團隊在做什麼。所以我們想既然花時間 聚在一起來分享這些訊息，那為什麼不讓所有的人都參加呢？ 正如你所看到的，Scrum-of-Scrums 的組成是跟環境有關聯的，這 絕對沒有一個放諸四海皆準的做法。有時候我會被這種狀況給嚇 到：公司每週 (或是每一天) 會進行一些相當無聊，沒有效率的會 議。大家目光呆滯，死盯著天花板。好像在念劇本一樣，喃喃自語 地在更新目前狀態。不要做一個 Scrum 的殭屍！做些改變吧！進 行一些實驗！不斷詢問大家問題，像是 ”這個會議真的有幫助嗎？ 它可能可以增加更多的價值嗎？我們要做什麼改變去讓他更有價值 呢？” 人生苦短，不要浪費在無聊的會議上。 交錯的每日會議 如果你在單一產品中有許多 Scrum 團隊，而且他們都在同一時間朝 開每日 Scrum 會議，你將會有很大的問題。產品負責人(和我像這樣 好管閒事)每天只能參加某個團隊的每日會議。。 所以我們要求團隊，避免在相同時間去朝開每日會議。 以上是一個開會時程的範例，我們朝開每日會議在不同的房間，而 不是在團隊的房間。會議通常是 15 分鐘，但是為每個團隊在每個房 間都有保留 30 分鐘，如果他們需要多一點時間。。
136 | SCRUM 和 XP 的實戰經驗 這方法相當有用的，理由有二。 1. 像產品負責人或是我自己，在早晨會去參加所有每日會議。 若是你要清楚知道每個 Sprint 的進度，以及關鍵的風險是什 麼，沒有什麼方法能比這個更好。 2. 團隊可以參加其他團隊的每日會議，這通常不太會發生。不 過當有兩個團隊在類似的環境下工作，有些成員會造訪其他 團隊的每日 Scrum 會議，以保持資訊的同步。 這方法的缺點是團隊的自由度變小 - 他們不能選擇任何他們喜歡的 時間來舉行每日會議。不過這還沒變成是我們的問題。 這有點困擾我。每日會議主要的目的，是讓團隊成員和其他人同步 資訊。他們應該找一個時間來進行，讓有些愛講話的人也在其中。 例如說我 – 好的，這是次要的。所以，是的，能有交錯的每日會 議是很不錯，但是不需要強迫團隊要這樣做。 救火團隊 我們曾經遇到一個狀況，一個很大的產品無法採用 Scrum，因為他 們花太多時間在救火。也就是修復之前貿然出貨的系統，所產生的 錯誤。這真的惡性循環，他們忙於救火，所以他們沒有時間主動去 做些事情，來預防火災(像是改進設計、自動化測試、建立監控工具 與警報工具)。 我們藉由建立一個專門的救火團隊，和專門的 Scrum 團隊，來解決 這個問題。 Scrum 團隊的工作是(帶著產品負責人的祝福)試圖去有效率地穩定系 統，預防事情惡化。 救火團隊(事實上我們叫它"支援團隊")有兩項工作。 1) 救火 2) 保護 Scrum 團隊免於各式各樣的干擾，包括擋掉那些不知從哪裡 來的，任意功能的請求。 救火團隊可放在最靠近們邊的地方，Scrum 團隊可以放在房間的最裡 面。所以救火團隊可以物理上保護 Scrum 團隊，免於著急的銷售人 員或是生氣的客戶的干擾。
我們怎樣處理多個 SCRUM 團隊| 137 在兩邊都會安插資深的開發人員，所以某一個團隊不會太依賴另一 團隊的核心人員。 基本上，它是去解決 Scrum 自我驅動(bootstrapping)問題的一種嘗試。 如果團隊一次無法規劃超過一天的工作，那要如何開始進行 Scrum 呢？ 我們曾經提過這樣的解法：我們的策略是把它拆成兩個群組 (Scrum 團隊和救火團隊)。 這方法運作的非常好。因為 Scrum 團隊有空間能努力工作，所以他 們最後能穩定系統。在這期間，救火團隊完全地放棄事先規劃的念 頭，他們只是根據外面的需求來運作，單單只修復下一個出現的問 題。 如果我當初知道看板，我絕對會使用 Kanban 來處理救火團隊的事 情。 當然啦，Scrum 團隊也不是完全不被干擾。救火團隊經常會請 Scrum 團隊的關鍵人員來幫忙，或最糟時，需要整個團隊的幫忙。。 但不管如何，在幾個月後，系統已經足夠穩定，所以我們可以解散 救火團隊，並建立額外的 Scrum 團隊。救火隊員會很高興把壓扁的 頭盔放在一旁，然後加入 Scrum 團隊中。 這是很好的模式，但這只是臨時的危機管理策略。正常來說，你不 應該需要一個單獨的救火團隊。如果你把救火團隊跟其他人隔離， 他們就沒有機會去學習新的東西，好讓他們之後可以預防新的問 題！反之，如果你老是需要處理錯誤或是救火 (就像每間公司一 樣)，這需要讓團隊思考該如何處理這個狀況。大部份的團隊內， 最後會有些輪流的救火隊員。這非常簡單而有效。因為它有一個很 明確的誘因，有段時間只寫程式，但是不用救火。 是否要拆解產品 backlog？ 假設你有一個產品和兩個 Scrum 團隊。那應該有多少產品 backlog？ 多少的產品負責人呢？ 我們為此曾經評估過三個模型。選擇結果對 Sprint 規劃會議的進行有很大的影響。
138 | SCRUM 和 XP 的實戰經驗 策略 1： 一個產品負責人，一個 backlog 這裡是"只能有一個"的模型。是我們最推薦的模型。 這個模型的優點是，讓團隊根據產品負責人目前的優先順序，來管 理他們自己。產品負責人只需著重於他所需要的，而團隊則決定如 何拆解工作。 更具體一點，這裡有個團隊 Sprint 規劃會議如何運作的方式： Sprint 規劃會議在外面的會議中心舉行。 在會議開始之前，產品負責人指定一面牆，當作"產品 backlog 的牆 壁"，並且把故事放上去(用索引卡的方式)，依照相對的優先順序來 排序。他會放到直到牆壁被擺滿為止，通常會比一個 Sprint 要做的 項目還要多。
我們怎樣處理多個 SCRUM 團隊| 139 每個 Scrum 團隊選擇一面空的牆，並且貼上自己團隊的名字。這是 他們的"團隊牆壁"。每個團隊會從產品 backlog 的牆壁拿取一些故事， 把這些索引卡貼到他們自己團隊的牆壁。 下面這張照片可以說明一切。黃色箭頭表示故事的索引卡，如何從 產品 backlog 牆壁，移到團隊牆壁的過程。
140 | SCRUM 和 XP 的實戰經驗 在會議的過程中，產品負責人和團隊對於索引卡進行討價還價，把 他們在團隊間移動，移上移下來調整優先順序，或是把它們拆解成 更小的項目，等等。再經過一小時左右，每個團隊在他們的團隊牆 壁上，有第一個 Sprint backlog 的候選版本。隨後團隊獨立工作，進 行時間估算和把故事拆解成任務。 這會相當的吵雜、混亂、和令人筋疲力盡。但是效果不錯，相當有 趣，可以相互聯誼交流。當時間到時，所有團隊通常已得到足夠的 訊息，讓他們可以開始下個 Sprint。 這個模式變成越來越普遍；甚至它被放到一些新的敏捷開發框架 中，像是 SAFe(Sacled Agile Framwork)。最近在 LEGO，我們進行 了兩天的規劃會議，一共超過 140 人！有時候，這樣規劃的技巧 被拿來當作臨時的措施，長達了半年之久。直到我們找到合適的團 隊組織和結構，才能更獨立地進行 sprint 規劃會議。 策略 2： 一個產品負責人，多個 backlog 在這個策略中，產品負責人維護多個產品的 backlog，每個團隊對應 一個。我們沒有真的試過這個方法，但是我們差點這樣做。如果第 一個方法失敗時，基本上這是我們的備援計畫。 這個策略的缺點是，產品負責人需要分配故事給團隊，這件事情可 能團隊自己做會比較好。
我們怎樣處理多個 SCRUM 團隊| 141 典型地，產品負責人在這種狀況下變成是一個瓶頸。 策略 3：多個產品負責人，每個人負責一個 backlog 這個和第二個策略有點像，每個團隊有一個產品 backlog，但是每個 團隊也只有一個產品負責人！ 我們並沒有用這個方法，可能也永遠不會使用。 如果兩個產品 backlog 包含相同的程式碼， 將會造成兩個產品負責 人之間嚴重的衝突。
142 | SCRUM 和 XP 的實戰經驗 如果兩個產品 backlog 能分開程式碼，這樣做和把產品拆成兩個子產 品獨自運作並沒有兩樣。這意味著我們回到了每個產品一個團隊的 解決方案，這將非常輕鬆和容易。 這個模式曾經在 Spotify 使用。每個超過 70 個人的團隊，有它自 己的產品負責人和產品需求清單。事實上，在某些狀況下，我們還 是有點是在使用策略 1 (多個團隊共享一個產品需求清單)。但是對 於大部份其他團隊，他們有他們自己的產品負責人和產品需求清 單。好處是我們很少需要大型的規劃會議。壞處是我們需要付出許 多代價去拆解架構，好讓這種情況可以發生。跟所有事情一樣，總 是有好有壞。因此，就繼續吧，呃…… (我本來要說 “繼續嘗試”， 但我已經說了很多遍了……我不想一直重複，是吧？) 程式碼分支 當多個團隊同時在相同的程式碼上工作，我們不可避免地，必須利 用 SCM(軟體建構管理工具)來處理程式碼的分支。有很多書籍或是 文章在教你如何處理，多個人在相同的程式碼上工作，所以這裡我 不再多談任何細節。我沒有任何新的東西，或是革命性的見解。但 是，我將簡述到目前為止，我們團隊所學到的一些重要的經驗。 § 應該要嚴格保持 mainline(或是 trunk)在一致的狀態。這意味 著最起碼，每件事應該要被編譯，所有的單元測試要被通過。 在每個時間點，應該都可以產生一個可運作的發佈版本。最 好這個持續建構的系統在每天晚上可以進行建構，並自動部 署到測試環境中。 § 每個發佈都打上標記(tag)。無論你何時發佈到驗收測試環境 或是到產品環境，要確認在你的 mainline 中打上版本的標記， 用來準確辨識什麼東西被發佈。這意味在未來任何時間，你 可以退回到之前某個時間點，建立一個可維護的分支。 § 在僅需要的時候才建立新的分支。這裡有一個好的規則： 當 你在不違反 codeline 的政策下，是無法使用現存的 codeline， 這時候就可以分支一個新的 codeline。當有疑問時，就不分 支。為什麼？ 因為每次分支，將導致複雜度和管理成本增加。 § 使用分支主要是為了切割不同的生命週期。你可能會或可能 不會，決定每個 Scrum 團隊能在他們自己的 codeline 進行編
我們怎樣處理多個 SCRUM 團隊| 143 碼。但是如果你把短程的修復和長程的改變放在同一個 codeline，你將會發現,那是非常困難去發佈短程的修復！ § 經常同步。如果你在分支上工作，每當你某些事情可以建構， 要 記 得 同 步 回 mainline 。 每 天 當 你 要 開 始 工 作 時 ， 把 mainline 的程式同步到分支上去。所以你的分支才能及時， 以反映其他團隊的改變。如果因為合併的痛苦，導致你接受 先不合併。不過，越等下去，將會使這狀況越來越糟糕。 是的，這個建議仍然有效 (除了經常標記外，你現在可以在大多 系統上獲得此建議)。使用近代的版本控制系統 (像是 Git)，沒有 理由不經常執行 commit，以保持分支乾淨。經常發佈，並確保 分支不要太久。我曾寫過一篇文章叫 “Version Control for Multiple Agile Teams”: http://www.infoq.com/articles/agile-version-control 我覺得像 Git 這樣的系統，被稱為去中心化的版本控制系統，是 有點好笑。因為大多專案都仍然是單一集中的 repo，每個人都 push 到這個 master branch，在那裡來進行發佈。雖然都是用 Git，但是觀念是不同的。 :o) 多個團隊的回顧會議 當有多個團隊在同一個產品中，我們要如何做 Sprint 回顧會議呢？ 在 Sprint 展示一結束後，大家鼓掌，每個團隊走回去他們自己的房 間，或是辦公室外某個舒服的地方。他們進行回顧會議的方式，和 我之前在"我們如何進行 Sprint 回顧會議"中，所描述的沒有太大的不 同。 在 Sprint 規畫會議期間(因為我們已經同步每個產品的 Sprint，所以 所有團隊都參加)，第一件事情我們從每個團隊中找出一個發言人， 站起來簡述她們回顧會議中所得到的重要結論。每個團隊花 5 分鐘。 然後我們有 10-20 分鐘的開放討論。之後休息一下，再開始真正的 Sprint 規劃會議。 對於多個團隊的狀況，我們還沒試過其他方法，目前這方法已經足 夠了。不過最大的缺點是，在 Sprint 回顧會議後，及 Sprint 規劃會議 前，沒有任何鬆弛的時間。(請看"Sprint 之間的休息時間")
144 | SCRUM 和 XP 的實戰經驗 沒錯，這是一個很大的缺點! 因此，到目前為止，在有相依性的多 團隊中，我偏愛在回顧會議中進行回顧總結。那就是每個團隊先去 進行自己的回顧會議，大約一小時之後，我們所有人在大會議室中 集合，每個團隊總結他們回顧會議的關鍵結果，列出他們最重要沒 有解決的障礙。當聽完每個團隊的報告後，通常可以清楚地看到障 礙 X 是我們最大的跨團隊的障礙 (例如，“各個團隊之間對做完的 定義不一致” 或 “trunk 老是有問題”)。這是一個絕佳的時機，讓大 家來進行迷你工作坊。或者是找一些志願者(例如，每個團隊出一 個人，再加上經理)，一起來找出解法。有時候，他們會在幾小時 內弄清楚，這對第二天的 sprint 規劃會議很有幫助。 對於只有單一團隊的產品，我們在 Sprint 規劃會議中，沒有需要做 任何回顧的總結。沒有必要是因為每個人都實際出席了回顧會議。 俗話說，脈絡為王。尤其面對不同團隊大小更是如此! 沒有一種能適 用所有地方的解法 – 任何方法都可能非常成功，或是完全失敗。 一 切視情況而定。 不過，我發現一些重要的共同點: 組成跨職能團隊，視覺化你的工 作，經常交付，邀請實際用戶參與，自動化你的測試和發佈流程， 以及常常進行實驗。這些確實是敏捷的基本原則。
16 我們如何管理分散在不同地理位置上的團隊 當團隊成員在不同地理位置時，那要該怎麼辦呢？ 大多數 Scrum 和 XP 的魔力所在，就是需要團隊成員聚集在一起緊密地合作，可以搭 檔編程，以及每天面對面溝通。 我們有一些在不同地理位置的團隊，也有些團隊成在常常在家裡工 作。 我們的策略相當簡單。我們的方法是，把物理上分散的團隊成員， 之間的溝通頻寬增加到最大。我並不是意味每秒多少 Mega bit(當然 這也很重要)這樣的頻寬，我是指更廣義的溝通頻寬： § 能夠搭檔編程在一起的能力。 § 在每日會議時能面對面溝通的能力。 § 隨時能面對面討論的能力。 § 能實際上見面和交流的能力。 § 能主動和整個團隊開會的能力。 § 對於 Sprint backlog，Sprint 燃燒圖，產品 backlog 和其他訊息， 有著相同理解的能力。。 還有一些我們已經規劃(或正在規劃，但還沒有用到)的方法： • 在每個工作站前都有網路攝影機和耳機。 • "遠端能力"的會議室具備有：網路攝影機，會議用的麥克風， 隨時可用的電腦，桌面分享軟體，等等。 • "遠端視窗"。在每個地方有個大的螢幕，用來顯示其它地方 的固定畫面。有點像兩個公寓間的虛擬窗口。你可以站在那 裡，並且揮揮手。你可以看到誰站在桌子面前，誰和誰在交 談。這可以讓我們有”嘿，我們是在一起”的感覺 • 交換的方案。每隔一段時間，來自每個地方的人要旅行去拜 訪對方。
我們如何管理分散在不同地理位置上的團隊| 147 利用這些技巧或是其它更多方法，雖然速度不快，但是我們可以確 定地知道，在地理位置不同的團隊成員間，如何去進行 Sprint 規劃 會議，展示，回顧會議，每日會議，等等。 分散式團隊無所不在(因為全球化也不得不分散)。大部分的開源專 案都是由分散式的團隊所組成。因此，無疑地，這是做得到的。但 是，沒有什麼比得上坐在同一房間內的跨職能團隊更有生產力，他 們 100% 專注於單一共同的目標。所以第一優先是去打造這樣的 環境，或者是盡可能地接近。如果你不可避免地讓團隊成員分散在 各地，則上面列出的工具和技巧，是可以減輕損失的好方法。因 此，不要小氣，用錢買最好的工具! 或許你可能無法像，在同一地 的團隊那麼有生產力，但是那會讓你感到變得親密點。 和其他方法一樣，所有一切都要經過不斷地實驗。 檢視 ==> 調整 ==> 檢視 ==> 調整 ==> 檢視 ==> 調整 ==> 檢視 ==> 調整 ==> 檢視 ==> 調整 境外經營 我們有幾個境外經營的團隊，已經嘗試如何使用 Scrum，來有效率 地處理事情。 這裡我們有兩個主要的策略： 分散的團隊或是分散的團隊成員。。
148 | SCRUM 和 XP 的實戰經驗 第一個策略，分散的團隊。它是一個被迫的選擇。無疑的，我們由 第二個策略開始，也就是分散的團隊成員。以下是我們考量的原 因：。 1. 我們希望團隊成員能夠彼此相互了解。 2. 我們希望兩個地方能夠有很好的溝通機制，並且讓團隊有強 烈的動機，讓這個機制建立好。 3. 在剛開始的時候，境外經營的團隊比較小，無法自己組成一 個有效的 Scrum 的團隊。。 4. 在獨立的境外經營團隊能運作前，我們會有一個時間需要緊 密的分享相關訊息。 長期來看，我們很可能會走向"分散團隊"這個策略。
我們如何管理分散在不同地理位置上的團隊| 149 這是一個相當不錯的整體策略。長期來說，你會真的希望團隊在同 一地方，因為分散式的團隊無法有那樣的 ”團隊精神”。因此，最初 即使你只能有一個分散式團隊，也要持續尋找方法，在每個位置建 立不同獨立的團隊。你還要處理兩個團隊之間的相依性以及溝通問 題，但這是一個容易處理的問題。除了改善日常溝通外，其中一個 關鍵因素是做事的動機，把團隊成員都放都一個房間會很有趣，會 刺激他們更快地打造出更好的東西。 在家工作的團隊成員 有時候，在家工作是相當不錯的。你有時候在家一天可以完成，在 辦公室一個禮拜都完成不了的程式。 如果你沒有小孩的話 ：o) 但是，在 Scrum 中有一個基本原則，整個團隊應該要在相同的場所 工作。所以那我們會怎麼辦呢？ 基本上，我們讓團隊自行決定，什麼時候，或多久可以在家工作。 有時候團隊成員因為距離辦公室太遠，所以會常常在家工作。但是， 我們還是鼓勵大部分的時間，是在相同的位置工作。 當團隊成員在家工作，他們需要用 Skype(有時候用錄影)來參加每日 會議。他們每天藉由即時通訊軟體，來保持隨時在線上。雖然沒有 像在同一個房間一樣好，但是已經不錯了。 如今，有很多非常酷，並且價格合適遠距辦公系統可用。例如，在 http://doublerobotics。com 上可以找到 Double Robotics。他的所 賣的產品，可以使 iPad 有再加上風火輪的效果。它很像是 Skype 的通話，但是你可以在遠端到處移動! 我越來越頻繁地使用它，它 讓我感覺我真的轉移到另一個地方！ 我們曾經試過把星期三當作聚焦日的想法，基本上這意味著"如果你 要在家裡工作，那是可以的，但是只能是禮拜三，並且要團隊許可 才行"。在我們試過的團隊中，它運作的還不錯。通常大部分的團隊 星期三待在家裡可以做很多事情，同時還可以合作的很好。因為它 僅有一天，團隊不會因此而太久無法和其他人同步訊息。不過因為 某種原因，這個做法沒有在其他團隊中流行起來。
150 | SCRUM 和 XP 的實戰經驗 整體而論，在家工作的成員，對我們來說已經不是問題。 自組織團隊是 Scrum 其中一個關鍵的做法。這件事的重要性是不 能被小看的。團隊要盡可能地被賦予更多責任，包括工作時數，以 及在家工作的政策。自組織是 創造力，動力，創新能力，和其他 美好事物的關鍵！有些經理害怕團隊會濫用這樣的信任，但是在實 務上，我很少看到這樣的事情發生。只要團隊明確清楚地知道，他 們要負責交付的是哪個產品，他們就會採取負責任的行動。
17 Scrum master 的檢查清單 在最後這個章節，我要介紹我們 Scrum master 的"檢查清單"，它列出 Scrum master 大部分常見的管理事務。這些事情很容易被遺忘。我們 不列出一些顯而易見的東西，像是"消除團隊的障礙"。 另外，請查看 Scrum 檢查清單 https://www.crisp.se/gratismaterial-och-guider/scrum-checklist 它是一份正式的非官方的 Scrum 檢查清單，但是它已廣泛地被使 用，你可能會說它已經非正式地成為官方的 Scrum 檢查清單。 :o) Sprint 開始階段 § 在 Sprint 規劃會議之後，建立一個 Sprint 訊息的頁面。 o 在 wiki 上的數位表，增加一個連結到你的頁面。 o 印出這個頁面，把它貼到牆壁上，人們經過你的團 隊時可以看到。 § 寄出郵件給每個人，公佈一個新的 Sprint 要開始。包括 Sprint 的目標，和指向 Sprint 訊息頁面的連結。 § 更新 Sprint 的統計文件。加入你的估算速度，團隊大小，和 Sprint 的長度等等。 每一天 § 確定每日 Scrum 會議準時開始和結束。
152 | SCRUM 和 XP 的實戰經驗 § 為了確保 Sprint 能準時完成，需要從 Sprint backlog 中增加 或移除些故事。 o 確保產品負責人有被通知到這些改變。 § 確保團隊能保持 Sprint backlog 和燃燒圖能被及時更新。 § 確保問題/障礙能被解決，或是報告給產品負責人和開發主 管。 在 Sprint 結束的時候 § 進行一個公開的 Sprint 展示。 § 每個人在一天或兩天前，就要被通知有一個展示。 § 和整個團隊以及產品負責人，進行 Sprint 回顧會議。也邀請 開發主管，他可以幫助擴展所得到經驗教訓。 § 更新 Sprint 統計文件。加入真實的執行速度，以及回顧會議 中關鍵的結論。 不錯的小清單。隨著時間的推移，身為 Scrum Master，試著讓你 自己變得多餘，指導團隊能在沒有你的狀況下把事情做完。即使你 沒辦法成功地讓自己變得多餘，單光這樣的嘗試，也會引導你做對 事。有些 Scrum Master 最終變成 Scrum 管理員或者是 Scrum 奴 隸，因為他們熱衷於取悅團隊。如果團隊過分依賴你，那實際上是 你在阻礙他們培養自組織的能力。剛開始時，團隊不熟悉 Scrum 且需要你幫忙的時候，可能覺得這樣不錯。但隨著時間的演進，你 應該慢慢地不要介入管理，並賦予團隊更多的責任。這會節省你尋 找障礙的時間，或是讓你有空做些非 Scrum Master 的事情，像是 寫程式或測試等等。
18 臨別贈言 喔！ 從來沒有想到，已經花了這麼長的時間。 不管你是剛學 Scrum，或者是一位經驗豐富的老將，我都希望能帶 給你一些有用的想法。 因為 Scrum 需要根據不同的環境，加以特別的客制化，所以在一般 的狀況下，是很難在最佳的實踐上，有建設性的爭論。但不管如何， 我都很有興趣聽到你的回應。請告訴我，你的方法和我不同之處。 給我一些建議要如何改善！ 可透過 henrik.kniberg@crisp.se 隨時與我聯繫。 哦，這解釋了為什麼我會收到這麼多電子郵件… 我非常感謝您的 回饋，但是如果我不回复，希望不會冒犯到你，因為有時我也想有 自己的生活。 ：o） 我同時也會留意 scrumdevelopment@yahoogroups.com 的信件 如果你喜歡這本書，你可能也會不時檢查我的 blog。我希望能寫一 些有關 Java 和敏捷軟體開發部份的文章。 http：//blog.crisp.se/henrikkniberg/ 現在，這個部落格上有很多文章，影片和資料！不只我的東西而 已，還有我 Crisp 同事以及各種合作夥伴和朋友的資訊。 老實說，這裡是個金礦！ 我在 Twitter 上也很活躍喔（@henrikkniberg）
哦，不要忘記… 這只是份工作而已，不是嗎？
推薦閱讀 以下這些書籍，帶給我許多啟發和想法。高度推薦！ 嗯 ... 我真的應該更新這裏。從 2007 年以來，我讀了許多有趣的 書！但這需要在某個時間點單獨發表。 #cliffhanger
關於作者 Henrik Kniberg (henrik.kniberg@crisp.se)是在斯德哥爾摩 Crisp 公司 (www.crisp.se)的顧問，擅長於 Java 和敏捷軟體開發。 如今，我更像是某種管理顧問，組織研究人員，或是精益/敏捷教 練。基本上，我幫忙重構，調整 和優化公司。不過，我有時候仍 然根據我的興趣去寫寫程式，這是非常好玩的! 當第一本 XP 的書籍和敏捷宣言出現後，Henrik 就開始擁抱敏捷原則， 並嘗試學習如何在不同的組織中，有效率的應用他們。在 1998 到 2003 年之間，他身為 Goyada 的創始人和 CTO，建立和帶領了一個 技術平台和 30 個人的團隊，因此他有大量的機會，去實驗測試先行 的開發方式和其他敏捷的實踐。 在 2005 年末，Henrik 在瑞典一家作遊戲的公司，簽約當開發部門的 主管。當時這家公司處於一個危險的狀況，主要是嚴重的組織和技 術問題。Henrik 利用 Scrum 和 XP 這些工具，在各個階層上實踐敏捷 和精實原則，幫助公司渡過這個困境。 在 2006 年十一月的某個禮拜五，Henrik 發燒，生病在家。他決定記 錄下他自己過去幾年來所學到的東西。不過一但他開始動筆，他無 法停筆下來，在三天內瘋狂的打字和繪圖，這份原始的紀錄已經成 長為 80 頁的文章，取名叫做"Scrum 和 XP 的實戰經驗"，最後變成了 這本小書。 仍然很驚訝我在週末裡把所有東西都寫完了! 這是其他作者討厭我 地方。 Henrik 開創了一個全新的道路，非常享受於扮演不同角色，像是經 理，開發人員，Scrum master，教師，和教練。他非常熱衷於幫助公 司建構優秀的軟體和優秀的團隊，擔當各種必要的角色。 Henrik 在東京長大，現在和他妻子及兩個小孩，居住在斯德哥爾摩。 仍然是相同的妻子和小孩，只是現在有更多小孩 :o) 在空閒時間，他是一個活躍的音樂家，會和當地樂團一起作曲，玩 玩貝斯和鍵盤。
若要得到他更多的訊息，可到 http：//www.crisp.se/henrik.kniberg
Scrum和XP 的實戰經驗 (第二版)

More Related Content

PDF
如何把看板和 Scrum 發揮到極致
byJen-Chieh Ko
 
PDF
敏捷開發分享
by東城 楊
 
PDF
敏捷軟體開發方法與 Scrum 簡介
by曦 徐
 
PDF
Do better-scrum
byWilly Marroquin (WillyDevNET)
 
PDF
Scrum in a nutshell
byMuhammad Azani Hasibuan, M.T.I., PMP
 
PDF
Netflix文化自由与责任
bycnscorpio
 
PDF
Scrum values
byVimarsha Jayawickrama
 
PDF
The Scrum Master Guidebook - 150 pages
byChandan Patary
 
如何把看板和 Scrum 發揮到極致
byJen-Chieh Ko
 
敏捷開發分享
by東城 楊
 
敏捷軟體開發方法與 Scrum 簡介
by曦 徐
 
Do better-scrum
byWilly Marroquin (WillyDevNET)
 
Scrum in a nutshell
byMuhammad Azani Hasibuan, M.T.I., PMP
 
Netflix文化自由与责任
bycnscorpio
 
Scrum values
byVimarsha Jayawickrama
 
The Scrum Master Guidebook - 150 pages
byChandan Patary
 

What's hot

PPTX
ログの書き方がチームの生産性を爆上げする話
byTsuyoshi Ushio
 
PPTX
比較サイトの検索改善（SPA から SSR に変換）
bygree_tech
 
PDF
リーンスタートアップにおける良い仮説、悪い仮説
byTakaaki Umada
 
PDF
セールスアニマルになろう　スタートアップ初期の営業戦略
byTakaaki Umada
 
PDF
ユーザーストーリー駆動開発で行こう。
bytoshihiro ichitani
 
PDF
Management3.0のワークを受けてから会社の偉い人へ M3.0のワークショップをするまでにやったこと
byterahide
 
PPTX
MLflowで学ぶMLOpsことはじめ
byKenichi Sonoda
 
PDF
如何將 Scrum 團隊轉換成 Kanban 團隊
byJen-Chieh Ko
 
PPTX
Lean Customer Development と顧客インタビュー (技術者/研究者発スタートアップのためのリーンスタートアップ)
byTakaaki Umada
 
PDF
OutSystems ユーザー会 セッション資料
byTsuyoshi Kawarasaki
 
PDF
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
byTakuto Wada
 
PDF
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
byizumi ito
 
PDF
俺のインセプションデッキ【Remaster版】
byTakao Oyobe
 
PDF
Amazon RDSを参考にしたとりまチューニング
byShunsuke Mihara
 
PDF
モデリングもしないでアジャイルとは何事だ
byIwao Harada
 
PDF
DynamoDBの初心者に伝えたい初めて触るときの勘所
byRyo Sasaki
 
PDF
重新想像：如何做技術選型決策 / Rethinking : Technical Decision
byYi-Feng Tzeng
 
PDF
20230215 - 凝聚團隊共識的溝通方法 (Effective Team Communication)
byRick Hwang
 
PDF
プロダクトマネージャのお仕事
byShohei Hido
 
PPTX
用社群形塑品牌形象 Social Media Marketing & Branding
byNorika
 
ログの書き方がチームの生産性を爆上げする話
byTsuyoshi Ushio
 
比較サイトの検索改善（SPA から SSR に変換）
bygree_tech
 
リーンスタートアップにおける良い仮説、悪い仮説
byTakaaki Umada
 
セールスアニマルになろう　スタートアップ初期の営業戦略
byTakaaki Umada
 
ユーザーストーリー駆動開発で行こう。
bytoshihiro ichitani
 
Management3.0のワークを受けてから会社の偉い人へ M3.0のワークショップをするまでにやったこと
byterahide
 
MLflowで学ぶMLOpsことはじめ
byKenichi Sonoda
 
如何將 Scrum 團隊轉換成 Kanban 團隊
byJen-Chieh Ko
 
Lean Customer Development と顧客インタビュー (技術者/研究者発スタートアップのためのリーンスタートアップ)
byTakaaki Umada
 
OutSystems ユーザー会 セッション資料
byTsuyoshi Kawarasaki
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
byTakuto Wada
 
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
byizumi ito
 
俺のインセプションデッキ【Remaster版】
byTakao Oyobe
 
Amazon RDSを参考にしたとりまチューニング
byShunsuke Mihara
 
モデリングもしないでアジャイルとは何事だ
byIwao Harada
 
DynamoDBの初心者に伝えたい初めて触るときの勘所
byRyo Sasaki
 
重新想像：如何做技術選型決策 / Rethinking : Technical Decision
byYi-Feng Tzeng
 
20230215 - 凝聚團隊共識的溝通方法 (Effective Team Communication)
byRick Hwang
 
プロダクトマネージャのお仕事
byShohei Hido
 
用社群形塑品牌形象 Social Media Marketing & Branding
byNorika
 

Similar to Scrum和XP 的實戰經驗 (第二版)

PDF
一個 agilist 的獨白
byTerry Wang
 
PPTX
Why Scrum (敏捷式專案管理)
byYu Wei Shang
 
PDF
客倌您好，有聽過scrum嗎？ first time meeting scrum
bySylvia Yang
 
PDF
Scrum深入淺出
byTaien Wang
 
PPTX
Scrum essential
by國昭 張
 
PDF
老闆，您敏捷和我們不一樣 - 2024.8.20- 釋出版本-Vincent Lee 李名揚
byVincent Lee
 
PDF
0918 產品經理先修班
byALPHA Camp Taiwan
 
PPT
SCRUM
byZongYing Lyu
 
PDF
專業外語（二）xxxddddddfffffddddddddddd-W06.pdf
byMeiMei986041
 
PPTX
Chapter 15 planning
byJen-Chieh Ko
 
PDF
Scrum and xp from the trenches (1st edition, Chinese)
byJen-Chieh Ko
 
PDF
從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup
byWen-Tien Chang
 
PPT
《Scrum漫谈》
bythinkinlamp
 
PPTX
老闆，您敏捷和我們不一樣-HWC Agile Summit-2024.9.12-公開版本
byVincent Lee
 
PDF
Scrum
byAscii Huang
 
PPTX
Scrum 實務超入門
byYin-Hong Hsu
 
PPTX
Scrum
byCloud Wu
 
PDF
20150714 succeeding with agile
byJen-Chieh Ko
 
PDF
Agile meetuphsinchu201508 scrumvskanban
byJen-Chieh Ko
 
PPTX
Scrum gathering 2014sharing v4
byJen-Chieh Ko
 
一個 agilist 的獨白
byTerry Wang
 
Why Scrum (敏捷式專案管理)
byYu Wei Shang
 
客倌您好，有聽過scrum嗎？ first time meeting scrum
bySylvia Yang
 
Scrum深入淺出
byTaien Wang
 
Scrum essential
by國昭 張
 
老闆，您敏捷和我們不一樣 - 2024.8.20- 釋出版本-Vincent Lee 李名揚
byVincent Lee
 
0918 產品經理先修班
byALPHA Camp Taiwan
 
SCRUM
byZongYing Lyu
 
專業外語（二）xxxddddddfffffddddddddddd-W06.pdf
byMeiMei986041
 
Chapter 15 planning
byJen-Chieh Ko
 
Scrum and xp from the trenches (1st edition, Chinese)
byJen-Chieh Ko
 
從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup
byWen-Tien Chang
 
《Scrum漫谈》
bythinkinlamp
 
老闆，您敏捷和我們不一樣-HWC Agile Summit-2024.9.12-公開版本
byVincent Lee
 
Scrum
byAscii Huang
 
Scrum 實務超入門
byYin-Hong Hsu
 
Scrum
byCloud Wu
 
20150714 succeeding with agile
byJen-Chieh Ko
 
Agile meetuphsinchu201508 scrumvskanban
byJen-Chieh Ko
 
Scrum gathering 2014sharing v4
byJen-Chieh Ko
 

More from Jen-Chieh Ko

PPTX
Mopcon 2021 Scrum 是新的死亡行軍嗎?
byJen-Chieh Ko
 
PPTX
啟動敏捷轉型的工具箱
byJen-Chieh Ko
 
PDF
O.R.I.D 初探 - 新竹敏捷分享.pdf
byJen-Chieh Ko
 
PDF
RSG Taipei 2023 LeSS Design Principles
byJen-Chieh Ko
 
PDF
Agile.Taipei 2025.1月聚會 - AI加持的人本軟體開發未來, Terry
byJen-Chieh Ko
 
PDF
Design sprint sharing of DS team
byJen-Chieh Ko
 
PDF
Beer game-public
byJen-Chieh Ko
 
PDF
AI_革命_軟體工程的新紀元. Martin Fowler 對 AI 的經驗談
byJen-Chieh Ko
 
PDF
2021 台灣軟體測試現狀調查
byJen-Chieh Ko
 
PDF
Stop Retrospective, Start Continuous Improving
byJen-Chieh Ko
 
PDF
Agile tourhsinchushare踩過的scrum event坑
byJen-Chieh Ko
 
PDF
DevOpsDays Taipei 2024 以系統思考來討論 LeSS 如何處理多頭馬車
byJen-Chieh Ko
 
PDF
Agile Summit Taipei 2019 - Agile Testing Strategy
byJen-Chieh Ko
 
PDF
Agile summit2021 - Talk About Exploratory Testing
byJen-Chieh Ko
 
PPTX
Practical Testing Strategy for Agile Team
byJen-Chieh Ko
 
PDF
Design sprint experience at Trend Micro
byJen-Chieh Ko
 
PDF
Agile Hsinchu 七月線上聚會: 我的教練旅程
byJen-Chieh Ko
 
PDF
The right It : How to make your assumption - Agile HsinChu 2020 Mar Gathering
byJen-Chieh Ko
 
PPTX
Container and Test Automation Management Practices in TrendMicro
byJen-Chieh Ko
 
PDF
Exploratory testing survey in 2020
byJen-Chieh Ko
 
Mopcon 2021 Scrum 是新的死亡行軍嗎?
byJen-Chieh Ko
 
啟動敏捷轉型的工具箱
byJen-Chieh Ko
 
O.R.I.D 初探 - 新竹敏捷分享.pdf
byJen-Chieh Ko
 
RSG Taipei 2023 LeSS Design Principles
byJen-Chieh Ko
 
Agile.Taipei 2025.1月聚會 - AI加持的人本軟體開發未來, Terry
byJen-Chieh Ko
 
Design sprint sharing of DS team
byJen-Chieh Ko
 
Beer game-public
byJen-Chieh Ko
 
AI_革命_軟體工程的新紀元. Martin Fowler 對 AI 的經驗談
byJen-Chieh Ko
 
2021 台灣軟體測試現狀調查
byJen-Chieh Ko
 
Stop Retrospective, Start Continuous Improving
byJen-Chieh Ko
 
Agile tourhsinchushare踩過的scrum event坑
byJen-Chieh Ko
 
DevOpsDays Taipei 2024 以系統思考來討論 LeSS 如何處理多頭馬車
byJen-Chieh Ko
 
Agile Summit Taipei 2019 - Agile Testing Strategy
byJen-Chieh Ko
 
Agile summit2021 - Talk About Exploratory Testing
byJen-Chieh Ko
 
Practical Testing Strategy for Agile Team
byJen-Chieh Ko
 
Design sprint experience at Trend Micro
byJen-Chieh Ko
 
Agile Hsinchu 七月線上聚會: 我的教練旅程
byJen-Chieh Ko
 
The right It : How to make your assumption - Agile HsinChu 2020 Mar Gathering
byJen-Chieh Ko
 
Container and Test Automation Management Practices in TrendMicro
byJen-Chieh Ko
 
Exploratory testing survey in 2020
byJen-Chieh Ko
 

Scrum和XP 的實戰經驗 (第二版)

  • 1.
    Scrum 和 XP的實戰經驗 我們如何進行 Scrum 第⼆版 - 導演完整版 Henrik Kniberg 著
  • 2.
    © 2007 C4MediaInc 版權所有 C4Media，是 InfoQ.com 的一家出版商。 這本書是 InfoQ 所出版企業軟體開發叢書的一部分。 如果要購買這本書籍或是其他 InfoQ 的書籍，請聯絡 books@c4media.com。 根據第 107 或 108 條的 1976 年美國版權法，未經過出版商事先書 面允許，本書任何部份不得用於再印刷，或是儲存於可重複使用的 系統，或者以任何方式進行電子、機械、影印、錄製、掃描、或其他形 式的傳播。 公司使用的名稱來區分他們的產品，這些名稱往往被稱作為商標。 在所有情況下，C4Media 公司要求，產品名稱需要第一個字大寫或 全部大寫。然而，讀者應聯絡適當的公司，去得到更完整的資料、 商標及註冊。 英文責任編輯： Diana Plesa 美國國會圖書館編目中，出版物資訊： ISBN： 978-1-4303-2264-1 本書在美國印製
  • 3.
    致謝 這本書的初稿僅花了一個週末去打字，但是這是一個工作密集的週 末！ 150%的投入程度 :o) 感謝我的老婆Sophia， 和我的小孩 Dave 與 Jenny，忍受我那個週末 要工作。同時也感謝 Sophia 的父母 Eva 和 Jörgen，過來幫忙照顧我 們家。 還要感謝我在斯德哥爾摩 Crisp 工作的同事，還有在 Yahoo 的 scrumdevelopment group 中的人們，一起校稿並且幫忙改進這本書。 最後，感謝我所有的讀者，長期提供一些有用的回饋。我特別高興 地聽到，本文引起這麼多人，對於敏捷軟體開發的熱情！
  • 5.
    目錄 序 - JEFFSUTHERLAND i 序 - MIKE COHN iii 第⼆版 - 導演完整版 1 簡介 9 免責聲明 10 為什麼我要寫這本書 10 但是什麼是 Scrum？ 10 我們如何紀錄產品的 Backlog 11 故事中其他的欄位 13 如何讓我們的產品 Backlog 保留在商業應用層次 14 我們如何準備 Sprint 的規劃 16 我們如何產生 Sprint 計畫 18 為什麼產品負責人需要參加 18 為什麼品質是不可被談判的 20 永無止境的 Sprint 規劃會議… 21 Sprint 規劃會議的議程 23 訂定 Sprint 的長度 24 定義 Sprint 的目標 25 決定在這次 Sprint 要做哪些故事 26 產品負責人如何影響哪些故事要放在這次 Sprint 中？ 27 團隊如何決定哪些故事要放到這個 Sprint 中？ 28 我們為什麼要使用索引卡 34 “做完”的定義 38 使用計畫紙牌來做時間規劃 38 釐清故事內容 41 把故事拆解成更小的故事 42 把故事拆解成任務 43 定義每日會議的時間和地點 44 哪裡是最後的底限 45
  • 6.
    技術性的故事 46 錯誤追蹤系統 vs.產品 backlog 48 Sprint 規劃會議終於結束了！ 49 我們如何溝通我們的 Sprints 52 我們怎麼撰寫 Sprint backlogs 55 Sprint backlog 的存放方式 55 如何讓任務板發揮作用 57 範例 1 – 在每日會議結束後 58 範例 2 – 在幾天之後 59 任務板上的警訊 62 嘿，要如何追蹤？！ 64 用天數來評估 vs. 用小時來評估 64 我們如何安排團隊的座位和空間 66 設計的角落 66 讓團隊坐在一起！ 68 讓產品負責人坐在隔壁間 69 讓經理和教練坐在隔壁間 69 我們怎麼進行每日會議 72 我們如何更新任務板 72 處理遲到的傢伙 73 處理"我不知道今天要做什麼"的狀況 74 我們怎樣進行 Sprint 的展示 77 為什麼我們堅持所有的 Sprint 在結束前都要展示 77 Sprint 展示的檢查清單 78 處理"無法展示"的項目 79 我們如何做 Sprint 回顧 80 為什麼我們堅持所有團隊都要做回顧會議呢？ 80 我們如何組織回顧會議 81 在團隊間散播所學到的教訓 83 改變，或不改變 84 在回顧會議中，所發現問題的範例 84 Sprint 之間的休息時間 88 我們如何做發佈計畫和處理固定價格的合約 91
  • 7.
    定義你的驗收門檻 91 對最重要的項目作時間的估算 92 估算速度94 在發佈計畫中考量所有因素 95 調適發佈計畫 96 我們如何結合 Scrum 和 XP 98 搭檔編程 98 測試驅動開發(TDD) 99 漸進式設計 102 持續整合 102 程式碼集體共有權 103 資訊化工作場所 103 編碼規範 104 可持續的開發速度/精力充沛的工作 104 我們怎樣做測試 106 您可能無法擺脫驗收階段 106 縮短驗收測試階段 107 藉由把測試人員放到 Scrum 團隊中來提高品質 108 藉由在 Sprint 中做較少的工作來提高品質 111 驗收測試應該是 Sprint 的一部分嗎？ 111 Sprint 週期 v.s. 驗收測試週期 112 不要讓最慢的一個連結從你的環節中斷掉 116 回到現實 117 我們怎樣處理多個 Scrum 團隊 120 要建立多少團隊 120 為什麼我們要導入"團隊領導"的角色 125 我們如何配置人手到團隊中 126 要不要有特別的團隊？ 128 是否在 Sprints 之間重新組織團隊？ 131 兼職的團隊成員 132 我們如何進行 Scrum-of-Scrums 133 交錯的每日會議 135 救火團隊 136 是否要拆解產品 backlog？ 137
  • 8.
    程式碼分支 142 多個團隊的回顧會議 143 我們如何管理分散在不同地理位置上的團隊146 境外經營 147 在家工作的團隊成員 149 Scrum master 的檢查清單 151 Sprint 開始階段 151 每一天 151 在 Sprint 結束的時候 152 臨別贈言 153 推薦閱讀 156 關於作者 158
  • 9.
    序 - JeffSutherland 團隊需要知道 Scrum 的基本知識。像是如何建立和估算一個產品 backlog？如何把它轉換成 Sprint 的 backlog？如何管理燃燒圖和計算 你團隊的速度？ Henrik 的書可當作一個基本實踐的入門工具，幫助 團隊從嘗試 Scrum 的程度，到可以把 Scrum 執行的很好的地步。 對於要投資軟體團隊的公司，良好的 Scrum 執行狀況變得很重要。 身為一個創業投資集團的敏捷教練，我為了幫助他們達成投資的目 標，我建議只投資執行敏捷方法情況良好的公司。集團中的資深合 夥人，向所有待投資的公司詢問，他們是否知道他們團隊目前的速 度，目前他們都很難回答這個問題。為了要得到能進一步被投資的 機會，開發團隊需要了解，他們自己軟體生產率的速度。 為什麼這件事這麼重要？如果團隊不知道自己的速度，產品負責人 無法公佈產品的路線，及其可靠的發佈時間。如果沒有可靠的發佈 日期，該公司可能會失敗，投資者可能會失去他們的錢！ 不管你的公司是大是小，是新是舊，有資金或沒資金，都會面臨這 個問題。最近在倫敦的會議中，有討論 Google 實施 Scrum 的狀況。 那時我詢問 135 個聽眾，有多少人在使用 Scrum，只有 30 個人舉手。 接著我問他們是否根據 Nokia 的標準來做反覆式開發。反覆式開發 是敏捷宣言的基礎，能及早並頻繁地交付可運作的軟體。Nokia 花了 幾年的時間，和幾百個 Scrum 團隊進行了許多回顧會議，對反覆式 開發規範出許多基本的需求： • 每次循環必須有固定的時間框(time boxes)，並且要小於 6 個 禮拜。 • 在每個循環結束後，程式必須被 QA 測試過並且能運作正常。
  • 10.
    ii | SCRUM和 XP 的實戰經驗 在 30 個有使用過 Scrum 的人中，只有一半的人說，他們有滿足 Nokia 標準，以及敏捷宣言的第一個準則。然後我問他們是否滿足 Nokia 的 Scrum 標準： • Scrum 團隊必須要有產品負責人，並且大家都知道他是誰。 • 產品負責人必須有一個產品 backlog，並且已經由團隊估算 過。 • 團隊必須有燃燒圖，可以知道他們的速度。 • 在 Sprint 的過程中，必須沒有外面的團隊來干擾他們。 在 30 位有使用過 Scrum 的人中，只有 3 位滿足 Nokia 對 Scrum 團隊 的測試。所以只有這些團隊，可以在將來得到我合資夥伴的錢了。 Henrik 這本書的價值在於，如果你遵照他所提出的實踐，你將會有 產品 backlog，產品 backlog 的估算，燃燒圖，並且知道你團隊的速 度，與其他許多重要的實踐。然後你將會通過 Nokia 對 Scrum 團隊 的測試，並且值得對你的工作做出投資。假如你是一個剛創業的公 司，可能還會收到創投集團的資金。你或許會是軟體開發的未來， 成為下一代領導軟體產品的創建者。 Jeff Sutherland, Ph.D.，Scrum 的共同創始人
  • 11.
    序 - MikeCohn Scrum 和 XP 都要求團隊在每次循環結束後，都完成某些實際可交付 的工作片段。這個循環被設計成要短，要有時間框。在短時間內， 將火力集中去交付可運作的程式碼，這意味著 Scrum 和 XP 沒有時間 研究理論。他們不致力於用工具去繪製完美的 UML 模型，或是撰寫 完美的需求文件，或編寫能應付所有未來變化的程式碼。反而， Scrum 和 XP 團隊著重於把事情做完，他們可以接受過程中有犯錯， 但是他們知道找到錯誤最好的方法，就是實際去做它，開始去建構 產品，而不是停留在理論階段的分析和設計。 這本書與眾不同之處，就著重在實踐而不是理論。Henrik Kniberg 知 道這些對初學者來說特別有用。他並不對 Scrum 是什麼，提供長篇 大論的描述，他只是提供一些網站給我們參考。反之，Henrik 一開 始就立即描述他的團隊如何管理，如何處理產品 backlog。從這裡他 又接著述說成功的敏捷專案，其他所有要素和實踐。沒有任何理論， 沒有任何參考的東西，沒有註腳，沒有廢話。Henrik 的書不是從哲 學的角度上來做解釋 Scrum 為什麼可行，或是為什麼你可以嘗試這 樣做或那樣做。它只是描述成功的敏捷團隊如何運作。 這是為什麼這本書的副標題 - "我們如何進行 Scrum" - 是如此洽當。 它可能不是你執行 Scrum 的方式，它只是 Henrik 的團隊進行 Scrum 的方式。你可能會問，為什麼你應該關心其他團隊如何進行 Scrum。 你是應該關心的，因為藉由聽到別人如何進行的故事，尤其是做的 很成功的案例，我們可以學習如何做的更好。這不是，也永遠不會 是"Scrum 最佳實踐"清單，因為團隊和專案的背景勝過其他一切考量。 與其是最佳實踐，我們應該要知道什麼是好的實踐，以及在什麼狀 況下它可以適用。讀過夠多成功團隊的故事，以及他們如何做事， 你將會準備好，去面對你實施 Scrum 和 XP 所面臨的困難。 Henrik 提供了很多好的實踐，以及對應使用的狀況。幫助我們學習 如何更有效地，在我們的專案中執行 Scrum 和 XP。 Mike Cohn "Agile Estimating and Planning"和"User Stories Applied for Agile Software Development"的作者
  • 12.
    前言 - 嘿，Scrum是可行的！ Scrum 是可行的！至少在我們這裡是這樣的(這裡是指我們在斯德哥 爾摩的客戶，但是我在這裡不會提到他們的名字)。希望它對你們也 一樣可行的！也許這篇文章能一路上幫助著你。 這是第一次，我看到一個開發方法論(抱歉，Ken，它是一個框架)， 離開書本後仍可以運作的很好，拿來就可以直接使用。所有人- 開發 人員，測試人員，經理 - 都很高興，它幫助我們脫離了困難的狀況， 儘管市場動盪嚴重和不斷地裁減人員，我們仍能集中精神在要處理 的事情上。 我不應該說我為此感到很驚訝，但是，是的，我確實是這樣。一開 始看了幾本書之後，覺得 Scrum 看起來挺好的，但是太好到不像是 真的(我們都知道"當某些事情看起來好到不像是真的…"，是在說什 麼 )，所以我有理由去懷疑它。但是在使用 Scrum 一年後，我充分地 被它吸引注了(大部分我的團隊成員也是如此)。如果沒有足夠的理由， 我之後新的專案，預設都會繼續使用 Scrum。
  • 13.
    前言 – 第二版 八年已經過了，這本書仍然受到歡迎。哇，我從沒想過，這本小書 能產生這麼大的影響。在很多地方，我仍然遇到很多團隊，經理， 教練，和訓練師，把它當成敏捷軟體開發的主要指南。 但是，這本書是我在2007 年所學到的東西，所以這本書需要更新。 看因為出版了這本書，讓我有機會和許多敏捷和精實思維的領袖一 起工作，甚至有些變成我個人的心靈導師。特別感謝 Jeff Sutherland， Mary and Tom Poppendieck，Jerry Weinberg,，Alistair Cockburn， Kent Beck，Ron Jeffries，以及 Jeff Patton - 我不能想到有更好的顧問 團體。 此外，我還有些機會去幫助許多公司，去把這些想法實際上給做出 來: 不管是處於危機中的公司，或是超級成功的公司都一樣，都想要 變成更好。總而言之，它是一個非常令人興奮的旅程！ 當我重讀這本書時，我很驚訝有不少地方我還是認同。但是還是有 些頁面我想要拿掉。想說”當初是見鬼了，為什麼我會這樣想，不應 該這樣做，應該還有更好的方法 !” 因為這本書是真實世界的案例，我無法改變故事內容，怎麼發生就 是怎樣發生。但是我可對它給些註解！ 所以這就是第二版要講的 - 原先版本的註解版。就像是導演完整版。 把它想成當你在讀這本書時，我站在你肩膀後面，對這些內容解釋， 對你歡呼，偶而參雜著笑聲和抱怨聲。 這裏讓你知道這個註解版看起來會是怎樣。在陰影框中是我對第二 版的註解和反思。其他的部分(除了這個前言外) 則是跟原先一樣， 沒有修改。
  • 14.
    vi | SCRUM和 XP 的實戰經驗 我還列了一些別的公司的範例，大部份是 Spotify (因為我大部份的 時間都花在那邊) ，但是還有其他公司的。 好好享受 Henrik，三月 2015
  • 17.
    1簡介 你即將在你的組織中開始使用 Scrum，可能你已經使用了 Scrum好 幾個月，或者你已經有些基本知識，也許你已經讀過幾本書，更或 者可能你已經拿到 Scrum Master 的認證。恭喜！ 但是你可能還是感到非常困惑。 用 Ken Schwaber 的話來說，Scrum 不是一個方法學，它是一個框架 (Framework)。也就是說 Scrum 不會馬上告訴你，你要做什麼。該死！ 好消息是我將告訴你，我如何來執行 Scrum，以及詳細痛苦折磨的 過程。壞消息則是，這只是我執行 Scrum 的方式，這並不意味你應 該和我做的方法一樣。事實上，如果我遇到不同的狀況，我可能會 用不同的方法來實踐。 Scrum 的強處和痛苦的地方，就是你被迫需要根據你自己特殊的狀 況，來進行調整。 我目前的方法，是過去一年來，大約四十人的開發團隊對 Scrum 的 實驗結果。公司那時處於艱苦的狀態，大家一直加班，產品有品質 的問題，很多人持續救火，一直錯失交付日期。公司已經決定使用 Scrum，但是並沒有真正的實行。對他們來說，那只是我的工作而已。 那時對於開發團隊的大部分人來說，Scrum 只是一個陌生的時髦術 語，可以常常在走廊上聽到它。但是對他們的日常工作來說，並沒 有任何關連或影響。 經過一年以上的時間，在公司中各個階層裡，我們都實踐了 Scrum。 我們試過不同的團隊大小(3-12 人)，不同的 Sprint 長短 (2-6 個禮拜)， 不同定義"作完"的方式，不同產品 backlog 和 Sprint backlog 的紀錄格 式(Excel，Jira，索引卡)，不同的測試策略，不同的方式進行展示， 不同的方法來同步多個 Scrum 團隊的訊息，等等。我們還嘗試了 XP 的實踐 - 各種不同方式來進行持續建構，搭檔編程，測試驅動開發 等等，以及如何把 XP 和 Scrum 結合。
  • 18.
    10 | SCRUM和 XP 的實戰經驗 這是一個持續學習的過程，所以故事不是到這裡就結。我相信如果 公司保持學習(如果他們持續進行 Sprint 回顧會議)，則在他們各自的 環境下，要如何執行 Scrum 才會最佳，他們將會獲得新的見解。 免責聲明 這份文件並不是告訴你如何以"正確"的方式來做 Scrum，它只是說明 某一種方式去做 Scrum，並且這是我們一年來，持續調整的結果。 當然你也可以說，我們作法完全是錯的。 在書中所說的每件事情，都是我個人的觀點，不代表 Crisp 或是我目 前客戶的官方意見。為此我避免提到任何產品或是人名。 為什麼我要寫這本書 在學習 Scrum 的時候，我讀過了幾本 Scrum 和 XP 書籍，瀏覽了許 多 Scrum 的網站和論壇，參加 Ken Schwaber 的 Scrum 認證課程，用 許多問題刁難他，花很多時間和我的同事進行討論。然而，在許多 資訊來源中，我感到最有價值的，是來自真正實戰的故事。這些實 戰的經驗把準則和實踐變成…嗯…你怎麼真的動手去做它。他們幫 助我去辨識出(有時候是避免)Scrum 新手容易犯的錯誤。 所以，這次該我做些事情來回饋了，以下就是我的實戰經驗。 我希望這本書，對於有相同經驗的人，可以促使他們提出一些回饋， 請記得要啟發我！ 但是什麼是 Scrum？ 哦，對不起，你完全對 Scrum 或 XP 很陌生嗎？ 那你可能要先去看 一下這些的連結： • http：//agilemanifesto.org/ • http：//www.mountaingoatsoftware.com/scrum • http：//www.xprogramming.com/xpmag/whatisxp.htm 看一下 Scrum Guide，它現在是 Scrum 的官方說明書，由 Jeff Sutherland 和 Ken Schwaber 所維護。 http://www.scrumguides.org 如果你沒有耐心去看它們，哪就隨你的意繼續往下看吧。大部分 Scrum 的術語，會在中間的過程中解釋，所以你仍然會感興趣的。
  • 19.
    2我們如何紀錄產品的 Backlog 產品的 backlog是整個 Scrum 中的核心，也是所有東西的起源。 嗯，不，產品 backlog 並不是起源。一個好的產品開始於客戶的需 求，以及如何解決它的願景。產品的 backlog 是將願景提煉成具體 交付項目的結果。這個從願景轉換成 backlog 的旅程，是相當複雜 的，需要用到許多技巧來填補這個差距。像是使用者故事地圖(唸 一下 Jeff Patton 的書，非常棒!)、精實用戶體驗、影響地圖等等。 但是不要因此藉故要做大規模的事前設計! 讓產品 backlog 是逐漸 地被浮現出來，就像其他東西一樣。 基本上來說，它是由需求、故事或是功能等，所組成的一個依重要 性排列的列表。它裡面是用客戶的術語，來描述客戶所想要的東西。 我們稱這些叫做故事(Stories)，有時候也叫做 backlog 項目。 我們的故事包含以下欄位： § 編號(ID) – 一個唯一的識別號碼，號碼會自動增加。若是我 們之後改變故事名稱，它可以避免我們找不到。 § 名稱(Name) – 由簡潔、有敘述性的句子來表示故事。例如： “查看交易的歷史紀錄”。它必須要夠清楚，才能讓程式設 計師和產品負責人，大致了解我們講的東西是什麼，並且也 可清楚區分和其它故事的差別。正常來說，大約是由 2~10 字所組成。 § 重要性(Importance) – 產品負責人評估故事的重要性。例如： 10 或是 150，數字越高代表越重要。 o 企圖避免使用"優先順序(Priority)"這個說法。通常 1 代表最高優先順序，可是後來如果有其它更重要的 事情，那它的優先順序應該要是什麼？ 要給 0 或是-1？
  • 20.
    12 | SCRUM和 XP 的實戰經驗 § 初始估算(Initial estimate) – 只是團隊最初對它的估算。認為 與其它故事相比，完成這個故事所需要付出的代價為何。最 小單位是用故事點數 (story point) 來表示。通常會用多少人 天來約略估算。 o “如果有適當的人員來開發這個故事(不會太多也不 會太少，通常是兩位)，並且把他們關到一間房間， 有很多食物，然後沒有打攪。那需要幾天才能交出 一個完整、可以展示、並且已經經過驗證的、可以 交付的實作結果呢？”如果答案是“把三個人關在 一起，大約需要 4 天”，則故事點數的初估值就是 12。 o 重要的是，這裡並不是絕對值(也就是 2 個故事點數 就是代表要花兩天)，而是一個相對值。(也就是說， 2 個故事點數所要花的時間，會是 4 個故事點數的一 半)。 § 如何展示 (How to demo) –大略描述這個故事，在 Sprint 的展 示會議上要如何被展示。它基本上是一個簡單的測試規格書。 “先做這個，再做那個，然後這個功能就完成”。 o 如果你有實作測試驅動的開發方式(TDD) ，那麼這段 說明就可以變成你驗收測試程式的虛擬碼(pseudo code) 。 § 註解(Noes) – 其他相關的資訊、解釋、參考資料等等， 一般 來說都很簡短。 產品 BACKLOG (範例) ID Name Imp Est How to demo Notes 1 存款 30 5 Log in，登入，打 看存款頁面，存入 €10 歐元，到帳戶 餘額頁面，檢查是 否已增加€10 歐 元。 需要 UML 的循序圖。 目前不需要 考慮加密的 問題。 2 查看交易的 歷史紀錄 10 8 登入，點選“交 易”，存入一筆款 項，回交易頁面， 檢查是否有新的交 易顯示。 使用分頁的 技術以避免 大量資料的 查詢。查看 使用者資料
  • 21.
    我們如何紀錄產品的 Backlog |13 的頁面也有 類似的設 計。 我們嘗試過很多欄位，但是最後發現，上面這六個欄位，是我們實 際上有一直採用下去。 有兩件事情我現在幾乎以不同方式來進行。首先，沒有 ”重要性” 這個欄位。取而代之的，我只對這個清單排序。所有的 backlog 管 理工具都有拖拉排序的功能。(即使 Excel 和 Google 電子表格都有 這功能，只要你知道它神秘的加速鍵為何) 這樣比較簡單又快速。 其次，沒有人天。評估是用故事點數，或是 T-shirt size (S/M/L)來 表示，或是都不做評估。但是後者比較多。 通常我們會把它存放在共享的 Excel 中 (這樣可以多個使用者，同時 去編輯它)。依官方說法，產品負責人擁有和負責這份文件，但是我 們並不想讓其他人不能接觸它。因為很多時候，測試開發人員需要 查詢這份文件，以釐清一些事情，或是改變原先的估算。 同理，我們並沒有把它放在版本控制工具的資料庫中。相反的，我 們把它放到共用的檔案夾中。這樣是最簡單方法，可以避免在同時 編輯下，造成 lock 或是 merge 的問題。 但是，大部分其他文件，我們都有還是有保留在版本控制工具的資 料庫中。 Excel，哈? 喔，那已經是過去的日子了。我現在已經不會再考慮 使用 Excel 來管理 backlog，除非它是一個不確定的版本。產品 backlog 需要以線上文件的方式存在，好讓每個人可以同時存取和 容易修改。可以從眾多的backlog 管理工具中找個來用 (Trello， LeanKit 和 Jira 都很流行)，或者 Google 的電子表單也可以 (非常 務實！)。 故事中其他的欄位 有時候我們會使用其他欄位，方便讓產品負責人來判斷優先順序。
  • 22.
    14 | SCRUM和 XP 的實戰經驗 § 軌道(Track) – 對這故事的簡單分類，像是：“後端系統”、 或是“最佳化”。產品負責人可以容易過濾出，屬於“最佳 化”種類的故事出來，然後把他們的優先順序設定比較低。 § 元件(Components) – 通常會利用 Excel 中的 checkboxes 來實 現。例如：“database，server，client”。這裡整個團隊或是 產品負責人，可以標示哪個技術元件可以用來實作這個故事。 當你有多個 Scrum 團隊時，這是非常有用的一個技巧。像是， 後端系統的團隊，客戶端系統的團隊，可以很方便讓每個團 隊知道，他們需要實作哪些故事。 § 請求者 (Requestor) – 產品負責人可以記錄，起初是哪個客 戶，或是關係厲害人提出這項需求，以方便日後回報目前處 理的進度。 § 錯誤追蹤代碼 (Bug tracking ID) – 如果你有錯誤追蹤系統， 像是我們用 Jira 一樣，方便讓你追蹤故事和錯誤案例之間的 關連。 如何讓我們的產品 Backlog 保留在商業應用層次 如果產品負責人有技術的背景，那他可以添加一個故事：“把 Event 表格增加索引”。為什麼他需要這個呢？背後真正的原因，可能是 希望在後端系統中，加快搜尋事件表單的反應速度。 但也有可能完全並不是那麼回事，表單變慢的瓶頸不見得是索引的 問題。所以產品負責人還是只關注在商業的需求上面，而開發團隊 才是解決這些技術問題的合適人選。 當我看到一些技術導向的故事出現，我一般都會問產品負責人，一 些“但是為什麼呢？(but why)”的問題，直到我們真正了解潛在的目 地為止。然後才用真正的目的，來改寫這個故事(加快後端系統中， 搜尋事件表單的反應速度)。原先技術導向的敘述只會放在註解中以 供參考 ("對 event 表格增加索引可能會解決這個問題")。 有一個古老但是行之有年的樣板：“身為 X 角色，我想要 Y，所以 Z” 。例如 “身為一個購物者，我想要儲存我的購物車內容，所以我 明天可以繼續購物”。我很驚訝我在 2007 年時沒有知道這個！如 果有知道就太方便了。是的，現今已經有很多精心設計的樣板，但 是這個簡易的做法是一個很好起始點，特別是當團隊還對敏捷不熟 悉時。這個樣板可以迫使你問些正確的問題，減少你陷在技術細節 的風險裡。
  • 23.
  • 24.
    3我們如何準備 Sprint 的規劃 是的，Sprint規劃會議這一天很快的到來。我們有個一而再學到的教 訓是： 教訓：在 Sprint 規劃會議之前，要確認產品 backlog 是井井有條的。 但願如此！我看過許多 sprint 規劃會議炸掉，是因為產品 backlog 是一個爛攤子。你知道這個名言 ”垃圾進 = 垃圾出” 嗎？沒錯。 這是代表什麼意思呢？是要所有的故事都必須被完美的定義嗎？還 是所有的估算都必須準確無誤？或者是所有優先順序都要被固定下 來？不，不，並不是這樣的！它的意思是： § 產品的 backlog 必須存在！(你能想像的到這一點嗎？) § 要有一個產品 backlog 和一個產品負責人 (對於每個產品而 言)。 § 所有重要的 backlog 項目，應該要被設定其重要等級，不同 重要程度有不同的等級。 o 事實上，如果所有不重要的項目，有相同的評定分 數，這是不要緊的。因為目前這次的 Sprint 規劃會議 上，它們並沒有機會被提出來。 o 任何故事，只要產品負責人相信它們最終會在下一 個 Sprint 出現，那就應該有某一特定的重要程度。 o 分數只是讓我們依重要性排序。如果 A 的分數是 20， B 的分數是 100，那只是簡單說明 B 比 A 重要，並不 是代表 B 比 A 重要五倍。如果 B 的分數是 21，也是 代表同樣的意義：B 比 A 重要！ o 最好在分數之間留下一些間隔，以防之後出現另一 個故事 C，它比 A 重要，但是比 B 還不重要，可是 卻沒有分數可以使用。當然啦，你可以給 C 評定成 20.5，但是看起來有點醜陋，所以我們還是留點空隙 比較好！
  • 25.
    我們如何紀錄產品的 Backlog |17 呸！這只是對這個清單排序，你不需要亂動重要等級。 § 產品負責人應該要知道每個故事的意義(通常他是作者，但是 有時候其他人會提出一些需求，因此他需要排優先順序) 。 他並不需要知道它們是如何被實踐的，但是他需要知道為什 麼這個故事會出現在這裡。 註記： 產品負責人以外的人，可能也會增加故事到產品的 backlog 中，但是他們不能指定它有多重要，這是產品負責人才能有的權力。 他們也不能設定時間估算(time estimates)的值，這是整個團隊的權力。 我們還嘗試，或評估過其他方法： § 使用 Jira(我們的錯誤案例追蹤系統)來存放產品的 backlog。 大部分的產品負責人覺得用起來太麻煩了。但是，Excel 是 一個不錯和方便直接使用的工具。你可以容易去使用不同顏 色表示、重新安排項目、任意增加新的欄位、添加註解、和 匯進/匯出資料等等。 Google 電子表單也一樣，只不過 Google 表單是雲端版，可 以多個使用者同時編輯。 § 像 VersionOne、ScrumWorks、XPlanner 等，這些 Agile 的輔 助工具，我們還沒有嘗試過它們，不過或許以後會用吧。
  • 26.
    4我們如何產生 Sprint 計畫 Sprint規劃是非常重要的會議，應該算是 Scrum 中最重要活動(當然 啦，這是我個人的意見)。執行不好的 sprint 規劃會議，將會毀掉整 個 Sprint。 重要嗎？是的。是 Scrum 中最重要的東西嗎? 不是！回顧會議更 重要！因為運作良好的回顧會議，會幫助你修復有問題的事情。如 果其他事情都到位(好的產品 backlog，很積極的產品負責人和團隊 等等)，Sprint 規劃會議可以只關心相當瑣碎的事情。此外，迭代 不是敏捷的唯一方法 – 許多團隊用看板來取代。我甚至寫過一本 有關於它的小書：” Kanban and Scrum: Making the Most of Both” 。 http://www.infoq.com/minibooks/kanban-scrum-minibook Sprint 規劃會議的目的，是要給團隊足夠的資訊，好讓他們能在之後 幾個星期內，能不受干擾地工作，同時也是給產品負責人能對此有 充分的信心。 好吧！你可能會說這樣還是相當模糊。其實，Sprint 規劃會議會產生 出一些有用的成果： § Sprint 的目標 § 團隊成員的名單(如果他們不是 100%投入，則需要列出他們 投入的程度) § Sprint backlog (也就是在 Sprint 中所包含的故事列表) § 事前訂好的展示時間 § 對於 Scrum 的每日會議，事前訂好舉行的時間和地點 為什麼產品負責人需要參加 有時候產品負責人不願意花數個小時，和團隊一起討論 Sprint 的規 劃。“同事們，我已經列出我所想要的，我沒有時間一直呆在 Sprint 的規劃會議中”，這是相當嚴重的問題。
  • 27.
    我們如何產生 SPRINT 計畫|19 為什麼整個團隊和產品負責人都需要參加 Sprint 規劃會議，原因是 因為每個故事包含三項變數，彼此之間都有高度的關連。 範圍(scope)和重要性(importance)是由產品負責人決定的，但是估算 是由團隊決定的。在 Sprint 規劃會議期間，經由團隊和產品負責人 面對面討論，這三個變數才能逐漸調整到理想的結果。 一般來說，會議一開始產品負責人會簡述，對於 Sprint 和重要的故 事而言，他想要達成的目標是什麼。接著，從最重要的故事開始， 團隊逐一討論和評估每個故事。在他們做這事情的時候，他們必須 對範圍提出重要的問題：“刪除使用者這個故事，需不需要把所有 使用者還沒處理處理完的交易也一並刪除？”有時候答案可能會讓 團隊很吃驚，因此而讓他們調整他們的估算。 在某些狀況下，對某個故事的時間估算，可能不是產品負責人所期 待的。這可能會讓他調整這個故事的重要性，或是改變故事的範圍， 因此而導致一連串的重新估算，等等。 像這樣直接合作的形式是 Scrum 的基本，事實上也是敏捷軟體開發 的基礎。 如果產品負責人堅持，他並沒有時間去參加 Sprint 規劃會議，那該 怎麼辦？我通常會根據以下的順序，來嘗試其中一個策略： § 嘗試幫助產品負責人了解到，為什麼他的直接參與是非常關 鍵，希望能夠改變他的心意。 § 嘗試讓團隊中某個成員，志願在會議過程中，扮演產品負責 人的代理人。然後告訴產品負責人：“因為你不能參與我們 的會議，我們會讓 Jeff 在這裡當你的代理人。在會議中，他 會被充分授權，去修改故事的優先順序和範圍。我會建議你 和他在會議之前，儘可能讓你們的想法一致。如果你不喜歡
  • 28.
    20 | SCRUM和 XP 的實戰經驗 Jeff 當你的代理人，你可以換其他人，只要這個人可以全程 參加我們的會議就可以。” § 試著說服管理團隊指派一個新的產品負責人。 § 在產品負責人找到時間來參加會議之前，會先暫緩 Sprint 開 始的時間。同時，拒絕承諾任何交付項目。讓團隊每天都可 以做他們最想要做的事情。 這個章節寫得不錯！<給自己一些掌聲> 只有一件事情 – 我強烈建議把 backlog 精進(refinement)會議(評 估、故事的拆解等等)，變成一個單獨的會議，所以 sprint 規劃會 議可以更專注。在這兩個會議中，產品負責人的參與仍然是相當關 鍵的。 為什麼品質是不可被談判的 在上面那個三角形中，我刻意忽略了第四個變數： 品質。 我企圖去把品質區分成內部品質和外部品質。 • 外部品質是系統的使用者可以感覺到的，一個緩慢和不直覺 的使用者介面，便是一個很明顯的例子。 • 內部品質是指一般使用者看不到的問題，但是它會深深影響 到系統的可維護性。像系統設計的一致性、測試涵蓋度、程 式的可讀性和重構等等。 一般說來，若是一個系統內部品質很高，仍然有可能會外部品質還 是很差。但是若是內部品質差的系統，很少會有很好的外部品質。 試想，在鬆軟的沙灘上，如何建立堅固精緻的大樓。 我把外部品質也視為範圍的一部份。有時在商業的考量下，可能會 發佈一版，它的使用介面比較簡陋，並且反應速度也比較慢。不過 隨後發行一版比較乾淨的版本。我會把這些做或不做的決定權留給 產品負責人，畢竟他是負責決定範圍的人。 然而，內部品質就沒有得談了，不管在怎樣的狀況，團隊都要維護 系統的品質，這是無庸置疑的，沒有可以討價還價的，向來都是這 樣的。
  • 29.
    我們如何產生 SPRINT 計畫|21 (好吧，差不多是直到永遠) 所以我們如何區分哪些是內部品質，哪些是外部品質的問題？ 假如說，產品負責人說：“我尊重妳們所估算的 6 個故事點數，但 是如果你們能花點心思，你們一定找到一些快速解(quick-fix)的方法， 來節省一半的時間”。 哈！他想把內部品質當作一個變數。你會想說我怎麼會知道呢？因 為他要我們縮短所評估出來的時間，可是卻沒有要對縮小範圍這件 事情來“買單”。所謂“快速解”這件事會敲響你的腦中警 鐘﹒﹒﹒ 為什麼我們不允許這樣做？ 我的經驗告訴我，犧牲內部品質是一個很糟、很糟的想法。所省下 來的時間，在之後的日子會不斷為它付出代價。一旦我們允許這樣 做，後面就很難恢復品質了。 相反地，我會試圖把話題回到範圍上面來，“既然你覺得早一點達 到這個功能是很重要的，我們能不能縮小這個範圍，好讓我們能縮 短實作時間？或者我們可以簡化錯誤處理的的方式，讓完整的錯誤 處理方式變成另一個故事，讓我們之後再去處理它？或是我們降低 其它故事的優先順序，讓我們先集中精神處理這一個？” 一旦產品負責人學到內部品質是不能被討價還價的，那對於其他變 數，反而他將會處理的很好。 原則上，是的。但是實務上不見得，現在我比較務實。有時候短期 犧牲品質，可以產生很好的商業效果 – 例如，我們在下個 sprint 之後有個超大的商業展覽，或是我們只需要一個雛型來驗證使用者 行為的假設。但是在這兩個狀況下，產品負責人需要明確解釋，為 什麼我們要做這件事，並且承諾讓團隊之後回來彌補這些技術債 (有時團隊可以在產品 backlog 中，補上一個”清理”的故事，來當作 提醒)。高水準的內部品質應該是標準，異常事件應該被視為例 外。 永無止境的 Sprint 規劃會議…
  • 30.
    22 | SCRUM和 XP 的實戰經驗 在 Sprint 規劃會議中，最困難的事情是： 1) 人們不認為他們會花這麼多時間 2) ﹒﹒﹒但是他們會的！ 不用，他們不用花這麼多時間，如果你在另一個會議中對 backlog 進行精進。我見過許多團隊，每週花一個小時進行 backlog 精進， 所以 sprint 規劃會議就可以專心在，是的，sprint 的規劃！這也讓 產品負責人，在 sprint 規劃會議前，有更多機會去討論和改進產 品的 backlog，這將會使會議變得更短。 指導方針：如果 sprint 長度是一週，sprint 規劃會議正常應該不 要超過一個小時(有經驗的團隊可能更短)。如果 sprint 長度是 3 週，則是小於或等於 3 個小時。 Scrum 中每件事情都是有時間框的(time-boxed)。我喜歡它簡單、一 致的規則，我們會試圖去貫徹到底。 如果 Sprint 規劃會議時間快要用完，但是還沒有 Sprint 的目標或是 backlog 產生，那要怎麼辦呢？我們要打斷它嗎？還是要延長一個小 時嗎？或是準時結束明天再繼續？ 這種事常常一再發生，特別是新上手的團隊。那你會怎麼做？我也 不知道。但是我們的作法是什麼呢？嗯﹒﹒﹒好的，通常我會直接 打斷它，結束它。讓這個 Sprint 去承受這個沒有結果的事情。更具 體一點，我會告訴團隊和產品負責人：“會議會在十分鐘後結束， 我們還沒有一個真正的 Sprint 計畫。我們是要照已經有結論的部份 先作，還是要明天早上 8 點，再來個 4 小時的 Sprint 規劃會議？”" 你猜他們會怎麼回答﹒﹒﹒：o) 我也嘗試讓會議繼續下去，但是通常還是沒有完成什麼事情，因為 大家都太累了。如果他們在 2~8 小時內(不管你的時間長度是多少)沒 有產生還可以的 Sprint 計畫，即使再一小時他們也不會有結果。隔 天再另外安排一個會議，或許是一個還不錯的主意。但是大家已經 失去耐心，只想開始這個 Sprint，不想再花另外的時間去做歸劃。 所以我會打斷它。是的，這個 Sprint 中，大家會承受這個問題。但 是，正面來說，團隊學到非常寶貴的經驗，下次會讓 Sprint 規劃會 議更有效率。此外，如果之前他們覺得你訂下的會議時間過長，這 時候大家便不會抱怨說時間太多。
  • 31.
    我們如何產生 SPRINT 計畫|23 學習去遵守你的時間框，並且學習設定合理的時間框長度。那對會 議長度和 Sprint 長度的設定也有幫助。 我曾經見過一個團隊，他們說 ”我們嘗試過 Scrum，但很討厭它， 不想要再用它！“ 我問為什麼，他們說 ”花太多時間在會議上面！ 我們從來沒有做完任何事情”。我問哪個會議花最多時間，他們說 是 sprint 規劃會議。我問說要花多久，他們說”要兩到三天！” 每 次 sprint 要花兩到三天規劃？！怪不得他們會討厭 Scrum！他們 遺漏了時間盒的規則：先決定你願意投資多少時間，然後就堅持下 去！Scrum 就像其他工具 – 你可以用鐵鎚去建造一些東西，或是 敲碎你的拇指。不管哪一種，不要去責怪工具。 Sprint 規劃會議的議程 對於 sprint 規劃會議，若是有事前制定好的時間表，可以減少違反時 間框的風險。 這裡有一個我們曾用過的，典型的時間表： Sprint 規劃會議：13：00-17：00 (每個小時休息 10 分鐘) • 13：00 – 13：30 產品負責人會介紹 Sprint 的目標和簡述產品 的 backlog，訂定要展示的地點和時間。 • 13：30 – 15：00 團隊評估所需時間，必要時，進一步拆解 backlog 項目。有需要的話，產品負責人也更新重要性欄位的 估算。所有項目都被釐清。對於所有高重要性的項目，“如 何展示”的欄位都需要被填寫。 • 15：00 – 16：00 團隊選擇哪些故事要被放入這次 Sprint 當中。 並計算團隊的速度，來檢查工作進行的狀況。 • 16：00 – 17：00 為了每日 Scrum 會議，安排固定的時間和地 點(如果和上次不同)，並進一步把故事拆解成工作項目。 從 13:30 到 15:00 這部分，那是產品 backlog 精進(refinement)會 議 (我以前叫它 “backlog 梳理(grooming)會議” ，但後來知道在某 些文化中，梳理意味者壞事) 。把它切割成另外一個會議，嘿嘿， 你可以有較短和令人喜歡的 sprint 規劃會議。是的，有些小的調 整可能是需要，但是大部分的 backlog 精進會議應該在 sprint 規 劃會議前完成。
  • 32.
    24 | SCRUM和 XP 的實戰經驗 這個時間表並不是要完全固定不變，Scrum master 可以根據會議的進 程，來延長或是縮短某個子項目的時間。 訂定 Sprint 的長度 Sprint 規劃會議的其中一個產出，就是定出 Sprint 展示的時間。這意 味你必須決定 Sprint 的長度。 所以 Sprint 的長度要多長比較好？ 好的，短的 Sprint 會比較好。它可以讓公司更敏捷，也就是說方便 於改變方向。短的 Sprint = 短的回饋週期 = 更頻繁的交付 = 更頻繁 的客戶回饋 = 在錯誤的方向上不會花太多時間 = 學習和改進的更快 速，等等。 但是，長的 Sprint 也不錯。團隊能有更有時間累積能量，更多空間 去解決問題，進而達成 Sprint 的目標。不會被一堆 Sprint 規劃會議或 展示，忙得不可開交。 一般說來，產品負責人喜歡短的 Sprint，而程式設計師喜歡長的 Sprint。所以 Sprint 的長度是可以討論的。我們實驗了許多次，最後 總結我們最喜歡的長度： 3 個星期。大部分我們的團隊(但不是全 部)Sprint 長度都是三週。對我們來說，它短的讓我們有足夠的敏捷 性; 也長的足夠讓我們完成在 Sprint 中，所要完成的事情和所要解決 的問題。 我們得到一個結論：在剛開始時，就要做 Sprint 長度的實驗。不要 浪費太多時間去做分析，先選一個還不錯的長度，做個一兩次 Sprint， 然後再調整長度。 不過，一旦你已經決定哪個長度最適合你，之後就要長時間堅持住。 經過幾個月後的實驗，我們發現 3 個禮拜很好，所以我們就用 3 週， 進行了一段時間。有時候可能會感覺有點長，有時候可能會感覺有 點短。不過只要保持住相同的時間，就會變成大家共同的心跳節奏， 會覺得很舒服。並且對於發佈日期不會有任何爭論，每個人都知道 每三週會有一個版本。 大部份我所遇到的 Scrum 團隊(事實上，幾乎都是) ，最終是兩週
  • 33.
    我們如何產生 SPRINT 計畫|25 或三週的 sprints。只有一週幾乎是太短 (我們才剛開始 sprint，馬 上我們就要規劃展示！壓力太大了！我們無法做到可以這麼快，然 後又可以享受開發過程！)。而四周則是太長 (我們的規劃會議會是 種折磨，而我們的 sprint 老是被中斷)。這只是我的觀察。 定義 Sprint 的目標 定義 Sprint 的目標，這是每次都要做的事情。在 Sprint 規劃會議中的 某個時間點，當我問“這次 Sprint 的目標是什麼？”，大家都會一 臉茫然的看著我，產品負責人也會皺起眉頭，開始搔著下巴。 基於某種原因，要訂出 Sprint 的目標是件很困難的事。但是我發現 是值得去把它找出來。半吊子的目標也比沒有好。這個目標可能是 “賺更多的錢”，或是“完成前三件重要的故事”，或是“打動 CEO”，或是“把系統做好到可以給真正的 beta 客戶來使用”，甚 至是"增加基本後台系統的支援"等等。重要的是，它必須用商業的用 詞來表示，而不是用技術的用語來表示。這意味著需要連團隊以外 的人都能了解。 Sprint 的目標需要來回答這個基本的問題：“為什麼要進行這個 Sprint？ 為什麼我們不去放假呢？”為了要能拐騙產品負責人說出 Sprint 的目標，其中一種方法就是問他這個問題。 Sprint 的目標應該是尚未達成的。“打動 CEO”可能是不錯的目標， 但如果他已經留下深刻的印象，在這種狀況下， 即使大家回家休息， Sprint 的目標仍然可以達成。 在 Sprint 規劃過程中，或許所訂出的 Sprint 的目標看起很愚蠢，或是 很作做。但是當大家開始對於他們該做什麼感到困惑時，它經常會 被拿出來提醒大家。如果你有很多 Scrum 的團隊(想我們一樣) ，可 以把所有團隊的目標列在一個 wiki 的網頁上(或是其他系統) ，並且 把它放在一個明顯的地方，讓公司內所有人(不只是高階主管)知道公 司在做什麼，以及為什麼要這樣做。 是的。甚至 Scrum Guide 也同意這點，認為所有的 sprint 應該都 要有 sprint 的目標。我個人覺得有個 sprint 層次的目標並不重 要，但有個較高層次的目標，去涵蓋多個 sprint 或下個發佈的循 環，這可能還不錯。我只是要確定 sprint 應該不只是 ”把一堆使用
  • 34.
    26 | SCRUM和 XP 的實戰經驗 者故事解決”，否則你的團隊會覺得超級無聊。 決定在這次 Sprint 要做哪些故事 在 Sprint 規劃會議中，一個主要的活動是決定哪些故事要在這個 Sprint 中完成。更具體的說，哪些產品 backlog 中的故事，要被放到 Sprint backlog 中。 看一下上面那個圖，每個長方形代表一個故事，並且依重要性排序。 最重要的故事是放在最上面。每個長方形的大小代表故事的大小(也 就是故事時間點數的估算) 。藍色括號的高度代表團隊評估的速度， 也就是團隊認為多少故事點數，他們可以在下一個 Sprint 中完成。 在右邊的 Sprint backlog，是產品 backlog 的一個故事快照(snapshot) 。 它代表團隊承諾要在這次 Sprint 中，所要完成的故事列表。 是團隊決定多少故事要在這個 Sprint 中被完成，而不是產品負責人 或是其他人所決定的。 這會引起兩個問題： 1。 團隊如何決定哪些故事要被放到這次 Sprint 中？ 2。 產品負責人如何影響他們的決定？ 我先回答第二個問題。
  • 35.
    我們如何產生 SPRINT 計畫|27 產品負責人如何影響哪些故事要放在這次 Sprint 中？ 在 Sprint 規劃會議中，假設我們遇到以下狀況。 產品負責人很失望，故事 D 沒有被排入這次的 Sprint 中。那在 Sprint 規劃會議中，他的選擇是什麼？ 有一個選擇是他能重新設定優先順序。假如他賦予故事 D 較高的優 先順序，那團隊就不得不把它先加入 Sprint 中 (在這裡需要把故事 C 給丟掉)。 第二的選擇是他可以改變換範圍。縮小故事 A 的範圍，直到團隊認 為故事 D 可以放到這個 sprint 為止。
  • 36.
    28 | SCRUM和 XP 的實戰經驗 第三的選擇是他可以拆解故事。產品負責人可能可以決定故事 A 中 某些部分不重要，所以把故事 A 分成故事 A1 和 A2，並且賦予不同 的重要程度。 就如你所看到的，雖然產品負責人在正常的狀況下不能控制團隊所 評估出來的速度，但是他還是有很多方法，可以影響哪些故事要放 到 Sprint 裡面。 團隊如何決定哪些故事要放到這個 Sprint 中？ 我們這裡使用兩種技術： 1. 憑感覺 2. 團隊速度的計算 憑感覺來評估 § Scrum master：“嘿，大夥們，我們能在這次 Sprint 中完成 故事 A 嗎？” (指向產品 backlog 中最重要的項目) § Lisa：“嗯，當然可以，我們有三週，這只是微不足道的功 能”
  • 37.
    我們如何產生 SPRINT 計畫|29 § Scrum master：“OK，如果我們加上故事 B 呢？” (指向第 二重要的項目) § Tom 和 Lisa 一起回答：“應該沒問題” § Scrum master： “好的，那故事 A、B、C 一起呢？” § Sam (對產品負責人說)：“故事 C 需要包含一些複雜的錯誤 處理嗎？” § 產品負責人：“不，你現在可以先跳過它，只需要有一些基 本的錯誤處理。” § Sam：“那故事 C 應該沒有問題” § Scrum master：“好的，那我們加上故事 D 呢？” § Lisa： “嗯…” § Tom：“我想我們應該可以完成它” § Scrum master：“90%的信心？或是 50%？” § Lisa & Tom：“大約 90%” § Scrum master：“好的，D 也包含在裡面，如果再加上 E 呢？” § Sam：“或許吧” § Scrum master：“90%或 50%？” § Sam：“我認為差不多 50%” § Lisa：“我很懷疑” § Scrum master：“好，那先不去管它。我們要做完 A、B、C、 和 D。如果還有空的話，當然我們我們可以做完 E。但是沒 人認為它應該被算到這次裡面，所以我們會先把它排除在這 次 Sprint 計畫外，大家覺得如何？” § 所有人：“沒問題！” 對於小的團隊或是短的 Sprint 來說，憑感覺的評估方式還運作的不 錯。 利用團隊速度的計算來評估 這個技術包含兩個步驟： 1. 決定估算的速度 2. 在沒有超過估算的速度下，計算有多少故事你可以加入 速度是一種“已經完成的工作的總量”的衡量方式，這裡每個項目 是根據原始估算來進行衡量的。
  • 38.
    30 | SCRUM和 XP 的實戰經驗 在下面的圖形中，左邊是一開始估算的速度，和右邊是 Sprint 最後 實際的速度。每個長方形代表一個故事，裡面的數字代表這故事初 始的估算。 注意，這裡實際的估算是根據初始估算為基礎的，在 Sprint 過程中， 任何有關故事時間的更新都被忽略了。 我已經可以聽到你的抱怨了，“這怎麼會有用？速度的快或慢可能 取決於一大堆的因素！愚笨的程式設計師、不正確的初步估算、範 圍的改變、或是在 Sprint 期間無預警的干擾等等。” 我同意，這不是準確的數字。但是它仍然很有用，尤其是跟什麼都 沒有比的話。它可以給你一些不容懷疑的事實：“不管原因為何， 我們以為我們可以完成的，和真正我們做的完的，還是有些差別 的。” 在 Sprint 中，對於幾乎快要完成的故事，那又該如何處理？為什麼 我們不能因此加部分點數到我們的速度中？呵呵，這裡必須要強調 Scrum 的 精 神 ( 事 實 上 ， 這 也 是 敏 捷 開 發 和 精 實 生 產 (lean manufacturing) 所強調的)，那就是要全部做完，可以出貨，才算是真 正做完。事情做一半，它的速度只能算是 0 (也許還可能是負值) 。 你 可 以 參 考 Donald Reinertsen 所 寫 的 “ Managing the Design Factory”，或是 Poppendieck 的書，便可以知道為什麼會這樣說。 所以，我們是透過什麼神秘的魔力來估算速度？ 有一個非常簡單的方法去評估速度，那就是查看團隊的歷史資料。 在過去幾個 Sprint 中，他們的速度是多少？然後再假設下一個 Sprint 的速度也差不多。
  • 39.
    我們如何產生 SPRINT 計畫|31 這個技術就是有名的昨日氣象(yesterday’s weather)。團隊若要使用這 項技術，必須滿足兩個條件：團隊已經做過幾次 Sprint(所以有些統 計資料可以得到)。以及在下個 Sprint 中，用大致相同方式來開發(也 就是相同的團隊大小，相同工作狀況等等)。當然啦，並不是每次都 能如此。 另一個較複雜的方法，是去做簡單的資源計算(resource calculation)。 假設我們規劃一個由四個人組成的團隊，要去進行一個為期三週的 Sprint。其中 Lisa 將會請兩天假，Dave 只能投入 50%的時間，並且 會休一天假。所以讓我們把這些加在一起… …將會得到這個 Sprint 會有 50 個可用的人天。 警告：這部分我真的不喜歡。我真的想要把下面幾頁撕掉！但是， 如果你很好奇的話，請繼續閱讀它，我後面會解釋為什麼。 那這是我們所估出來的速度嗎？不是的，我們估算的單位是故事點 數，雖然是可差不多對應到“理想化的人天”。一個理想化的人天 是指能工作有效率，不受打擾的一天。但是這種狀況太少見了。我 們還需要進一步考慮一些事情，像是把沒有規劃到的工作進去，員 工生病不能工作等等。 所以我們的估計的速度一定小於 50，但是到底少多少呢？我們利用 了“投入程度” (focus factor)來解決這個問題。 投入程度是指能投入多少精力的估算。投入程度低，表示團隊預計 將有許多干擾，或預期自己的時間估算是樂觀的。
  • 40.
    32 | SCRUM和 XP 的實戰經驗 廢話一堆。一些神奇的數學公式。只要使用昨日氣象就好，忽 略投入程度這個沒意義的東西吧。 想要決定一個合理的投入程度，最好的方法是去看看上一次 Sprint 的狀況 (或是前幾次 Sprints 的平均值更好)。 把上次 Sprint 中，所有故事的初始估算的值的總和，就是真實速度 的值。 假設上次 Sprint 中，由 Tom、Lisa 和 Sam 三個人所組成的團隊，在 三個星期內工作了 45 個人天，一共完成 18 個故事點數。現在我們 試圖要算出下一個 Sprint 的估算速度，為了更複雜一點，有一個新 的同事 Dave 要加入這個 Sprint。把假期和新成員一起加起來，我們 在下一個 Sprint 會有 50 個人天。 所以根據上面的公式，下一個 Sprint 的估算速度是 20 個故事點數。 這意味著這個團隊，在這次的 Sprint 中，所能做的故事點數總和不 能超過 20。
  • 41.
    我們如何產生 SPRINT 計畫|33 在這個狀況下，團隊可能選了前四個故事，加起來一共 19 個故事點 數。或是選了前五個故事，加起來一共 24 個故事點數。假設他們選 了四個故事，因為最靠近 20。如果沒有保握，那就再選少一點。 因為這四個故事加起來一共 19 故事點數，所以最後他們所估算的速 度就是 19。 “昨日氣象”是一個方便使用的技術，但是需要一點常識。如果上 一個 Sprint，因為大部份的成員都生病了一周，是一個執行的很糟的 Sprint。你可以安全的假設你應該不會這麼慘，所以你可以評估下次 的 Sprint 會有較高的投入程度。如果團隊最近安裝了新的 CI (持續整 合)系統，你可能可以假設投入的程度會比較高。如果有新人加入這 次 Sprint，你需要考慮會因為要訓練他，因而減低投入程度。 只要狀況允許，你應該看看前幾個 Sprint，算出平均值，這樣會得到 更合理的估算。 但如果是全新的團隊，你沒有任何之前的統計數據，那該怎麼辦呢？ 你可以看一下其他有類似狀況的團隊，他們投入的狀況是怎樣。 如果你沒有其他團隊可以參考呢？那就隨便猜一下。好消息是你所 猜的值，只用在第一次的 Sprint。之後你就會有歷史資料可以分析， 以用來不斷地分析和改進你的投入程度和估算的速度。 我自己對於新的團隊，所使用的“預設”投入程度是 70%，因為大 部分其他團隊都能達到相同的數值。 那我們用哪一個評估的技術呢？ 上面我們提到好幾個技術–憑感覺、根據昨日氣象來做團隊速度的 計算、以及根據人日和預估的投入程度來做團隊速度的計算。 所以我們到底用哪一個？ 我們通常的是結合起來使用，這並不會花我們太多時間。 我們會檢查上個 Sprint 的投入程度和真實的速度。接著，我們會檢 查我們這次 Sprint 中所有可用的資源，並估算投入程度。然後，我 們會討論這兩次投入程度之間的差別，必要時作出適當的調整。
  • 42.
    34 | SCRUM和 XP 的實戰經驗 好的，這個痛苦部分已經結束。我從未使用投入程度，因為它很花 時間，產生出誤以為很精準的感覺，並且迫使你用理想人天的方式 來評估故事。 此外，投入程度帶來一個假設：更多人 ＝ 更快的速度，有時候這 是對的，但有時候不是。如果我們增加一個新人到這個團隊，在第 一個或第二個 sprint，這個速度通常會變慢，因為人們需要花時間 帶這個新人。如果團隊太大(像是超過 10 個人)，這個速度必定更 慢。同樣地，投入程度這個詞，意味著這個值小於 100％，團隊並 沒有全心投入，這會給管理高層一個非常誤導的訊息。 所以忽略投入程度和人天這些東西吧，只藉由計算故事點數，或是 如果你都沒作估算的話，那我們只計算完成的故事個數，看看你在 上幾個 sprint 能做多少。這樣可以大致抓出，這個 sprint 可以完 成多少個故事。如果在這個 sprint 中，你有些已知的干擾 (像是有 兩個人要去上課)，可以移除一些故事，直到你感覺可以為止。如 果你沒有太多歷史資料，則大多時間需要靠你的直覺。 以這樣的方式去進行，你的 sprint 規劃會議會變得更短，更有效 率，以及更有趣。並且，出乎意料地，你的計畫結果可能更加準 確。 一旦我們根據上次的速度和投入程度，算出這次 Sprint 該包含哪些 故事，接著我會用“憑感覺”的方法再做一次檢查。我會要求團隊 忘記之前算出來的數字，只要想像一下，是否這些這東西在一次的 Sprint 中，會太大而咬不下去。如果感覺太多了，我們就移掉一兩個 故事。反之亦然。 在這天結束以前，只要決定出哪些故事要在這個 Sprint 內完成，我 們就算達成目標。投入的程度、可使用的資源、以及評估速度的方 法，這些都是達成目標的手段。 我們為什麼要使用索引卡 大部分 Sprint 的規劃會議，會花很多時間在討論產品 backlog 中故事 的細節。要去評估它們，排定優先順序，釐清它們，以及進一步分 解它們等等。
  • 43.
    我們如何產生 SPRINT 計畫|35 那我們是怎麼做這些事情呢？ 好的，基本上，有些團隊是利用投影機，把 Excel 中的 backlog 投影 在牆上，然後有一個人(通常是產品負責人或是 Scrum master)操作鍵 盤，咭哩咕嚕講解每個故事，並要求大家進行討論。當團隊和產品 負責人討論過優先順序和故事細節後，拿著鍵盤的這個人會直接在 Excel 更新討論後的結果。 聽起來不錯吧？好的，事實上不是這樣的，大多只是在高談闊論。 更糟的是，團隊不會注意到在會議結束之前，他們都只是在高談闊 論，可能連所有故事都沒有看完過一遍！ 哦，這個痛苦…. 一個比較有效果的作法，是去建立一些索引卡，把他們放到牆壁上 (或是一張大桌子上)。 和使用電腦或是投影機比較起來，這是比較好的使用者互動方式， 因為︰ § 大家必須站起來並四處走動 => 讓大家可以較長時間的保持 清醒，並會留意會議的進行 § 每個人會感覺到有參與感 (而不是只有拿著鍵盤的那個人) § 有多個故事可以同時被編輯 § 要重新規劃優先順序變得比較容易–只要移動索引卡就可以 § 會議結束後，索引卡可以被拿出會議室，被放到牆壁上的任 務版上 (可參考後面第六章“我們怎麼撰寫 Sprint backlog”) 你可以手寫索引卡(像我們一樣)；或是利用一些簡單的腳本，從產品 backlog 中，直接來產生可被印出的索引卡。
  • 44.
    36 | SCRUM和 XP 的實戰經驗 附註–這個腳本在我的blog中可以拿到︰ http：//blog.crisp.se/henrikkniberg 最簡單去找到這個腳本的方式是去 Google “index card generator”。不要相信舊的方法還仍然可行！有些好心人士已經把 它轉到 Google 電子表單上面。任何像樣的 backlog 管理工具都有 類似的列表功能。可嘗試不同的工具，找出最合適你環境的一個。 並且確認你是在調整工具去配合你的流程，而不是相反。 重要事項︰在 Sprint 規劃會議結束後，我們的 Scrum master 會手動 更新 Excel 上的產品 backlog，以反映故事索引卡中的任何變化。是 的，這確實帶給管理者一些麻煩，但是我們考量在使用索引卡後， 所帶來 Sprint 規劃會議效率的提升，這樣的做法是完全可以接受的。 這裡有個地方要注意：“重要性”這個欄位。它和 Excel 中的產品 backlog 所記錄的重要性是一樣的。把它放到卡片上，可以方便我們 根據重要性來排序(一般我們把較重要的項目放在左邊，比較不重要 的放在右邊)。不過，一旦卡片被放到牆壁上，我們可以忽略它的重 要性評分，只要注意他在牆壁上在左在右的位置，來指出它相關的 重要性。如果產品負責人交換某兩個項目的位置，先不要去更新 Excel 上的資料，只要在會議後去更新就可以。 或者是放棄重要性這個欄位。哎呀，我已經說過了好幾次。我是不 是在重複？我是不是在重複？
  • 45.
    我們如何產生 SPRINT 計畫|37 如果把一個故事拆解成更小的任務(task)，那將會更容易評估時間了 (也更容易準確) 。事實上，我們是使用”activity”，因為在瑞典”task” 有完全不同的意義：o) 用索引卡來處理既方便又容易，你可以把團隊拆成兩個人一組，讓 他們同時拆解各一個故事。 實際上，我們在每個故事下面貼上一張便利貼，每張便利貼表示故 事中的一個任務。 我們不會把拆解出來的任務，更新到 Excel 中的產品 backlog。理由 有兩個： § 任務的拆解通常是比較反覆無常，也就是說，在 Sprint 的過 程中，它經常會改變，會不斷調整，所以若要保持和 Excel 內的產品 backlog 同步，將是一件非常麻煩的事。 § 產品負責人不需要去知道這種程度的細節。 拆解出來的任務可以和故事索引卡貼在一起，在 Sprint backlog 中直 接被使用。(參見後面第六章“我們怎麼撰寫 Sprint backlog”)
  • 46.
    38 | SCRUM和 XP 的實戰經驗 “做完”的定義 這一點是非常重要的，產品負責人和團隊必須同意，要對“做完” 有一致的定義。 非常重要！ 是所有程式碼被 check-in 就算故事做完了嗎？或是要被放到測試環 境，並被整合測試的團隊驗證過，才叫作做完嗎？有時候可能我們 使用這樣的定義：“隨時可以上線”，但有時候我們可能這樣說： “已經部署到測試的機器上，準備好要做驗收測試”。 在最開始的時候，我們曾使用詳細的的檢查清單。但現在我們則會 說：“如果測試人員說可以了，那這個故事就是做完了”然後就由 測試人員去確保，產品負責人所想要的事情，已經被團隊充分理解， 並且此項目已經"完成"到，足夠通過大家以認可的做完定義。 是的，這是有點沒有說服力。一個具體的檢查清單是有幫助的 — 只要確定它不會太長。把它視為是預定要做的，而不是像聖經一樣 供著。專注於人們可能會忘記的部分 (像是 ”更新發佈日誌”，或者 “沒有新增的技術債”，或是 ”獲得真實用戶回饋”） 我們慢慢瞭解到，並非所有故事能用相同方法來對待。“查詢用戶 表單”和“操作手冊”這兩個故事處理方式就差異很大。後者， “做完”的定義可能只是被運作團隊接受就可以。所以有時候用一 些常識就可以確認了，不必用到正式的檢查清單。 如果你經常對“做完”的定義感到困惑(就像我們一開始一樣)，你應 該在每個故事上，增加一個的欄位：“做完的定義”。 使用計畫紙牌來做時間規劃 估算是一項團體活動，每個團隊成員通常都要參加所有故事的估算， 為什麼大家都要參加呢？ § 在規劃的時候，我們通常都不知道誰要負責實作故事中的哪 個部份。
  • 47.
    我們如何產生 SPRINT 計畫|39 § 每個故事要求好幾人參加，並且要包括不同類型專長的人(使 用者介面設計、程式撰寫、測試等等) 。 § 為了要能提供一個估算值，團隊成員必須要對故事的內容， 有一定程度的了解。藉由要求每個人去估算每個項目，可確 保每個人知道每個項目是什麼。此外在 Sprint 中，也會增加 大家相互幫忙的機率。同時也增加重要的問題提早浮現的可 能性。 § 在要求每個人對一個故事評估時，我們常發現對同一個故事， 可能有兩個人的估算結果相差很大，像這樣的狀況我們應該 儘早發現，並儘早討論。 如果你要求對團隊提供一個評估的結果，通常來說最了解故事的人 會第一個發言。不過不幸的，這通常會嚴重影響其他人的估算。 這裡有一個很棒的方式可以去避免這件事 - 它叫做計畫紙牌(Planning Poker) (我記得是由 Mike Cohn 所創造出來的)。 事實上，Mike 說他是從 James Grenning 學來的。James 說他應該 是從某人身上得到一些想法。沒關係，我們都是站在巨人的肩膀 上。也許我們是一群侏儒站在彼此的肩膀上。嗯，無論如何 … - 你知道我的意思。 每個人都會拿到如上圖中的 13 張卡片， <推銷> 我們在 planningpoker.crisp.se 網站上賣這副牌。他們現在 看起來比照片中的更棒，雖然你可能可以在 Google 上找到更便宜
  • 48.
    40 | SCRUM和 XP 的實戰經驗 的。喔，在那個網站，我們還有賣其他更酷的東西，叫 Jimmy Cards，這是我的同事 Jimmy 做的（是的，我們在取名上有遇到麻 煩）快來看看吧。</推銷> 每當在估算一個故事時，每個成員選擇一張卡片，來表示他的時間 估算(以故事點數方式來表示)，並且把它的正面朝下放在桌子上。所 有的成員都放完以後，桌上的紙牌在同時掀開。這個方法要求每個 成員要自行思考，而不是依賴別人估算的結果。 如果有兩個估算之間有很大的差異，這時候團隊需要討論這之間的 差異，試圖讓大家對這故事的內容去達成共識。他們可能會做一些 任務拆解，然後再重新估算。這樣的事情會反覆進行，直到這個估 算收斂到一致。也就是所有的估算對這個故事是差不多的。 還有一件重要的事情，那就是提醒所有成員，他們是要對這個故事 中所有的工作做評估，而不是只是對“他們自己”負責的部份做估 算。測試人員不能只是估算測試的工作而已。 要注意到，這裡的數字順序不是線性的。例如在 40 和 100 之間是沒 有任何數字，為什麼會這樣呢？ 這是因為，一旦時間估算的值比較大時，很難估的很準確，這樣可 避免對於估算精確度產生錯誤的印象。例如，如果一個故事被估算 後，大約是 20 個故事點數，那它到底應該是 20，還是 18，還是 21， 這都並不重要。重要的是，我們知道它是一個很大的故事，很難被 估算的很準。所以 20 只是一個大約的估算。 那需要更準確的估算嗎？要就要把故事拆解成更小的故事，然後去 評估那些故事。 此外，你不能玩那種 5 + 2 = 7 哪種把戲。要嘛就是 5，要嘛就是 8， 沒有 7 這種事。 有些卡片比較特殊： § 0 = “這個故事已經完成了" 或是 "這個故事沒什麼，只要幾 分鐘就能搞定。” § ？ = “我一點概念都沒有，沒有主意。” § 咖啡杯 = “我已經太累了，先休息一下吧。”
  • 49.
    我們如何產生 SPRINT 計畫|41 另外一家公司想到一個更酷的撲克牌：不鬼扯的估算撲克牌。 (estimation.lunarlogic.io) 它只有三種牌： - 1 (一點) - TFB (太他媽的大) - NFC (他媽的沒有線索) 相當酷！我希望我能想到這個。我只想到咖啡杯這個東西。 釐清故事內容 當團隊會自豪地，在 Sprint 展示會議中展示一個新的功能，最糟糕 的事是產品負責人皺著眉頭，並說：“是的，看起來不錯，但是那 不是我要的。” 你如何確認產品負責人和團隊有相同的認知呢？或是團隊中每個人 對故事有相同的理解呢？嗯，你可能無法確定。但是有一些簡單的 方式，可以幫忙找出最明顯的誤解。最簡單的方式就是確保故事中， 所有的欄位都被填寫(或是更具體地說，對於那些有高優先順序，需 要在這個 Sprint 中完成的故事，都需要填寫)。 有些人稱之為 ”準備好的定義”。所以，做完的定義，是當故事完成 時的檢查清單。而準備好的定義，是當故事準備好可以被拉到 sprint 時的檢查清單。非常有用。 範例 1： 團隊和產品負責人對於 Sprint 的計畫很滿意，打算結束會議。這時 候 Scrum master 問說：“等一下，這裡有個“增加使用者”的故事 還沒有估算時間，讓我們來評估吧！經過幾次計畫紙牌投票，團隊 同意它的故事點數是 20。這時候產品負責人站起來，大聲說道： “什…什…什麼？”在經過幾分鐘的爭吵，最後發現是團隊誤解了 故事的範圍，他們認為這只是要“提供一個漂亮的使用者介面，來 增加，移除，刪除，和搜尋使用者”，但是產品負責人認為它只是 “手動透過 SQL 指令去增加使用者到資料庫中”，所以他們再評估 一次，給了這個故事 5 個故事點數。 範例 2： 團隊和產品負責人對於 Sprint 的計畫很滿意，打算結束會議。這時 候 Scrum master 問說：“等一下，這裡有個“增加使用者”的故事
  • 50.
    42 | SCRUM和 XP 的實戰經驗 還沒有說它要如何展示？”在一陣七嘴八舌之後，某個人站起來說： “嗯，首先我們登入網站，然後…”，這時候產品負責人打斷說： “登入網站？”不，不，不，這個功能並不包含在這網站裡面，應 該只要給有技術背景的管理者，一些簡單的 SQL，它就能夠執行了。 故事中"如何展示"的描述，需要(最好應該)非常精簡！ 否則你就沒辦 法準時結束 Sprint 規劃會議。基本上，它應該是非常平鋪簡單的敘 述，來描述如何手動執行最具代表的測試流程。"先做這個，然後那 個，最後再確認這個" 我發現，這種簡單的敘述，往往可以發現到，團隊對故事嚴重的誤 解。這種事早點發現會比較好，不是嗎？ 我仍然喜歡這個技巧。每當有故事很模糊時就會使用它，可以讓事 情具體化。另一種做法，是畫出低真度的草圖，或是準備驗收標準 的列表。把故事想像成一個高層次的問題敘述，而做完的定義，則 是當它完成後，看起來會長怎樣的具體範例。 把故事拆解成更小的故事 故事不應該太小或是太大(以評估的角度來看)。如果你有一堆 0.5 故 事點數的故事，你可能會是微觀管理的受害者。另一方面，若是你 有 40 故事點數的故事，則代表你有高度風險會只做完一部分的故事 而已。那對你公司是沒有價值的，並增加管理上的負擔。進一步來 說。如果你們所評估的速度是 70，可是有兩個高優先順序的故事是 40，那這個規劃就非常困難。你可能有兩種選擇：承諾不足，意味 你只選擇一個；或過度承諾，意味你選擇都做。 我發現多數大的故事可以拆解成小的故事。只要確認小的故事依然 能有商業價值即可 我們一般都確保故事在 2-8 人天內可以做完，我們的速度通常大約是 在 40-60 之間，所以我們大約在每個 Sprint 中可以完成 10 個故事左 右。有時候少到 5 個，有時候多到 15 個左右。不過這些數量都是用 索引卡來管理可以負荷的 一個 sprint 中做 5 到 15 個故事，是一個有用的準則。小於 5 個 通常表示故事太大了。而多餘 15 個，則表示團隊拉太多故事，會
  • 51.
    我們如何產生 SPRINT 計畫|43 無法完成每件事情。(或是故事太小，造成微觀管理) 把故事拆解成任務 等一下，故事和任務的區別是什麼？ 這是一個非常好的問題。 這個區別很簡單。故事是可以交付的東西，是產品負責人所關心的。 任務不是可以交付的項目，並且產品負責人也不在乎。 這裡是把一個故事拆解成更小的故事的例子： 這裡是把一個故事拆解成任務的例子： 這裡我們看到一些有趣的事情： • 新的 Scrum 團隊通常不願意花時間，事先把一堆故事拆解成 任務。有些人覺得這像是 waterfall 的方法。 • 對於了解非常清楚的故事，事前拆解或是之後拆解都是一樣 容易的。 • 這樣的拆解，通常會找出一些額外的工作，讓原先估算的時 間變長，但可以讓 Sprint 計畫更接近真實。 • 這種事先的拆解，可以讓每日的 Scrum 會議有顯著的效率 (可參考第八章 我們怎樣進行每日會議)。
  • 52.
    44 | SCRUM和 XP 的實戰經驗 • 即使這樣的拆解不夠準確，開始進行後也許馬上就要被修正， 但是以上所提到的好處還是可以獲得的。 所以，我們試圖將 Sprint 規劃會議的時間拉到夠長，以確保有時間 進行任務的拆解。如果時間不夠了，我們可能就不做了 (請看後面的 "最後的底限在哪裡")。 任務拆解是一個很好的機會，去找出之間的相依性–像是 ”我們需 要存取生產線上的日誌” 或 “我們需要 HR Jim 的幫助”–並且來找 出對付這些相依性的方法。也許是打個電話給 Jim，看看他是否能 在這個 sprint 中保留時間給我們。越早發現這些相依性，越有可 能避免讓它搞砸你的 sprint。 注意 - 我們在實踐 TDD(Test Driven Development)，也就是對於每個 故事，第一件任務就是"撰寫一個失敗的測試"，而最後一個任務是" 重構" (= 改進程式的可讀性和移除重複的地方)。 定義每日會議的時間和地點 Sprint 規劃會議有一個經常被遺忘的產出，就是"事先規劃好的每日 會議時間和地點"。第一次每日會議是非常重要的開始，每個成員會 決定要怎麼開始工作。沒有這樣，你的 sprint 將會有一個不好的開始。 我比較喜歡早上開會，但是，我必須承認，我們並沒有嘗試過在中 午或是下午，進行過每日會議。 現在我有中午或下午的每日會議，運行的還不錯。就讓團隊來決定 吧。如果不確定，就做實驗吧。雖然大部份的團隊比較喜歡早上。 在下午開每日會的缺點是： 當你早上開始工作，你必須試圖去回想， 你昨天告訴別人你今天要做什麼。 在上午開每日會的缺點是： 當你早上開始工作，你必須試圖去回想， 你昨天做了什麼，這樣才能告訴別人。 我的看法是，第一個缺點比較糟，因為重要的事是要知道你今天要 做什麼，而不是你已經做了什麼。
  • 53.
    我們如何產生 SPRINT 計畫|45 我們預設的作法是選擇一個大家都不會有意見的最早時間。通常是 9： 00，9：30 或是 10：00。最重要事情是，這是每個人都能接受的時 間。 哪裡是最後的底限 好的，現在時間已經用完了。照理說，所有事情要在 Sprint 規劃會 議中完成，如果我們時間不夠，那麼我們應該要把哪些事情砍掉呢？ 嗯，我會使用以下規則，來決定要做事情的優先順序： 順序 1： Sprint 的目標和展示的時間。這是你開始一個 Sprint 最基本 該有的東西。團隊需要有個目標，和一個結束的日期，然後他們就 可以根據產品 backlog 正確運作。是的，有點扯。你應該考慮規劃一 下明天再開一次 Sprint 規劃會議。但是如果你真的需要馬上開始 Sprint，或許這樣就可以。不過，老實說，我從來沒有試過在這麼少 資訊下開始 Sprint 的。 順序 2： 列出哪些故事是團隊接受要在這個 Sprint 中處理的。 順序 3： 填寫 Sprint 中每個故事的估算值 順序 4： 填寫 Sprint 中每個故事的"如何展示" 。 順序 5： 速度和資源計算，當作你 Sprint 計畫中的實現檢查(reality check)。包括團隊成員的清單，以及他們的承諾。(否則你就無法計 算速度)。 保持簡單，以及在較高層次，最多花五分鐘來做。詢問：”從人員 配置的角度來看，這次的 sprint 和上次的 sprint，主要不同的地 方在哪?” 如果沒有，就使用昨日氣象。如果有，就根據現狀加以 調整。 順序 6： 描述每日會議的時間和地點。它將會花點時間去決定，如 果你時間不夠用，Scrum master 可以先決定，在會議後以 mail 通知 所有人。 順序 7： 把故事拆解成任務。這個拆解也可以在每日會議上去做， 不過它會有點影響到 Sprint 進行的流程。
  • 54.
    46 | SCRUM和 XP 的實戰經驗 技術性的故事 這裡有個很複雜得問題： 技術性的故事。或者非功能性項目，或者 你想怎麼稱呼它都行。 每當某些人提到 ”非功能性需求”，我就不禁咯咯地笑。聽起來好像 這個東西不是個功能 :o) 我所指的是需要完成，但是不屬於交付項目，和任何故事沒有直接 的關連，並且不會帶給產品負責人直接的價值。 我們稱它做 "技術性的故事"。 例如： § 安裝 continuous build server o 為什麼需要完成它：因為它可以節省開發人員許多 時間，並且降低在循環結束時，大規模整合所帶來 的風險。 § 撰寫系統設計概述 o 為什麼需要完成它：因為開發人員常常忘記整體設 計的方向，因此而寫出不一致的程式碼。所以需要 有描述整體方向的文件，讓每個人都對設計有相同 的認知。 § 重構 DAO 層的程式 o 為什麼需要完成它： 因為 DAO 層的程式已經相當混 亂，每個人都因為無謂的困惑，或是 bug 浪費不少時 間。整理這些程式碼可以節省大家的時間，並且改 進系統的強健性(robustness)。 § 升級 Jira (錯誤追蹤系統) o 為什麼需要完成它：目前的版本太多 bugs，並且速 度又慢。升級後可以節省大家的時間 這些故事是正常的狀況嗎？ 或是這些任務和其他故事沒有任何關聯 嗎？ 誰要來排優先順序？ 產品負責人需要參與其中嗎？ 我們曾嘗試過許多不同的方法來處理技術性的故事。我們曾經把他 們視為第一級的(first-class)故事，就像其他故事一樣。但是這樣不好， 因為當產品負責人在排產品 backlog 的優先順序，它就好像拿蘋果和
  • 55.
    我們如何產生 SPRINT 計畫|47 橘子在比較一樣。事實上，基於某些明顯原因，技術性的故事通常 會是比較低的優先順序，因為有人可能會說： "喂，大夥們，我知道 continuous build server 是非常重要，但是我們先完成一些可以帶來收 入的功能，之後我們再來處理這些技術性的補強，好嗎？" 有些時候，產品負責人是正確的，但是，通常這只是少數狀況。我 們得到的結論是，產品負責人通常無法勝任的，去做出這方面正確 的判斷。所以我們會這樣做： 1) 試著避免技術性的故事。努力尋找一種方式，把技術性的故 事轉換成一個正常的故事，和可衡量的商業價值。這樣的方 法會幫助產品負責人，有更好的機會去做出正確的決定。 2) 如果我們不能把技術性故事轉換成一般的故事，看看是否這 項工作能夠被當作另一項故事中的某個任務。例如： "重構 DAO 層"應該可以當作"編輯使用者"這個故事中的一項任務， 因為這個故事包含到 DAO 層。 3) 如果以上兩種都不行，那就把它定義成一個技術性的故事， 並且用另一個列表來放這些故事。讓產品負責人可以看到它， 但不能編輯它。使用"投入程度"和"估算速度" 這兩個參數， 來跟產品負責人協商，從 Sprint 中偷一些時間來完成這些技 術性的故事。 我仍然認為技術性故事是一個很好的樣式(pattern)，並且常常使用 這樣的說法。較小的技術性故事可以放在日常的工作中，而較大的 故事會放到技術性的 backlog 中。讓產品負責人知道這件事，但這 個 backlog 是由團隊來管理它。團隊和產品負責人都同意這樣的準 則：”10-20% 的時間花在技術性故事上面”。不需要用投入程度或 工時報告這種精緻的追蹤機制，只要憑感覺就好。在回顧會議時詢 問，“在 sprint 中，我們大約花多少精力在技術性故事上面，那樣 的感覺對嗎？” 下面是一個例子 (這個對話類似我們之前某一個 Sprint 規劃會議中的 談話)。 § 團隊： "我們有一些內部的技術性工作需要被完成，我們要 抽出 10%的時間來處理它，也就是把投入程度從 75%降到 65%，你覺得可以嗎？" § 產品負責人： "不行，我們沒有時間"
  • 56.
    48 | SCRUM和 XP 的實戰經驗 § 團隊： "好的‥那看一下上次的 Sprint(所有人轉向看板上的 生產率草圖)。我們估算的速度是 80，但是我們只有 30，對 嗎？" § 產品負責人："相當正確，所以我們沒有時間做那些內部技 術的工作，我們需要新的功能！" § 團隊： "嗯，之所以我們速度變得這麼糟的原因，是我們花 太多時間，試圖去弄出一個穩定的版本，以供測試使用。” § 產品負責人： "嗯，然後呢？" § 團隊： "好的，如果我們不做些事情，我們的速度還會繼續 便糟下去" § 產品負責人： "嗯，接下來呢？" § 團隊： "所以，在這個 Sprint 中，我們打算大約花 10%的時 間，來建立一個 continuous build server，這樣我們就可以擺 脫整合時所帶來的痛苦。這樣接下來的每個 Sprint，我們的 速度大概會至少提高 20%左右" § 產品負責人： "哦，真的嗎？ 那為什麼上個 Sprint 我們沒有 這樣做？" § 團隊： "嗯……因為你不要我們這樣做……" § 產品負責人： "哦，嗯，好吧，這主意聽起來不錯，就這樣 做吧。" 當然，另外一種選擇是把產品負責人排除在外，或是給他一個無法 協商的投入程度。但是，沒有理由不去和產品負責人先達成共識， 就自己蠻幹。 如果產品負責人能力比較強，並且通情達理(這點，我們比較幸運)。 我會建議讓他盡可能知道所有事情，並且讓他決定所有的優先順序。 透明化也是 Scrum 的核心價值，不是嗎？ 如果你無法和產品負責人坦誠交談，討論有關於技術性故事，品質 和技術債的問題，那你有很大的問題需要解決！這個徵狀顯示出， 你刻意對產品負責人隱瞞訊息。當然啦，你不需要每次的對話都邀 請產品負責人加入，但是能這樣做是基於信任和尊重。沒有這些的 話，無論你打算建造什麼，你都不可能會成功。 錯誤追蹤系統 vs. 產品 backlog
  • 57.
    我們如何產生 SPRINT 計畫|49 這裡有一個詭異的地方，Excel 雖然是一個管理產品 backlog 的好工 具，但是你還是需要一個 bug 追蹤系統，Excel 可能不適合。我們使 用的是 Jira。 那我們如何把 Jira 上的問題帶到 Sprint 規劃會議中？ 我的意思是， 我們不能只注意故事，而忽略了這些 bugs。 我們嘗試過幾種策略： 1) 產品負責人列印出 Jira 中，最高優先順序的項目，把他們帶 到 Sprint 規劃會議中，把它們和其他故事一起貼到牆壁上(因 此，就暗地裡說明了這些錯誤，和其他故事的比較後的優先 順序為何)。 2) 產品負責人建立一些參考到 Jira 項目的故事。例如： "修理 最嚴重的後端系統報表的 bug，代碼是 Jira-124，Jira-126， 和 Jira-180"。 3) Bug 的修復被考慮當做 Sprint 以外的工作，也就是，團隊保 持較低的投入程度(例如 50%)，讓剩餘的時間來確保他們有 空去修復錯誤。所以可以單純假設，團隊在每個 Sprint 中， 會花一些時間來修復 Jira 上報告的錯誤。 4) 把產品的 backlog 放到 Jura(也就是拋棄 Excel)。把 bugs 和其 他故事同等看待。 我們還沒有結論，那一種策略對我們最好。事實上，不同團隊，不 同 Sprint，會有不同的作法。我傾向使用第一個策略，它又好又簡單。 八年後我只能同意，沒有單一最佳的做法。上面每個做法，在某些 環境下可能是很好的。保持實驗，直到你發現那個對你最好的。 Sprint 規劃會議終於結束了！ 哇啊，我從沒想過，Sprint 規劃會議這一章會是這麼的長！ 我想這 應該會反映我的想法，Sprint 規劃會議真的是 Scrum 中最重要的事。 花很多精力在這裡是對的，這樣之後的工作才會比較簡單。 或者反之亦然 – 其他的東西準備好，則 sprint 規劃會議就只是小 菜一碟。:o)
  • 58.
    50 | SCRUM和 XP 的實戰經驗 如果每個人都帶著微笑離開會議，並且隔天起來時也面帶微笑，或 是在第一次每日會議中面帶微笑，這樣 Sprint 規劃會議就是成功的。 當然，所有事情都有可能會出現問題，但是至少你不能都歸咎於 Sprint 計畫 ：o)
  • 60.
  • 61.
    我們如何產生 SPRINT 計畫|53 我們在 wiki 上也有一個"數位儀表板"，將會連結所有目前正在進行 的 Sprints。 此外，Scrum master 印出 Sprint 訊息頁，把它貼在團隊外面的牆壁上。 所以所有經過的人，都能藉由看到這個訊息頁，知道這團隊目前在 做什麼。因為這包含了每日會議和 Sprint 展示的時間和地點，每個 人知道他要去哪裡，可以得到更多訊息。 當 Sprint 接近尾聲的時候，Scrum master 會提醒所有人，有關於即將 到來的展示。 有了這個，沒有人會有藉口會說不知道你們的工作狀態。 嘿嘿，真是個好主意！我應該經常這樣做！
  • 62.
    54 | SCRUM和 XP 的實戰經驗
  • 63.
    6我們怎麼撰寫 Sprint backlogs 你們已經走了這麼遠啊？喔，幹得好。 現在我們已經完成 Sprint 規劃會議，並告訴大家我們下一個閃閃發 光的新 Sprint 是什麼。接著是時候，讓 Scrum master 建立 Sprint backlog。當 Sprint 規劃會議結束後，和第一次每日會議前，並需要 把 Sprint backlog 給建立完。 Sprint backlog 的存放方式 我們曾經嘗試過用不同格式來保存 Sprint backlog，像是 Jira，Excel 和牆壁上的任務板(taskboard)。剛開始，我們主要是使用 Excel，有 很多公開的 Excel 模板，可以用來存放 Sprint backlog，還包括可以 自動產生的 burn-down chart 等等。我可以告訴你很多我們怎樣調整 Excel 為主的 Sprint backlog。但是這裡我先不提，我也不會舉任何例 子。 代替的，我將要詳細描述，我們發現存放 Sprint backlog 最有效率的 方法 - 掛在牆上的任務板！ 是的，實體牆壁為主的任務板(又叫做 Scrum 板)是我首選工具！它 的效果是令人驚訝地強大。對於分散在各地的團隊，則是利用電子 工具來提供 Scrum 板的概念，並且在各地都用一個大的螢幕來呈 現。在每日會議時，每個人站在牆壁的螢幕前，利用 Skype (或是 其他工具)來交談。 找一面尚未使用或是充滿了沒用訊息的大牆(像是公司的 logo，舊日 的圖表，或是醜陋的塗鴉)。把它清理乾淨(如果必要的，先請求許可 這樣做)。貼上一張大的白紙(至少 2 x 2 平方公尺，大的團隊可能需 要 3 x 2 平方公尺)，然後這樣做：
  • 64.
    56 | SCRUM和 XP 的實戰經驗 你當然可以使用白板，但是多少有點浪費。如果可能，把白板省下 去劃設計的草圖，用沒有白板的牆壁來做任務板。 或者更好的是，把整面牆弄成白板，這是一個值得的投資！ 注意 - 如果你使用便利貼來記錄任務，不要忘記用真的膠帶把他們 黏好，否則你有一天會發現，所有便利貼會掉在地板上，堆成一堆。 或者買一個超級黏的便利貼，稍微有點貴，但是他們不會容易掉下 來！(不，我不是贊助者，真的)
  • 65.
    我們怎麼撰寫 SPRINT BACKLOGS| 57 如何讓任務板發揮作用 當然，你可以加上許多欄位，像是 "等待去做整合測試"，或是 "已取 消"等等。但是，在你把事情變複雜之前，多想一下，這些增加的欄 位是否真的需要？ 我發現對於這類事情，簡單是極端有用的。所以當不做會真的很不 好時，我才會增加這些額外的複雜度進來。
  • 66.
    58 | SCRUM和 XP 的實戰經驗 範例 1 – 在每日會議結束後 在每日會議結束後，任務板可能會變成這樣： 你可能會看到，有三個任務被放到"checked out"欄位中，也就是，團 隊今天將會處理這些項目。 有時候，對於比較大的團隊，任務可能會一直停在"checked out"狀態 中，因為已經沒有人記得，是誰要負責這個項目。如果這種狀況一 再發生，他們通常會導入這樣的規則，在每個 checked out 的任務上， 標上是誰負責這個項目。 現在幾乎所有團隊都使用替身。每個團隊成員挑選他們的替身 (像 是南方四賤客或是其他)，印出來，把它們放在磁鐵上面。這是很 棒的方式可以知道誰正在做什麼。並且，如果每個人只有兩個磁 鐵，間接限制同時處理的工作數目，和避免多工。“真他媽的見鬼 了，我用完了磁鐵！” 是的，所以停止做新的任務，把正在做的任 務給完成！
  • 67.
    我們怎麼撰寫 SPRINT BACKLOGS| 59 範例 2 – 在幾天之後 在幾天之後，任務板可能看起來像這樣： 你可以看到我們已經完成"deposit"這個故事(也就是，它已經被 checked in 到原始碼資料庫，被測試過，和重構過等等) 這 migration tool 只完成了一部份，"back office login"已經開始，"back office user admin"還沒開始。 你可以看到右下角，我們已經有三個未計畫到的項目。當你在進行 Sprint 回顧會議，它非常有用，可以幫助你記住有過這些事。
  • 68.
    60 | SCRUM和 XP 的實戰經驗 這裡有一個真實 Sprint backlog 的例子，這個例子已經接近 Sprint 的 尾聲了。在 Sprint 的過程中，這個表變得有點亂，但是還好，因為 這樣的時間不長。每次新的 Sprint 開始，我們會建立一個全新，乾 淨的 Sprint backlog。
  • 69.
    我們怎麼撰寫 SPRINT BACKLOGS| 61 燃燒圖如何運作 讓我們放大燃燒圖： 這張圖表可以告訴我們： § 在 Sprint 的第一天 ，8 月 1 日，團隊評估大約有 70 個故事點 數的工作要完成。這就是實際上整個 Sprint 的估算速度。 § 在 Sprint 的第十六天，團隊評估大約剩 15 個故事點數的工作 要完成。虛線顯示出他們目前進度大約是在控制中，也就是， 以這樣的速度，他們在 Sprint 結束前，會完成每件事情。 我們沒有把週末放到 X 軸上，因為很少人會在週末工作。我們曾經 把週末放進去，但這將使得燃燒圖看起來很奇怪，因為在週末都是 平的，看起來會好像是一個危險的徵兆。 Scrum 最初是被設計給團隊進行一個月的 sprint，並且使用 Excel 來追蹤任務的。在那個情形下，對於我們怎麼做事，燃燒圖是一個 非常有用的視覺化總結。現在，雖然大部份的團隊採用較短的 sprint，並且有更好的視覺化 Scrum 板。因此，他們越來越多人完 全忽略了燃燒圖，因為只需要看一眼，他們就得到他們想要的。試 著忽略燃燒圖，看看你會失去什麼！
  • 70.
    62 | SCRUM和 XP 的實戰經驗 任務板上的警訊 在任務板上快速瀏覽一下，應該就可以知道，目前 Sprint 進行的狀 況如何。Scrum master 要負責確認，團隊會對這些警訊採取行動：
  • 71.
  • 72.
    64 | SCRUM和 XP 的實戰經驗 嘿，要如何追蹤？！ 在這種狀況下，如果你需要可追蹤性，我所能提供的最佳可追蹤性 的方法，就是每天對任務板拍一張數位照片。我有時候這樣做，但 是我從來沒有用到這些照片。 如果可追蹤性對你是非常重要，那任務板可能不適合你。 但是我會建議你去評估一下，詳細的 Sprint 可追蹤性，對你的實際 的價值是什麼。一旦 Sprint 完成，可以運作的程式碼被交付，文件 也被 checked in。那還有人會關心有多少故事，在 Sprint 的第五天被 完成？ 又有誰會真的關心"為 Deposit 實作測試先行"這個故事，原先 估算的時間是多少？ 我仍然覺得可追溯性被過度高估，有些工具有提供這類型的資訊， 但是基本上沒有人用它。你的程式碼版本控制系統，就可以提供大 部份你需要的資訊。(真他媽的見鬼了？誰做了這個修改？！)。規 定一些公約，像是增加故事 ID 到你提交的註解中，這樣在大多的 狀況下，你就可以有足夠的可追溯性。 用天數來評估 vs. 用小時來評估 在大部分有關 Scrum 的書籍或是文章，你會看到任務大部分是用小 時來做時間的評估的。我們曾經也這樣做過。我們一般的作法是： 一個有效的人天 = 大約是 6 個人時(man-hours)。 現在我們已經不這樣做，至少在我們大部分的團隊已經是這樣，原 因如下： § 人時的評估太過精細了，這會導致很多 1~2 小時的任務，因 而引發微觀管理(micromanagement)。 § 通常結果證明是，人們的思考始以人天為單位，只是把它乘 以 6 得到了人時。"嗯……這個任務需要花大概一天。哦， 我必須要寫小時數，那我寫 6 小時就好了"。 § 兩個不同單位會導致混亂，"這是使用人天，還是人時評估 的呢？"。 所以我們現在使用人天，當做所有時間估算的單位(雖然我們叫它故 事點數)。我們最小的值是 0.5，也就是，只要任何任務小於 0.5，要
  • 73.
    我們怎麼撰寫 SPRINT BACKLOGS| 65 嘛不把它移掉，要不然就是把它和其它任務合在一起，或者就是給 它 0.5 的估算值(稍微超過估算不會有太大的影響)。這樣比較單純， 比較好。 可以更簡單：完全跳過任務評估！大部份的團隊最終將學習如何將 工作拆解成，大約是一天或兩天的任務。如果你可以做到那樣，你 不需要受到評估任務的干擾，可以排除很多浪費。燃燒圖仍然有用 (如果你一定要的話)–在那種狀況下，只要數有多少任務，而不用 去加總時數。
  • 74.
  • 75.
    我們如何安排團隊的座位和空間| 67 這個"設計牆"只是大的白板，它包含大部分重要的設計草圖，還有一 些印出來的最重要的設計文件(循序圖(sequence charts)，GUI的原型， 領域模型(domain models)等等)。 上圖：每日會議將發生在上述角落。 嗯……這個燃燒圖看起來太好，曲線看起來太直。但是團隊堅持說 它是反映真實的狀況 ：o) 邪惡的教練提供了假的燃燒圖直尺，對於高度失控的環境來說非常 方便。:o) http://blog.crisp.se/2013/02/15/evil-coach/fake-burndown-ruler
  • 76.
    68 | SCRUM和 XP 的實戰經驗 讓團隊坐在一起！ 在安排座位和桌椅佈置時，有一件事情再怎麼強調也不為過。 讓團隊坐在一起！ 說的更清楚一點，我所說的就是 讓團隊坐在一起！ 經過八年幫助其他公司導入 Scrum，我只想補充: 讓團隊坐在一起！ 大家都懶得動，至少我工作的地方是這樣。他們不要去收拾他們的 東西，拔下電腦插座，把所有東西搬到新的座位，再插上電腦電源。 當距離越短，他們越懶得去搬。"拜託，老闆，搬這這 5 公尺的作用 是什麼？" 然而，為了建立有效率的 Scrum 團隊，沒有其他選擇。就是要團隊 坐在一起。即使你必須親自威脅每個人，幫他們搬他們的裝備，清 除他們的咖啡污漬，也要搬在一起。如果空間不夠，那就創造空間。 就算你必須把團隊放到地下室，也要去做。把桌子搬在一起，賄賂 辦公室管理員，竭盡所能，只要團隊能在一起。 一旦團隊坐在一起，好處就馬上出現。只要一個 Sprint 完後，團隊 會同意搬在一起是一個好的主意(從我個人經驗來看，你的團隊有可 能因為太固執，而不承認這一點)。 現在，"坐在一起"是代表什麼意思？ 桌子應該要怎麼擺？ 好的，我 沒有太多意見怎樣擺最好。即使我有，我會假設大多數的團隊沒有 這麼有錢，可以決定桌子可以怎麼擺。通常會有一些空間上的限制 - 鄰近的團隊，廁所的門，在房間中大型的自動販賣機，等等。 "坐在一起"代表： • 互相看到： 團隊中所有人都能彼此交談，不需要大聲喊叫， 或是離開座位。
  • 77.
    我們如何安排團隊的座位和空間| 69 • 互相聽到：所有人都可以看到彼此，看到任務版。不需要靠 的太近也能夠看到上面的內容，至少可以看到大概的樣子。 •隔離： 如果你的團隊突然站起來，會自動地進行熱烈的設計 討論。沒有團隊以外的人會被打擾到，反之亦然。 "隔離"並不是意味著團隊需要被完全的分隔起來。在一個隔間式的辦 公環境中，只要團隊有他自己的隔間，並且夠大，可以去屏障大部 份外面的噪音，那這樣就足夠了。 如果你是一個分散式的團隊呢？ 好的，那就沒那麼幸運了。可以用 一些高科技工具來幫你降低傷害 - 視訊會議，網路攝影機(Webcams)， 桌面分享工具(desktop sharing tools)等等。 讓產品負責人坐在隔壁間 產品負責人應該坐的離團隊很近，所以團隊可以走過去問問題，產 品負責人也可以走過來看看任務版。但是他不應該和團隊坐在一起。 為什麼呢？ 因為他可能無法控制自己，去管一些更進一步的細節， 導致團隊無法"凝結"的很好(也就是，無法達到合作無間，自我管理， 有超高生產力的狀態)。 老實說，這是我自己的猜測。我並沒有實際遇到過，產品負責人和 團隊坐在一起的狀況，所以我沒有實際根據去說，那是一個不好的 主意，只是個人直覺和聽別的 Scrum master 的訴說。 好的，你猜怎樣。我錯了，大錯特錯。我看過最棒的團隊，是產品 負責人是坐在一起的。如果產品負責人坐太遠的話，團隊會遇到很 多問題，會比坐太近還要麻煩許多。然而，產品負責人需要平衡和 團隊與利害關係人相處的時間，所以他不需要把所有時間花在團隊 身上。但是，一般而言，和團隊越近越好。 讓經理和教練坐在隔壁間 這時候，對我來說有點困難去提到這件事，因為我既是經理，又是 教練… 我的職責是盡可能和團隊緊密工作，我建立數個團隊，在團隊之間 切換，和成員搭檔編程(pair programmed)，培訓 Scrum master，組織
  • 78.
    70 | SCRUM和 XP 的實戰經驗 Sprint 規劃會議，等等。事後，大部分的人認為這是件好事，因為我 在敏捷軟體開發方面很有經驗。 但是，另一方面，我同時(這時星際大戰中，黑武士出場的音樂響起) 也是開發團隊的主管，在行政上是經理的角色。也就是說，每當我 來到團隊時，自主性會自動降低。"好討厭，老闆來了，他可能又很 多意見，是有關於我們應該做什麼，或是誰應該做什麼，讓他去說 吧" 我的觀點是：如果你是 Scrum 的教練(可能也是經理)，就應該盡可能 貼近團隊。但是只是有限的一段時間，之後就離開，讓團隊凝聚在 一起和自我管理。每隔一段時間(不要太頻繁)，藉由參加 Sprint 展示 來查看團隊的狀況，看看任務板，參加他們每天早上的每日會議。 如果你看到可以改進的地方，把 Scrum master 叫到一旁去指導他， 記得不是在團隊的面前這樣做。如果你的團隊非常相信你，不會看 到你就不說話，那就去參加他們的 Sprint 回顧會議，這是另外一個 好的方法。(請參考後面的章節"我們怎樣做 Sprint 的回顧") 對於運作良好的 Scrum 團隊，確認他們可以得到一切他們所需要的 東西，然後就可以讓他們自行處理 (除了 Sprint 展示會議除外)。 對於在敏捷環境下的經理們，上面的最後一句話，仍然是我能說的 最佳綜合建議。有一位好的經理是關鍵的成功因素。但是身為一位 經理，你應該試著讓你自己是多餘的。你可能不會因為那樣做而成 功，但是在嘗試的過程，會把你推向對的方向。多詢問 ”團隊需要 什麼，才能讓他們自管理？”，而非 ”我如何可以管理這個團隊？” 這可能需要有透明度，明確的目的，有趣和激勵的工作環境，適當 的保護，以及遇到問題時可以向上反映的管道。
  • 80.
    8我們怎麼進行每日會議 我們每日會議都按照書中進行。它們每天會在同一個地方，同一時 間進行。在剛開始的時候，我們都是在一間單獨的房間中，舉行 Sprint 規劃會議(在那個時候，我們還使用電子板的 Sprintbacklogs)。 然而，現在我們都在任務板前面舉行每日會議，沒有什麼能比它有 更好的效果。 我們通常都是站著舉行會議，因為它可降低會議時間超過 15 分鐘的 風險。 每日會議真的很重要！它是一個時機來讓大部分的同步訊息發生， 以及讓團隊提出重要的障礙。無疑地，如果做得不好，它可能會真 的真的很無聊 – 一堆人在那邊閒聊，可是卻沒人真的在聽。 Scrum Guide 最近更新了這三個問題，去反擊這樣狀況： - 我昨天做了什麼，來幫助我們團隊去達成這個 sprint 的目標？ - 我今天打算做什麼，好幫助我們團隊去達成這個 sprint 的目標？ - 我發現了什麼障礙，會阻止我或是團隊去達成這個 sprint 的目標？ 注意把重點放在 sprint 的目標，團隊所共享的高層次議題！如果 你的每日會議開始感到單調時，嘗試詢問以下的問題或是 Dan North 版本的問題：“我們 ’今天’ 最棒的事情是什麼？”，然後以開 放方式進行討論。無論你怎麼做，不要讓每日會議很無聊。保持不 斷嘗試！ 我們如何更新任務板 我們通常在每日會議中更新任務板。每一個人都會說明他昨天做了 什麼，今天要做什麼，然後一邊移動任務板上的便利貼。如果他有 提到一個沒有規劃到的項目，他會加一張便利貼到任務版上面。如 果他需要更新時間的估算，他會寫新的時間到便利貼上面，然後槓
  • 81.
    我們怎麼進行每日會議| 73 掉舊的。有時候 Scrummaster 會在大家說話的時候，同時更新這些 便利貼。 有些團隊會規定，每個人需要在會議之前更新任務板上的東西。這 個方法也不錯。只要決定好規則後，堅持執行就可以。 在每日會議中，許多團隊花了很多時間在更新便利貼上的數字。真 浪費！每日會議的目的是在取得同步，所以我發現最好的方式是 ” 即時” 更新白板(也就是，在事情發生時更新)，並且完全忽略任務 的估算。以這種方式進行，每日會議就變成是真的在溝通，而不是 管理或監督。 不管你用什麼形式存放你的 Sprint backlog，試圖讓整個團隊，一起 保持 Sprint backlog 的內容是及時更新的。我們曾試過讓 Scrum master 扮演 Sprint backlog 的唯一維護者，因此他必須每天詢問大家， 各自剩餘的時間估算為何。這個方法的缺點是： § Scrum master 花太多時間在管理工作上，而不是對團隊提供 支持，和消除他們障礙。 § 團隊的成員不再關心 Sprint backlog 的狀態，所以他們不再知 道 Sprint 的狀態。缺少回饋，將會降低整體的敏捷性和團隊 專注的程度。 如果 Sprint backlog 設計的很好，團隊中的每個人，都應該很容易去 更新它。 在每日會議一結束後，要有人算出所有剩餘時間估算的總和，然後 在 Sprint 的燃燒圖上畫上一個新的點。 處理遲到的傢伙 有些團隊會準備一個存錢筒。當你遲到時，即使只有遲到一分鐘， 你也要投錢到筒子裡頭，沒有人會關心為什麼。如果你在會議前打 電話，說你會晚一點到，你也是要投錢。
  • 82.
    74 | SCRUM和 XP 的實戰經驗 除非你有很好的理由，像是預約去看醫生，或是你自己的婚禮等等， 否則是無法倖免。 在筒中的錢，可以被使用在團隊中的一些活動，像是我們會在遊戲 之夜，用這些錢來買些漢堡吃 ：o) 這個方法效果不錯，但是，只有在有人常常遲到的團隊才需要，有 些團隊不需要這樣的東西。 團隊使用各種方式來互相取笑，好讓大家可以準時出現 (如果需要 的話)。只要確定是團隊他們自己想出來的，而不是強迫他們用上 面或是外面人的方法。要確定它很有趣。在某個團隊，遲到的人必 須唱一首很白癡的歌。如果你遲到第二次，你必須還要加上跳 舞。:o) 處理"我不知道今天要做什麼"的狀況 有時候，有人會說"昨天我做了這個那個，但是今天不知道該做什麼"， 這種狀況並不常見。那現在該怎麼辦？ 讓我們假設 Joe 和 Lisa 兩個人都不知道今天要做什麼。 如果我是 Scrum master，我會讓下個人繼續講下去，但是會先記起來 哪個人沒有事做。在每個人都說完後，我會和團隊從上到下檢視一 下任務板，確認每件事已經同步，也就是確保每個人都知道，每個 項目所代表的意思是什麼，等等。然後我會請人加上更多的便利貼。 接下來我會跟那些覺得沒事做的人說： "現在我們已經看過任務板了， 你們是否會對今天要做的事有些概念呢？"，我希望他們會知道了。 如果還沒，我會考慮是否有採用搭檔編程(pair programming)的機會。 假設 Niklas 將要去實做後端系統的使用者管理系統的 GUI。我會有 禮貌地建議，Joe 和 Lisa 可能可以和 Niklas 去撘檔編程。通常這都會 有效果。 要是這樣還不行，應該會採取下面的技巧。 Scrum master："好的，誰要展示有 Beta 水準的這個版本給我們看一 下？" (假設這是 Sprint 的目標)
  • 83.
    我們怎麼進行每日會議| 75 團隊：感到困惑，並保持沉默 Scrum master："我們還沒有做完嗎？" 團隊："嗯……還沒" Scrum master："哦，該死，為什麼還沒？ 還剩什麼？" 團隊："我們還沒有一個測試的伺服器，此外建構的腳本(build script) 也有問題" Scrum master："哈" (在任務的牆壁上加上兩張便利貼) "Joe 和 Lisa， 你們今天可以幫我們什麼呢？" Joe："哦……我想我可以試著去找找，有沒有測試的伺服器"。 Lisa："……我可以試著去解決建構腳本的問題"。 如果你很幸運的話，會有某個人真的展示出，你所要求的 beta 水準 的版本給你看，那真的是太好了，你已經達到 Sprint 的目標。但是 如果你的 Sprint 只進行到一半呢？ 很簡單，先恭喜團隊做的不錯。 然後從任務板中右下角的"next"區域，找出一到兩個故事，放到左邊 "not checked out"的欄位中。然後重新開始每日會議，通知產品負責 人，你已經加了一些項目到這個 Sprint 中。 或是利用時間去償還一些技術債，或者是做些技術上的探索。並確 保產品負責人在這個訊息迴圈中。 但是如果團隊還沒有達到目標，Joe 和 Lisa 仍然拒絕去做些有用的工 作。我通常會考慮以下幾種方法(沒有一種是令人愉快的，但是已經 是最後的手段了)： • 羞辱的方法："如果你不知道你怎樣可以幫助團隊，我建議 你回家去吧，或是看些書，或是怎樣都行。要不坐在旁邊， 等到有人需要幫忙就過去幫忙"。 • 保守的方法：隨便指派一個任務給他們。 • 同事間施壓的方法：告訴他們： "Joe 和 Lisa，放輕鬆來選擇， 我們大家站在這裡等你，直到你們找出可以幫助我們達成目 標的工作為止" • 奴役的方法："你們可以幫忙做一些雜役,像是倒咖啡，幫人 按摩，清理垃圾，煮午餐，或是一些我們可能要你們幫忙的 事"(你可能很驚訝，一聽到這裡，Joe 和 Lisa 在一瞬間就找 出要做的技術性任務：o)
  • 84.
    76 | SCRUM和 XP 的實戰經驗 如果有人經常逼得你這樣做，你應該要把她叫到一旁，給他一些指 導。如果這個問題持續存在，你需要評估一下，是否這個人對你的 團隊很重要。 如果他不是太重要，試圖把他從你的團隊中移走。 如果他很重要，就試圖讓他和別人搭檔，讓那個人當他的"牧羊者"。 Joe 可能是一個優秀的開發人員和架構師，只是他比較需要讓其他人 告訴他該做什麼。好的，給 Niklas 當 Joe 的牧羊者，或者你自己來 做這件事。如果 Joe 在你的團隊是非常重要，那這樣做非常值得。 我們有過這樣的例子，多少有點效果。 對於剛接觸 Scrum 的團隊，”我不知道今天要做什麼” 是常見的典 型問題，因為過去是由其他人為他們決定事情。當他們對於自組織 有更多經驗後，這個問題就會消失。人們會學習去找出要做什麼。 所以如果你是一個 Scrum master，並且發現你常常依賴上面那些 方法，你應該考慮後退一步。儘管你有想幫忙的意圖，但你可能會 是阻礙團隊學習去變成自組織的最大絆腳石！
  • 85.
    9我們怎樣進行 Sprint 的展示 Sprint展示(有些叫它 Sprint review)是 Scrum 中重要的一部份，但是 人們都低估它。 "哦！ 我們真的需要去展示嗎？ 沒有啥好東西可以展示" "我們沒有時間去準備&%$#的展示" "我沒有時間去參加其他團隊的展示！" 我無法了解為什麼我會叫它 “sprint 展示(demo)”！我倒底在想什 麼？官方名字是叫做”sprint 檢視(review)會議” ，這是比較好的名 字。展示意味著單向溝通 (”來這裡一下，這是我們所建造出來 的”)。而檢視則意味這雙向溝通 (”這是我們所建造出來的，你認為 如何？”)。Sprint 檢視是有關於回饋的事情！所以當你下面看到”展 示”時，把它想成”檢視”，好嗎？ 為什麼我們堅持所有的 Sprint 在結束前都要展示 一次做得不錯的展示，即使可能看起來很一般，也會帶來深遠的影 響。 § 團隊因所完成的結果而得到認可，他們會感覺很棒。 § 其他人可以知道你們團隊現在正在做什麼。 § 這個展示可以吸引關係利害人給予重要的回饋。 § 展示是(或應該是)一個社交的活動，不同團隊可以相互交流， 和討論各自的工作。這是有價值的。 § 有展示會促使團隊真正完成一些東西，並發行它(即使是在測 試環境中)。沒有展示，我們總是會得到一個 99%完成的東 西。有了展示，或許我們完成的東西變少，但是這些東西是 真正的完成。這(以我們的例子來說)會比得到一堆看似完成 的東西好的多，而且他們將會影響到下一個 Sprint 的進行。
  • 86.
    78 | SCRUM和 XP 的實戰經驗 如果團隊是有點被半強迫去進行展示，尤其他們沒有太多東西是真 正的完成，這樣的展示將會令人感到很尷尬。團隊在展示過程中， 可能會結結巴巴的，之後的掌聲也可能是稀稀落落的。人們會對這 團隊感到有點難過，也有人感到不太高興，因為他們浪費時間在一 場很爛的展示上面。 這會傷害到一些人，但是就像良藥苦口一樣。下一次的 Sprint，團隊 會真的試圖去完成一些事情。他們會感覺 "好的，也許下個 Sprint 我 們只能展示 2 件事情，而不是 5 件。但是這些該死的功能一定會正 常運作！" 團隊知道，無論如何他們必須展示。讓一些真正有用的東 西被展示的機會，會變得大的很多。這種情況我已經看過很多次了。 對於多個團隊的環境下，這是十分重要的。每隔固定一段時間，被 邀請的每個人都需要看看產品的整合狀況。總是會有些整合上的問 題，但是你越早發現它們，就越容易被解決。自組織的團隊總是利 用透明度和回饋迴圈在運行，而一個運作良好的 sprint 檢視會 議，則提供了以上兩個機制在裡面。 Sprint 展示的檢查清單 • 確保你已清楚地描述 Sprint 的目標。在展示中，如果有人對 你的產品一無所知，花幾分鐘簡介一下產品。 • 不要花太多時間去準備展示，特別不要去做些花俏的展示。 把那些玩意放到一邊，只要集中精神在真正可運作的程式碼 上面。 • 保持快速的結奏，也就是集中精神，讓簡報能保持快結奏， 而不是好看。 • 讓展示是保持在商業導向的層次，不要有太多技術性的細節。 著重於"我們做了什麼"，而不是"我們如何做到它"。 • 如果可能，讓觀眾自己試用一下產品。 • 不要展示一堆小的錯誤修復，或是微不足道的功能。可以提 到他們，但不用展示他們，因為通常會花很多時間，並且讓 大家不能專注於更重要的故事中。 有些團隊進行兩種檢視：短暫的公開檢視，目標瞄準外在的利害關 係人。之後再接著內部的檢視，來看更多細節，像是關鍵的挑戰和 技術決策等等。這是很好的做法，可以讓知識在團隊間散播，又避 免利害關係人聽到他們不在乎的技術細節。
  • 87.
    我們如何做 SPRINT 回顧|79 處理"無法展示"的項目 團隊成員： "我不打算去展示這個項目，因為它無法被展示出來。這 個故事是'改進延展性，因此系統可以處理 10,000 同時上線的使用者' 我拼了老命也無法讓 10,000 使用者同時上線來展示，不是嗎？" Scrum master： "那你已經做完了嗎？" 團隊成員： "是的，當然"。 Scrum master： "那你怎麼知道？" 團隊成員： "我在效能測試環境中架設好系統，啟動 8 個負載伺服器， 對系統同時發出請求 "。 Scrum master： "但是你有任何指標能顯示出系統可以處理 10,000 使用者？"。 團隊成員： "嗯，這個測試機器挺爛的，但是在我的測試過程中，它 還是可以處理到 50,000 使用者同時上線"。 Scrum master： "你怎麼知道？" 團隊成員(快失去耐性)： "好的，我有份報告，你可以自己看啊，上 面有如何設定這個測試，以及多少請求被發出！" Scrum master： "嗯，太棒了，這就是你的"展示"啊。只要給大家看 這份報告就可以了，這比什麼都沒有強，對嗎？"。 團隊成員： "哦，這樣就夠了嗎？ 但是這報告有點難看，需要去美 化一下"。 Scrum master： OK，"好的，但不要花太多時間。不需要很好看， 只要能表達訊息就可以"
  • 88.
    10我們如何做 Sprint 回顧 為什麼我們堅持所有團隊都要做回顧會議呢？ 有關回顧最重要的事情，就是確保回顧會發生。 基於某種原因，團隊傾向不太願意去做回顧。沒有些溫柔的刺激， 我們大部分的團隊通常會跳過回顧，然後移向下一個Sprint。或許這 是瑞典文化的問題，但我不太確定。 不是的，我在許多國家都看到相同狀況，所以那是人的本性，我們 總是想要跳到下一件事情。諷刺的是，你越有壓力，你越可能跳過 回顧會議。但是，就是因為你越有壓力，你越迫切需要回顧會議！ 這有點像是 ”我急著想把樹木砍倒，所以我沒有時間停下來把斧頭 磨利！” 所以 Scrum Master 真的要堅持進行回顧會議！它不會要 花太久時間。對於一個兩週的 sprint，回顧會議固定的長度是一小 時。但是每隔幾個月，你可以進行比較長的回顧會議 (半天或整 天)，用來處理比較棘手的問題。 不過，每個人看起來是同意，回顧是極端有用的。事實上，我想說 的回顧是 Scrum 中第二重要的事件(最重要的是 Sprint 規劃會議)，因 為這是你去改進的最佳機會！ 沒錯。這是為什麼回顧會議是 Scrum 頭號最重要的事情，而不是 第二重要的事！ 當然，你不用需要回顧會議去得到好的點子，你在家裡的洗澡盆中 就能想到！ 但是團隊能接受你的想法嗎？ 可能吧！ 但是如果這想法 "來自團隊"，也就是在回顧會議上，每個人都可以貢獻和討論一些主 意，這樣得到的想法會讓大家容易接受。 如果沒有回顧，你會發現團隊，會一而再的，再犯同樣的錯誤。
  • 89.
    我們如何做 SPRINT 回顧|81 我們如何組織回顧會議 或許大家的做法會稍有不同，但是我們通常會這樣做： • 根據討論的範圍有多少，我們會安排 1-3 個小時。 • 參與者： 產品負責人，整個團隊，和我自己。 • 我們會到一個封閉的房間，或是有舒適的沙發的角落，或屋 頂庭院，或是類似的地方。只要我們能夠不受干擾的討論就 好。 • 我們通常不會在團隊的房間內做回顧，因為人們的注意力很 容易被分散。 • 會指定某個人當秘書。 • Scrum master 會展示 Sprint backlog，在團隊的幫助下，對 Sprint 做出總結。包括重要的事件或是決定等等。 • 我們會輪流發言。每個成員在不被打斷的狀況下，會有機會 說出他認為什麼是好的，什麼是可以做的更好，以及什麼是 下個 Sprint 可以做的不一樣的。 • 我們會檢視預估和實際的速度。如果有太大的差異，我們會 分析為什麼。 • 當時間快要結束的時候，Scrum master 會試圖去總結出具體 的建議，有關於下次 Sprint 中我們什麼地方可以做的更好。 我們的回顧會議一般來說不會太結構化，太嚴謹。但是潛在的主題 都是一樣的： "下次 Sprint 中，什麼事情我們能做的更好？"。 這裡是我們最近一次回顧會議的白板：
  • 90.
    82 | SCRUM和 XP 的實戰經驗 這裡有三行： § Good： 假如我們再做一次相同的 Sprint，我們哪些事情可以 保持相同的作法。 § Could have done better： 假如我們再做一次相同的 Sprint， 我們哪些事情的做法可以改變。 § Improvements： 有關未來我們如何改進的具體方法。 所以第一行和第二行是回顧過去，而第三行是展望未來。 在團隊集思廣益，列出所有的想法後，他們會用"計點投摽"去決定， 哪些改進是下個 Sprint 需要注重的。每個團隊成員會有三塊小磁鐵， 可用來決定在下一個 Sprint 中，要改進項目的優先順序。每個團隊 成可以自行決定磁鐵要放在哪個項目，或是三個都放在同一個項目 上也可以。 根據投票的結果，選出 5 個要著重的項目。在下一個回顧會議中， 他們會追蹤這些項目的改進狀況。。 重要的是，不要過度貪多。在每個 Sprint 中，只要著重幾個改進項 目就可以了。 有很多有趣的方式，可來進行回顧會議。有各式各樣的形式，所以 會議不該了無新意。你可以在 Agile Retrospectives 一書中發現很 多想法。或者試試 Retromat，它是一個回顧方式的隨機產生器， 也很有趣。(www.plans-for-retrospectives.com)。 :o) 然而，我注意到，對於大多數的案例，我持續使用上述簡單的方
  • 91.
    我們如何做 SPRINT 回顧|83 式，仍然可以運作的很好。或者以更簡單的方法，花二十分鐘的休 息時間，進行兩個討論主題：“什麼要保持下去” 和 “什麼應該改 變” 。雖然簡單，但是總比沒有好！ 在團隊間散播所學到的教訓 在 Sprint 回顧會議中，所得的資訊通常是極度有價值的。團隊很難 集中火力，是因為銷售經理強押開發人員，在銷售會議上充當技術 專家？ 這是非常重要的資訊。是否其他團隊可能也有相同的問題？ 我們是否應該教育產品經理更多有關於產品的知識？ 因此讓他們自 己可以做銷售支持(sales support)。 或者更好的方式，邀請銷售經理來參加會議，從中學習他們的需 求，一起討論可能的解法！ 一個 Sprint 回顧會議，不只有關如何讓團隊在下個 sprint 中能做得更 好，它還有更大的涵義。 我們處理的策略是十分簡單的。有個人(目前是我)參加所有 Sprints 的回顧會議，充當經驗知識的橋樑。這是相當不正式的作法。 另外一種方法，是讓每個 Scrum 團隊公佈一份 Sprint 回顧報告。我 們曾經試過這個方法，但是發現沒有很多人去看這些報告，更不用 講因此展開行動的更少。所以我們只是用上面這種簡單的方式。 對於充當"經驗知識橋樑"的這個人，有些重要的規則： § 他應該是一個好的傾聽者。 § 如果回顧會議太安靜，他應該準備去問些簡單，但是目標明 確的問題，可以刺激團隊的討論。例如："如果時間可以到 轉，重新從第一天開始這個 Sprint，那些事情你會用不同的 方法進行？"。 § 他應該自願花時間去參與所有團隊的所有回顧會議。 § 他應該具有某種權力地位，所以在一些團隊無法控制的改進 建議，他可以幫忙推動。 這種方法運作的相當好，不過也許有其它方法能做的更好。如果有 的話，請告訴我。
  • 92.
    84 | SCRUM和 XP 的實戰經驗 互換引導者是不錯的模式。像是 “我會引導你團隊的回顧會議，如 果你可以引導我的團隊”。讓簡單的雙向知識傳播可以發生，也讓 身為 Scrum master 的你，可以專心參與你團隊的回顧會議 (而不 是只能引導而已) 改變，或不改變 假設說，團隊總結出"我們團隊內部溝通太少了，所以總是重覆著彼 此做過的工作，並且搞亂對方的設計" 那我們應該怎麼呢？導入每日會議？或是導入新的功具來促進溝通？ 還是更多 wiki 的頁面？嗯，也許吧。也許會再發生，也許不會。 我們發現，在許多狀況下，只要能清楚的指出問題所在就足夠了， 在下個 Sprint 中會自動地被解決。特別是，如果你在團隊房間的牆 壁上，貼上 Sprint 回顧的結果(我們常常忘記去做，還蠻丟臉的！)， 這樣會更有效。你所導入的每個改變，都會要付出一些代價。因此 在導入改變之前，先考慮什麼都不做，然後希望問題會自行消失(或 是變小)。 上面這個例子("我們團隊內部溝通太少了…")是一個很典型的例子， 說明若是什麼都不做的狀況下，這問題有可能被解決。 如果每次你都導入一些改變，可能有些人會開始抱怨。人們會變成 不太願意去提出一些小問題，這將會很麻煩。 在回顧會議中，所發現問題的範例 這裡有些在回顧會議中所找出的一些問題，以及相對的典型處理動 作。 "我們應該花更多的時間，把故事拆解成更多的小項目和任 務"
  • 93.
    我們如何做 SPRINT 回顧|85 這個問題相當普遍。在每次的每日會議上，團隊成員自己會說"我真 的不知道今天要做什麼"。所以之後每次每日會議上，你需要花時間 去找出具體要做的任務。通常這些事情會前做，會更有效率。 典型處理動作： 無。團隊會在下次 Sprint 規劃會議中自行解決這個 問題。如果它重複發生，延長 Sprint 規劃會議的時間。 "太多外界的干擾" 典型處理動作： • 要求團隊在下一個 Sprint 中，減低他們的投入程度，所以他們會有 比較合理的計畫 • 要求團隊在下一個 Sprint 中，紀錄干擾的狀況更清楚一點，誰干擾， 花多久時間。可以幫助我們之後更容易解決問題。 • 要求團隊將所有干擾都轉給 Scrum master 或是產品負責人 • 要求團隊指定某個人當"守門員"，所有的干擾都要經過他，所以剩 餘的人都可以集中精力在要做的事情上面。Scrum master 或是大家輪 流來扮演這個角色。 守門員輪流的模式相當常見，並且通常運行的不錯。試試看吧！ "我們過度承諾，最後只做完了一半" 典型處理動作： 無。團隊可能在下個 Sprint 中不會過度承諾。或是 至少不會像這次承諾這麼多。 順便一提，在 2014 年時，“sprint 承諾(commitmment)” 一詞從 Scrum Guide 中移走。相對地，它更名為 “sprint 預測(forecast)”。 好多了！承諾這個詞會造成多大的誤解。許多團隊認為 sprint 規 劃是某種形式的允諾 (有點傻，想想敏捷宣言中四個主要價值之 一：“回應變化 重於 遵循計劃” )。Spint 規劃不是一種承諾，它是 一個預測和假設 –“這是我們認為如何達成 sprint 目標的最好方 式”。 無疑地，能交付的東西持續少於預測的，會令人覺得很討厭。如果 這是問題，可嚴格採用昨日天氣的做法，根據上次 sprint 做完的 量，來拉多少個故事點數 (如果你想要有些變化，可以用過去三個 sprint 的平均值)。這樣簡單而強大的技巧，可以讓問題消失，因 為你的速度變成可自我調適。
  • 94.
    86 | SCRUM和 XP 的實戰經驗 "我們辦公室環境太吵或是太混亂了" 典型處理動作： • 試圖去建立一個較好的環境，或是把團隊搬到辦公室外面去， 租一旅館的房間，怎樣都行。請看"我們怎樣佈置團隊的房間 "。 • 如果不可能，告訴團隊在下次 Sprint 中減低他們的投入程度， 並且清楚註明這是因為太吵和太混亂環境的緣故。希望這會 使團隊負責人，開始去向上層主管去反映這件事。 幸運地，我從來不用糟到要威脅團隊搬到辦公室外面去。但是如果 需要的話，我會這樣做 ：o)。
  • 96.
    11Sprint 之間的休息時間 在實際生活中，你不能總是在衝刺。你需要在衝刺之間休息。如果 你都是在做衝刺，你的效果可能只是像在慢跑。 這也適用於生活，不只是 Scrum！例如，如果我生活中沒有鬆懈 的時間，本書就不會出現(更不用講第二版，或是我其他的書籍， 文章，和視頻等等)。鬆弛對於生產力和個人福祉兩者來說，是超 級重要的！如果你是行事曆老是滿檔的人，試試看這個：打開你的 行事曆，每週凍結半天，寫下 ”鬆弛” 或是 ”不可預定” 或是其他。 不要事先決定你在那個時候要做什麼，看看會發生什麼事 :o) 同樣地，Scrum 和軟體開發也一樣。Sprint 安排的相當密集。身為開 發人員，你可能沒有機會休息，每天你必須站在那該死的會議中， 告訴大家你昨天完成什麼。而沒有人願意說"我昨天把腳翹在桌子上， 都在逛 blog，和喝卡布基諾"。 除了真正的休息外，還有另外一個好的理由，讓我們在 Sprint 之間 有些休息。在 Sprint 展示和回顧會議之後，團隊和產品負責人將會 有一堆資訊和想法需要消化。如果他們立即開始規劃下一個 Sprint， 將沒有人有機會去消化現有的資訊，或是上次所學到的教訓。在 Sprint 展示完後，產品負責人沒有時間去調整它的優先順序。 較差的安排：
  • 97.
    我們如何做發佈計畫和處理固定價格的合約|89 我們試圖在開始新的 Sprint 之前(更準確地說，在Sprint 回顧會議後 和下個 Sprint 規劃會議之前)，導入某種形式的休息。但是我們並不 是每次都成功。 但是最起碼，我們試圖去確保 Sprint 回顧會議和接下來的 Sprint 規劃 會議不會在同一天發生。在開始下一個 Sprint 前，每個人應該至少 可以有個晚上，不用去想 Sprint 的事。 好一點： 更好些： 有一種方式叫"實驗室之日(lab days)" (或你愛叫什麼都行)。那也是， 在這個日子裡，開發人員可被允許去做任何他想做的事情(嗯，我承 認，是從 Google 抄來的)。例如，研究最新的工具或是 API，準備認 證，和同事討論一些有的沒的，或是寫些自己有興趣的程式，等等。 我們的目標是在每個 Sprint 之間有個實驗室之日。這樣你在 Sprint 之 間會得到自然的休息，你讓團隊有機會，能讓他們的知識能持續跟 得上潮流。這也是一項能吸引人的員工福利。 最好的方式？ 目前我們每個月有一個實驗室之日，在每個月的第一個禮拜五。為 什麼不是在每個 Sprint 之間呢？ 好的，因為我覺得，整個公司應該 有相同的實驗室之日，這是非常重要的事情。否則人們不會把它當
  • 98.
    90 | SCRUM和 XP 的實戰經驗 作一回事。我們(到目前為止)還沒有把所有的產品的 Sprints 都調整 一致，因此我必須選擇一個和 Sprint 無關的實驗室之日來代替。 也許有一天，我們會嘗試去同步所有產品的 Sprints(也就是，所有產 品和團隊，Sprint 都有相同的開始和結束時間)。在這種狀況下，我 們絕對能在 Sprint 之間，擺個實驗室之日。 在 Spotify 公司，經過大量的實驗後，我們最終實現了全公司的黑 客松週。每年兩次，我們在一週內，可以做任何你想要做的，然後 在星期五會有個展示的宴會。全公司的人都會參加，不只是技術的 人員。這樣觸發的創新數量是非常驚人的！並且因為每個人都是相 同時間，團隊不會因為有相依性而出問題。我做了一個影片，來描 述 Spotify 的工程師文化，並提到了黑客松週和其他事情。可以在 http://tinyurl.com/spotifyagile 看到這個影片。
  • 99.
    12 我們如何做發佈計畫和處理固定價格的合約 有時候，一次只規劃一個 Sprint 要做的事情是不夠的，我們需要提 前做更多計畫。尤其是處理固定價格的合約，我們必須事先規劃， 否則我們將會有無法準時交付的風險。 對我們來說，發佈計畫是試圖去回答這樣的問題："最晚是什麼時候， 我們才能交付這個新系統的1.0 版本"。 如果你需要去學有關發佈計畫的事，我建議你跳過這個章節，去看 Mike Cohn 的書： "Agile Estimating and Planning"。我真的希望，我 能更早就讀到這本書(我是在我自己已經解決這些問題後才讀到它)。 我的發布計畫版本有點簡單，但是對於入門來說已經足夠了。 並且還需要看 Eric Ries 所寫的精實創業。最大的問題，是大多數 的專案，都企圖打造大規模的發佈，而不是交付小的增量，然後再 看看是否在正確的道路上。精實創業，如果使用的合宜，可以徹底 地降低風險和失敗的代價。 定義你的驗收門檻 除了一般的產品 backlog 外，產品負責人需要定義一些驗收門檻，它 是從合約的角度，將產品 backlog 的重要性層級，做出簡單的分類。 這裡有些驗收門檻規則的範例： § 所有重要性 >=100 的項目，都需要被放到 1.0 版本中，否則 我們將會罰款到死。 § 所有重要性在 50-99 間的項目，應該要被放到 1.0 版本中。 不過或許我們可以在下一個緊接快速發行的版本中，完成他 們。
  • 100.
    92 | SCRUM和 XP 的實戰經驗 § 重要性在 25-49 之間的項目也是需要的，但是他們可以在緊 接的 1.1 版本中被完成。 § 重要性 < 25 的項目是不確定的，可以永遠不會需要。 這裡有一個產品 backlog 的範例，根據上面的規則，用了不同顏色來 標示。 紅色= 必須被包含在 1.0 版本中 (banana – pear) 黃色= 應該在 1.0 版本中 (raisin – onion) 綠色= 可能可以之後完成 (grapefruit – peach) 所以如果我們可以在期限前，交付從 banana 到 onion 的每個項目， 我們就安全了。如果時間不夠用，我們可能跳過 raisin，peanut， donut 或 onion。Onion 以下的東西都是額外的。 當然啦，如果可以的話，不需要用這些數字優先等級來做分析！只 需列出順序，但是對你來說已經足夠。 對最重要的項目作時間的估算 為了要去產生發佈計畫，產品負責人需要估算，至少對於合約中， 所包含的所有故事都要算。就像 Sprint 規劃會議一樣，需要產品負 責人和團隊一起共同完成 - 團隊一起估算，產品負責人描述項目內 容，並回答問題。 Importance Name 130 banana 120 apple 115 orange 110 guava 100 pear 95 raisin 80 peanut 70 donut 60 onion 40 grapefruit 35 papaya 10 blueberry 10 peach
  • 101.
    我們如何做發佈計畫和處理固定價格的合約|93 如果事實證明這樣可以更接近正確的結果，那這個時間估算是有價 值的。但如果結果證明是有所差距的，例如像是偏差了 30%，這樣 會比較沒價值。可是如果它跟事實一點關係都沒有，那就完全沒有 用了。 這裡，我根據做估算的人，做估算所用的時間，以及估算的價值， 三者間的關係畫了一張圖。 若是用文字來解說，這就有點冗長： § 讓團隊來做估算。 §不要讓他們花太多時間。 § 確定他們了解到時間估算只是粗略的估算，並不是承諾。 通常產品負責人會把團隊放到一個房間中，提供一些點心飲料，並 且告訴他們這個會議的目的，是把產品 backlog 中前 20 個(或多少都 可以)故事作時間估算。他會把所有故事講過一遍，然後再讓團隊開 始工作。產品負責人會待在房間裡，回答大家的問題，有需要時釐 清每個項目的範圍。就像在做 Sprint 規劃會議一樣，"如何展示"這個 欄位是非常有用的方法，可減低產生誤解的風險。 這個會議必須嚴格控制時間長度，否則團隊會試圖花太多時間，在 少數的故事上。 如果產品負責人要他們花更多的時間，他可以之後再安排另一個會 議。團隊必須確保這個會議，對於目前這個 Sprint 的影響，可以讓 產品負責人感到非常明顯的。所以他能理解，他們時間估算的活動 是有代價的。 下面這個例子，說明了時間估算最終的結果 (用故事點數表示)：
  • 102.
    94 | SCRUM和 XP 的實戰經驗 把這個叫做 ”時間估算” 非常容易搞混。相反地，叫 ”大小估算” 比 較好。我不知道 “banana” 要多久能完成，但是我相當確定它 比 ”apple” 長一點，並且比 “orange” 短一點。大致對會比確定錯 好多了！ 估算速度 好的，所以我們對於最重要的故事，已經有了一些粗略的估算。 下一步就是估算每個Sprint平均的速度。 這意味著我們需要去決定我們的投入程度。請參見"團隊如何決定哪 些故事要被放到 Sprint 中"。 噢，不，不要再提到該死的投入程度 … 投入程度基本上表示："團隊有多少時間，可花在目前所承諾的故事 上"。它不可能是 100%，因為團隊會花時間，在做一些沒有規劃到 的項目，或是切換工作內容，幫助其他團隊，檢查 mail，修理他們 出問題的電腦，在茶水間討論一些政治等等。 假設我們決定團隊的投入程度是 50%(相當低，我們一般都是 70%左 右)。並且 Sprint 的長度假設是 3 周(15 天)長，然後團隊是 6 個人。 Imp Name Estimate 130 banana 12 120 apple 9 115 orange 20 110 guava 8 100 pear 20 95 raisin 12 80 peanut 10 70 donut 8 60 onion 10 40 grapefruit 14 35 papaya 4 10 blueberry 10 peach
  • 103.
    我們如何做發佈計畫和處理固定價格的合約|95 每個 Sprint 都是90 人天，但是只能被預期產出 45 人天的故事 (因為 投入程度是 50%)。 所以我們估算的速度是45個故事點數。 忽略投入程度。要求團隊查看這個列表，根據經驗來猜在一個 sprint 內可以做多少，然後算出點數。那會比投入程度還快，不管 準確或不準確。大致對會比 … 好 – 噢，等等，我已經講過了。 如果每個故事的時間估算都是 5 天(但實際上不是)，那團隊差不多能 在一個 Sprint 中完成 9 個故事。 在發佈計畫中考量所有因素 現在我們有時間估算和速度(45)，我們可以很容易把產品 backlog 中 拆解到 sprint 中： Imp Name Estimate Sprint 1 130 banana 12 120 apple 9 115 orange 20 Sprint 2 110 guava 8 100 pear 20 95 raisin 12 Sprint 3 80 peanut 10 70 donut 8 60 onion 10 40 grapefruit 14 Sprint 4 35 papaya 4 10 blueberry 10 peach 在沒有超過 45 的估算速度下，每個 Sprint 盡可能塞下很多的故事。
  • 104.
    96 | SCRUM和 XP 的實戰經驗 現在我們知道我們大約需要三次 Sprint，才能完成所有"必須要做"和 "應該要做"的。 3 個 Sprint = 9 個星期 = 2 個月。這是我們要承諾客戶的最後期限嗎？ 這要視合約的性質而定，以及範圍有多固定，等等。我們通常會增 加蠻多的緩衝，來保護糟糕的時間估算，無法預期的問題，以及無 法預期的功能等等。所以在這種狀況下，我們可能會同意會"保留"1 個月，然後設定交付日期在三個月後。 這裏有另一個替代方案，也運作得不錯。用一個範圍(30-50 點)來 評估速度。把 backlog 分成三堆： 所有：這些故事都要被做完，即使我們的速度不快 (30) 。 某些：某些故事將要被完成，但不是全部。 沒有：沒有一個故事要被完成，即使我們的速度很快(50)。 最棒的事情是，我們能每三個星期，展示一些有用的事情給客戶。 並且在我們進行中，邀請他們更改需求(當然啦，這要看這是什麼合 約而定)。 調適發佈計畫 現實不會調整自己去適應計畫，所以我們必須削足適履。 在每個 Sprint 後，我們會檢查一下這個 Sprint 的實際速度。如果實際 的速度和估算速度差距很大，我們會調整下一個 Sprint 的估算速度， 並且更新發佈計畫。如果這會帶來麻煩，產品負責人會開始和顧客 談判，或是檢查一下是否可以在不違反合約下調整範圍。或者他跟 團隊想出一些方法，藉由消除在 Sprint 過程中，所發現的某些嚴重 障礙，以增加團隊的速度或是投入程度。 產品負責人可能打電話給顧客說 "嘿，我們進度有點落後，但是我相 信，如果把'embedded Pacman'給拿掉的話，我們一定可以趕上期限， 因為它會花我們許多時間去建構它。如果你接受的話，我們可以在 第一次發佈後，在三週後的下一個發佈中，把它加進去"。
  • 105.
    我們如何做發佈計畫和處理固定價格的合約|97 可能這對顧客來說並不是好消息，但是至少我們是很有誠意，並且 給顧客一條容易的選擇 - 我們應該要準時交付最重要的功能，還是 延遲一段時間後交付出所有功能？通常這不是很困難的選擇 ：o) 我做了一個十五分鐘的視頻，叫做 “Agile Product Ownership in a Nutshell”。它包含了一堆有用的提示和技巧，是和 Scrum 的發佈 計畫和 backlog 管理有關的。來看看吧！ http://tinyurl.com/ponutshell
  • 106.
    13我們如何結合 Scrum 和XP Scrum 和 XP 結合後，可以帶來很多好處，這點是無須爭議的。網路 上，我看到大部分的資料都支持這個論點，所以我不用再花時間去 爭論為什麼。 好的，我注意到一件事。Scrum 著重在管理以及組織的實踐。而 XP 大多著重於實際的編程實踐。那是為什麼它們可以一起運作的很好 - 它們解決不同領域的問題，並且互補對方的不足。 因此，我要在現有的經驗證據中，加上我的聲音：Scrum 和 XP 組合 起來是很有成效的！ 我從 Jeff Sutherland 那裡了解到，一開始 Scrum 是有實施 XP 的 實務。但是 Ken Schwaber 說服了他，把工程實踐從 Scrum 中移 除，以保持整個模型的單純，讓團隊自己去負責技術實務的部分。 或許，這可以幫助 Scrum 傳播的很快。但是，缺點是許多團隊因 此而受難。因為缺乏技術實務，而導致無法建立可持續的敏捷開 發。 我將要介紹某些較有價值的 XP 實踐，以及他們如何套用到我們每日 的工作中。我們並沒有要求所有團隊，去採用所有的實踐。但是總 歸來說，我們已經在大多數的方面，嘗試過 XP 和 Scrum 的組合。有 些 XP 的實踐，可以直接被 Scrum 解決掉，因此可被視為重疊的實踐。 例如： "完整團隊"、"坐在一起"、"故事"、和"計畫遊戲"。在這樣的 狀況下，我們已經直接採用 Scrum。 搭檔編程 我們最近在某一個團隊開始採用搭檔編程，運作的相當好。我們大 部分的其他團隊，仍然沒有嘗試太多的搭檔編程。但是在某個團隊
  • 107.
    我們如何結合 SCRUM 和XP | 99 實際運用它，跑幾次 Sprint 後，我因此而被啟發，願意試著指導更 多團隊去試試看。 到目前為止，有些關於搭檔編程的結論： § 搭檔編程可以改進程式碼的品質。 § 搭檔編程可以改進團隊的注意力(例如，坐在你後面的人說" 嘿，這個東西在這個 Sprint 中真的需要嗎？")。 § 令人驚訝的，那些強烈反對搭檔編程的開發人員，實際上根 本沒有嘗試過它。可是一旦嘗試過，便很快喜歡上它。 § 搭檔編程會讓人精疲力盡，不應該整天都這樣做。 § 經常更換夥伴是有好處的。 § 搭檔編程可以增進團隊間知識的傳播。會令人想不到的快速。 § 有些人就是對搭檔編程感到不舒服。不要因為他不想搭檔編 程，就否決一個優秀的程式設計師。 § 檢視程式可以當作搭檔編程的替代方案。 § "領航員"(不使用鍵盤的傢伙)應該也要有他自己的電腦。並 不是用來開發，而是需要作一些嘗試，或是當"司機"遭遇到 問題的時候查看文件，等等。 § 不要強迫人們採用搭檔編程。而是鼓勵他們並提供正確的工 具，讓他們根據他們自己的步調去實驗。 測試驅動開發(TDD) 阿們，對我來說，TDD 是比 Scrum 和 XP 還要重要。你可以拿走我 的房子，我的電視，和我的狗。但是不要試圖阻止我去做 TDD！如 果你不喜歡 TDD，那不要讓我到你的地盤，因為我會想盡各種方法 偷偷去嘗試它：o) 好吧，我已經不再對它這麼狂熱。我了解到 TDD 只是一個相當小 眾的技術，只有少數的人有耐心去精通它。相反地，我會教授這些 技術，但是讓團隊決定要用多少，以及何時去用。 這裡有個 TDD 的 10 秒總結： 測試驅動開發意味著，你要先寫自動化測試，然後你 再寫足夠的程式碼去通過測試，接著重構你的程式碼， 主要是去改進可讀性和移除重複的地方。一直反覆進 行這樣的事。。
  • 108.
    100 | SCRUM和 XP 的實戰經驗 這裡有些對測試驅動開發的看法。 § TDD 很難，程式設計師要花一段時間才能掌握它。事實上， 在很多狀況，問題不在於你教多少，指導多少或是展示多少。 唯一有效的方法，是讓一個擅長 TDD 的人，讓他和你一起 搭檔編程。一但知道怎麼做以後，他將會受到很大的影響， 並且不會再去用其他方法工作。 § TDD 對系統設計有相當深遠且正面的影響。 § 在新產品中，需要花一段時間，才能讓 TDD 被應用的很有 效率。特別是黑箱整合測試，但是投資報酬率相當好。 § 確認你投資的時間，足夠到讓大家能很容易撰寫測試。這意 味著要有適當的工具，受過訓練的人，以及提供合適的 utility classes 或是 base classes 等等。 因為 TDD 還蠻難的，我並不打算強迫人們去用它。相反地，我指 導他們以下準則： 1) 確保每個關鍵的功能，都至少有一個端點到端點的驗收測試。可 透過畫面，或是畫面下一層來操作。 2) 確保每個複雜或是關鍵的業務之程式片段，都有進行單元測試。 3) 這會遺留某些程式碼沒有被涵蓋，那沒有關係。但是要知道哪些 沒有被涵蓋，確定這是經過深思熟慮後的取捨，而不是只是被忽略 了。 4) 當你開發到哪裡，就要撰寫測試到哪裡，不要留著之後才做（因 為你之後可能跟你現在一樣忙）。 在沒有要求全面 TDD 的狀況下，看起來仍然有足夠的維護能力。 因為報酬遞減的關係，測試涵蓋度最終只達到 70%。簡單來說， 測試自動化是關鍵，而 TDD 是可有可無。 我們在測試驅動開發過程中，使用了以下工具： § jUnit / httpUnit / jWebUnit 我 們 正 考 慮 去 用 TestNG 和 Selenium。 § HSQLDB 在測試中，被當成一個嵌入式的 in-memory 資料庫。 § Jetty 在測試中，被當成一個嵌入式的 in-memory 的 web container。 § Cobertura 用來做測試涵蓋度度量。 § Spring framework 用 來 連 接 不 同 型 態 的 測 試 裝 置 (test fixture)(帶有 mock，不帶 mock，連接外部資料庫，連接 in memory 資料庫等等)。
  • 109.
    我們如何結合 SCRUM 和XP | 101 在我們最複雜的產品中(從 TDD 的觀點來看)，我們都有自動化黑箱 驗收測試。這些測試會在記憶體中啟動整個系統，包括資料庫和網 頁伺服器，並且透過它的公開介面去存取這個系統(例如像是 HTTP)。 這樣的運作方式，比之前用的還要容易，因為有很多靈巧的測試工 具或是框架可以用。他們非常有用，不論你是否要做 TDD。 這樣會使開發-建構-測試的循環變得很快。這也可當作一張安全網， 讓開發人員有足夠的信心常常去重構，即使當系統成長後，設計也 能保持乾淨和簡單。 在新的程式碼上做 TDD 對於所有新開發的程式，我們都會做 TDD。即使這意味著最初的專 案建置，需要花費較長的時間(因為我們需要更多工具，以及和支援 一些測試的裝置等等)。這是有點不容易，但是它的好處很大，因此 沒有任何理由不去用它。 在舊的程式碼上做 TDD TDD 是有點難的，但是試圖在一開始沒有用 TDD 的程式碼上要去做 TDD，那是更加困難…為什麼？ 嗯，事實上，關於這個主題，我可 以寫出一堆文章，所以我想我先到這裡為止。我將保留到我下一本 書"TDD 的實戰經驗"中再談。：o) 一直都抽不出時間寫這些東西 … 但是，從來都不缺乏 TDD 的書 籍！有一本很棒的書是有關於處理遺留代碼的，叫做 Working Effectively with Legacy Code，作者是 Michael Feathers，非常經 典。我也寫過一些有關於技術債的文章，可以參考我的部落格。 http://blog.crisp.se/tag/technical-debt 我們花相當多的時間，試圖對一個較複雜的系統，自動化其整合測 試。它的程式碼已經存在很長一段時間，並且處於嚴重混亂狀態， 完全沒有測試程式。 每次系統的發佈前，我們會有一個專門的測試人員，去執行大量、 複雜的回歸測試和效能測試。回歸測試大多數是手動進行，因此嚴 重地減緩開發和發佈的週期。我們的目標是去自動化這些測試，但 是，在幾個月的痛不欲生後，我們還是無法能有更多進展。
  • 110.
    102 | SCRUM和 XP 的實戰經驗 之後我們改變我們的方法。我們承認這個事實，那就是我們身陷於 必須手動進行回歸測試的麻煩。然後相反地問自己："我們如何使手 動測試流程，花費的時間比較少？" 當時有一個賭博遊戲的系統，我 們意識到，許多測試團隊的時間是花在繁瑣的安裝工作，像是瀏覽 後台系統去建立牌局來進行測試，或是等待一個安排好的牌局啟動。 所以我們為了這樣寫了一些工具，他們是一個很小，容易被使用的 腳本(script)，並且會處理掉一些瑣碎繁雜的工作，好讓測試人員可 以專注於真正的測試工作。 這些努力確實收到效果！ 事實上，我們一開始就應該要這樣做。我 們過去太急著去自動化它，卻忘記要按部就班來。剛開始的第一步 應該是建立一些東西，讓手動測試能更有效率。 學到的教訓：如果你身陷於必須手動進行回歸測試的麻煩，並且想 要把它自動化，還是放棄吧(除非它很容易去做到)。相反地，想些方 法來讓手動回歸測試容易點，然後再考慮將真正的測試給自動化。 漸進式設計 這意味著一開始設計就要保持簡單，然後持續去改進它。而不是一 開始就試圖要所有的事情都正確，然後就凍結它。 我們這點上做的相當好，也就是，我們花了可觀的時間去重構，改 進現有的設計。並且我們很少花時間去大規模的預先設計。當然， 有時我們也會搞砸了。例如，允許一個搖搖欲墜的設計"陷入"的太深， 導致後來的重構變成是一個大工程。但是整體來說，我們還相當滿 意。 持續設計的改進，很大程度是做 TDD 所自動帶來的副作用。 持續整合 我們大部分的產品在持續整合方面已經相當成熟，它是利用 Maven 和 QuickBuild 來達成的。這是相當有用，並且節省時間。對於"嘿， 它在我的電腦上是可以的"這個問題，持續整合是終極解決方案。若 是要判斷所有程式碼的健康狀況，我們把持續建構的伺服器當作是" 仲裁者"，或是參考點。每次有人 checkin 東西到版本控制系統，持 續建構系統會醒來，在共用的伺服器上，重新建立每件事情，然後 再執行所有的測試。如果有出現問題，它將會寄郵件去通知整個團
  • 111.
    我們如何結合 SCRUM 和XP | 103 隊，告訴他們這個版本是有問題的，包括準確地告知哪些修改的程 式碼造成建構失敗，以及指向相關的測試報告的連結，等等。 在每個晚上，持續建構伺服器將會重新建構產品，並發佈執行程式 碼(ears，wars，等等)、文件、測試報告、測試涵蓋度報告、相依性 報告，等等，把他們放到我們內部的 portal 上面。有些產品也會自動 部署到測試環境中。 設定這件事情需要花費大量的工作，但是每一分鐘都是值得的。 如果你再走的更遠一點，你會達到持續交付的境界。每個提交的版 本，都是一個可發行的候選者，所以發佈只是一個按鍵的操作。我 看到越來越多的團隊做到這樣，我自己帶領的專案也是這樣在做。 它讓你感到非常神奇地的有效！我建議你可以研讀 (或者至少瀏覽 一下) Continuous Delivery 這本書。建置它需要做很多事情，但是 在新產品開始時，這絕對是值得去做的，幾乎可以馬上得到回報， 並且現在有很多工具都支援這件事情。 程式碼集體共有權 我們鼓勵程式碼集體共有，但是並不是所有團隊都已經採用它。我 們發現到，搭檔編程中經常更換搭檔，會自動形成高度的程式碼集 體共有權。若團隊有高度的程式碼集體共有權，這個團隊就會非常 強壯。例如，他們的 Sprint 不會因為某個關鍵的人員生病而有所影 響。 Spotify (和其他所多快速發展的公司)有個 “內部開源” 的運作方 式。所有的程式碼都放在內部的 GitHub 上面，所有人都可以複製 儲存庫，以及提出 pull request，就像任何公開的開源專案，非常 方便。 資訊化工作場所 所有團隊可以善加利用白板和空白牆壁的空間。在大部分的房間， 你將會發現到牆壁上，貼滿了產品或是專案的各式各樣資訊。最大 的問題是，舊的訊息也積累在牆壁上。我們可能需要在每個團隊中， 導入一個"管家"的角色。
  • 112.
    104 | SCRUM和 XP 的實戰經驗 我們鼓勵使用任務版，但是不是所有團隊都已經採用它。請看"我們 如何安排團隊的座位和空間"。 編碼規範 最近我們已經開始定義編碼規範，它非常有用。要是我們能早點這 樣就好了。它一點都不花時間，只要從簡單開始，然後讓它慢慢增 加。只要寫下不是所有人都明顯知道的事，如果可能的話，連結到 現存的資料上。 大部分的程式設計師有他們自己的編碼風格。細節像是他們如何做 例外處理，他們如何註解程式碼，什麼時候要傳回 null，等等。在某 些狀況下，這些差異是沒有關係。可是在某些狀況下，可能會導致 嚴重的系統設計不一致，以及很難閱讀的程式碼。此時編碼規範就 非常有用，只要你關注在一些重要的事項上面。 這裡有些我們編碼規範的範例： § 你可以打破裡面任何一個規則，但是要確認有個好的理由， 並且要記錄下來。 § 預 設 使 用 Sun 的 編 碼 規 範 ： http ： //java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html § 永遠，永遠，永遠不要在，沒有記錄 stack trace 的情況下， 或是重新丟出 exception 的狀況下，去抓住 exception。用 log.debug()是可以的，只是不要忘記 stack trace 就可以。 § 使用 setter 為主的依賴性注入(dependency injection)，來減低 類別之間的關連(當然，如果緊密耦合是適用的話，那就另當 別論)。 § 避免縮寫。但是為人熟知的縮寫則是可以，像是 DAO。 § 需要傳回 collection 或是陣列的函式，不能夠傳回 null。而是 要用空的 collection 或是陣列來代替 null。 程式碼規範和風格指南是非常有用的。但是沒有必要去重新發明輪 子 – 你可以從我的好友 Google 中複製一份： http://google-styleguide.googlecode.com 可持續的開發速度/精力充沛的工作 許多敏捷開發的書籍宣稱，加班在軟體開發過程中會降低生產力。
  • 113.
    我們如何結合 SCRUM 和XP | 105 在幾次不情願的試驗後，我非常同意這件事！ 大約幾年前，我們其中一個團隊(最大的團隊)大量瘋狂的加班，現存 程式碼的品質令人沮喪，他們必須花大量的時間在救火。測試團隊 (也同樣在加班)沒有機會，認真地去做品質確認的工作。我們的使用 者很生氣，很多八卦都快把我們給吃掉。。 在幾個月後，我們成功地將工作時間降到適當的範圍。人們正常上 下班(除了專案關鍵時期例外)。令人驚訝的事發生了，生產力和品質 有明顯的改進。 當然，減少工作時間，絕對不是唯一會導致改善的原因，但是我們 都相信它佔很重要的因素。 我再看了幾遍，認為在軟體開發中 (或是其他任何複雜和有創意的 工作) ，交付的價值和所花費的時間，其實是沒有什麼關聯性。真 正重要的是有多少專注和有動力的時間。我們大多數曾經經歷過這 樣的感受，在星期六上午工作的很平順，好幾個小時很安靜，並且 在那時間似乎完成了一整個禮拜的工作！這就是我說的專注和有動 力的時間。所以不要強迫人們超時工作，除了極少數例外的狀況是 真的需要這些時間。另外，讓人們精疲力盡是不道德的。
  • 114.
    14我們怎樣做測試 這是最困難的部份。我不確定是否它是 Scrum 中，最難的一部份。 還是它在軟體開發中，通常也是最困難的部份。 在不同組織之間，測試可能是差異最大的部份。它依賴你有多少測 試人員，有多少自動化，哪些型態的系統(只是伺服器+網頁應用程 式？)發佈週期的長短，軟體的關鍵性(blog伺服器 v.s 飛行控制系統) 等等。 在 Scrum 中，我們試過很多如何去測試的方法。我會試著描述我們 曾經做過的方法，以及目前我們得到的經驗。 您可能無法擺脫驗收階段 在理想的 Scrum 世界，每次的 Sprint 會產生一個可以部署的系統版 本。所以只要部署它就好，是嗎？ 沒錯！ 不是。 嘿？
  • 115.
    我們怎樣做測試 | 107 根據我們的經驗，這通常是不可行的，都會有很嚴重的錯誤。如果 品質對你來說還有價值的話，某種手動測試的階段是需要的。 滿口胡言！我不敢相信我會這樣寫！這本書已流傳到各地，並且有 很多人唸過和相信它，我真的感到羞愧！好爛的作者，不要再寫這 些錯誤的東西了！＊啪啪＊ 是的，手動測試是非常重要的，並且有些環境是無可避免的。但 是，應該是由團隊在sprint 中進行，而不是交由另一個獨立的團 隊來進行，或是保留到未來的測試階段來進行。這不就是為什麼我 們會拋棄瀑布式模型的原因嗎？ 還記得吧？ 對於不隸屬於團隊的專職測試人員，他們必需利用 Scrum 團隊，沒 有想過、沒時間做、或是沒有硬體配備去做的方式，去攻擊系統。 測試必須和真正使用者一樣的方式，來存取系統。也就是說他們必 須手動進行(假設你系統是給人使用)。 測試團隊發現錯誤(bug)，Scrum 團隊必須要發佈錯誤修復(bug-fix)的 版本，遲早(希望會快一點)你將會為使用者發佈 1.0.1 的錯誤修復版 本，而不是出問題的 1.0.0 版本。 當我說"驗收測試階段"，我是指整個在做測試、除錯、以及重新發佈 的階段。直到有個版本，可以好到做生產版本(production release)為 止。 縮短驗收測試階段 驗收測試階段帶來很大的痛苦，它感覺相當地不太敏捷。 是的，所以不用。 嗯，好的，我知道。在某些環境它看起是不可避免的。但是我的觀 點是，我過去曾經認為它是不可避免的。但是，現在我看到許多真 的敏捷的公司，藉由放棄單獨的驗收測試階段，把它合併到 sprint
  • 116.
    108 | SCRUM和 XP 的實戰經驗 中，以達到行動迅速和提高品質。所以如果你還認為它是不可避免 的，這可能是因為你被你的現狀所蒙蔽了 (就像我以前一樣)。然 而，這個章節提供了一些有用的樣式，讓你知道如何處理獨立的驗 收測試，把它當作一個臨時的作法，直到你可以合併的 sprint 裡 面。:o) 雖然我們無法擺脫它，我們可以(並)盡量減少它。更具體一點的說， 縮短驗收測試階段所需要的時間。我們的作法是： § 提高 Scrum 團隊所交付程式碼的品質 § 提高手動測試工作的效率(也就是，挑選最好的測試人員，給 他們最好的工具。確保他們所說的很浪費時間的工作，能夠 被自動化) 所以那我們如何提高從 Scrum 團隊所交付程式碼的品質呢？ 嗯，方 法有很多。這裡有兩個方法是我們發現非常有用的： § 把測試人員放到 Scrum 團隊中 § 每個 Sprint 中做較少的工作 藉由把測試人員放到 Scrum 團隊中來提高品質 是的，我聽過完全不同的說法： • "但是，那很明顯啊！ Scrum 團隊理應是 跨功能職務的" • "Scrum 團隊裡應該是沒有角色的！ 我們 不能有一個人僅僅只是在做測試" 讓我澄清一下，在這裡我所謂的"測試人員"是指"一個主要技能是測 試的人"，而不是"一個它的角色只是在做測試的人"。 這是一個重要的觀點。“跨職能” 並不意味著每個人要會所有的東 西。它的意思只是每個人願意去做，超過他們所負責的部分。我們 需要的是專業化與跨職能化，取得一個合適的平衡。所以，整個團
  • 117.
    我們怎樣做測試 | 109 隊共同為他們的產品的品質負責，所以每個人都被要求要做測試。 然而，測試人員需要指導這工作的進行，和開發人員配對去做測試 自動化，自己則執行更複雜的手動測試。 開發人員通常是相當差勁的測試人員，特別是在測試他們自己的程 式碼的時候。 測試人員就是"驗收的傢伙" 除了"只是"團隊的一員外，測試人員有一個重要的工作，他是驗收的 傢伙。在Scrum 中，要直到他說完成才算完成，否則沒有事情能算" 完成"。我曾經發現，開發人員常常說某件事情已經完成，但是實際 上還沒有。即使你有非常清楚"完成"的定義(你應該如此，請看"'完成 '的定義")，開發人員還是經常忘記。我們這些程式設計師常是沒有 耐心的人，只想要很快的進到下一個 Sprint。。 那我們的測試先生如何知道某些事情已經做完呢？ 嗯，首先，他應 該(很驚訝吧)測試它！ 在許多狀況下，那些開發人員認為已經做完 的項目，結果是不可能被測試的。因為那些東西還沒被 check-in，或 是還沒被部署到測試伺服器中。一但測試先生開始測試時，他應該 和開發人員，從頭到尾確認過那份"做完"的清單(如果你有的話)。例 如，如果在"做完"的定義中，描述應該有個發佈說明，那測試先生要 檢查是不是有個發佈說明。如果這個功能有某種更為正式的規格， 那測試先生也要檢查，等等。 這裡有一個很好的副作用，因為團隊現在有一個傢伙，非常適合安 排做 Sprint 展示的工作。 我不再是簽核這種模式的粉絲了。這將會產生瓶頸，並且將太多責 任放到一個人的手上。但是，我認為在某些環境下，簽核還是有用 的(在某些時間，它一定有用)。此外，如果有任何人必須要對品質 簽核的話，那個人一定是真實客戶。 當沒有東西要測試時，測試人員要做什麼？ 這個問題常常被提出來。測試先生說： "嗨，Scrum master 現在沒有 東西要測試，所以我要做什麼？" 團隊可能需要一個禮拜，才能完成 第一個故事。那這時候測試人員應該做什麼？
  • 118.
    110 | SCRUM和 XP 的實戰經驗 好的，首先，他應該要為測試做些準備。那就是撰寫測試規格書， 準備測試環境，等等。所以當開發人員已經有東西可以被測試時， 就不用再等待，測試先生可以立即開始測試。 如果團隊有做 TDD，那大家從第一天開始，就會花時間撰寫測試程 式碼。測試人員應該和開發人員撘檔編程，一起撰寫測試程式。如 果測試人員一點都不會寫程式，他也應該和開發人員撘檔編程。即 使他只能瀏覽，而開發人員去敲鍵盤。一個好的測試人員總是會比 好的開發人員，想出更多不同種類的測試，所以他們可以互相互補。 如果團隊沒有採用 TDD，或是沒有足夠的測試個案需要去撰寫，他 應該完全地盡他所能，幫助團隊實現 Sprint 的目標。就像團隊其他 成員一樣，如果測試人員會寫程式，那很好。如果不會，你的團隊 必須找出需要在 Sprint 中完成，但不用寫程式的工作。 在 Sprint 規劃會議中，把故事拆解成任務時，團隊著重於編程的工 作。然而，通常還有許多非編程的工作，需要在 Sprint 中完成。在 Sprint 規劃會議中，如果你花時間，企圖找出非編程的工作，測試先 生將會有機會去貢獻許多，即使他不會寫程式，或者目前沒有測試 工作要進行。 這裡有些非編程的任務，需要在 Sprint 中被完成： § 建置測試環境。 § 釐清需求。 § 和營運部門討論佈署的細節。 § 撰寫部署的文件(發佈說明，RFC，或是任何你組織中要寫的 東西)。 § 和外部資源進行聯繫 (例如 GUI 設計師) § 改善建構腳本(build scripts) § 進一步將故事拆解成任務 § 從開發人員中找出關鍵的問題，並解決他們。 從另一個角度來看，如果測試先生變成是瓶頸，那我們該怎麼辦？ 假設我們現在在 Sprint 的最後一天，突然間有很多工作被完成，導 致測試先生沒有去測試完所有事情，那我們要怎麼辦？ 嗯，我們應 該叫團隊中所有人去測試先生當助手。他來決定哪些事情他自己要 做，然後把一些平凡的測試交給團隊中其他人來做。這就是跨功能 職務團隊所該做的事情！
  • 119.
    我們怎樣做測試 | 111 所以，是的，測試先生在團隊中，確實是一個特別的角色，但是他 仍然可以去做其他工作，其他團隊成員也被允許去做他的工作。 說得好！(我可以被允許有時候誇獎一下自己嗎？)這是一個觀察團 隊成員其他能力的好方法。 藉由在 Sprint 中做較少的工作來提高品質 讓我們回到 Sprint 規劃會議中。簡單地說，不要把太多故事放到同 一個 Sprint 裏！ 如果你有品質的問題，或是要很長的驗收測試週期， 那就在每個 Sprint 中做較少的事情！ 這將自動地導致較高的品質， 較短的驗收測試週期，較少影響使用者的錯誤。長期來說會有較高 的生產力，因為團隊可以所有時間都著重於新的東西。不會因為要 修復舊的東西，而打斷目前工作的進行。 與其建構許多東西，但是需要出些 hot-fixes 來補救；還不如建構少 一點，但是建構的比較穩定，這樣會比較划算點。 這是完全正確！我一直在世界各地重複看到這樣的狀況。 驗收測試應該是 Sprint 的一部分嗎？ 我們在這裡差距很大。有些團隊把驗收測試當做 Sprint 的一部份， 但大部分的團隊則沒有。主要有兩個原因： § Sprint 是有時間框的限制，驗收測試(根據我的定義，它包含 了除錯和再次發佈're-releasing')的時間是非常困難去固定的。 如果時間用完了，你還有一些關鍵的錯誤，那你要怎麼辦？ 你要去發佈一個有嚴重錯誤的產品嗎？ 還是你要等到下一個 Sprint 才發佈？ 在大部分的狀況，這兩種作法都無法接受。 所以我們把手動驗收測試不視為 Sprint 的一部份。 § 如果你有多個 Scrum 團隊一起開發一個產品，必須把這些團 隊的工作結果結合在一起，再進行手動驗收測試。如果這些 團隊各自把驗收測試放在自己的 Sprint 中，你還是需要一個 團隊去測試最後版本，也就是最後整合所有團隊工作結果的 版本。
  • 120.
    112 | SCRUM和 XP 的實戰經驗 這並不是一個完美的解法，但是在大部分的狀況下，對我們來說已 經足夠了。 再次強調，努力去把驗收測試變成 sprint 的一部分。它會需要花 一段時間才能做到，但是你不會後悔去做這件事。即使你無法達到 這種境界，你所做的嘗試，都能讓你的工作有很大的改進。 Sprint 週期 v.s. 驗收測試週期 在完美的 Scrum 世界中，你不會需要驗收測試階段，因為每個 Scrum 團隊，在每次 Sprint 結束後，會發佈一個新的、已經產品化就 緒的版本。 這是可以做到的！我已經看過世界上有許多團隊每天可發佈到線 上，有時候是每天好幾次。每次當 Scrum 的講師告訴他們 ”在 sprint 結束時，你需要產生出一個有完整的測試，可能交付的產品
  • 121.
    我們怎樣做測試 | 113 增量”，他們的反應是”啥？為甚麼要等這麼久？” 所以，不用，你 不需要等到完美的 Scrum 境界。只要捲起你的袖子，指出在每次 sprint 中，阻擋你拿到可發行程式的原因，並且一個個地修復它 們。當然，這可能或多或少在你的領域中有點困難，但是仍然值得 嘗試。只要從你現在的發佈週期開始 (無論它是一個月，一年或是 多少都可以)，然後逐漸且持續的縮短它。 嗯，這裡有張更真實的圖片： 在 Sprint 1 後，一個充滿錯誤的版本 1.0.0 被發佈。在 Sprint 2 期間， 錯誤報告開始大量湧入，團隊花大量的時間在除錯，並且在 Sprint 中期，被迫發佈了錯誤修復的版本 1.0.1。然後在 Sprint 2 結束後， 他們發佈一個有新功能的版本 1.1.0， 當然啦，會有更多的錯誤，因 為他們受到上次發佈版本錯誤的干擾，這次他們只有較少的時間去 確保品質。這樣的情形會一直重複發生。 在 Sprint 2 中紅色斜線代表混亂的狀況。 並不怎麼好吧？ 嗯，悲慘的是這問題會持續下去，即使你有一個驗 收測試團隊。差別僅是大部分的錯誤報告來自於測試團隊，而不是 生氣的使用者。從商業的角度來看，兩者有很大的差別，但是從開 發人員的角度來看，它們是相同的。不過測試人員沒有像使用者那 樣積極，通常是這樣。
  • 122.
    114 | SCRUM和 XP 的實戰經驗 對於這個問題，我們還沒有發現任何簡單的解法。不過我們試過許 多不同的模型。 首先，再一次強調，還是要提高 Scrum 團隊所發佈程式碼的品質。 在 Sprint 中，早一點找出和修復錯誤的費用，會比在 Sprint 結束後， 找出和修復錯誤的費用，要低的很多。 但是事實仍然是事實，即使我們能減少錯誤的數目，在 Sprint 結束 後，仍然有錯誤報告被產生，那我們是如何處理呢？ 方式 1： "不要開始建立新的東西，直到舊的東西已經產品 化了" 聽起來不錯，不是嗎？ 你是否也有溫暖、模糊的感覺？ 是的，它很棒！ 我們好幾次差點採用這個方法，還畫出想像我們如何進行的模型。 然而，當我們了解到它的缺點後，我們就改變了心意。如果我們採 用這個方法，我們必須在 Sprint 之間，加了一段沒有時間框的發佈 時段，在這段時間內我們只做測試和除錯，直到我們能發佈一個產 品為止。
  • 123.
    我們怎樣做測試 | 115 如果你做完的定義是部署到生產環境，在這個狀況下，你可以立即 開始下一個sprint，因為上個 sprint 的程式碼已經部署到生產環 境了。它可以在sprint 中持續發佈，是有點極端，但是它是可以做 得到的。 我們不喜歡在 Sprint 之間，有一個沒有時間框的發佈時段，主要是 因為它打破正常的 Sprint 心跳節奏。我們不再能號稱"我們每三周會 開始一個新的 Sprint"。此外，它不能完全地解決問題，即使我們有 一個發佈的時段，但是隨時還是會有緊急的錯誤報告出現，我們必 須準備好去處理它。 這是真的。即使你做到持續發佈，你仍然需要一個方式來處理進來 的重要 bug。因為它們有時候會發生，並且沒有一個團隊可以厲害 到不會發生。因此處理這件事情的最好的方式，就是在 sprint 中 保留一些鬆弛的時間。 方法 2： "可以開始去建構新的東西，但是要對舊有功能的 產品化這件事給排出優先順序" 這是我們比較喜歡的方法，至少現在是這樣。 基本上，我們完成一個 Sprint 後接下一個 Sprint。但是我們希望在下 一個 Sprint 中，能花些時間去修復上一個 Sprint 中的錯誤。如果我們 花太多時間去修復上一個 Sprint 所產生的錯誤，那下個 Sprint 將會被 嚴重的破壞。我們會評估為什麼會發生這樣的事情，以及我們如何 改善品質。我們會確認 Sprint 的時間，是長的足夠去完成上個 Sprint 中，相當數量錯誤的修復。 一般來說，經過幾個月後，花在修復上個 Sprint 所產生錯誤的時間 會減少。此外，當錯誤發生時，我們要參與的人員變少，所以整個 團隊不需要每次都被干擾。現在我們已經到一個較可以接受的程度。
  • 124.
    116 | SCRUM和 XP 的實戰經驗 在 Sprint 規劃會議期間，我們設定較低的投入程度，讓我們能夠有 時間去處理上個 Sprint 來的錯誤。經過一段時間後，團隊已經相當 擅長去評估這樣的事情。速度的度量可以幫助我們做的更好(請看"團 隊如何決定哪些故事要被放到這次 Sprint 中？")。 或是使用昨日天氣 – 只拉跟你上個 sprint，所完成的數量一樣多 的故事。或者是過往三個 sprint，所完成量的平均值。這樣你的 sprint 就自動會有內建的鬆弛機制，可以讓你去處理中斷事務和程 式補丁。你會自動地避免想做很多事，而改成盡快產生出結果 (如 果你需要相信負擔過重的 sprint 是不好的，那你可看一下任何有 關精實和排隊理論的書籍) 。 不好的方式 - "著重於建構新的東西" "著重於建構新的東西，而不去讓舊的東西能產品化"。誰會去做這樣 的事呢？ 我們一開始就經常犯這樣的錯誤，我確定其他公司也是這 樣。它是一種和壓力有關的病狀。許多經理實際上並不了解它：即 使所有的程式碼都已經完成，你通常還是離產品化很遠。至少複雜 的系統是這樣。所以經理(或是產品負責人)會要求團隊繼續增加新的 東西，可是那些舊的”接近快要發佈”的程式碼的越來越多，那將會 拖垮之後每件事的進行。 我一直驚訝有多少公司掉入這個陷阱中。他們應該做的，就是限制 同時處理的專案或是功能的數目。我曾經看過某些案例，這些公司 就是限制了同時處理的數目，效率毫不誇張地變成了七倍快。想像 一下，同樣多的東西被交付，但是七倍快，沒有更辛苦的工作或是 找更多人，並且品質更好，這都是因為較短的回饋迴圈的緣故。有 點瘋狂，但是這是真的。 不要讓最慢的一個連結從你的環節中斷掉 假設驗收測試是你最慢的連結，你沒有很多測試人員。或是因為令 人沮喪的程式碼品質，導致驗收測試的時間過長。
  • 125.
    我們怎樣做測試 | 117 假設你驗收測試的團隊，每週最多能測試三個功能(不，我們不用"每 週多少個功能"來衡量，我只是使用它來當作例子)。而你的開發人員 能每週開發6 個功能。 它會誘使經理或產品負責人，去規劃每週六個新功能的開發。 千萬不行，最終現實將會讓你嚐到苦頭，並且帶來傷害。 相反的，我們規劃每週做 3 個功能，剩下的時間花在減輕測試的瓶 頸。例如： § 讓一些開發人員作測試人員的工作(哦，他們一定會喜歡你 的…)。 § 實作一些工具和腳本讓測試更容易。 § 增加更多自動化程式。 § 增加 Sprint 的長度，把驗收測試加到 Sprint 中。 § 把有些 Sprint 定義成"測試的 Sprint"，當中所有團隊都變成 驗收測試團隊在做事。 § 僱用更多的測試人員(即使這意味著減少開發人員) 我們曾試過這些解決方案(除了最後一個以外)。最好的長期解決方案 當然是第二和第三點，也就是有更好的工具、腳本和測試自動化。 回顧會議是一個很好的檢討時機點，可以找出你環節中最慢的連結。 如果驗收測試被包含在 sprint 中，那會變成可以自我調整，會比 分開做好。試試看 – 在你的做完的定義中包含驗收測試，看看一 段時間後會怎樣。 回到現實 或許我給你一個錯覺，我們在所有 Scrum 團隊中都有測試人員。並 且我們對每個產品，有一個很大的驗收測試團隊。在每個 Sprint 完 後我們都會發佈，等等。 嗯，事實上我們並沒有。 我們曾經有做到這樣的地步，也看過它的正面影響。但是我們離驗 收品質保證流程所要求的，還差的很遠，我們仍然還有很多東西要 學習。
  • 126.
    118 | SCRUM和 XP 的實戰經驗 的確，我們還有很多要學。
  • 128.
    15我們怎樣處理多個 Scrum 團隊 當你有許多Scrum 的團隊工作在同一個產品時，許多事情會變得比 較困難。這問題是眾所周知的，和 Scrum 實際上沒有太多關係。更 多的開發人員 = 更複雜的狀況。 當在寫這本書時，我已經有許多大型團隊的經驗。可以在 Lean from the Trenches 這本書中，找到詳細的案例。那本書跟我這本 書的風格非常相像。它描述一個 60 人的政府專案，如何組合 Scrum，Kanban 和 XP 的方法來執行。 https://pragprog.com/book/hklean/lean-from-the-trenches 我們(和以前一樣)遭遇過這種狀況。最多的時候，我們大約有 40 個 人在做同一個產品。 主要的問題是： • 要建立多少團隊 • 要如何分配人員到團隊當中 並且，當然還包括團隊之間如何保持同步。 要建立多少團隊 如果處理多個 Scrum 團隊是這麼困難，我們為什麼要這麼做呢？ 為 什麼不把所有人都放到同一個團隊中呢？ 我們曾經有過最大的 Scrum 團隊，大約是 11 個人。它是可以運作的， 但是無法運作的很好。每日的 Scrum 會議往往會拖超過 15 分鐘。團 隊成員不知道其他成員在做什麼，所以有點混亂。Scrum master 很難 讓其他成員都朝著相同目標前進，也不容易找到時間去解決所有回 報的問題。
  • 129.
    我們怎樣處理多個 SCRUM 團隊|121 另外一個方法是把它拆成兩個團隊，但會比較好嗎？ 不一定。 如果團隊對 Scrum 很有經驗並且也很適應，可以用邏輯的方式將產 品規劃藍圖，切割成兩個不同的行動路線，並且他們不會使用到相 同的程式碼。那我會說把它分成兩個團隊是個好的主意。否則我會 考慮把它合成一個團隊，不管大的團隊會有怎樣的缺點。 我的經驗是，寧可團隊數量較少，人數較多。因為團隊個數多，但 人數少，會容易相互干擾。因此要成立小團隊，必須確保他們不會 相互干擾！ 虛擬團隊 對於"大團隊"與"很多團隊"之間的權衡，你怎麼知道您做出了正確還 是錯誤的決定？ 如果你一直持續觀察和仔細聆聽，你可能會注意到"虛擬團隊"的存在。 範例 1：你選擇大的團隊。但是在 Sprint 過程中，從誰和誰在講話的 過程中，你會注意到團隊有效地自行分成兩個小團隊。 範例 2： 你選擇成立三個小團隊。但是在 Sprint 過程中，觀察誰和 誰在講話的過程中，你注意到團隊 1 和團隊 2 會一直在交談，而團 隊 3 工作上比較孤立。
  • 130.
    122 | SCRUM和 XP 的實戰經驗 所以，這代表什麼意思？ 是你團隊切割策略不正確嗎？ 如果不正確， 這樣的虛擬團隊似乎會一直存在下去。如果正確的話，這樣的虛擬 團隊會只是暫時的。 讓我們再看一次範例 1。如果兩個虛擬子團隊一直在改變(也就是， 大家在虛擬子團隊間移動)，那你可以決定把他們放到同一個 Scrum 團隊。如果兩個虛擬子團隊，在整個 Sprint 過程中都待在相同的地 方，你可以在下一個 Sprint 中，把他們拆解成兩個真正的 Scrum 團 隊。 現在再看看範例 2。如果團隊 1 和團隊 2 在整個 Sprint 中都一直在交 談(不是和團隊 3)，你可能在下一個 Sprint 中，要去把團隊 1 和團隊 2 結合成一個團隊。如果在 Sprint 前半段，團隊 1 和團隊 2 一直在交 談; 在 Sprint 後半段，團隊 1 和團隊 3 則一直在交談，你可以考慮把 三個團隊變成一個，或是還是保留原先三個團隊。把這個問題帶到 回顧會議中，讓團隊自己決定。 團隊切割，是 Scrum 其中一個困難的部份。不要想太多，或是花太 多精力去最佳化。先做實驗，對虛擬團隊保持觀察，確認你在回顧 會議中，有足夠的時間去討論這類議題。遲早你會根據你的狀況， 發現最佳的解決方案。最重要的事情是團隊會覺得舒適，不會常常 互相干擾到。 有一個逐漸流行的新進技術：團隊可以根據需要，動態地來改變自 己。我有時候把這個叫做”超級團隊” 模式，或是 ”動態子團隊” 模 式。這個方法最適合以下狀況：當你有 12-16 個人，大家坐在一 起，彼此相互熟悉，一起為相同的產品來努力。給他們一個共享的 產品需求清單，某些人會針對某個故事成立一個小組 (”Pat，Tom 和我現在要處理故事 X” )，當故事處理完後，又動態地重新組成另 外的小組。在實務上，需要有些引導來幫助這件事情發生。當你不 需要一個大的團隊，而且又不能以一個固定的方式，來拆解小團 隊，這樣的作法是最好的。 最佳的團隊大小 在大部分我所讀過的書中，都宣稱最佳團隊的大小大約是 5-9 人。
  • 131.
    我們怎樣處理多個 SCRUM 團隊|123 到目前為止，我所觀察的團隊來說，我同意這個說法。不過我會建 議是 3-8 人。事實上，我相信值得花些代價，去達到這樣的團隊大小。 假設你有一個團隊是 10 個人。考慮把兩個最弱的成員趕出去吧。哦， 我真的有那樣說嗎？ 哈哈。我要怎麼才能避免這樣見鬼的狀況? :o) 然而，我注意到當某些成員放假去後，這個大的團隊進度十分神 速。這並不是因為沒有來的人是很差的成員，而是因為團隊的大小 變成是可管理的，所以溝通和混亂的程度已經減少。 假設你有兩個產品，每個產品都有一個 3 個人的團隊，兩個都進行 的很緩慢。把它變成一個 6 個人的團隊去負責兩個產品，或許是個 好主意。在這個情況，讓其中一個產品負責人離開(或是給他顧問之 類的角色)。 假設你有一個 12 個人的團隊，因為程式碼處於很糟糕的狀況，沒有 方法讓兩個不同的團隊，獨立在上面工作。所以需要認真投入一些 精力，去改進這些程式碼(而不是建立新功能)，直到你可以拆解他們 為止。這些投資你很快就可以得到回報。 這是值得強調的。如果你掙扎於找出對的團隊結構，真正的罪魁禍 首通常會是系統組織的問題。好的系統組織，可以讓團隊移動快 速，並且獨立自主。不好的系統組織，會讓團隊絆倒別的團隊，並 且因為依賴的關係而陷入困境。所以你應該不斷質疑和發展你的組 織和團隊結構。
  • 132.
    124 | SCRUM和 XP 的實戰經驗 是否要同步多個 Sprint？ 假設你有三個 Scrum 團隊，都為同一個產品工作。他們的 Sprint 應 該要被同步嗎？也就是，開始和結束都相同嗎？或是他們應該重疊 嗎？ 我們一開始的方法是有重疊的 Sprints(因為各自時間考量的關係)。 聽起來不錯。在任何一個時間點上，會有一個正在進行的 Sprint 要 結束，或是有一個新的 Sprint 正要開始。產品負責人的工作量，隨 著時間的演進，將會均勻地分佈各個 Sprint 中。系統將會持續不斷 地被發佈，每一週都有展示，哈利路亞！！ 耶，我知道你要說什麼，但是那時候聽起來是蠻有說服力的！ 我們之前一直是這樣做的，直到有一天，我有機會和 Ken Schwaber 對談時(在我 Scrum 認證的時候)。他指出這不是一個好的主意，比較 好的方法是去同步 Sprints。我已經不記得他確切的理由，但是在幾 次討論後，我被說服了。 這是我們後來使用的解決方案，之後沒有覺得後悔或不好。我永遠 不會知道，是否重疊的 Sprint 終究會失敗。但是我認為應該要這麼 做。同步 Sprints 會有以下的好處： § 這裡自然有時間去重新組織團隊 - 在 Sprint 之間的時間！ 在 重疊的 Sprint 中，沒有任何方法可以重新組織團隊，而不干 擾到某一個正在進行 Sprint 的團隊。 § 所有的團隊可以在同一個 Sprint 中，朝著相同目標努力，可 以一起做 Sprint 規劃會議，導致團隊間會有較好的協同合作。
  • 133.
    我們怎樣處理多個 SCRUM 團隊|125 § 較少的管理花費，也就是，較少的 Sprint 規劃會議，Sprint 展示，和發佈。 在 Spotify，雖然我們曾經使用同步 sprint 但後來我們決定讓每個 團隊依它自己速度來運作，可以選擇自己的 sprint 長度 (有些團隊 適用 Kanban 來取代 sprints)。當我們團隊間有很多相依性時，我 們會每天會進行 Scrum-of-Scrums 型態的同步會議，不管每個團隊 原先的節奏是什麼。很難說那一種做法 (同步 sprint 跟非同步的 sprint) 比較好，因為這是跟環境有關的。 為什麼我們要導入"團隊領導"的角色 假設我們一個產品有三個團隊。 那個標記 P，紅色的傢伙是產品負責人。標記 S，黑色的傢伙是 Scrum master。其餘的都是咕噥著…呃…尊敬的團隊成員。 在這樣群星聚集的團隊中，誰要決定哪些人應該在哪個團隊中？產 品負責人是誰？ 這三個 Scrum master 一起搞定嗎？或是讓每個人選 擇他要參加的團隊？ 如果每個人都要待在團隊 1 要怎麼辦？(因為 Scrum master 1 看起太帥了嗎？) 如果後來證明，這確實是不可能有超過兩個以上的團隊，並行處理 這份的程式碼。所以我們必須把 3 個 6 人的團隊，轉變成 2 個 9 人的 團隊。意味著只要 2 個 Scrum masters。所以哪一個 Scrum master 要 被免除頭銜呢？ 這在許多公司都是非常敏感的問題。
  • 134.
    126 | SCRUM和 XP 的實戰經驗 讓產品負責人去作人員的配置或重新分配，是乎很誘人。但是這不 是產品負責人該做的事，對吧？ 產品負責人他是領域的專家，可以 告訴團隊他們應該朝哪個方向運行。他不應該介入這些內部的細節。 尤其是他是"chicken"的話(如果你沒有聽過 chicken 和 pig 的隱喻，可 以 google 一下""chickens and pigs")。 嗯，我討厭那個愚蠢的隱喻 (如果必要的話，你可以 Google 去了 解一下)。由於某些特殊的緣故，以前 Scrum 的世界裏，很流行把 產品負責人視為是局外人，認為他不會去承諾他該做的事。非常令 人反感。儘管如此，我仍然認為產品負責人，不應該去主導團隊結 構的人，因為產品負責人的工作已經夠艱難了。所以，誰應該做這 件事呢？讓我們繼續看下去 … 我們藉由導入"團隊領導"這個角色去解決問題。你可能叫他"Scrum of Scrums master"，"老大" 或是 "首席 Scrum master"等等。他不用去 領導單一團隊，不過他必須負責跨團隊的問題，像是誰應該是團隊 的 Scrum master，人員應該如何被拆解到不同團隊中，等等。 我們花了一段時間，才為這個角色想出好的名稱。"團隊領導"已經是 我們能想出最不糟糕的名稱。 這個解決方案運作的很好，我向你大力推薦一下 (不管你決定要叫這 個角色什麼)。 在我看過的大部分公司，部門經理是負責調整團隊結構的人，所以 沒有需要有個團隊領導的角色 (此外，團隊領導是一個相當混淆的 名稱，它聽起像是只有一個團隊)。然而，最好的方式是經理會找 出一個方法，讓團隊自己組出一個合適的結構，而非是高層指派一 個結構出來。 我們如何配置人手到團隊中 當你有多個團隊在同一個產品工作時，這裡有兩個普遍的策略，來 分配人員到團隊中。 • 讓某個指定的人來分配，例如，我前面所提到的"團隊領導"， 產品負責人，或是功能經理人(functional manager)(如果他參 與的夠深入，他就能做出正確的決定)。 • 讓團隊以某種方式自己進行。
  • 135.
    我們怎樣處理多個 SCRUM 團隊|127 我們嘗試過以上三種方法。三種？ 是的。策略 1 ，策略 2，和兩者 的組合。 我們發現兩者組合的效果最好。 經過多年的實驗，我只能同意。 在 Sprint 規劃會議前，團隊領導需要和產品負責人，以及所有 Scrum master 一起開團隊配置會議。我們討論上一個 Sprint 的狀況，並決定 是否需要重新配置。可能我們要整合兩個團隊，或是把某些人從某 個團隊移動到另一個團隊。我們決定某些事情，把它寫下來，當做 所提議的團隊配置，並把它帶回到 Sprint 規劃會議討論。 在 Sprint 規劃會議中，第一件事就是檢視產品 backlog 中，最高優先 順序的項目。團隊領導可能會說： "嗨，各位，在下一個 Sprint，我們建議以下的團隊配置" "就你們所看到的，這樣意味我們從 4 個團隊減到 3 個團隊。我們已 經列出每個團隊中成員。請大家聚在一起，自己在牆上佔一塊區域" (人們來回在房間內走動，團隊領導耐心地等待。過了一段時間，這 三組人馬，每一個團隊站在一面空牆前面)。 "目前團隊這樣的拆解只是開端！它只是一個起點，以節省大家的時 間。在 Sprint 規劃會議的過程，你可以自由地換到另一個團隊，把 你的團隊猜解成兩個，或是和另一個團隊整合在一起，或怎樣都可 以。根據產品負責人的優先順序，來當作處理事情的基本常識"
  • 136.
    128 | SCRUM和 XP 的實戰經驗 我們發現這樣處理的效果最好。一開始某種程度的中央集權控制， 之後再某種程度的個別最佳化。 這是一個很棒的模式。只是要記住，有很多方法可以做到這件事 – 結合 sprint 規劃會議只是其中一種，並不是最好的。現在，我 通常把團隊配置重組會議和 sprint 規劃會議分開，讓 sprint 規劃 會議更專注 (也就是說，當在規劃 sprint 時，我已經有個穩定的團 隊結構，和穩定的產品需求清單) 。然而，對於大型的專案來說， 把所有 sprint 規劃會議同時在一間大房間內舉行，這是非常有用 的。有時候，一個繁雜的相依關係，藉由把某個人換到某個團隊 (暫時或是長期)，事情就很簡單地被解決了。 要不要有特別的團隊？ 假設你的技術由三個主要元件所組成： 並且假設你有 15 個人為這個產品工作，若是你不想把他們都放在同 一個團隊，那你會怎樣組織你的團隊呢？ 方法 1： 特定元件的團隊 有一個方法是建立特定元件的團隊，像是"用戶端團隊"，"伺服器端 團隊"，和"資料庫團隊"。
  • 137.
    我們怎樣處理多個 SCRUM 團隊|129 我們一開始這樣做，不過運作的不是很好，至少當大部分的故事包 含許多元件時，就不太好。 例如，假設我們有一個故事叫"留言板，使用者可以留下訊息給其他 人"。這個留言板的功能，包括更新用戶端使用者界面，在伺服器端 新增邏輯，在資料庫內加些表格。 這意味著所有三個團隊 - 用戶端團隊，伺服器端團隊，和資料庫團 隊 - 必須協同合作去完成這個故事。所以並不是太好。 在很多公司裡，這是一個超級常見的問題！
  • 138.
    130 | SCRUM和 XP 的實戰經驗 方法 2： 跨元件的團隊 第二個方法是建立一個跨元件的團隊，也就是，團隊不會被約束在 任何特定的元件上面。 如果你的許多故事都包含多個元件，這種形式的團隊切割策略都可 以運作的不錯。每個團對可能實作一個完整的故事，包含用戶端， 伺服器端，以及資料庫端。所以團隊可以運作地更獨立，那是一件 好事。 當我們實施 Scrum 時，其中第一件事就是把現存特定元件的團隊打 散(方法 1)，並且建立跨元件的團隊(方法 2)。減少了像這種狀況的 發生次數："我們無法完成這個項目，因為我們必須等待伺服器端的 人完成" 在我工作過的每家公司，幾乎都有相同的故事發生。把特定元件團 隊重組成跨元件團隊是相當有破壞性，但是好處會是相當大的！ 然而，當真的有強烈的需求時，我們有時候也會成立，臨時的特定 元件的團隊。 有時候，特定元件團隊是合理的，即使是長期來說也是。但是，這 應該是例外，並且正常。一個好的檢驗問題：“誰是我們的客戶？ 我們可以實現他們的需求，並且不會阻礙了其他團隊嗎？“ 在大部
  • 139.
    我們怎樣處理多個 SCRUM 團隊|131 分的狀況，跨元件團隊不會有問題，而特定元件團隊則會有問題。 最常見的案例是內部導向的團隊，像是工具或是平台團隊 (例如： 伺服器端的基礎架構團隊)，他們把其他團隊(跨元件團隊)視為是 他們客戶。較大的公司通常這兩者的混合體：也就是對外是跨元件 團隊，但是對內是特定元件團隊。因此沒有所謂的銀製子彈，需要 持續不斷地實驗！ 是否在 Sprints 之間重新組織團隊？ 每個 Sprint 基本上都是相當不一樣的，這是因為在每個階段時，所 擁有的較高優先順序的故事並不相同。因此，在每個 Sprint 中，最 佳的團隊組成也就不同。 事實上，幾乎在大部分的 Sprint 中，我們發現我們自己，可能會說 像這樣的話："這個 Sprint 不是一般的 Sprint，因為…"。在一段時間 後，我們放棄了"一般"Sprint 的概念。沒有所謂的一般 Sprint，就像 沒有所謂的"一般"家庭或"一般"人一樣。 在這個 Sprint 中，有一個用戶端團隊隊可能是件好的主意，它由非 常懂用戶端程式的人所組成。下一個 Sprint，有兩個跨元件的團隊也 可能是件好的主意，把懂用戶端的人拆散到這兩個團隊中。 "團隊凝聚力"是 Scrum 重要的關鍵之一，也就是，如果團隊要一起 工作好幾個 Sprints，他們通常會變得非常緊密。他們會學習到如何 達成團體心流(group flow)，並達到令人難以置信的生產力水準。但 是需要花幾個 Sprint 才能做到。如果你持續變換組織，你將無法達 到真正的團隊凝聚力。 所以，如果你要重新組織團隊，請確認你考慮過後果。它是長期的 改變還是短期的改變？如果它是短期的改變，那就考慮忽略它。如 果它是長期的改變，那就進行吧。 這裡會有個例外︰當你對大型的團隊，第一次開始進行 Scrum。在 這種情況下，值得對團隊的拆解做些實驗，直到你找到每個人都滿 意的答案。並且要確認每個人都了解，在前幾次犯些錯誤是可以被 接受的，只要你能持續改進。
  • 140.
    132 | SCRUM和 XP 的實戰經驗 經驗法則：經過幾次迭代後，你團隊的組成應該相當穩定。也就是 說，對於任何團隊，至少一季的時間，他們的關係不會改變 (沒有 人加入或移出)。如果團隊組織常常改變，他們可能無法達到 Scrum 想要的超級生產力。然而，如果改變來自內部 (由團隊成員 提出)，通常殺傷力比上面的狀況(外部提出)小。因此，如果你是 部門經理，試圖拒絕干擾團隊的誘惑。讓大家專注於工作，鼓勵團 隊組織穩定。但是要讓大家可以在有需求時，自己決定轉調團隊。 你將會很驚訝這樣所帶來的成效！ 兼職的團隊成員 我可以確認很多 Scrum 的書上說 - 一般而言，Scrum 團隊中有兼職的 成員，這並不是一個好的主意。 … 就像上面說的，它真的是糟！ 假設 Joe 是 Scrum 團隊的兼職成員。在他進來之前，請先仔細考慮 一下，你真的需要 Joe 到你的團隊嗎？你確定 Joe 不能作全職嗎？那 他其它時間在做什麼？有人能幫忙他做他的其它工作嗎？好讓 Joe 在 其他工作中變成被動或是支援的角色？在下個 Sprint 中，能讓 Joe 在 你的團隊中是全職，並且同時把他的其他工作轉給別人嗎？ 有時候就是沒有其他方法。你非常需要 Joe，因為他是目前這棟大樓 唯一的 DBA，但是其他團隊也非常需要他，因此他很難把所有時間 都用在你們團隊上面。此外公司也沒有辦法僱用更多的 DBA。好的， 這種狀況下只好讓他可以兼職工作(這剛好是發生在我們身上)。但是， 要確定每次你都有做這樣的評估。 一般而言，我寧可要一個團隊中有 3 個專職，也不要有 8 個兼職。 如果有一個人需要把它的時間分配到多個團隊，像是上面提到的 DBA，最好讓他主要隸屬於某一個團隊。找出哪一個團隊最需要他， 把它當作他的"主要團隊"。當沒有人急著需要他，他可參加這個團隊 的每日 Scrum 會議、Sprint 規劃會議、回顧會議等等。 經驗法則：專職意味著至少有 90% 的時間專注於這個團隊上面， 兼職則大約是 50-90% (”這是我的主要團隊，但是我還有別的承 諾”)。小於 50% 不能算是團隊的一份子 ( ”我可以偶爾支援你們，
  • 141.
    我們怎樣處理多個 SCRUM 團隊|133 但是我並不是你們團隊的一份子，不要老是依賴我”)。如果團隊中 只有一個兼職，其他都是專職，那就不用擔心。然而，如果有超過 一個以上的兼職，你需要考慮重新組織，或是減少同時在進行的工 作量，讓一些兼職員工可以變成專職。多工是一頭怪獸，它會讓殺 死生產力，積極性和品質，所以盡量保持最小的同時工作量吧！ 我們如何進行 Scrum-of-Scrums Scrum-of-Scrums 基本上是一個經常性的會議，所有的 scrum master 聚在一起談話。 在某個時間點，我們曾經有 4 個產品，其中 3 個產品都各自有一個 Scrum 團隊，最後一個產品有 25 個人，分成好幾個 Scrum 團隊。像 是以下的狀況： 這意味著我們有兩個層次的 Scrum-of-Scrums。我們有一個"產品層次 "的 Scrum-of-Scrums，由產品 D 中的所有團隊組成。另外有一個"群 體層次"的 Scrum-of-Scrums，由所有產品組成。 產品層次的 Scrum-of-Scrums 這個會議非常重要。我們每週舉行一次，有時候可能頻率更高。我 們討論整合的問題，團隊平衡的問題，為了下次 Sprint 規劃會議的 準備，等等。我們保留了 30 分鐘，但是經常超過。另外一個方法是 每天都有 Scrum-of-Scrums，但是我們沒有試過這樣。
  • 142.
    134 | SCRUM和 XP 的實戰經驗 我們 Scrum-of-Scrums 的議程 1)圍繞著桌子，每個人描述他們團隊上週完成什麼，什麼計劃將要 本週完成，以及他們遇到什麼困難。 2)任何其他需要被提到的跨團隊的問題，例如整合的問題。 對我來說，Scrum-of-Scrums 的議程不是很重要，重要的事情是你要 定期舉行 Scrum-of-Scrums 會議。 在 Spotify 公司，在不同團隊間，通常我們為了某件事情大家聚在 一起，以 “每日同步” 的方式來實踐 Scrum-of-Scrums。這是一個簡 短的會議，通常最長是 15 分鐘。會議的議程是著重於團隊間相關 的問題，而非是狀態更新。例如，某個團隊遇到阻礙時，會有人說 他需要另一個團隊幫忙什麼之類的等等。我們有時會一個簡單的白 板，上面有些便利貼，來追蹤一些未解決的跨團隊問題。這個會議 變成像是一個小型的市集，用來找出需要同步的需求。同步的需求 本身各自發生的 – 這個會議只是幫助我們找出，誰需要跟誰去談 談，以解決目前這個關聯性的問題。 群體層次的 Scrum-of-Scrums 我們稱這會議叫做"脈動"。我們曾經試過各種不同的形式，邀請不同 的參與者。後來，我們已經放棄整個概念，而是用每週所有人開會 來代替(是的，所有一起開發的人)，15 分鐘長的會。 什麼？ 15 分鐘？ 所有人？ 所有產品，所有團隊的所有人？ 這可行 嗎？ 是的，只要你(或是其他主持會議的人)嚴格確保會議不要太長，那就 可行。 會議的形式像是： 1) 由開發主管來更新或公佈訊息。像是即將發生的事件。 2) 依序報告，每個產品小組有個人報告他們上週完成什麼，他們本 周計劃完成什麼，以及有什麼問題。其他人也會報告(建構管理的 lead，QA Lead 等等)。 3)任何人自由去補充任何訊息，或是問問題。
  • 143.
    我們怎樣處理多個 SCRUM 團隊|135 這裡是用來簡述團隊訊息的論壇，不是用來進行討論，或是反思的。 只要只剩這件事，15 分鐘通常夠用。有時候我們會超過，但是很少 超過 30 分鐘。如果有些熱烈的討論出現，我會中斷它，請有興趣的 人在會議結束後繼續這個討論。 為什麼我們要舉行全體的脈動會議？ 因為我們注意到，"群體層次" 的 Scrum-of-Scrums 內容大多是報告而已。我們很少有真正的討論。 此外，許多其他團隊組織外面的人，很渴望知道這類型的資訊。基 本上，每個團隊想知道其他團隊在做什麼。所以我們想既然花時間 聚在一起來分享這些訊息，那為什麼不讓所有的人都參加呢？ 正如你所看到的，Scrum-of-Scrums 的組成是跟環境有關聯的，這 絕對沒有一個放諸四海皆準的做法。有時候我會被這種狀況給嚇 到：公司每週 (或是每一天) 會進行一些相當無聊，沒有效率的會 議。大家目光呆滯，死盯著天花板。好像在念劇本一樣，喃喃自語 地在更新目前狀態。不要做一個 Scrum 的殭屍！做些改變吧！進 行一些實驗！不斷詢問大家問題，像是 ”這個會議真的有幫助嗎？ 它可能可以增加更多的價值嗎？我們要做什麼改變去讓他更有價值 呢？” 人生苦短，不要浪費在無聊的會議上。 交錯的每日會議 如果你在單一產品中有許多 Scrum 團隊，而且他們都在同一時間朝 開每日 Scrum 會議，你將會有很大的問題。產品負責人(和我像這樣 好管閒事)每天只能參加某個團隊的每日會議。。 所以我們要求團隊，避免在相同時間去朝開每日會議。 以上是一個開會時程的範例，我們朝開每日會議在不同的房間，而 不是在團隊的房間。會議通常是 15 分鐘，但是為每個團隊在每個房 間都有保留 30 分鐘，如果他們需要多一點時間。。
  • 144.
    136 | SCRUM和 XP 的實戰經驗 這方法相當有用的，理由有二。 1. 像產品負責人或是我自己，在早晨會去參加所有每日會議。 若是你要清楚知道每個 Sprint 的進度，以及關鍵的風險是什 麼，沒有什麼方法能比這個更好。 2. 團隊可以參加其他團隊的每日會議，這通常不太會發生。不 過當有兩個團隊在類似的環境下工作，有些成員會造訪其他 團隊的每日 Scrum 會議，以保持資訊的同步。 這方法的缺點是團隊的自由度變小 - 他們不能選擇任何他們喜歡的 時間來舉行每日會議。不過這還沒變成是我們的問題。 這有點困擾我。每日會議主要的目的，是讓團隊成員和其他人同步 資訊。他們應該找一個時間來進行，讓有些愛講話的人也在其中。 例如說我 – 好的，這是次要的。所以，是的，能有交錯的每日會 議是很不錯，但是不需要強迫團隊要這樣做。 救火團隊 我們曾經遇到一個狀況，一個很大的產品無法採用 Scrum，因為他 們花太多時間在救火。也就是修復之前貿然出貨的系統，所產生的 錯誤。這真的惡性循環，他們忙於救火，所以他們沒有時間主動去 做些事情，來預防火災(像是改進設計、自動化測試、建立監控工具 與警報工具)。 我們藉由建立一個專門的救火團隊，和專門的 Scrum 團隊，來解決 這個問題。 Scrum 團隊的工作是(帶著產品負責人的祝福)試圖去有效率地穩定系 統，預防事情惡化。 救火團隊(事實上我們叫它"支援團隊")有兩項工作。 1) 救火 2) 保護 Scrum 團隊免於各式各樣的干擾，包括擋掉那些不知從哪裡 來的，任意功能的請求。 救火團隊可放在最靠近們邊的地方，Scrum 團隊可以放在房間的最裡 面。所以救火團隊可以物理上保護 Scrum 團隊，免於著急的銷售人 員或是生氣的客戶的干擾。
  • 145.
    我們怎樣處理多個 SCRUM 團隊|137 在兩邊都會安插資深的開發人員，所以某一個團隊不會太依賴另一 團隊的核心人員。 基本上，它是去解決 Scrum 自我驅動(bootstrapping)問題的一種嘗試。 如果團隊一次無法規劃超過一天的工作，那要如何開始進行 Scrum 呢？ 我們曾經提過這樣的解法：我們的策略是把它拆成兩個群組 (Scrum 團隊和救火團隊)。 這方法運作的非常好。因為 Scrum 團隊有空間能努力工作，所以他 們最後能穩定系統。在這期間，救火團隊完全地放棄事先規劃的念 頭，他們只是根據外面的需求來運作，單單只修復下一個出現的問 題。 如果我當初知道看板，我絕對會使用 Kanban 來處理救火團隊的事 情。 當然啦，Scrum 團隊也不是完全不被干擾。救火團隊經常會請 Scrum 團隊的關鍵人員來幫忙，或最糟時，需要整個團隊的幫忙。。 但不管如何，在幾個月後，系統已經足夠穩定，所以我們可以解散 救火團隊，並建立額外的 Scrum 團隊。救火隊員會很高興把壓扁的 頭盔放在一旁，然後加入 Scrum 團隊中。 這是很好的模式，但這只是臨時的危機管理策略。正常來說，你不 應該需要一個單獨的救火團隊。如果你把救火團隊跟其他人隔離， 他們就沒有機會去學習新的東西，好讓他們之後可以預防新的問 題！反之，如果你老是需要處理錯誤或是救火 (就像每間公司一 樣)，這需要讓團隊思考該如何處理這個狀況。大部份的團隊內， 最後會有些輪流的救火隊員。這非常簡單而有效。因為它有一個很 明確的誘因，有段時間只寫程式，但是不用救火。 是否要拆解產品 backlog？ 假設你有一個產品和兩個 Scrum 團隊。那應該有多少產品 backlog？ 多少的產品負責人呢？ 我們為此曾經評估過三個模型。選擇結果對 Sprint 規劃會議的進行有很大的影響。
  • 146.
    138 | SCRUM和 XP 的實戰經驗 策略 1： 一個產品負責人，一個 backlog 這裡是"只能有一個"的模型。是我們最推薦的模型。 這個模型的優點是，讓團隊根據產品負責人目前的優先順序，來管 理他們自己。產品負責人只需著重於他所需要的，而團隊則決定如 何拆解工作。 更具體一點，這裡有個團隊 Sprint 規劃會議如何運作的方式： Sprint 規劃會議在外面的會議中心舉行。 在會議開始之前，產品負責人指定一面牆，當作"產品 backlog 的牆 壁"，並且把故事放上去(用索引卡的方式)，依照相對的優先順序來 排序。他會放到直到牆壁被擺滿為止，通常會比一個 Sprint 要做的 項目還要多。
  • 147.
    我們怎樣處理多個 SCRUM 團隊|139 每個 Scrum 團隊選擇一面空的牆，並且貼上自己團隊的名字。這是 他們的"團隊牆壁"。每個團隊會從產品 backlog 的牆壁拿取一些故事， 把這些索引卡貼到他們自己團隊的牆壁。 下面這張照片可以說明一切。黃色箭頭表示故事的索引卡，如何從 產品 backlog 牆壁，移到團隊牆壁的過程。
  • 148.
    140 | SCRUM和 XP 的實戰經驗 在會議的過程中，產品負責人和團隊對於索引卡進行討價還價，把 他們在團隊間移動，移上移下來調整優先順序，或是把它們拆解成 更小的項目，等等。再經過一小時左右，每個團隊在他們的團隊牆 壁上，有第一個 Sprint backlog 的候選版本。隨後團隊獨立工作，進 行時間估算和把故事拆解成任務。 這會相當的吵雜、混亂、和令人筋疲力盡。但是效果不錯，相當有 趣，可以相互聯誼交流。當時間到時，所有團隊通常已得到足夠的 訊息，讓他們可以開始下個 Sprint。 這個模式變成越來越普遍；甚至它被放到一些新的敏捷開發框架 中，像是 SAFe(Sacled Agile Framwork)。最近在 LEGO，我們進行 了兩天的規劃會議，一共超過 140 人！有時候，這樣規劃的技巧 被拿來當作臨時的措施，長達了半年之久。直到我們找到合適的團 隊組織和結構，才能更獨立地進行 sprint 規劃會議。 策略 2： 一個產品負責人，多個 backlog 在這個策略中，產品負責人維護多個產品的 backlog，每個團隊對應 一個。我們沒有真的試過這個方法，但是我們差點這樣做。如果第 一個方法失敗時，基本上這是我們的備援計畫。 這個策略的缺點是，產品負責人需要分配故事給團隊，這件事情可 能團隊自己做會比較好。
  • 149.
    我們怎樣處理多個 SCRUM 團隊|141 典型地，產品負責人在這種狀況下變成是一個瓶頸。 策略 3：多個產品負責人，每個人負責一個 backlog 這個和第二個策略有點像，每個團隊有一個產品 backlog，但是每個 團隊也只有一個產品負責人！ 我們並沒有用這個方法，可能也永遠不會使用。 如果兩個產品 backlog 包含相同的程式碼， 將會造成兩個產品負責 人之間嚴重的衝突。
  • 150.
    142 | SCRUM和 XP 的實戰經驗 如果兩個產品 backlog 能分開程式碼，這樣做和把產品拆成兩個子產 品獨自運作並沒有兩樣。這意味著我們回到了每個產品一個團隊的 解決方案，這將非常輕鬆和容易。 這個模式曾經在 Spotify 使用。每個超過 70 個人的團隊，有它自 己的產品負責人和產品需求清單。事實上，在某些狀況下，我們還 是有點是在使用策略 1 (多個團隊共享一個產品需求清單)。但是對 於大部份其他團隊，他們有他們自己的產品負責人和產品需求清 單。好處是我們很少需要大型的規劃會議。壞處是我們需要付出許 多代價去拆解架構，好讓這種情況可以發生。跟所有事情一樣，總 是有好有壞。因此，就繼續吧，呃…… (我本來要說 “繼續嘗試”， 但我已經說了很多遍了……我不想一直重複，是吧？) 程式碼分支 當多個團隊同時在相同的程式碼上工作，我們不可避免地，必須利 用 SCM(軟體建構管理工具)來處理程式碼的分支。有很多書籍或是 文章在教你如何處理，多個人在相同的程式碼上工作，所以這裡我 不再多談任何細節。我沒有任何新的東西，或是革命性的見解。但 是，我將簡述到目前為止，我們團隊所學到的一些重要的經驗。 § 應該要嚴格保持 mainline(或是 trunk)在一致的狀態。這意味 著最起碼，每件事應該要被編譯，所有的單元測試要被通過。 在每個時間點，應該都可以產生一個可運作的發佈版本。最 好這個持續建構的系統在每天晚上可以進行建構，並自動部 署到測試環境中。 § 每個發佈都打上標記(tag)。無論你何時發佈到驗收測試環境 或是到產品環境，要確認在你的 mainline 中打上版本的標記， 用來準確辨識什麼東西被發佈。這意味在未來任何時間，你 可以退回到之前某個時間點，建立一個可維護的分支。 § 在僅需要的時候才建立新的分支。這裡有一個好的規則： 當 你在不違反 codeline 的政策下，是無法使用現存的 codeline， 這時候就可以分支一個新的 codeline。當有疑問時，就不分 支。為什麼？ 因為每次分支，將導致複雜度和管理成本增加。 § 使用分支主要是為了切割不同的生命週期。你可能會或可能 不會，決定每個 Scrum 團隊能在他們自己的 codeline 進行編
  • 151.
    我們怎樣處理多個 SCRUM 團隊|143 碼。但是如果你把短程的修復和長程的改變放在同一個 codeline，你將會發現,那是非常困難去發佈短程的修復！ § 經常同步。如果你在分支上工作，每當你某些事情可以建構， 要 記 得 同 步 回 mainline 。 每 天 當 你 要 開 始 工 作 時 ， 把 mainline 的程式同步到分支上去。所以你的分支才能及時， 以反映其他團隊的改變。如果因為合併的痛苦，導致你接受 先不合併。不過，越等下去，將會使這狀況越來越糟糕。 是的，這個建議仍然有效 (除了經常標記外，你現在可以在大多 系統上獲得此建議)。使用近代的版本控制系統 (像是 Git)，沒有 理由不經常執行 commit，以保持分支乾淨。經常發佈，並確保 分支不要太久。我曾寫過一篇文章叫 “Version Control for Multiple Agile Teams”: http://www.infoq.com/articles/agile-version-control 我覺得像 Git 這樣的系統，被稱為去中心化的版本控制系統，是 有點好笑。因為大多專案都仍然是單一集中的 repo，每個人都 push 到這個 master branch，在那裡來進行發佈。雖然都是用 Git，但是觀念是不同的。 :o) 多個團隊的回顧會議 當有多個團隊在同一個產品中，我們要如何做 Sprint 回顧會議呢？ 在 Sprint 展示一結束後，大家鼓掌，每個團隊走回去他們自己的房 間，或是辦公室外某個舒服的地方。他們進行回顧會議的方式，和 我之前在"我們如何進行 Sprint 回顧會議"中，所描述的沒有太大的不 同。 在 Sprint 規畫會議期間(因為我們已經同步每個產品的 Sprint，所以 所有團隊都參加)，第一件事情我們從每個團隊中找出一個發言人， 站起來簡述她們回顧會議中所得到的重要結論。每個團隊花 5 分鐘。 然後我們有 10-20 分鐘的開放討論。之後休息一下，再開始真正的 Sprint 規劃會議。 對於多個團隊的狀況，我們還沒試過其他方法，目前這方法已經足 夠了。不過最大的缺點是，在 Sprint 回顧會議後，及 Sprint 規劃會議 前，沒有任何鬆弛的時間。(請看"Sprint 之間的休息時間")
  • 152.
    144 | SCRUM和 XP 的實戰經驗 沒錯，這是一個很大的缺點! 因此，到目前為止，在有相依性的多 團隊中，我偏愛在回顧會議中進行回顧總結。那就是每個團隊先去 進行自己的回顧會議，大約一小時之後，我們所有人在大會議室中 集合，每個團隊總結他們回顧會議的關鍵結果，列出他們最重要沒 有解決的障礙。當聽完每個團隊的報告後，通常可以清楚地看到障 礙 X 是我們最大的跨團隊的障礙 (例如，“各個團隊之間對做完的 定義不一致” 或 “trunk 老是有問題”)。這是一個絕佳的時機，讓大 家來進行迷你工作坊。或者是找一些志願者(例如，每個團隊出一 個人，再加上經理)，一起來找出解法。有時候，他們會在幾小時 內弄清楚，這對第二天的 sprint 規劃會議很有幫助。 對於只有單一團隊的產品，我們在 Sprint 規劃會議中，沒有需要做 任何回顧的總結。沒有必要是因為每個人都實際出席了回顧會議。 俗話說，脈絡為王。尤其面對不同團隊大小更是如此! 沒有一種能適 用所有地方的解法 – 任何方法都可能非常成功，或是完全失敗。 一 切視情況而定。 不過，我發現一些重要的共同點: 組成跨職能團隊，視覺化你的工 作，經常交付，邀請實際用戶參與，自動化你的測試和發佈流程， 以及常常進行實驗。這些確實是敏捷的基本原則。
  • 154.
    16 我們如何管理分散在不同地理位置上的團隊 當團隊成員在不同地理位置時，那要該怎麼辦呢？ 大多數 Scrum和 XP 的魔力所在，就是需要團隊成員聚集在一起緊密地合作，可以搭 檔編程，以及每天面對面溝通。 我們有一些在不同地理位置的團隊，也有些團隊成在常常在家裡工 作。 我們的策略相當簡單。我們的方法是，把物理上分散的團隊成員， 之間的溝通頻寬增加到最大。我並不是意味每秒多少 Mega bit(當然 這也很重要)這樣的頻寬，我是指更廣義的溝通頻寬： § 能夠搭檔編程在一起的能力。 § 在每日會議時能面對面溝通的能力。 § 隨時能面對面討論的能力。 § 能實際上見面和交流的能力。 § 能主動和整個團隊開會的能力。 § 對於 Sprint backlog，Sprint 燃燒圖，產品 backlog 和其他訊息， 有著相同理解的能力。。 還有一些我們已經規劃(或正在規劃，但還沒有用到)的方法： • 在每個工作站前都有網路攝影機和耳機。 • "遠端能力"的會議室具備有：網路攝影機，會議用的麥克風， 隨時可用的電腦，桌面分享軟體，等等。 • "遠端視窗"。在每個地方有個大的螢幕，用來顯示其它地方 的固定畫面。有點像兩個公寓間的虛擬窗口。你可以站在那 裡，並且揮揮手。你可以看到誰站在桌子面前，誰和誰在交 談。這可以讓我們有”嘿，我們是在一起”的感覺 • 交換的方案。每隔一段時間，來自每個地方的人要旅行去拜 訪對方。
  • 155.
    我們如何管理分散在不同地理位置上的團隊| 147 利用這些技巧或是其它更多方法，雖然速度不快，但是我們可以確 定地知道，在地理位置不同的團隊成員間，如何去進行 Sprint規劃 會議，展示，回顧會議，每日會議，等等。 分散式團隊無所不在(因為全球化也不得不分散)。大部分的開源專 案都是由分散式的團隊所組成。因此，無疑地，這是做得到的。但 是，沒有什麼比得上坐在同一房間內的跨職能團隊更有生產力，他 們 100% 專注於單一共同的目標。所以第一優先是去打造這樣的 環境，或者是盡可能地接近。如果你不可避免地讓團隊成員分散在 各地，則上面列出的工具和技巧，是可以減輕損失的好方法。因 此，不要小氣，用錢買最好的工具! 或許你可能無法像，在同一地 的團隊那麼有生產力，但是那會讓你感到變得親密點。 和其他方法一樣，所有一切都要經過不斷地實驗。 檢視 ==> 調整 ==> 檢視 ==> 調整 ==> 檢視 ==> 調整 ==> 檢視 ==> 調整 ==> 檢視 ==> 調整 境外經營 我們有幾個境外經營的團隊，已經嘗試如何使用 Scrum，來有效率 地處理事情。 這裡我們有兩個主要的策略： 分散的團隊或是分散的團隊成員。。
  • 156.
    148 | SCRUM和 XP 的實戰經驗 第一個策略，分散的團隊。它是一個被迫的選擇。無疑的，我們由 第二個策略開始，也就是分散的團隊成員。以下是我們考量的原 因：。 1. 我們希望團隊成員能夠彼此相互了解。 2. 我們希望兩個地方能夠有很好的溝通機制，並且讓團隊有強 烈的動機，讓這個機制建立好。 3. 在剛開始的時候，境外經營的團隊比較小，無法自己組成一 個有效的 Scrum 的團隊。。 4. 在獨立的境外經營團隊能運作前，我們會有一個時間需要緊 密的分享相關訊息。 長期來看，我們很可能會走向"分散團隊"這個策略。
  • 157.
    我們如何管理分散在不同地理位置上的團隊| 149 這是一個相當不錯的整體策略。長期來說，你會真的希望團隊在同 一地方，因為分散式的團隊無法有那樣的 ”團隊精神”。因此，最初 即使你只能有一個分散式團隊，也要持續尋找方法，在每個位置建 立不同獨立的團隊。你還要處理兩個團隊之間的相依性以及溝通問 題，但這是一個容易處理的問題。除了改善日常溝通外，其中一個 關鍵因素是做事的動機，把團隊成員都放都一個房間會很有趣，會 刺激他們更快地打造出更好的東西。 在家工作的團隊成員 有時候，在家工作是相當不錯的。你有時候在家一天可以完成，在 辦公室一個禮拜都完成不了的程式。如果你沒有小孩的話 ：o) 但是，在 Scrum 中有一個基本原則，整個團隊應該要在相同的場所 工作。所以那我們會怎麼辦呢？ 基本上，我們讓團隊自行決定，什麼時候，或多久可以在家工作。 有時候團隊成員因為距離辦公室太遠，所以會常常在家工作。但是， 我們還是鼓勵大部分的時間，是在相同的位置工作。 當團隊成員在家工作，他們需要用 Skype(有時候用錄影)來參加每日 會議。他們每天藉由即時通訊軟體，來保持隨時在線上。雖然沒有 像在同一個房間一樣好，但是已經不錯了。 如今，有很多非常酷，並且價格合適遠距辦公系統可用。例如，在 http://doublerobotics。com 上可以找到 Double Robotics。他的所 賣的產品，可以使 iPad 有再加上風火輪的效果。它很像是 Skype 的通話，但是你可以在遠端到處移動! 我越來越頻繁地使用它，它 讓我感覺我真的轉移到另一個地方！ 我們曾經試過把星期三當作聚焦日的想法，基本上這意味著"如果你 要在家裡工作，那是可以的，但是只能是禮拜三，並且要團隊許可 才行"。在我們試過的團隊中，它運作的還不錯。通常大部分的團隊 星期三待在家裡可以做很多事情，同時還可以合作的很好。因為它 僅有一天，團隊不會因此而太久無法和其他人同步訊息。不過因為 某種原因，這個做法沒有在其他團隊中流行起來。
  • 158.
    150 | SCRUM和 XP 的實戰經驗 整體而論，在家工作的成員，對我們來說已經不是問題。 自組織團隊是 Scrum 其中一個關鍵的做法。這件事的重要性是不 能被小看的。團隊要盡可能地被賦予更多責任，包括工作時數，以 及在家工作的政策。自組織是 創造力，動力，創新能力，和其他 美好事物的關鍵！有些經理害怕團隊會濫用這樣的信任，但是在實 務上，我很少看到這樣的事情發生。只要團隊明確清楚地知道，他 們要負責交付的是哪個產品，他們就會採取負責任的行動。
  • 159.
    17 Scrum master 的檢查清單 在最後這個章節，我要介紹我們Scrum master 的"檢查清單"，它列出 Scrum master 大部分常見的管理事務。這些事情很容易被遺忘。我們 不列出一些顯而易見的東西，像是"消除團隊的障礙"。 另外，請查看 Scrum 檢查清單 https://www.crisp.se/gratismaterial-och-guider/scrum-checklist 它是一份正式的非官方的 Scrum 檢查清單，但是它已廣泛地被使 用，你可能會說它已經非正式地成為官方的 Scrum 檢查清單。 :o) Sprint 開始階段 § 在 Sprint 規劃會議之後，建立一個 Sprint 訊息的頁面。 o 在 wiki 上的數位表，增加一個連結到你的頁面。 o 印出這個頁面，把它貼到牆壁上，人們經過你的團 隊時可以看到。 § 寄出郵件給每個人，公佈一個新的 Sprint 要開始。包括 Sprint 的目標，和指向 Sprint 訊息頁面的連結。 § 更新 Sprint 的統計文件。加入你的估算速度，團隊大小，和 Sprint 的長度等等。 每一天 § 確定每日 Scrum 會議準時開始和結束。
  • 160.
    152 | SCRUM和 XP 的實戰經驗 § 為了確保 Sprint 能準時完成，需要從 Sprint backlog 中增加 或移除些故事。 o 確保產品負責人有被通知到這些改變。 § 確保團隊能保持 Sprint backlog 和燃燒圖能被及時更新。 § 確保問題/障礙能被解決，或是報告給產品負責人和開發主 管。 在 Sprint 結束的時候 § 進行一個公開的 Sprint 展示。 § 每個人在一天或兩天前，就要被通知有一個展示。 § 和整個團隊以及產品負責人，進行 Sprint 回顧會議。也邀請 開發主管，他可以幫助擴展所得到經驗教訓。 § 更新 Sprint 統計文件。加入真實的執行速度，以及回顧會議 中關鍵的結論。 不錯的小清單。隨著時間的推移，身為 Scrum Master，試著讓你 自己變得多餘，指導團隊能在沒有你的狀況下把事情做完。即使你 沒辦法成功地讓自己變得多餘，單光這樣的嘗試，也會引導你做對 事。有些 Scrum Master 最終變成 Scrum 管理員或者是 Scrum 奴 隸，因為他們熱衷於取悅團隊。如果團隊過分依賴你，那實際上是 你在阻礙他們培養自組織的能力。剛開始時，團隊不熟悉 Scrum 且需要你幫忙的時候，可能覺得這樣不錯。但隨著時間的演進，你 應該慢慢地不要介入管理，並賦予團隊更多的責任。這會節省你尋 找障礙的時間，或是讓你有空做些非 Scrum Master 的事情，像是 寫程式或測試等等。
  • 161.
    18 臨別贈言 喔！ 從來沒有想到，已經花了這麼長的時間。 不管你是剛學 Scrum，或者是一位經驗豐富的老將，我都希望能帶 給你一些有用的想法。 因為Scrum 需要根據不同的環境，加以特別的客制化，所以在一般 的狀況下，是很難在最佳的實踐上，有建設性的爭論。但不管如何， 我都很有興趣聽到你的回應。請告訴我，你的方法和我不同之處。 給我一些建議要如何改善！ 可透過 henrik.kniberg@crisp.se 隨時與我聯繫。 哦，這解釋了為什麼我會收到這麼多電子郵件… 我非常感謝您的 回饋，但是如果我不回复，希望不會冒犯到你，因為有時我也想有 自己的生活。 ：o） 我同時也會留意 scrumdevelopment@yahoogroups.com 的信件 如果你喜歡這本書，你可能也會不時檢查我的 blog。我希望能寫一 些有關 Java 和敏捷軟體開發部份的文章。 http：//blog.crisp.se/henrikkniberg/ 現在，這個部落格上有很多文章，影片和資料！不只我的東西而 已，還有我 Crisp 同事以及各種合作夥伴和朋友的資訊。 老實說，這裡是個金礦！ 我在 Twitter 上也很活躍喔（@henrikkniberg）
  • 162.
  • 164.
    推薦閱讀 以下這些書籍，帶給我許多啟發和想法。高度推薦！ 嗯 ... 我真的應該更新這裏。從2007 年以來，我讀了許多有趣的 書！但這需要在某個時間點單獨發表。 #cliffhanger
  • 166.
    關於作者 Henrik Kniberg (henrik.kniberg@crisp.se)是在斯德哥爾摩Crisp 公司 (www.crisp.se)的顧問，擅長於 Java 和敏捷軟體開發。 如今，我更像是某種管理顧問，組織研究人員，或是精益/敏捷教 練。基本上，我幫忙重構，調整 和優化公司。不過，我有時候仍 然根據我的興趣去寫寫程式，這是非常好玩的! 當第一本 XP 的書籍和敏捷宣言出現後，Henrik 就開始擁抱敏捷原則， 並嘗試學習如何在不同的組織中，有效率的應用他們。在 1998 到 2003 年之間，他身為 Goyada 的創始人和 CTO，建立和帶領了一個 技術平台和 30 個人的團隊，因此他有大量的機會，去實驗測試先行 的開發方式和其他敏捷的實踐。 在 2005 年末，Henrik 在瑞典一家作遊戲的公司，簽約當開發部門的 主管。當時這家公司處於一個危險的狀況，主要是嚴重的組織和技 術問題。Henrik 利用 Scrum 和 XP 這些工具，在各個階層上實踐敏捷 和精實原則，幫助公司渡過這個困境。 在 2006 年十一月的某個禮拜五，Henrik 發燒，生病在家。他決定記 錄下他自己過去幾年來所學到的東西。不過一但他開始動筆，他無 法停筆下來，在三天內瘋狂的打字和繪圖，這份原始的紀錄已經成 長為 80 頁的文章，取名叫做"Scrum 和 XP 的實戰經驗"，最後變成了 這本小書。 仍然很驚訝我在週末裡把所有東西都寫完了! 這是其他作者討厭我 地方。 Henrik 開創了一個全新的道路，非常享受於扮演不同角色，像是經 理，開發人員，Scrum master，教師，和教練。他非常熱衷於幫助公 司建構優秀的軟體和優秀的團隊，擔當各種必要的角色。 Henrik 在東京長大，現在和他妻子及兩個小孩，居住在斯德哥爾摩。 仍然是相同的妻子和小孩，只是現在有更多小孩 :o) 在空閒時間，他是一個活躍的音樂家，會和當地樂團一起作曲，玩 玩貝斯和鍵盤。
  • 167.