2015/4/18 16:04-16:24
我們團隊進行Sprint Planning Meeting時，挑選的Story已經經過優先權排序，挑選團隊所認為最重要的Story先做。
你猜猜，我們第一個完成的Story是什麼？
沒錯，就是大家開始使用大部分個人化App都會有的功能『登入』
Story會依對客戶的價值，經過排序後擺進Product Backlog，再經由Sprint Planning Meeting這個活動，挑選這個Sprint中所要完成的Story，所以我們團隊認為對客戶最重要的價值是『登入』！？
團隊在一開始已大致了解Scrum的進行方式，但是一個不小心，又掉入流程價值的陷阱，團隊是這樣想的「沒有登入，要怎麼繼續後面的功能？」
流程價值的意思大概是這樣：
在專案還未進行之前，團隊會大致決定App服務的流程，一般都會依流程畫面的先後順序，決定要施工的項目，先出現的流程，就須先實作。
到今天Sprint已經過了四分之三，Scrum大師突襲檢查，反問了我們：「難到系統不登入，就沒辦法體驗你們的App嗎？」
於是團隊驚覺之前的Story排序有錯，這個Sprint的Story應該要重新排序，所以我們利用Daily Scrum的時間重新排序了Story的優先順序，將不重要的Story從Sprint Backlog丟回Product Backlog，新選進來的Story，依照Sprint Planning Meeting的流程一樣，切Task然後估點。
雖然在真的這樣做之前我反對團隊這麼做，但我無法說服團隊不這麼做，其實我也不知道哪裡不好，還沒守住Scrum就先擅自靈活用運Scrum，總覺得怪怪的。
到底哪裡怪？還須請Scrum Master大師指點
Scrum只是一種流程框架，可依團隊狀況自行調整，調整不好就容易走火入魔
2015年4月25日 星期六
2015年4月18日 星期六
Scrum初體驗(4) - Scrum Master 存在的地目
2015/4/18 15:18-15:36
我：「身為Scrum Master，初到一個公司導入敏捷開發的時候，一定會遇到有一種團隊，不知道自動化測試、持續整合、單元測試、版控系統等等等等等，從一個千錘百鍊的Scrum Master眼中，一定會覺得這種開發團隊似乎沒救了，但是又不可能一次把這些知識全部塞給開發團隊，那Scrum Master到底要怎麼抓對時機給開發團隊需要的知識呢？」
Scrum大師：「就像老師帶幼稚園小朋友一樣，幼稚園小朋友不會數學、不會英文、不會國文，你也不可能請數學家教、英文家教幫小朋友惡補，如果真的這樣做了，小朋友一定會被壓垮，當Scrum Master最難的地方，就在於要有耐心，你的主觀上，雖然一下就能看出開發團隊不足的地方，但又不能一次性修正所有的不足，在適當的時候提出一點點的不足，Scrum Master雖是一個觀察者，看似什麼事情都不用做，其實在內心卻要擺番地掙扎，選擇適當的時機一點一點地透過團隊自己發覺這些不足，且引導他們能一點一點地自動克服這些不足。對團隊來說，他們的產品是客戶；對Scrum Master來說，他們的產品是團隊，直到團隊成員能達到自我管理，那Scrum Master有能功臣身退了。有一句話說得很棒：『Scrum Master存在的目的，就是為了消滅自身的存在』」
我：「我懂了，謝謝Scrum大師」
我：「身為Scrum Master，初到一個公司導入敏捷開發的時候，一定會遇到有一種團隊，不知道自動化測試、持續整合、單元測試、版控系統等等等等等，從一個千錘百鍊的Scrum Master眼中，一定會覺得這種開發團隊似乎沒救了，但是又不可能一次把這些知識全部塞給開發團隊，那Scrum Master到底要怎麼抓對時機給開發團隊需要的知識呢？」
Scrum大師：「就像老師帶幼稚園小朋友一樣，幼稚園小朋友不會數學、不會英文、不會國文，你也不可能請數學家教、英文家教幫小朋友惡補，如果真的這樣做了，小朋友一定會被壓垮，當Scrum Master最難的地方，就在於要有耐心，你的主觀上，雖然一下就能看出開發團隊不足的地方，但又不能一次性修正所有的不足，在適當的時候提出一點點的不足，Scrum Master雖是一個觀察者，看似什麼事情都不用做，其實在內心卻要擺番地掙扎，選擇適當的時機一點一點地透過團隊自己發覺這些不足，且引導他們能一點一點地自動克服這些不足。對團隊來說，他們的產品是客戶；對Scrum Master來說，他們的產品是團隊，直到團隊成員能達到自我管理，那Scrum Master有能功臣身退了。有一句話說得很棒：『Scrum Master存在的目的，就是為了消滅自身的存在』」
我：「我懂了，謝謝Scrum大師」
---
雖然我還是不知道什麼時機該向團隊提出缺點，但在Scrum大師的回答中，提醒了自己要有耐心、有耐心、有耐心，因為很重要所以打三遍。
Scrum Master存在的目的，就是為了消滅自身的存在
2015年4月11日 星期六
Scrum初體驗(3) - Scrum Master 出現的時機
2015/04/11 21:31-20:03
最近打網誌的習慣快要蒸發了，非得要拖到星期六快結束才開始打網誌，當初開始發網誌的時候給了自己小小的目標「每個星期六要發一篇網誌」，持續到現在也有23週。
剛開始寫網誌時，想要試著分享自己在身活中所遇到的趣事，每個星期還沒到星期六前就能產出一篇網誌，那時候的心態是「為了分享而寫網誌」，可是現在好像是「為了寫網誌而寫網誌」。現在這個Form好像不太Fitness，該來找找Force後，換個Form再來！！發牢騷到這邊，以下開始進入正題...
在我們修課而組成的Scrum中，Scrum Master很幸運地由我來擔任，但很不幸地我也是開發人員，一不小心就會身分錯亂，平常也可能是當開發者當習慣了，也不知道Scrum Master會有什麼不一樣，目前跟著課程進度，開始了我們的第一個Sprint，這個Sprint開始到今天已經過了8天，我這個不專業Scrum Master的角色觀察到一些現象。
1. Daily Scrum雖然已經訂下時間，但是開發人員(包括我)，常常因為突發的重要事情，必須取消當次的Daily Scrum或頻頻改時間。
2. 因平常沒有相約一起專案的時間，雖然在Sprint Planning Meeting的時候，假設每個人每天會花1小時的時間在Sprint上，但我自己好像就沒有做到這點(忘了我也是開發人員Orz)。
3. 平常身在不同實驗室，因大家工作時間都不一樣，有時候開發遇到問題，就稍微怠惰，放著不管等著有緣份的下一次見面
4. 在Scrum的框架中，最後有一個回顧會議(Retrospective)，主要是用來讓團隊成員們提出這個Sprint中好的部分和可以更好的部分，但從Sprint開始到現在，就有好多部分想要修正，能不能等到Sprint還沒結束就提出來呢？ (我是真的不知道XD)
之前基於對Scrum的好奇，有稍稍和某Scrum專業人士討論，他說：「通常在團隊剛開始使用Scrum的時候，都會發現產能反而比採用之前的方式還要低，所以大家在跑完第一個Sprint之後就被打回原形」。
我自己對於Scrum Master角色定位，覺得他是個默默的觀察者，這個觀察者盡量不要輕易地干涉開發人員現在做事的方式，等觀察一段時間後，再出現提醒或糾正。可是哩，我這個不專業觀察者一不小心就會把自己的主觀感受帶入。可能是因為完全不知道Scrum Master到底要幹嘛。
如果團隊已經遵守Scrum框架，那要Scrum Master來做什麼？
最近打網誌的習慣快要蒸發了，非得要拖到星期六快結束才開始打網誌，當初開始發網誌的時候給了自己小小的目標「每個星期六要發一篇網誌」，持續到現在也有23週。
剛開始寫網誌時，想要試著分享自己在身活中所遇到的趣事，每個星期還沒到星期六前就能產出一篇網誌，那時候的心態是「為了分享而寫網誌」，可是現在好像是「為了寫網誌而寫網誌」。現在這個Form好像不太Fitness，該來找找Force後，換個Form再來！！發牢騷到這邊，以下開始進入正題...
在我們修課而組成的Scrum中，Scrum Master很幸運地由我來擔任，但很不幸地我也是開發人員，一不小心就會身分錯亂，平常也可能是當開發者當習慣了，也不知道Scrum Master會有什麼不一樣，目前跟著課程進度，開始了我們的第一個Sprint，這個Sprint開始到今天已經過了8天，我這個不專業Scrum Master的角色觀察到一些現象。
1. Daily Scrum雖然已經訂下時間，但是開發人員(包括我)，常常因為突發的重要事情，必須取消當次的Daily Scrum或頻頻改時間。
2. 因平常沒有相約一起專案的時間，雖然在Sprint Planning Meeting的時候，假設每個人每天會花1小時的時間在Sprint上，但我自己好像就沒有做到這點(忘了我也是開發人員Orz)。
3. 平常身在不同實驗室，因大家工作時間都不一樣，有時候開發遇到問題，就稍微怠惰，放著不管等著有緣份的下一次見面
4. 在Scrum的框架中，最後有一個回顧會議(Retrospective)，主要是用來讓團隊成員們提出這個Sprint中好的部分和可以更好的部分，但從Sprint開始到現在，就有好多部分想要修正，能不能等到Sprint還沒結束就提出來呢？ (我是真的不知道XD)
之前基於對Scrum的好奇，有稍稍和某Scrum專業人士討論，他說：「通常在團隊剛開始使用Scrum的時候，都會發現產能反而比採用之前的方式還要低，所以大家在跑完第一個Sprint之後就被打回原形」。
我自己對於Scrum Master角色定位，覺得他是個默默的觀察者，這個觀察者盡量不要輕易地干涉開發人員現在做事的方式，等觀察一段時間後，再出現提醒或糾正。可是哩，我這個不專業觀察者一不小心就會把自己的主觀感受帶入。可能是因為完全不知道Scrum Master到底要幹嘛。
如果團隊已經遵守Scrum框架，那要Scrum Master來做什麼？
2015年4月4日 星期六
Scrum初體驗(2) - 這個Sprint要選幾個Story
2015/4/4 16:43-17:04
相信各位有試過Scrum的鄉民們，在開始人生中第一次的Sprint Planning Meeting時，一定都會有一個很大很大的問號：「Story點數都估完了，我怎麼知道這個Sprint要選幾個Story？」
這週四在軟體生命週期的課堂上，終於把這個積了一星期之久的問號丟給Teddy
Brian：「我怎麼知道這個Sprint要選幾個Story？」
Teddy反問：「為什麼要估算？」
同學A：「(%$(&^@($%)#@$&!#$^!@#%!@#$」
同學B：「根據上一次的Sprint經驗，決定這次要選幾個Stroy」
同學C：「藉由估算，可以看出每個團隊成員是否都了解這個Stroy的需求」
聽到同學C的答案，才回憶起上一次上課的時候我明明才在筆記本抄了幾個字
＜估牌是為了讓PO知道團隊成員是不是對這個Story的認知一致＞，可能是因為寫的字太小，讓我完全忘記它的存在，瞬間有一種被打醒的感覺。
Teddy在後面補上比較有漂亮的講法：「估算，是為了讓團隊成員了解這個Stroy的Boundry。」
接著再加碼介紹兩個選Story到這個Sprint方法：
1. Velocity base
依據團隊的產能挑選Stroy的數量。
2. Commitent based
相信各位有試過Scrum的鄉民們，在開始人生中第一次的Sprint Planning Meeting時，一定都會有一個很大很大的問號：「Story點數都估完了，我怎麼知道這個Sprint要選幾個Story？」
這週四在軟體生命週期的課堂上，終於把這個積了一星期之久的問號丟給Teddy
Brian：「我怎麼知道這個Sprint要選幾個Story？」
Teddy反問：「為什麼要估算？」
同學A：「(%$(&^@($%)#@$&!#$^!@#%!@#$」
同學B：「根據上一次的Sprint經驗，決定這次要選幾個Stroy」
同學C：「藉由估算，可以看出每個團隊成員是否都了解這個Stroy的需求」
聽到同學C的答案，才回憶起上一次上課的時候我明明才在筆記本抄了幾個字
＜估牌是為了讓PO知道團隊成員是不是對這個Story的認知一致＞，可能是因為寫的字太小，讓我完全忘記它的存在，瞬間有一種被打醒的感覺。
Teddy在後面補上比較有漂亮的講法：「估算，是為了讓團隊成員了解這個Stroy的Boundry。」
接著再加碼介紹兩個選Story到這個Sprint方法：
1. Velocity base
依據團隊的產能挑選Stroy的數量。
2. Commitent based
一次挑一個Stroy，直到團隊認為無法再挑更多的Stroy加入這次Sprint。
在估算中學習，而不是學習該怎麼估算
訂閱：
文章 (Atom)