由「每週例會」說起
每天專案例會的話，頻率太高了，可能會浪費時間，如果每月一次，似乎時間太長了，於是我們往往會「每週例會」。
有一次我參加了某專案的每週例會，開會的時間是周五，會上其中一位專案成員反應了乙個問題。
我問：該問題什麼時候發現的。
答曰：周一。
我問：周一為什麼不說這個問題？
……這是真實個案，有問題為什麼不立刻反饋，要等到例會才說？擔心例會上沒有東西可以說嗎？
如果你們公司實施年度績效考核，12月你的領導找你談話，進行績效考核，你的領導說：小x啊，你1月份做得那個事情不對啊，然後2月份到11月份你每個月都重複犯類似的錯誤啊！你的領導之前一直沒有跟你說過此事，直到績效考核才跟你說，你會有什麼反應？如果因為這樣，你的績效成績很差，導致你得不到年終獎，你會不會有衝動去掐死你的領導？
績效考核這個案例是虛構的（儘管是虛構，其實有很多類似的真實個案），但道理和「每週例會」其實差不多，開會到底是為了啥？其實我很反感「例會」的這個「例」字，一旦帶上這個字，就很容易認為這是例行要做的事情，這樣就很容易導致我們走形式，而忘記了為什麼要開會？
不過話說回來，前面提到的「每週例會」個案已經不算很差的了，一些專案的每週例會說的事情是：本週幹了啥，下週準備幹啥。變成了工作匯報會議！如果遇到這樣的會議，我會直接開罵：你這專案經理幹什麼吃的？大家幹了啥你平時不知道嗎？下週要幹啥，你事先沒有規劃嗎？
為了避免走形式，下面開始我不會用「例會」這個詞，為了讓你們的會議效率更好，建議不要用「例會」這個詞，你甚至可以考慮將會議室改名為「war room」！每一次會議都是一場戰鬥，是需要解決問題的！一位同事曾經形容過會議給她的感覺，只有四個字：刀光劍影！會上所有與會者都會投入進來，為了專案的成功各抒己見、據理力爭。沒錯，咱們要的就是這個效果！
作者：
張傳波www.umlonline.org
每日會議是這樣開的嗎？
極限程式設計有每日站立會議，scrum有每日晨會，那是不是每天開一次會就是敏捷呢？
有朋友提到他們也實踐每日會議，但沒啥效果。
我問：你們每天開會是不是說一下最近一天幹了啥，接下來了一天打算幹啥呢？
答曰：是滴……
那自然沒啥效果了，這樣就變成工作匯報會了，而且更嚴重的問題是：敏捷開發是今天計畫明天的事情，見一步走一步的嗎？
極限程式設計中的小版本發布，以及scrum中的sprint（衝刺），其實就是一次迭代。在某一次迭代中的工作應該是事先規劃好的，絕對不是見一步走一步的。每日會議完全沒有必要說那些大家都知道的事情，說廢話可不是敏捷的初衷。
每日會議應該怎樣開？
每日會議應該重點說以下有價值的內容：
1.有什麼問題、困難、風險影響你當前的工作，以致不能按照既定計畫進行。
2.有什麼問題、困難、風險會影響當前迭代的成功？
3.有什麼問題、困難、風險會影響專案的成功？
4.當前計畫是不是已經或者可能不合時宜了，需要立刻更新或改進？
5.有什麼做法或建議可以讓專案更加成功？
簡單說，每日會議主要是用來讓你提出問題、困難和風險的。
每日會議可以讓問題隱藏不會超過24小時，並且可以讓你的工作及時獲得其他成員的支援！這是「白痴」也懂的道理：問題早一點暴露和解決，將會節省莫大的成本。可惜我們往往是為了節省開會成本，日會變成週會甚至是月會，看上去節省了不少開會時間，但專案的問題就在你的姑息下滋生和蔓延，最後可能會要了專案的命！任何專案都會存在大量的問題，如果說你的專案沒有問題，那麼你要警惕了，沒有問題是最大的問題！不是你的專案真的沒有問題，而是你們連發現問題的能力都沒有了！質量是需要投資的，每天會議就是一種投資。
敏捷開發絕對不是今天計畫明天的工作的，要保證每一次迭代都能成功，那麼工作就必須落實到每一天。每日會議是保證計畫有力執行的重要手段，將專案的情況每天都視覺化地展現在所有專案成員面前，讓我們一天乙個腳印、踏踏實實地將專案做好。
讓專案組全體成員明白為什麼要每日會議和如何每日會議，這樣每日會議其實很容易做到很有效的。每日會議無論是站著開還是坐著開？是早上開還是下班前開？要用白板還是用投影？等等這些都是形式而已。開門見山，抓住要害，必要時要做書面記錄。
每日會議高階
有朋友在群中提到，他們專案基本不需要開會，因為平時就把問題給解決了！
我覺得這實在是太牛了！說到底開會只是一種形式，問題是我們開會的目的是什麼？如果不用開會能用更簡單有效的辦法達到開會的目的，那麼開會幹嘛？回到這個原點，我們自然就會處理很多專案中的問題，讓會議更加有效甚至不需要會議！
當然有些溝通是必須通過會議來進行的，目前可能我們暫時沒有辦法完全不需要會議，那麼必要的會議是必須的！譯作會議的英文單詞有「meeting」和「conference」，你知道這兩個英文單詞有什麼不同意思嗎？
meeting：參與人數不多，參與者聚在一起討論問題，每個人的發言權力是平等的。
conference：參與人數比較多，說話的人佔少數，大部分人是聽眾。例如你參加什麼過程改進年會，我在上面演講，你在下面聽，那種就叫conference。
兩個詞的意義不同主要在於三點：
1.目的不同：meeting尋求各人的意見來達成共識；conference主要是宣講某些人的觀點。
2.參與人數不同：meeting參與人數不多（我建議不要超過7人，5人以內最有效）；conference參與人數可以很多。
3.參與方式不同：meeting人人有均等發言權力；conference中演講者佔主導，其他人是聽眾。
按照上述的定義，你可以看看你們專案中的會議是meeting還是conference？
如果你要打造自組織的團隊，那麼就必須賦予小組成員權力，讓你的會議是meeting而不是conference！而且在meeting中做到每個人都是主角！
後話：每日會議不會助長懶人歪風？
有朋友提到：他們解決不了的問題都會拋給我，自己也不思考，搞得我頻繁救火，感覺很疲憊。
再進一步深挖此問題，發現：這些專案成員是來自不同部門的，專案經理基本上沒啥權力了管理他們，不能影響專案組成員的薪金、獎金和職位公升降等。
也就是說：這個專案小組全體成員並不在一條船上！專案的成敗只與pm有關，與專案組成員基本沒有關係，專案組成員當然是能少幹就少幹，能不幹就不幹了！
會議中提問題的目的是集合全體智慧型來應對這些問題，如果提問題的目的是為了偷懶，那根本就不是這個味了！這個團隊建設或者說團隊文化就超級有問題，在這樣的基礎上，其實無法實施任何敏捷實踐。曾經在2011廣東過程改進年會上，有朋友問到什麼東西是最需要首先改進的？我提出的觀點是：首先要做好團隊建設，否則其他都是虛的；如果團隊建設能做好，那麼團隊就能自覺解決很多問題，也很容易實施各種敏捷實踐，甚至打造屬於自己自己的最佳實踐。
本文關於每日會議及半日會議的實踐體會，是基於專案組全體是在一條船上的基礎上的。如果目前你的專案組還不能坐在一條船上，請參考umlonline**關於團隊建設的文章。
但要提到的一點是，專案組必須是相對獨立和有一定的權力，專案經理應該有一定的權力。至於scrum中提到的scrummaster有點專案經理的意思，但他是沒有行政權力的，僅是充當教練的角色。問題是：這樣的角色在國外可能適用，但在國內如果你沒有任何權力，僅靠人格魅力來帶動團隊，那要看你的rp了，看看你帶領的團隊成員是不是都是人格高尚的了。
敏捷實踐 每日站立會議
每日站立會議 晨會 這是在每個工作日特定的時間舉行的短小 15分鐘 的會議，開發團隊的每一成員都將參與，通常可以選擇在早上或者下午下班前進行。為了保證其短小精悍，與會成員都保持站立 所以叫 站立會議 以此提供給開發團隊機會來匯報交流成果和闡述任何存在的障礙。每個團隊成員回答三個問題式的報告進展 1 ...
每日站立會議 敏捷流程scrum實踐
每日站立會議是敏捷流程scrum中的很重要的乙個制度之一。功能 1.快速同步進展，讓專案組內部的員工互相了解彼此的進展，從而了解本專案的整體進展。2.給每個人一種精神壓力，信守承諾。這是一種面對面的精神壓力，直面專案進展。3.培養團隊的文化，讓每個人意識到 我不是乙個人在戰鬥，我們是乙個團隊。站立會...
敏捷實踐之如何開好scrum回顧會議
scrum中的5個活動分別是 產品代辦事項列表梳理 product backlog sprint計畫會議 sprint plan meeting 每日站會 scrum daily meeting sprint 評審會 sprint review meeting sprint 回顧會議 retrosp...