引言：
我會以系列文章的形式跟蹤記錄我現在正在做的一個完整運用Scrum管理項目的筆記，裏面會有一些經驗教訓總結心得，以便讀者與我互相學習勉勵。有寫的不對的或者寫的不好的地方還請海涵，當然我更希望大家多多提寶貴意見，讀者的支持是我最大的動力。（之一，之二，之三，之四，之五，之六）
============================================================================================
不好意思，最近一直都很忙，不僅僅是忙於工作，還有家裏的一些事情需要處理。所以沒有抽出時間來更新博客。
系列談上一回我們主要談到了溝通問題，相信大家都知道Scrum的5個價值觀：溝通、公開、專注、尊重、勇氣。所以我一直認爲溝通是第一位的。只有擁有良好的溝通敏捷才可以成功。當然其他幾個都同等重要。
到目前爲止我們項目敏捷已經實施了將近3個多月了。按道理說我們應該有很多收穫了，但是我個人總覺得收穫不大，或者說是因爲我們的進程太慢。總感覺使不上勁，最近看一些論壇說過一句話，敏捷實施的好不好或者徹不徹底要看你Scrum Master（SM）這個職位或者職責實施的徹不徹底。現在我們團隊沒有定義SM這個職位，所以我們敏捷其實是非常的不徹底的。只能靠我個人的努力不斷的去接近。心力交瘁啊。
上乾貨，今天主要談談幾個會議吧，其實Scrum中的所有會議都是非常重要的，1、Sprint計劃會。2、每日例會。3、回顧會。4、反思會。有的地方還會加一個Release發佈計劃會。
Sprint計劃會議：（這個會議我們做的最不好，所以我說的最多）
Product Owner（PO）講解Story，特別是業務背景，驗收準則等。然後Team團隊一起評估Story，並分解成2~16小時的Task。我們一直都沒有做好這一部分的工作，主要問題有這麼幾個方面：
1、我們沒有真正意義上的PO，基本上是客戶提出需求，然後主要有Project Manager（PM）來分析理解需求，然後Technical Manager（TM）協助PM編寫Product
Backlog，當然寫出來的Story就更偏向於功能級的Feature List。所以首先在需求講解這一部分就比真正的PO要弱了很多，業務背景也差了許多。這是我們的不足之一。
2、開發人員沒有很強的主動意識，或者還不願意去改變，或者說公司並沒有很直接的去推動敏捷。開發人員總是依賴於PM或者TM去分配任務，在計劃會議的時候不喜歡或者說不善於去思考問題。導致Story分解Task的時候無法進行下去。或者非常困難的進行下去又都是形式上的分解。何爲形式化分解了，就是每個任務都是分解成同樣的5步：（1）需求理解。（2）界面設計。（3）測試用例和概要設計文檔編寫。（4）編碼。（5）自測。當然分成這幾步沒錯，也總比不分解要好的多，但是過於形式化，大家並不喜歡真正的去思考，最後還是跑到了老套路去了，一個功能模塊一個人去完成，不論分解成5步也好還是10步也好。完全沒有體現合作、協作、團隊。不過追根到底可能還是跟我們一開始分解的Story太偏向功能模塊有關。
3、評估時間與單位問題，常見的評估工作量有兩種度量單位，1、Story Point。2、理想時間。對於第一種Story
Point來說比較抽象對於第一次實施敏捷的團隊來說可能不好掌握，所以我們採用了理想時間。可是問題來了，雖然我解釋了無數遍理想時間的意思是你完成一個task所需要的連續的理想的時間，強調是無打擾不間斷很理想的。可是開發人員還是喜歡用8小時，16小時這樣的時間段來評估任務。總是無法拋開1天8個小時這樣的概念。在我強調我們最大利用率最多時有70%，也就是一天只有5.6小時理想時間時，他們依然很茫然。意識的改變真的是一件非常困難的事情。每天我在收集時間所用task時間的時候他們也總是把一天填滿8個小時，每次我問實際時間是多少，他們總是說是8小時，似乎不填滿8小時就是犯罪一般。
分析以上幾方面的問題，我給出的一些建議是，1、增加與客戶的聯繫，沒有PO是硬傷，這個我也沒有具體的辦法，只能做好一切可能的溝通理解用戶的業務背景與真實需求。2、Story編寫應該跨功能，趨近客戶價值。不應該是功能模塊，這樣不是敏捷的思想，沒有價值可言。而且在分任務時必定會趨近瀑布模型一個人編寫一個功能模塊。增強開發主人翁意識，強迫每個人來分析Story應該如何劃分task，要給出初步的界面設計和概要設計，要說出來，如果你來開發這個Story準備分幾步來完成。並且如何完成。（簡要說明）3、收集時間時，一天不然填滿8小時甚至是不然填7小時，最多可填6小時或更少。估算時間時，就可以參考以前收集的時間來分析估算現在任務所需時間。
每日例會，也叫晨會：
晨會其實說起來簡單，但是做好他也不是一件非常容易的事情。那麼我覺得應該注意的幾點是：
1、不要超過15分鐘。（7人左右團隊）
2、回答三個問題的時候，要注意，1）我昨天做了什麼？但是要說明做的情況，是否已經做完？做完了是否解決了什麼特別的技術問題？沒做完預計什麼時候可以做完？2）今天將要做什麼？但是要說明今天的任務預計什麼時候做完？3）遇到了什麼困難？包括昨天我們遇到的困難？超過2小時候的困難一定要記錄到Block看板裏。還有今天我處理的事情中我可能會遇到的困難，我需要幫助。那麼其他人員儘量主動的思考是否可以幫助到他的。然後約定時間會後一起溝通解決。
3、會上不要解決任何技術問題，如果會上有很多技術問題的話，那麼一定是會下大家都很少溝通的原因。會上應該找好可以幫助到自己的人，然後會下去解決。
回顧會：暫時我們沒有這一部分。這裏也不做分析。
反思會：
反思會個人認爲對於敏捷的持續改進來說非常有作用。在反思會當中，團隊會自我發現我們在上一個sprint中大家最關心的碰到的問題。或者我們做的好的地方，大家都很認同的。那麼反思會應該是在一個好的溝通環境當中，大家都非常放鬆暢所欲言。好的東西，我們要總結出來爲下一個sprint發揚使用。不好的方面我們要選出2~3項做更深入的分析，找出深層次的原因，拿出解決方案。然後制定負責人，在下一個sprint中取改進。很重要的一點就是，如果有多個sprint都提到了同樣的不好的地方，我們就要引起注意，把他特別的拿出來做分析討論。拿出可執行的解決方案。派專人跟蹤執行情況。作爲一個團隊，我們每一個人都有責任和義務一起去思考拿出解決方案，並一同協作解決。等會我會加上我們幾次反思會的一些成果分享給大家。我也非常想看到大家的分享。呵呵
最後還是強調Scrum的價值觀：溝通、公開、專注、尊重、勇氣。