l

2012年6月22日 星期五

Scrum FAQ (1)

June 21 20:00~22:00

image

 

可能是前幾天校對Teddy的「巨作」看得太累了,等到書本送印之後,Teddy整個人好像被榨乾似的,都沒什麼精神。這禮拜接下來的幾天就先以「省電模式」低速運轉一下,下週再重新出發(希望不要本週省電,下週沒電XD)。

有鄉民留言說比較想要知道「Branch/Merge Pattern」,這種需要花腦筋的文章,寫作日期要等Teddy吃了大還丹之後再視情況而定。還有學妹問Teddy:「為什麼學長的粉絲好像都是一些怪怪的人」。沒辦法,物以類聚。Teddy這種怪咖,也只能吸引到一些「怪叔叔」或「楊婆婆」這種天賦異稟的粉絲…XD(請勿對號入座啊XD)。

***

言歸正傳,在這一系列的文章中,Teddy以「Q&A」的形式,來回答鄉民們在執行Scrum時也可能遭遇的問題。先從幾天前在「六月份Scrum軟體開發流程實作班,Day 2」所提出來的10個問題做為開端。

在回答問題之前Teddy想說明一下,很多在導入Scrum時所遭遇的問題都沒有所謂的「正確答案」。Teddy的回答只是依據自己經驗所判斷的回應,不代表在所有的情境下都適用,鄉民們在服用這些「成藥」之前最好還是請教一下「醫生」(鄉民甲:這算是先撇清關係嗎?)。

問題:團隊成員需要花費好幾個小時來準備sprint review,是否需要將準備demo的工作列為task?

回答:Teddy曾經聽過一種說法:「準備sprint demo的時間不要超過30分鐘」。假設鄉民們先勉為其難的接受這種講法,那麼回答這個問題的可能答案應該是反問自己:「為什麼團隊需要花費好幾個小時來準備sprint review?」。在回答「為什麼團隊需要花費好幾個小時來準備sprint review?」這個問題之前,如果貿然把準備sprint review獨立成一個task,那麼有可能會忽略開發流程的潛在問題,也失去了改善的機會。以下是幾個常見需要花費數小時準備sprint review的原因:

  • 系統不易佈署:要demo的系統需要花很多時間才裝得起來,所以每次sprint review光是安裝與設定準備demo的系統就花費好幾個小時。造成這個問題的原因最常見的原因就是沒有自動化安裝程式,所以每次都要手動安裝。包含重建資料庫、安裝作業系統、安裝demo系統、設定demo的資料等等。
  • 準備review時才發現一堆錯誤:每個Story都「宣稱」已經完成,但是等準備demo前,負責demo的人實際去操作使用之後,才發現一堆問題。
  • 製作過多文件:負責demo的人花費過多時間準備demo的文件或精美投影片。這種情況經常發生在被指派到demo某的story的人,不知道要如何正確demo這個story。於是為了保守起見,花了很多時間,準備了很多demo的資料。例如,從該功能的設計文件、演算法、架構圖等慢慢解釋起,最後才demo如何使用該功能。

如果鄉民們的團隊是因為上述原因導致準備demo的時間過久,首先要做的事情不是把demo獨立成一個task,而是要思考如何改善現況。

系統不易佈署

需要花費長時間才可以將系統安裝與設定成功,這可以看成是「持續整合沒有做好」的警訊。如果持續整合作的好,系統應該要很容易可以被自動化安裝,否則就不可能做到「持續整合」(需要長時間才能把系統裝好,這樣的情況是不可能實施「持續整合」的)。所以,團隊首先要做的,應該是要跟Product Owner討論,看看是否可能在後續的sprint中,加入幾個technical story,用來改善團隊實施持續整合的能力。至少在持續整合系統上,每建構一次軟體,都要產生一份安裝程式。團隊成員只要使用這份安裝程式,就可以快速的設定好要demo的系統。

準備review時才發現一堆錯誤

在剛導入Scrum的團隊身上經常可以發現這個問題,同樣地,這也是一個軟體開發流程的警訊,代表團隊的品質不佳。可能是開發人員沒有寫單元測試,或是寫的太少。也有可能是每項工作被移到Done之前,缺少第三者的驗證。團隊可以藉由在DoD中明確定義工作完成的最小要求條件,例如每個method至少要寫三個單元測試,或是在task board中,在Done之前增加一個Review階段,並且規定所有的task在移到Done之前,一定要讓第三者(不是原本認領該工作的人)確認過之後,才可以移到Done。或是團隊也可以藉由實施pair programming來降低產生bug的機率。

製作過多文件

這也是另一個初學Scrum的團隊很容易發現的問題。傳統上,開發人員經常被要求寫所謂詳細(但卻沒人要看)的需求、分析、設計、與使用文件,或是在demo的時後要製作精美的投影片。避免這個問題的方法,可以在sprint review之前,由Scrum Master事先寄出sprint review meeting agenda(請參考「Scrum 是什麼(3):三種補充文件」),讓準備demo的人員,知道每個demo項目大致有多少demo的時間,以避免準備過多的資料而沒有時間可以demo。

***

看到這邊鄉民們可能會問:「那如果上面三種方法都嘗試了,但是短時間之內團隊還是需要數個小時來準備sprint review那該怎麼辦?」那沒辦法,如果上面幾招都用了,但是都沒有效果,很有可能是團隊在每個sprint中安排太多功能性story(functional requirement),導致沒有時間去關注品質或是流程改善(例如撰寫單元測試與做好持續整合)的議題。在這種情況下,團隊也許該考慮是否每個sprit不要安排那麼多的功能性story,讓團隊有足夠的時間可以逐步提升敏捷實務做法的能力,也許幾個sprint之後團隊的開發流程會變得比較順一點。

最後,如果Teddy所建議的方法都沒用,那鄉民們就放心地增加「準備sprint review」的task到每一個story裡面吧。反正法律也沒規定「準備sprint review」不能變成一個單獨的task…XD。

***

友藏內心獨白:法律沒規定的事可多的哩。

2 則留言:

  1. To Charles:

    這也是一招...不過...會有這種問題的團隊,有時間寫驗收測試的比例應該不高。

    回覆刪除