根據 VersionOne 的調查[註1]，Scrum 中最受歡迎的的實務之一是站立會議。公司內很多團隊在導入 agile 時，都會採用這個實務。但是水能載舟，亦能覆舟。雖然它很容易被導入團隊中，但是也是聽到不少人對它抱怨連連，認為那是罰站會議，是一個無奈的活動。
到底發生甚麼事情，會讓工程師這麼沮喪呢？根據我所參與的專案，以及和別人交流後，以下是常見的困境：
1. 每日站立時間過長
有些團隊動輒要花 20~30 分鐘以上來執行，日子久了，大家會覺得這一種折磨，沒有效率, 漸漸地大家便會沒有興趣參與。
通常會這麼久，有可能是在會議中討論如何解決問題。要切記，解法是會議結束後，再由相關的人留下來談論，並不是在會議中占用所有人的時間來討論。另一種可能是團隊太大，請試著使用 scrum of scrums，根據不同的目的，找不同代表來參加。或者利用 feature team 的結構，讓組織維持 5-9 人的大小。
2. 當成 status report meeting 來執行
Status report 只是站立會議其中一小部分。重點是要提出你所遇到的困難，並且要相互幫忙來解決困難。若是只是 status report，容易發生只是報喜不報憂的狀況，會讓人誤以為專案進行一切順利。
以正常的狀況來說，專案進行都是充滿了許多不確定性，有許多事情你需要假設、求證或是提出疑問。這些事情若是能及時提出，別人也可以即時給你意見，你也才能及時修正。如果大家只是流於形式化的狀態回報，這只是在粉飾太平。
此外，每日站立會議還需要修正 task board 上面的 task (也就是隨時修正計畫)，像是從 To do List 中移到 In Progress，或是從 In Progress 移到 Done 等等。否則常常有人會覺得雖然每天開會，但是還是無法確認工作是否已經做完了。此外，在這 task 移動過程中，可以適當地利 用同儕壓力，來促使大家遵守承諾。
3. 除了每日站立會議之外，還有每周會議
很多團隊在執行 agile 的作法，是除了原先要做的事情外，再加上 agile 的活動。這時候不管這些事情性質是否重複，用意是否良好，同仁都會抱怨事情做不完，以及質疑 agile 是否真的那麼 agile。
很多團隊在執行 agile 的作法，是除了原先要做的事情外，再加上 agile 的活動。這時候不管這些事情性質是否重複，用意是否良好，同仁都會抱怨事情做不完，以及質疑 agile 是否真的那麼 agile。
像每周會議，當每日站立會議有在進行時，便可以不用再執行。當然啊，相反地，若是有人質疑有每周會議，為何還要每日站立會議？那就代表你的每日站立會議的重點在 status report，並沒有做到前面所講的重點。
4. 時間不固定
剛開始時可能因為不知道那個時段比較合適，或者因為需要配合長官的開會時間，因此時間常常變來變去的。也許剛開始還好，但是時間一久，很多成員會對這件事情，感到非常不耐煩。
開這會並不需要配合長官的時間，或許長官無法天天參加，但是一週來個兩至三次，對於團隊狀況的掌握也是有幫助的。千萬不要變成長官不再就無法開每日站立會議，需知道這會議是為了同步團隊狀況以及解決問題而開，並不是為了長官。
5. 長官問太多問題
長官或許希望知道一些細節，或者想知道是否成員有些地方沒有注意到。建議可採取以下方式來解決：
(1) 做完的定義(Definition of Done)：若是能詳細定一一些檢查的清單，或是完成驗收標準，自然成員就會注意到這些事情，不用重複提醒這些事情。
(1) 做完的定義(Definition of Done)：若是能詳細定一一些檢查的清單，或是完成驗收標準，自然成員就會注意到這些事情，不用重複提醒這些事情。
(2) 增加檢查的 task：若是要確認的事情太多，不如增加一些檢查的 task，像是 design review、code review、單元測試、整合CI系統等等，來檢視是否事情做的正確，這樣就不用在每日站立會議上刻意再問。
6. 成員報告的內容詳細程度不一
每個成員與會時，需要將自己的事情，在一到兩分鐘內講完，並且是要和多數人有關的重要部分。有些人會滔滔不絕講很久，可是並沒有重點也和其他人沒有關係。 或者幾乎甚麼都沒說，讓人實在不清楚他在做甚麼。一開始執行站立會議時，這確實是件不容易的事情，但是這是需要練習。在與會前花 5-10 分鐘思考整理一 下，讓人家能很容易知道你的重點，並且強調在跟大家有關的部分。
註1: 5th Annual State of Agile Development Survey Final summary report, VersionOne
全站熱搜
留言列表
