hursing所在的公司推行敏捷開發有兩年多了，其中最讓人直接感受到的就是scrum晨會。從生搬硬套到過程創新，令大家由抵觸變成積極響應，這個過程真的很花費心思。 11年12月，hursing開始在自己的團隊推行晨會。當時團隊是剛成立的，很小，包括hursing自己在內的2個老人+2個新人，基本上hursing得指導所有的事情。事實上，團隊小到不開晨會hursing也知道他們在做什麼，所以晨會的內容更多是反饋他們遇到的還未解決的問題以及提出對編碼過程的改善意見，然後hursing做一些指導和糾正。這個階段，整個團隊是在確定自己的風格和目標，探索一個合適的行為準則。 在此過程中，發現一個有用的技巧：團隊的人應該坐成一堆，而不是一排。即工位安排坐成背靠背（或者沒有障礙的面對面），而不要一字排開地坐。這樣每個人坐著說話就行，整個團隊的人都能聽見。有了這個便利性，平常大家也更樂於溝通，甚至可以就在座位上開晨會，足夠放鬆。有事的話大吼一聲就行，完全不用郵件或即時通訊工具。需要當面溝通的話，雙腳一瞪，凳子就滑到那邊去了，立刻可以交談。如此一來平常的事務大家都知道，晨會上自然也能更簡短地敘述。 不過，座位的事情hursing沒法自己決定，不久就在10年1月聽組織安排，大家坐散了。然後團隊再加了新人，變成6個。於是大夥得找會議室來開晨會。因為平常的溝通不便，大家在晨會的發言變多了，此時限制大家發言的內容有了必要。當時對scrum也沒那麼多的認識，基本上是說“昨天做了什麼，今天要做什麼，目前有什麼問題”。這是老三點，有點“俗”，但是也不會錯，只是不是很適合實際的工作節奏。 以上算是對scrum最初的探索。 12年中，調崗換組，直到10月開始再次對一個團隊擁有一些掌控權。這個團隊很複雜，非常有挑戰性。團隊共11人，分別來自4個不同業務的組織（分由4個leader打績效，不包括hursing），而且負責同時開發兩個專案。hursing被指定為團隊的介面人，一開始還真覺得頭疼，因為團隊連個晨會都沒有，4個組織的人是跟各自的leader一起開晨會的。通過積極的反饋與溝通，最終是本團隊的人一起開晨會、但由於人員組織的複雜性，開始的時候晨會的形式也很特別：

• 每週只是一三五開。因為彼此的工作相關性不是很大，而且晨會有比較多的時間是hursing在宣講專案事宜
• 不用把技術點說得很細。因為其它組織的人可能聽不懂，這是浪費時間。只要提出了問題，由各個組織內部解決就行了，有執行困難的話才由hursing出面直接找leader幫忙。
• 今明兩天要做的事情在晨會說完後要寫在白板上，下次再擦掉寫新的。這裡沒有用傳統做法，即紙貼ToDo、Doing、Done，因為那樣不環保，且字小，不直觀，都是給自己看的，別人看不清；讓別人也能看清，那就有種無形的監督作用。團隊的負責人可以知道整體的狀況並隨時跟蹤進度，並且下次晨會的時候，各人可以回顧一下執行得怎麼樣。

一開始，大家都不是很適應，因為各自負責的模組差別很大，組織間有不同的業務術語，聽不懂跨組別的資訊。為了解決這個矛盾，在晨會之外，hursing推動了跨組織的知識交流活動。

• 每個組織出人，介紹自己該組織負責的模組的主流程，並且對跟別的模組有互動的部分著重描述。
• 跨組織安排工作。主要是幫忙解bug，不承擔開發任務，這樣可以互相熟悉業務。
• 推動跨組織的程式碼review
• 建立愛分享知識的氛圍，鼓勵寫技術文章

隨著分享次數的增多，也增加了不少人性化的配套，如會議上會有零食吃，大家投票決定買什麼；有專人負責培訓分享的事務，從訂會議室到備份文件、做會議記錄等都不用演講者操心了。 經過兩三個月的磨合，解決了互相聽不懂技術問題的矛盾後，晨會的內容也逐漸迴歸正軌，重點變成：

1. 前兩天做了什麼，所屬的任務完成了百分之多少（標在白板上）
2. 做的工作有哪些會影響別人或需要別人配合，提出來協商
3. 對於正在解決的棘手問題，大家有什麼建議

另外，晨會主持人要把專案的時間表和當前階段寫在白板上，大家能每次開晨會都看到，自然地知道緊急性。 一些有意義的小技術點和經驗總結，都用郵件分享，不佔晨會時間。 後來還做了個改進，把每個人身上的未解決bug數量標在白板上的每人名字旁邊（就像iOS的未讀資訊角標），這樣大家能看到誰名下的bug最多，多的人會自覺地爭取把這第一的名號給去掉。 至此，那時候的晨會可謂相當高效。 再後來，團隊解散，hursing又調崗了，這是個更大的團隊（16人）。團隊的狀況其實也算複雜，雖然是同一個專案同一個組織，但業務上會分三大塊，彼此較少聯絡，也會存在聽不懂的狀況。不過hursing不是負責人，也腹黑地想看看反面的例子，所以沒推進什麼改善，一旁觀察後總結出這些問題：

• 晨會主持人很少做改進工作，誰做得不合理也沒人提點
• 各人的發言沒有預先經過組織，隨想隨講，思路混亂，停頓較長
• 過長的討論沒人打斷，每人平均發言1.5分鐘，有時候整個晨會接近半個小時
• leader當成聽報告會，樂於聽到很詳細的技術處理過程，有些點還會追著細問
• 大家聽不懂以後，經常開小差，看著別的地方也有，私下討論的也有
• 人多了，圍成的圈很大，有些人說話聲音小，部分人聽不見（建議每人都走出來背靠白板面對所有人來講，leader站在最遠的地方）

除了問題各個擊破，特別的改進建議是：分批/分組開晨會，每批不要超過10個人，人員是工作更加緊密相關的，leader可以各批都參加。這在別的部門以有應用，效果不錯。 最後就是，主持人必須帶頭做好示範。最重要的是，作為第一個發言人，要笑著說話，奠定整個晨會的基調很重要。 總結地說，晨會開得怎麼樣，還是得看負責打績效的那個人的態度。團隊的核心永遠是管理者本身，其風格怎樣，團隊的運作風格也會怎樣。無論要求團隊成員如何如何自管理，始終還是要得到首肯的。 有一點很重要，也是最實際的，如果晨會開得不好也不礙事（啥叫礙事就見仁見智了），那就隨便吧。