我的Scrum新體驗 - 每日會議篇(Daily Scrum Meeting)

Business meeting
我的專案開始採用 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. 即時回饋: 若是有同事表現良好, 經理可以立即鼓勵. 或是公司專案有好消息, 在這時候便可以馬上公佈, 以振奮人心. 當然若是有人表現不好, 會議後及時溝通, 也會讓事情不至於惡化太多.

 

作者:David Ko

作者簡介:David具備Certified Scrum Master以及Certified Scrum Product Owner的認證,也是台灣最早期 Agile 社群(AgileCommunity.tw)發起人之一。 為了推廣Agile知識,還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管,並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。

文章出處:David Ko的學習之旅

原文連結:http://kojenchieh.pixnet.net/blog/post/75409339

圖片出處:http://courseimage.com/4773-business-meeting

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
David Ko

David具備Certified Scrum Master以及Certified Scrum Product Owner的認證,也是台灣最早期 Agile 社群(AgileCommunity.tw)發起人之一。 為了推廣Agile知識,還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管,並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。

4 則讀友回應

  1. engineer 2015-10-05 12:59:04 第 2 則

    我是個工程師,曾經參加過需要daily meeting的案子。先講結論,就是我不覺得daily meeting對於我個人或project有起到好處。
    先說對於"個人":
    1.對於我,聽對方的報告"你昨天做了什麼?你今天要做什麼?你遇到什麼困難?",對我來說沒有好處,因為這麼簡短的內容,我學不到任何東西。
    2.對於他,他報告完後,我無法幫上他的忙,因為軟體也有專業分工,你今天請一個灌漿師傅和水電師傅報告灌漿中遇到的困難,水電師傅也愛莫能助。
    所以對於每個參與報告的人來說,從中獲取好處的機率都很低。

    再說對於"團體":
    1.我每天花30分鐘一一聽過所有工程師的報告,卻沒能產出甚麼(因為每個"個人"都沒有獲取好處)。一個人30分鐘,10個人就是300分鐘,那還不如請大家回去寫幾行code還比較能讓project往前進。

    我覺文中提到的好處,其實指派PL or PM去處理就好了
    如果誰遇到困難就私下和PL/PM報告,由PL/PM分配人力幫忙即可。
    如果經理需要天天知道工程師的進度,那麼他分別和每個人(或特定有risk的人) tracking即可。

    總結是: 我覺得全員daily meeting,其實是在做無效的資訊分享。就像我們開會並不會請掃地阿姨與會。並所有工程師都需要分享彼此的狀況。

  2. david ddd 2015-09-15 12:13:40 第 1 則

    每日緊迫盯人就叫做agile?
    每天沒有目標的跳來跳去就叫敏捷?
    根本還沒花時間思考好方向,
    一遇到困難就要工程師改變做法就叫做敏捷,
    這種敏捷決對會讓你經常跳進糞坑裡 XD

    假設我預計花3天的時間把軟體進度做到B點,
    但是我想到有3種寫法可以到B點,
    無法確定哪一種比較容易成功,
    但嚐試其中任何一種都至少會花上2天時間,

    我嚐試了第一種方式後發現不可行,
    改用第二種方式,
    專案項目必定延遲,
    那麼manager會認為我沒有進度,
    manager會認為我沒有在做事,

    久而久之就會得到一個惡果,
    那就是工程師一遇到困難就會改變方向,
    因為工程師必須表現給上面看到一個好像很敏捷樣子,

    而且工程師會不願意嚐試新的道路去走,
    因為不知道要花多久時間,
    如果新道路走不通,
    上面的人又會念說怎麼沒有進度,
    最後導致公司全體變得平庸。

    真正的敏捷應該是客戶提出一個產品想法,
    由工程師先初步完成產品想法中比較具體的部分,
    且初步測試所需要的技術是否有把握,
    並評估將來可能遭遇的困難,
    這是敏捷開發的第一個階段,
    第一階段完成後就可以先把產品給客戶看看,

    第二階段是跟客戶討論更具體的完成這個產品,
    客戶看過第一階段的樣品後會有更多想法與意見,
    這時候就根據客戶的想法意見做,
    並且不要想一次完成某項功能,
    因為客戶的想法總是反反覆覆的,
    如果定了一個某項功能完成的時間表,
    結果客戶又說要改,
    反而會花上更久的時間,

    總之,
    我要強調的是,
    定出[專案進度]跟[每日開會檢討]這兩件事情本身就已經違反了敏捷開發的初衷。