2015年4月25日 星期六

Scrum初體驗(5) - 在Sprint進行中重新安排Story

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月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大師的回答中,提醒了自己要有耐心、有耐心、有耐心,因為很重要所以打三遍。


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來做什麼?


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
一次挑一個Stroy,直到團隊認為無法再挑更多的Stroy加入這次Sprint。




在估算中學習,而不是學習該怎麼估算