摘要：
10年前第一次聽說每日站立會議，覺得很酷，於是我們馬上就實踐了！開始兩三週效果不錯，因爲新鮮事物嘛，但沒多久新鮮感就木有了，慢慢變成“walking dead”，每次開會就是一羣殭屍在開會，項目工作變成殭屍大戰項目，或者是項目經理大戰殭屍。本文在之前一篇關於每日會議文章的基礎上，繼續爲大家分享！
看此文之前，建議先看看之前的文章：“敏捷實踐:比每日會議更瘋狂的半日會議！”
鏈接：http://blog.csdn.net/fireball1975/article/details/9294071
前文回顧
前文再續書接上一會，上次我們提到：
“敏捷開發絕對不是今天計劃明天的工作的，要保證每一次迭代都能成功，那麼工作就必須落實到每一天。每日會議是保證計劃有力執行的重要手段，將項目的情況每天都可視化地展現在所有項目成員面前，讓我們一天一個腳印、踏踏實實地將項目做好。”
也提到：
“說到底開會只是一種形式，問題是我們開會的目的是什麼？如果不用開會能用更簡單有效的辦法達到開會的目的，那麼開會幹嘛？回到這個原點，我們自然就會處理很多項目中的問題，讓會議更加有效甚至不需要會議！”
我突然覺得我有點象神仙在談理想了，我說的這些境界可能短期內無法做到，我們必須回到現實，本文給出一些循序漸進的做法，並且針對常見的每日例會疑難雜症給出一些建議。我們可以先進入每日例會的初級階段，然後用半年左右的時間逐步過渡到高級階段，而終極形態我從來沒有真正可以完全做到，估計將來也不太可能做到，我們瞭解一下就可以了。
每日會議的初級階段
案例分享：用戶故事看板前的每日站立會議
某會議室有一張很大的白板，上面貼面了小卡片，卡片上記錄的是用戶故事。最左邊的用戶故事是“todo”的，中間的用戶故事是“doing”的，右邊的用戶故事是“done”的。“doing”和“done”的用戶故事都寫着負責人，而只有部分“todo”的用戶故事寫着負責人。每天，項目小組會圍着一個半圓，在這個白板前面討論最近24小時做的事情，規劃和調整將來24小時要做的事情。每位成員都能重複發言和仔細聆聽，相互尊重和交流意見。會議結束前大家還會完成一圈，把手都握在一起，齊聲說：加油！整個過程大家精神高度集中，所有人的語速都比較快，10-15分鐘就結束戰鬥。
之前我一直認爲如果每日會議做成今天規劃明天的工作，這其實仍然是原始的工作模式，我認爲項目應該有中長期的大致規劃，而至少近期1-2周的工作應該是細化和明確的。這個項目小組有當前Sprint的大致計劃，但近期1-2周的計劃暫時無法做到很具體，於是他們採用“今天規劃明天”的工作模式。
我是這個項目小組的敏捷教練，他們的工作方式我非常讚賞，以下幾點是可以供我們學習：
1）每日會議最好圍着“用戶故事看板”來開，用戶故事要分成以下幾類：todo、doing、done。
2）每一位都需要精神高度集中，充分發言和仔細聆聽。
3）如果實在不能細化近期1-2周的工作，那麼也不必強求，可以每天持續細化。
每日會議的高級階段
相對於原始的工作模式，如果能做到初級階段已經是一個很大的進步！
不過我們的項目總是有交付壓力的，如果某個Sprint的工作不能做到儘量細化，那麼我們就難以保證這個Sprint能不能按期按量按質交付，我們也難以預測將來會怎樣。所以每日會議的高級階段應該是這樣的：
1）當前Sprint的計劃應該儘量明細，至少要做到近期1-2周的工作時細化的，落實到人頭上的，可檢查的。
2）每日會議討論重點不是今天干了啥明天打算幹啥，而是每一位對照計劃和自己實際的完成情況，交流影響當前進度的問題、風險等。
3）每一位爲其他成員提供解決這些問題或風險的線索，會中不具體討論解決辦法，而是會後相關人員繼續溝通。
但是要做到近期工作細化是有難度和前提的：
1）需要我們具備比較強的需求分析能力，能在初期就充分拆解用戶故事，把握全部或者是大部分用戶故事的細節；
2）需要我們在掌握需求的基礎上，能儘早做好軟件的架構設計，想好所有或者至少是大部分的技術難點實現辦法；
說明一下，上面提到的“初期”並不是指項目整個週期的初期，而是指當前的Sprint。我們一般沒有辦法在整個項目的初期就能確定整個項目的需求和設計方案，但我們需要在某個Sprint的初期就能基本確定當前Sprint的需求和設計。
每日會議的終極形態
這個“終極形態”其實就是武學上的最高境界——無招勝有招！每日會議終極形態就是沒有會議！
上一篇文章提到：
“有朋友在羣中提到，他們項目基本不需要開會，因爲平時就把問題給解決了！
我覺得這實在是太牛了！說到底開會只是一種形式，問題是我們開會的目的是什麼？如果不用開會能用更簡單有效的辦法達到開會的目的，那麼開會幹嘛？回到這個原點，我們自然就會處理很多項目中的問題，讓會議更加有效甚至不需要會議！ ”
我做過的項目還真的有很多會議，但都是很有效果和效率的會議，我估計將來我也無法做到“無招勝有招”的境界，但我們需要記住開會並不是爲了開會，只要能達到目的，我們就採取最簡單最直接的辦法。“簡單和有效”是我們的重要工作原則。
每日會議的“疑難雜症”
下面列一些疑難雜症及解決建議，這些症狀是初級階段之前可能會出現的症狀。
1）項目中是“木頭人”太多，除了項目經理，其他人都不說話。
改善建議：讓大家輪流做每日會議的主持人。
2）SCRUM Master不懂具體需求和技術，每天都是他來主持會議。
改善建議：每日會議是“自組織團隊”自己開的，SCRUM Master在一邊旁觀就可。
3）敏捷教練“書生治國”，只關注理論和敏捷的條條框框，不切合工作實際，每日例會上只顧搞漂亮的燃盡圖。
改善建議：項目經理學習相關敏捷知識後兼任敏捷教練，活學活用，不要拘泥於形式。原敏捷教練應該到研發第一線去做具體的研發工作（注意不是敏捷教練的工作哦），獲取實踐經驗。
4）會議中大家只是口頭說某某用戶故事做完了，但實際完成情況有沒有底，事實上程序員的工作質量你懂的……
改善建議：通過測試的用戶故事才叫完成了，測試工程師是每日會議的重要角色。
上述給出的改善建議都是“戰術”層面的，但很多症狀的根本原因是公司體制、團隊文化、考覈機制的問題，這個時候要改善問題需要從“戰略”層面動手術。
曾經有人問過這樣的問題：他們團隊的人就是不積極不主動，怎樣弄都不行！我教了好幾招，他說都試過了，但就是開始有點效果，後面很快就恢復“正常”了。我相當鬱悶，爲什麼了？後來才瞭解到這是“弱矩陣”的管理架構！
類似的問題也出現在“外包人頭”的團隊上。什麼叫“外包人頭”？某些大公司爲了所謂的降低成本，不直接招聘員工，而是通過人頭外包的方式向合作方租用員工。這些被外包的員工其實是很慘的，想讓他們自組織自管理基本是沒戲的。
如果你們公司是“弱矩陣”，或者你們有“外包人頭”的情況，實踐各種敏捷實踐的時候就會有諸多問題，這些問題需要“戰略”層面來解決，但戰略層面的事情，往往不是我們能左右的。敏捷實踐是需要土壤的，歡迎參考下面爲你推薦的“神馬是敏捷”系列文章。
有些事情我們可能是有心無力的，在自己的能力範圍內做好事情，真誠地對待每一位小夥伴，做到問心無愧就OK了！
本文對具體一種敏捷實踐爲大家分享，如果你對敏捷還不是很理解，建議先看看“神馬是敏捷？”系列文章（共4篇）。
第一篇鏈接：http://blog.csdn.net/fireball1975/article/details/17049373
敏捷相關學習資料
體驗最火的敏捷——SCRUM（視頻課程）：http://www.umlonline.org/school/viewthread.php?tid=2524
超越極限編程（視頻課程）： http://www.umlonline.org/school/viewthread.php?tid=321
每日例會 = 殭屍大會？（視頻課程）：http://www.umlonline.org/school/thread-2602-1-1.html
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟件研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者