我的專案開始採用 Scrum 的方法來開發專案, 這是一個新的體驗. 一開始時是工程師們說要這麼做, 我的想法是一則以喜, 一則以憂. 喜的是終於有機會可以嘗試 agile 的方法了, 憂的是在這麼短的時程內, 用新的方法似乎風險很大. 不過既然大家都願意這樣做, 那就豁出去了.
因此, 接下來我將會分享這幾個月來(開始於2009/2中), 使用 Scrum 的風風雨雨.
每日會議篇(Daily Scrum Meeting)
一開始我們是訂早上10點鐘開始 meeting, 當初 manager 們是有點擔心, 是否這樣可行. 因為敝公司工程師一向不太早到, 到時候可能會二二六六的. 沒想到幾天後, 發現大部分的人都還能準時出現, manager 們還真感動的痛哭流涕. 可能是同事間的壓力, 讓大家比較願意守法. 因此沒有需要採取一些罰則, 否則大家一定覺得很不高興.
在專案初期, 人員還沒有完全到位, 大約有 8 位(2 位經理, 4 位 RD, 2 位 QA). 在前面一到兩週, 我們大約花了 20-30 分鐘來進行. 這是因為不熟悉每日會議要談什麼, 以及對要開發的系統不熟悉, 再加上經理會多談一些事情和紀錄每個人所報告的東西, 導致時間拖的比較長.
之後, 人數漸漸增加到 13人( 2位經理, 5 位RD, 6 位QA), 可是時間約只花 10-15 分鐘左右. 短的原因是因為大家很清楚要講的重點是什麼; 加上因為每日舉行, 不可能會有爆大量的狀況發生.
此外會議一結束後, 工程師會立即找相關的人, 處理所遭遇的問題. 所以不會有太多不清楚或新的事情要報告. 對此, 曾經發生過一個笑話, 我們某位成員只遲到了幾分鐘, 一到meeting的地方, 發現都沒有人在, 還以為會議沒有開始. 壓根沒想到, 我們已經結束了.
對於要報告的內容, 一開始就是跟 Scrum 要求的一樣, 會談以下事情:
- 你昨天做了什麼?
- 你今天要做什麼?
- 你遇到什麼困難?
但是, 在一開始經理們還是不容易掌握狀況, 因為我們遇到的問題是講的東西和工作板(taskboard)上的東西對不起來. 當每個員工在講的時候, 可能所用詞和便利貼不一樣. 或是有些細節經理們不知道. 再加上看到有些便利貼項目沒有更新, 或是已經延遲了, 經理們會因此而很緊張.
那我們怎麼解決這個問題呢? 我們試過以下幾種方法:
1. 完全不改變: 會議進行的方式還是不變, 但是私底下會去問相關的工程師, 到底發生了什麼事情. (我們最常用這種)
2. 加一些問題: 例如: "你那些已經延遲的項目要如何補救?", "為何你說昨天要做, 但是卻沒做的原因為何?", 讓你得到一些重要的資訊. (視情況採用)
3. 根據任務板來回答: 從上而下檢查每項任務(task)的狀況, 讓負責的人來回答. 這還蠻花時間, 因為看的不只是in progress項目, 還包括一些delay項目. 一陣子之後就不了了之, 可能是還蠻花時間, 並且是由經理主導, 讓員工覺得很不自在吧!! 或許是執行的順序不對, 若是一開始就是採用這樣的方式, 也許就不會這麼窒礙難行了.
至於任務板的更新, 我們大該有幾種方式:
1. 每日會議前
2. 每日會議後
3. 任務被執行完或開始執行: 根據你執行的狀況, 隨時去更新任務板的內容.
4. 在每日會議中: 一邊報告, 一邊更新便利貼.
這些方法我們都是混合使用. 但是這要工程師自己自動自發. 若是有人偷懶或是忘記, 免不了要勞動經理們追殺一下, 要求大家去更新.
執行了那麼久的每日會議, 每個成員對它可是讚不絕口, 認為它的好處如下:
1. 資訊同步化: 了解目前專案的進度, 以及同事之間進度, 讓經理可以適當的判斷
2. 同儕的壓力: 有時候若是每天沒有什麼進度, 或是內容空洞, 別人會很容易知道. 因此保持每天自己都要有表現.
3. 即時請求幫助: 每日會議一個重點是有問題就要提出來, 讓問題在最早時間點被知道, 能夠開始被處理.
4. 可以共同解決問題: 有時候有些任務比較困難, 自己處理會花比較多時間, 每日會議可以讓大家即時知道這個狀況, 有些人手上工作允許的話, 可以適當地協助你. agile一個重點是要大家合作, 互相幫助, 而不是指是自己的事情做完就是成功.
5. 即時回饋: 若是有同事表現良好, 經理可以立即鼓勵. 或是公司專案有好消息, 在這時候便可以馬上公佈, 以振奮人心. 當然若是有人表現不好, 會議後及時溝通, 也會讓事情不至於惡化太多.
留言列表
