14 . 我們怎樣做測試藉由把測試人員放到Scrum團隊中來提高品質
- 10月 29 週四 201521:31
Scrum 和 XP 的實戰經驗(2nd) - Ch14-2
14 . 我們怎樣做測試藉由把測試人員放到Scrum團隊中來提高品質
- 10月 27 週二 201523:29
Scrum 和 XP 的實戰經驗(2nd) - Ch14-1
14 . 我們怎樣做測試這是最困難的部份。我不確定是否它是Scrum中，最難的一部份。還是它在軟體開發中，通常也是最困難的部份。
- 10月 19 週一 201520:08
Scrum 和 XP 的實戰經驗(2nd) - Ch13-2
13 我們如何結合Scrum和 XP
漸進式設計
這意味著一開始設計就要保持簡單，然後持續去改進它。而不是一開始就試圖要所有的事情都正確，然後就凍結它。
漸進式設計
這意味著一開始設計就要保持簡單，然後持續去改進它。而不是一開始就試圖要所有的事情都正確，然後就凍結它。
- 10月 12 週一 201523:08
Scrum 和 XP 的實戰經驗(2nd) - Ch13-1
13 我們如何結合Scrum和 XP
Scrum和XP結合後，可以帶來很多好處，這點是無須爭議的。網路上，我看到大部分的資料都支持這個論點，所以我不用再花時間去爭論為什麼。
Scrum和XP結合後，可以帶來很多好處，這點是無須爭議的。網路上，我看到大部分的資料都支持這個論點，所以我不用再花時間去爭論為什麼。
- 10月 05 週一 201522:14
Scrum 和 XP 的實戰經驗(2nd) - Ch12-2
12. 我們如何做發佈計畫和處理固定價格的合約
- 10月 04 週日 201521:07
Scrum 和 XP 的實戰經驗(2nd) - Ch12-1
12. 我們如何做發佈計畫和處理固定價格的合約有時候，一次只規劃一個Sprint要做的事情是不夠的，我們需要提前做更多計畫。尤其是處理固定價格的合約，我們必須事先規劃，否則我們將會有無法準時交付的風險。
- 9月 23 週三 201522:43
Scrum 和 XP 的實戰經驗(2nd) - Ch11
11. Sprint之間的休息時間在實際生活中，你不能總是在衝刺。你需要在衝刺之間休息。如果你都是在做衝刺，你的效果可能只是像在慢跑。
- 9月 13 週日 201508:35
Scrum 和 XP 的實戰經驗(2nd) - Ch10-2
10. 我們如何做Sprint回顧
在團隊間散播所學到的教訓
在Sprint回顧會議中，所得的資訊通常是極度有價值的。團隊很難集中火力，是因為銷售經理強押開發人員，在銷售會議上充當技術專家？ 這是非常重要的資訊。是否其他團隊可能也有相同的問題？ 我們是否應該教育產品經理更多有關於產品的知識？ 因此讓他們自己可以做銷售支持(sales support)。
或者更好的方式，邀請銷售經理來參加會議，從中學習他們的需求，一起討論可能的解法！
一個Sprint回顧會議，不只有關如何讓團隊在下個sprint中能做得更好，它還有更大的涵義。
我們處理的策略是十分簡單的。有個人(目前是我)參加所有Sprints的回顧會議，充當經驗知識的橋樑。這是相當不正式的作法。
另外一種方法，是讓每個Scrum團隊公佈一份Sprint回顧報告。我們曾經試過這個方法，但是發現沒有很多人去看這些報告，更不用講因此展開行動的更少。所以我們只是用上面這種簡單的方式。
對於充當"經驗知識橋樑"的這個人，有些重要的規則：
• 他應該是一個好的傾聽者。
• 如果回顧會議太安靜，他應該準備去問些簡單，但是目標明確的問題，可以刺激團隊的討論。例如："如果時間可以到轉，重新從第一天開始這個Sprint，那些事情你會用不同的方法進行？"。
• 他應該自願花時間去參與所有團隊的所有回顧會議。
• 他應該具有某種權力地位，所以在一些團隊無法控制的改進建議，他可以幫忙推動。
這種方法運作的相當好，不過也許有其它方法能做的更好。如果有的話，請告訴我。
互換引導者是不錯的模式。像是“我會引導你團隊的回顧會議，如果你可以引導我的團隊。”讓簡單的雙向知識傳播可以發生，也讓身為 Scrum master 的你，可以專心參與你團隊的回顧會議（而不是只能引導而已）
改變，或不改變
假設說，團隊總結出"我們團隊內部溝通太少了，所以總是重覆著彼此做過的工作，並且搞亂對方的設計"
那我們應該怎麼呢？導入每日會議？或是導入新的功具來促進溝通？還是更多wiki的頁面？嗯，也許吧。也許會再發生，也許不會。
我們發現，在許多狀況下，只要能清楚的指出問題所在就足夠了，在下個Sprint中會自動地被解決。特別是，如果你在團隊房間的牆壁上，貼上Sprint回顧的結果(我們常常忘記去做，還蠻丟臉的！)，這樣會更有效。你所導入的每個改變，都會要付出一些代價。因此在導入改變之前，先考慮什麼都不做，然後希望問題會自行消失(或是變小)。
上面這個例子("我們團隊內部溝通太少了…")是一個很典型的例子，說明若是什麼都不做的狀況下，這問題有可能被解決。
如果每次你都導入一些改變，可能有些人會開始抱怨。人們會變成不太願意去提出一些小問題，這將會很麻煩。
在回顧會議中，所發現問題的範例
這裡有些在回顧會議中所找出的一些問題，以及相對的典型處理動作。
"我們應該花更多的時間，把故事拆解成更多的小項目和任務"
這個問題相當普遍。在每次的每日會議上，團隊成員自己會說"我真的不知道今天要做什麼"。所以之後每次每日會議上，你需要花時間去找出具體要做的任務。通常這些事情會前做，會更有效率。
典型處理動作： 無。團隊會在下次Sprint規劃會議中自行解決這個問題。如果它重複發生，延長Sprint規劃會議的時間。
"太多外界的干擾"
典型處理動作：
• 要求團隊在下一個Sprint中，減低他們的投入程度，所以他們會有比較合理的計畫
• 要求團隊在下一個Sprint中，紀錄干擾的狀況更清楚一點，誰干擾，花多久時間。可以幫助我們之後更容易解決問題。
• 要求團隊將所有干擾都轉給Scrum master或是產品負責人
• 要求團隊指定某個人當"守門員"，所有的干擾都要經過他，所以剩餘的人都可以集中精力在要做的事情上面。Scrum master或是大家輪流來扮演這個角色。
守門員輪流的模式相當常見，並且通常運行的不錯。試試看吧！
"我們過度承諾，最後只做完了一半"
典型處理動作： 無。團隊可能在下個Sprint中不會過度承諾。或是至少不會像這次承諾這麼多。
順便一提，在 2014 年時， “sprint 承諾”一詞從 Scrum Guide 中移走。相對地，它更名為“sprint 預測” 。好多了！承諾這個詞會造成多大的誤解。許多團隊認為 sprint 規劃是某種形式的允諾（有點傻，想想敏捷宣言中四個主要價值之一：“回應變化 重於 遵循計劃”）。Spint 規劃不是一種承諾，它是一個預測和假設 –“這是我們認為如何達成 sprint 目標的最好方式。”
無疑地，能交付的東西持續少於預測的，會令人覺得很討厭。如果這是問題，開始嚴格採用昨日天氣的做法，根據上次 sprint 做完的量，來拉多少個故事點數（如果你想要有些變化，可以用過去三個 sprint 的平均值）。這樣簡單而強大的技巧，可以讓問題消失，因為你的速度變成可自我調適。
"我們辦公室環境太吵或是太混亂了"
典型處理動作：
• 試圖去建立一個較好的環境，或是把團隊搬到辦公室外面去，租一旅館的房間，怎樣都行。請看"我們怎樣佈置團隊的房間"。
• 如果不可能，告訴團隊在下次Sprint中減低他們的投入程度，並且清楚註明這是因為太吵和太混亂環境的緣故。希望這會使團隊負責人，開始去向上層主管去反映這件事。
在團隊間散播所學到的教訓
在Sprint回顧會議中，所得的資訊通常是極度有價值的。團隊很難集中火力，是因為銷售經理強押開發人員，在銷售會議上充當技術專家？ 這是非常重要的資訊。是否其他團隊可能也有相同的問題？ 我們是否應該教育產品經理更多有關於產品的知識？ 因此讓他們自己可以做銷售支持(sales support)。
或者更好的方式，邀請銷售經理來參加會議，從中學習他們的需求，一起討論可能的解法！
一個Sprint回顧會議，不只有關如何讓團隊在下個sprint中能做得更好，它還有更大的涵義。
我們處理的策略是十分簡單的。有個人(目前是我)參加所有Sprints的回顧會議，充當經驗知識的橋樑。這是相當不正式的作法。
另外一種方法，是讓每個Scrum團隊公佈一份Sprint回顧報告。我們曾經試過這個方法，但是發現沒有很多人去看這些報告，更不用講因此展開行動的更少。所以我們只是用上面這種簡單的方式。
對於充當"經驗知識橋樑"的這個人，有些重要的規則：
• 他應該是一個好的傾聽者。
• 如果回顧會議太安靜，他應該準備去問些簡單，但是目標明確的問題，可以刺激團隊的討論。例如："如果時間可以到轉，重新從第一天開始這個Sprint，那些事情你會用不同的方法進行？"。
• 他應該自願花時間去參與所有團隊的所有回顧會議。
• 他應該具有某種權力地位，所以在一些團隊無法控制的改進建議，他可以幫忙推動。
這種方法運作的相當好，不過也許有其它方法能做的更好。如果有的話，請告訴我。
互換引導者是不錯的模式。像是“我會引導你團隊的回顧會議，如果你可以引導我的團隊。”讓簡單的雙向知識傳播可以發生，也讓身為 Scrum master 的你，可以專心參與你團隊的回顧會議（而不是只能引導而已）
改變，或不改變
假設說，團隊總結出"我們團隊內部溝通太少了，所以總是重覆著彼此做過的工作，並且搞亂對方的設計"
那我們應該怎麼呢？導入每日會議？或是導入新的功具來促進溝通？還是更多wiki的頁面？嗯，也許吧。也許會再發生，也許不會。
我們發現，在許多狀況下，只要能清楚的指出問題所在就足夠了，在下個Sprint中會自動地被解決。特別是，如果你在團隊房間的牆壁上，貼上Sprint回顧的結果(我們常常忘記去做，還蠻丟臉的！)，這樣會更有效。你所導入的每個改變，都會要付出一些代價。因此在導入改變之前，先考慮什麼都不做，然後希望問題會自行消失(或是變小)。
上面這個例子("我們團隊內部溝通太少了…")是一個很典型的例子，說明若是什麼都不做的狀況下，這問題有可能被解決。
如果每次你都導入一些改變，可能有些人會開始抱怨。人們會變成不太願意去提出一些小問題，這將會很麻煩。
在回顧會議中，所發現問題的範例
這裡有些在回顧會議中所找出的一些問題，以及相對的典型處理動作。
"我們應該花更多的時間，把故事拆解成更多的小項目和任務"
這個問題相當普遍。在每次的每日會議上，團隊成員自己會說"我真的不知道今天要做什麼"。所以之後每次每日會議上，你需要花時間去找出具體要做的任務。通常這些事情會前做，會更有效率。
典型處理動作： 無。團隊會在下次Sprint規劃會議中自行解決這個問題。如果它重複發生，延長Sprint規劃會議的時間。
"太多外界的干擾"
典型處理動作：
• 要求團隊在下一個Sprint中，減低他們的投入程度，所以他們會有比較合理的計畫
• 要求團隊在下一個Sprint中，紀錄干擾的狀況更清楚一點，誰干擾，花多久時間。可以幫助我們之後更容易解決問題。
• 要求團隊將所有干擾都轉給Scrum master或是產品負責人
• 要求團隊指定某個人當"守門員"，所有的干擾都要經過他，所以剩餘的人都可以集中精力在要做的事情上面。Scrum master或是大家輪流來扮演這個角色。
守門員輪流的模式相當常見，並且通常運行的不錯。試試看吧！
"我們過度承諾，最後只做完了一半"
典型處理動作： 無。團隊可能在下個Sprint中不會過度承諾。或是至少不會像這次承諾這麼多。
順便一提，在 2014 年時， “sprint 承諾”一詞從 Scrum Guide 中移走。相對地，它更名為“sprint 預測” 。好多了！承諾這個詞會造成多大的誤解。許多團隊認為 sprint 規劃是某種形式的允諾（有點傻，想想敏捷宣言中四個主要價值之一：“回應變化 重於 遵循計劃”）。Spint 規劃不是一種承諾，它是一個預測和假設 –“這是我們認為如何達成 sprint 目標的最好方式。”
無疑地，能交付的東西持續少於預測的，會令人覺得很討厭。如果這是問題，開始嚴格採用昨日天氣的做法，根據上次 sprint 做完的量，來拉多少個故事點數（如果你想要有些變化，可以用過去三個 sprint 的平均值）。這樣簡單而強大的技巧，可以讓問題消失，因為你的速度變成可自我調適。
"我們辦公室環境太吵或是太混亂了"
典型處理動作：
• 試圖去建立一個較好的環境，或是把團隊搬到辦公室外面去，租一旅館的房間，怎樣都行。請看"我們怎樣佈置團隊的房間"。
• 如果不可能，告訴團隊在下次Sprint中減低他們的投入程度，並且清楚註明這是因為太吵和太混亂環境的緣故。希望這會使團隊負責人，開始去向上層主管去反映這件事。
- 9月 13 週日 201508:29
Scrum 和 XP 的實戰經驗(2nd) - Ch10-1
10. 我們如何做Sprint回顧為什麼我們堅持所有團隊都要做回顧會議呢？
- 9月 03 週四 201521:17
Scrum 和 XP 的實戰經驗(2nd) - Ch9
9. 我們怎樣進行Sprint的展示
Sprint展示(有些叫它Sprint review)是Scrum中重要的一部份，但是人們都低估它。
Sprint展示(有些叫它Sprint review)是Scrum中重要的一部份，但是人們都低估它。
