Stand up meeting作為敏捷項目開發中的一個重要實踐不可或缺。站立會議每天都要發生，在會議上大家可以了解到每個人的工作進展、項目遇到的concern和issue，從而做出適應的資源調整和措施，保證項目交付的順利進行。如何讓站會變得高效，本人總結了一些tips，希望對大家有用。
站會的形式
一般站會分為兩個形式。一種是在站會上每人輪流進行各自的狀態更新，另一種是以story wall上的user story為主進行更新。 第一種好處是每人都有更新機會，但是更新的內容稍顯混亂，第二種好處是通過卡片追蹤能更清晰的了解到當前的狀態，不好的地方是如果有人的工作任務沒體現在卡片上，可能就沒機會得到更新。
我個人比較傾向于第二種更新方式。一個典型的story wall有這些列: BACKLOG->BA->DEV->TEST->UAT->DONE。站會開始的時候，由一個facilitator按照從DONE->UAT->TEST->DEV->BA的順序依次念出這些故事卡，被點到的故事卡則由工作在這張卡上的人進行相應的更新。之所以采用倒序是出于精益的思想。我 們敏捷的迭代式開發就是要將story card盡量的往done column里挪，采用倒序過卡的方式就是要突出這一點。當將墻上所有的卡都過完后，facilitator可以再問下有沒有其他人有update，這樣可以防止有些人由于工作不能體現在卡片上而漏掉更新。比如迭代經理可以此時做出自己的更新。最后facilitator再問還有什么問題或風險沒，此時可以把自己的一些想法表露給團隊,好借團隊之力拿出應對方案。
個人的更新
個人的更新注重言簡意賅，突出重點。一般更新需要包括下面三點。
昨天做了什么。這個只需2句話帶過，切忌陷入細節。
有沒有遇到問題，需不需要資源或幫助。如果遇到什么困難，可以大概描述下，并指出需要什么樣的幫助。
今天打算做什么。
一些tips
站會一定要站著開。凡是坐著的會議都短不了。
one conversation. 站會上的時候一定要保證同一時刻只有一個人說話，切忌變成了群體討論。做法可以是將一個小玩具作為token，只有拿著這個token的人才可以說話。
限制每個人更新的時間。有些人在更新自己工作狀態的時候喜歡講的很細節，無形中浪費了很多時間。這時候facilitator就需要適時的打斷他，可以告訴他只要給出大概的內容進行，細節部分可以會后再討論。
團隊中成員輪流當facilitator。一般團隊中喜歡固定一個人當facilitator，一當就當到了項目結束。其實更好的做法是每天站會時都要更換facilitator，這樣保證每個人都能充分參與到團隊中。
站會不能遲到，也不要定在剛上班時。剛踩著點進辦公室就迎來站會略顯緊張，很多人還沒調整好狀態。 一般可以將站會定為早上上班15分鐘后。
凡是可能花時間的討論都不要發生在站會上。站會只是專注狀態更新，暴露問題，而不是解決問題。針對會上暴露的問題可以再組織相關的人商討解決方案。
切忌將站會流于形式，失去原有的意義。站會注重的是team間橫向的溝通，并且每天都會發生，如果不能堅持就說明了團隊間配合出現了問題，失去了快速反饋的意義。
文章列表
留言列表
