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。
在估算中學習，而不是學習該怎麼估算
2015年3月28日 星期六
Scrum初體驗(1) - Sprint Planing Meeting
2015/3/28 20:08-20:28
我們的Scrum Team共有六個人，
一個Product Owner、一個不懂Scrum的Scrum Master兼Developer、其餘4位都是Developer，在Spint Planning Meeting中有遇到2個問題：
1. Story在估點數的時候，如果每個人點數差異性一直過大，該怎麼辦？
2. PO怎麼知道這個Sprint要拿幾個Story
我們團隊共有五位開發人員，這個Sprint共有三週，假設每個人每天工作一小時，所以一個Sprint，共有
這個Sprint就選入75小時的Story量。
整個Meeting耗時3小時，中間休息十分鐘，以Team的角度來看，發現要完成每個功能很簡單，跟著一群神一般的隊友。
結果會如何呢？讓我們繼續看下去
我們的Scrum Team共有六個人，
一個Product Owner、一個不懂Scrum的Scrum Master兼Developer、其餘4位都是Developer，在Spint Planning Meeting中有遇到2個問題：
1. Story在估點數的時候，如果每個人點數差異性一直過大，該怎麼辦？
2. PO怎麼知道這個Sprint要拿幾個Story
目前使用的估點數方法：
我們最後所採用的方法，首先看大家所估的點數是不是差不多，只要有一個人出的點數過大，會請他說明原因，再由PO或點數出很低的人解釋Story達成的複雜度，通常解釋完之後，第二回合點數的差異性會變低，但是我們最後估出來的點數是採用多數所出的點數，而不是全部點數加起來平均，剛開始還不覺得奇怪，但估到後面發現大家點數不一定會一樣，多少都會有差異，但目前還是遵照一開始的方法將Story估完，待下一個Sprint再改進。目前估算這個Sprint要做幾個Story的方法：
第二個問題，點數估完了，開發人員將Story切成若干個Task，將每個Task估算時間。我們團隊共有五位開發人員，這個Sprint共有三週，假設每個人每天工作一小時，所以一個Sprint，共有
5(人) * 1(小時) * 5(天) * 3(週) = 75 小時
整個Meeting耗時3小時，中間休息十分鐘，以Team的角度來看，發現要完成每個功能很簡單，跟著一群神一般的隊友。
結果會如何呢？讓我們繼續看下去
2015年3月21日 星期六
什麼是設計？
2015/3/21 15:59-16:32
這星期上北科大軟體生命週期，有點像在上哲學課，一上課Teddy照慣例問題轟炸。
Teddy：「什麼是設計？」
學生A：「確定要解決的問題。」
Teddy：「什麼是問題？」
學生A：「...」
經過一番苦戰，還是說不過Teddy。
什麼是定義？定義就是在所有情況下皆適用，而Teddy隨時都能把我們所認為的【定義】輕易用一個不適用的例子擊垮。
Teddy引用Alexander的想法：
設計就是決定Form在Context中的範圍。
Form
= Problem
= Solution
依時間性來看Form在設計的開始，通常是一個Problem，而在設計的最後，就會變為Solution。
什麼是好的設計？
在宇宙中，充滿了各式各樣的Force(作用力)，因為有這些Force的存在，才有Problem的產生。
Force就是這些Problem的特徵，無法抵消，只能平衡。
一個好的設計，就是將你的Form代入Problem，看這個Problem的Force有沒有被平衡，越平衡就代表這個設計越好。
這個定義好像到哪都適用耶，不愧是可以行騙天下的哲學！
解決問題時，要先找到問題。找到問題後，在開始研究作用力。
這星期上北科大軟體生命週期，有點像在上哲學課，一上課Teddy照慣例問題轟炸。
Teddy：「什麼是設計？」
學生A：「確定要解決的問題。」
Teddy：「什麼是問題？」
學生A：「...」
經過一番苦戰，還是說不過Teddy。
什麼是定義？定義就是在所有情況下皆適用，而Teddy隨時都能把我們所認為的【定義】輕易用一個不適用的例子擊垮。
Teddy引用Alexander的想法：
這張圖有錯，圖中的Force不可能超出Context (2015/06/06 11:21)
設計就是決定Form在Context中的範圍。
Form
= Problem
= Solution
依時間性來看Form在設計的開始，通常是一個Problem，而在設計的最後，就會變為Solution。
------
什麼是好的設計？
在宇宙中，充滿了各式各樣的Force(作用力)，因為有這些Force的存在，才有Problem的產生。
Force就是這些Problem的特徵，無法抵消，只能平衡。
一個好的設計，就是將你的Form代入Problem，看這個Problem的Force有沒有被平衡，越平衡就代表這個設計越好。
這個定義好像到哪都適用耶，不愧是可以行騙天下的哲學！
------
解決問題時，要先找到問題。找到問題後，在開始研究作用力。
2015年3月14日 星期六
一個星期換一個晚上
2015/03/14 22:25-22:51
最近的Waterfall專案眼看就要到驗收時間了，但距離驗收合格的功能標準還差了一半左右，所以呢我們團隊必須利用一星期的時間完成為期一年的專案，這個專案牽涉到硬體到整個軟體的整合，我們團隊只負責開發軟體，但我們直到最後不到一個月的時間，才拿到完整的硬體可以開發，而且在每個專案成員都壓很緊的情況下，還必須負責維護舊有專案問題，就在一連串的阻礙之下，終於到了捷案的前一天...
這天還有許多工項沒有做完，大家似乎做好了熬夜的準備，今晚準備一起在公司奮鬥一晚，自己覺得即使奮鬥一晚，也不可能來的及將全部的工項完成，但也不敢和上司說，應該想想該怎麼跟客戶溝通延期，於是在上個星期四的夜晚和許多團隊成員們開夜車，功能最後一樣沒有完成，而且效率還很差，還把自己的身體搞得疲累不堪。
秉著敏捷的精神，撐到驗收時間後，和團隊成員們討論我們這次的瓶頸在哪裡，結論是承接的案子太多了，且每個專案都採用Waterfall的形式，所以大家一個瀑布沖完之後，接著又要趕場沖下一個瀑布。每次專案都急得要命，主管所給的時間都很短，完全沒有商量的空間，即使每個星期都有回報該星期的進度客戶，但對客戶來說，其實是我們創造出<有做完>的假象，實際上沒有完成整合，只有完成該功能的元件，但對上司來說，完成元件功能就等於完成該項功能。
但我想說，開發程式最難的地方其實不是完成某個小功能，而是把功能全部整合在一起
這些話最後我只講在心裡。
其實自己有很多內心戲應該要更勇敢地爭取，表達出來給上司聽，講在心裡也沒人知道你在想什麼。
那一夜之後，睡一覺起床就得了嚴重感冒，失聲一星期，喉嚨痛得要命。
看來已經不是新鮮的肝了 Orz
有問題就要說出來，會吵的孩子有糖吃
最近的Waterfall專案眼看就要到驗收時間了，但距離驗收合格的功能標準還差了一半左右，所以呢我們團隊必須利用一星期的時間完成為期一年的專案，這個專案牽涉到硬體到整個軟體的整合，我們團隊只負責開發軟體，但我們直到最後不到一個月的時間，才拿到完整的硬體可以開發，而且在每個專案成員都壓很緊的情況下，還必須負責維護舊有專案問題，就在一連串的阻礙之下，終於到了捷案的前一天...
這天還有許多工項沒有做完，大家似乎做好了熬夜的準備，今晚準備一起在公司奮鬥一晚，自己覺得即使奮鬥一晚，也不可能來的及將全部的工項完成，但也不敢和上司說，應該想想該怎麼跟客戶溝通延期，於是在上個星期四的夜晚和許多團隊成員們開夜車，功能最後一樣沒有完成，而且效率還很差，還把自己的身體搞得疲累不堪。
秉著敏捷的精神，撐到驗收時間後，和團隊成員們討論我們這次的瓶頸在哪裡，結論是承接的案子太多了，且每個專案都採用Waterfall的形式，所以大家一個瀑布沖完之後，接著又要趕場沖下一個瀑布。每次專案都急得要命，主管所給的時間都很短，完全沒有商量的空間，即使每個星期都有回報該星期的進度客戶，但對客戶來說，其實是我們創造出<有做完>的假象，實際上沒有完成整合，只有完成該功能的元件，但對上司來說，完成元件功能就等於完成該項功能。
但我想說，開發程式最難的地方其實不是完成某個小功能，而是把功能全部整合在一起
這些話最後我只講在心裡。
其實自己有很多內心戲應該要更勇敢地爭取，表達出來給上司聽，講在心裡也沒人知道你在想什麼。
那一夜之後，睡一覺起床就得了嚴重感冒，失聲一星期，喉嚨痛得要命。
看來已經不是新鮮的肝了 Orz
有問題就要說出來，會吵的孩子有糖吃
訂閱：
文章 (Atom)