老翅寒暑

項目管理沙龍第七次聚會紀要

本次沙龍的主題是由NSEC項目組介紹他們的敏捷實踐經驗。作為公司第一個實施敏捷的項目，他們的成績給整個公司帶來了震動，也是公司其他項目實施敏捷的參考和基礎。因為時間是所限，這次沙龍雖然只來得及只討論了NSEC的四個問題，不過逐個問題討論的過程中，我們涉及到了更多的方面。

上次沙龍提出的“代碼秀”在NSEC實施了一周，效果不是很好，首先是頻率問題，上次沙龍談到的代碼秀周期是“周”或“月”為單位，NSEC的實踐證明以“天”為單位確實是太頻繁了；其次是項目組太忙了，沒時間總結，而且分散獨立提出各自的代碼片段，如果沒有專人匯總收集的話，分享起來還是不太方便；另外出現的問題是，程序員知道某些做法是錯誤的，但是太忙了，沒有時間去寫的更好。對于最后一種情況，每日的代碼審查效果會更好些。

NSEC啟動的時候，由他們的敏捷教練給大家講了一個多小時的敏捷方法，但是大部分人之前沒有聽說過敏捷，并不是十分了解敏捷給各方面帶來的好處，當然也就沒什么想法，用時髦的說法，就是屬于“被推行”敏捷的。在實施的過程中，感覺每日例會有些用處，另外就是感覺工作壓力大了，尤其是在結對的時候。于此相對應，AOM的敏捷實施就好很多，感覺推行起來比較有趣。當然最開始也有一個敏捷啟動會議，說明一下試試敏捷對大家的好處，使大家能夠理解并支持。所以項目的敏捷啟動會議是很重要。AOM的實施過程中對角色劃分有了一定的改進，把標準定義中的ScrumMaster職責劃歸兩個角色，一個是PM，負責項目的進度，另外則是新的ScrumMaster，他僅負責和保證敏捷的規則實施的準確性。這樣的分工，敏捷教練可以身兼多個項目組的教練職責。

另外需要說明的是，因為NSEC的項目進度壓力比較大，依然加班比較多。這種NSEC達到的快速交付效果，到底是敏捷帶來的還是加班帶來的，其實很難分清。即使從現在來看，也一樣。

PM對敏捷能否正確理解是很重要的。有一段時間，NSEC的敏捷教練因為工作關系只要一沒去跟蹤，敏捷規則就會松懈下來。如果項目組內部有人熟悉敏捷，保持持續的跟蹤，效果會更好一些。在敏捷的實施過程中提出了很多的問題，比如狀態更新不及時，多任務并發的時候如何去處理等等。NSEC項目組采用的方法是ScrumWorks和卡片同時進行的方法，所以每個人除了去更新卡片的進度之外，同時還要去更新軟件里邊的進度，所以忘記更新的概率很大。在AOM的實施過程中，同樣也是ScrumWorks和卡片同時使用，但是做了改進，每個人都只需要去更新卡片的進度，并由專人把每個卡片的進度同步到ScrumWorks中去。這個工作由每日例會的主持人負責。除了同步進度之外，主持人還需要每天在例會開始時候向大家報告項目的總體進度（已做的、正在進行的、未開始的），并且還要對本次sprint的完成時間進行預估，除了例會之外，還需要負責sprint計劃會議和回顧會議。AOM的例會主持人是每周輪換的。每周輪換主持人的效果很好，每個人的積極性和學習都非常投入，項目成員對于一些深入的做法也比較容易接受。一個典型的例子就是他們的設計和文檔工作，做到了很仔細的程度。但是每周輪換主持人也有不好的地方，就是團隊主持人的能力提高速度比較慢，因為每周都是新人，所以每周都是初學者狀態，直到一次輪換結束。如果在此期間敏捷教練缺席的話，敏捷制度就可能松懈。相比而言，ASPI項目的輪換做得就比較好，輪換是以月為單位。主持人有充分的時間來學習和提高，即使敏捷教練缺席，主持人也可以擔當起“規則的維護者”這個角色來的。

從AOM和NSEC的敏捷實施過程中來看，都出現了每個人都只關注局部而忽視總體的情況，最后解決的方法也大同小異，基本都是派出一個專人去負責這個事情。也就是我們的敏捷團隊中依然存在有“架構師”的角色。

在任務評估方面，NSEC是最早引入“打撲克”backlog評估方式的項目組，但是NSEC在backlog評估完畢之后，沒有去進一步跟蹤point數和實際工時的對應關系，也沒有在總結回顧的時候評估point評估的準確性。對比AOM團隊和BPM團隊，目前也僅評估了每一個backlog的point數，并沒有深入去評估每個task和工時的對應關系。ASPI評估了point和每個task的工時，但是沒有去跟蹤兩者的對應關系。從實踐來看，不把point換算成實際的工時，對敏捷的繼續發展沒有多大的影響。但是和NSEC相比，其他幾個項目組采用了簡單的效率計算公式，就是“效率=sprint的總point數/（人數×sprint工作日數）”，這個效率就是每人每工作日可以完成的point數，目前的數據是1個point/人日，因為一個point對應0.5工作日，所以也就是平均工作效率為50%，雖然有提高的空間，但是也已經夠可以了。

在我們參考的書中特別提出，敏捷在實施三個月之后會有危機出現。事實上我們雖然沒有出現危機，但是也有了一些的壞味道，比如改進錯誤的速度降低了，隨意增加backlog或隨意擴大backlog的工作量，隨著時間的推移，在大家習慣了敏捷的快節奏之后，問題會出現的更多，應該對此做好準備。

NSEC的另外問題是缺少一些敏捷的要素，比如現場沒有客戶或客戶代表，做完之后和客戶的期望不符導致返工等。經過我們的討論，認為客戶不再現場有幾種方法可以緩解或避免：要么有客戶代表或讓產品經理和客戶充分溝通，要么使用設計原型和客戶事先就達成一致，要么就是建立UAT（User Acceptance Testing）環境，讓用戶可以實時看到系統的變化情況。

在討論過程中，與會人員冒出了兩句經典錯誤認識，“敏捷不要文檔”和“敏捷實施需要高超的能力”，遭到了大家的駁斥。首先說“敏捷不要文檔”，對了一半，敏捷只是不要重復去做一些只為了看的文檔，敏捷更重視過程原始數據的收集和分析。也就是說，如果文檔和推進項目進度和交付的目標不符，那么這種文檔就盡量不要，即使需要，也是用最簡單的格式記錄一些原始數據就可以了。至于“敏捷實施需要高超的能力”，正好相反，從我們的實踐中就可以知道，敏捷的實施并不需要什么特別的準備，只需要項目團隊實施敏捷的共識而已。更不需要管理者有什么高超的能力，無論如何實施，敏捷都“不會做的比項目組的現狀更差”。

下一次的聚會，依然討論NSEC的敏捷實踐。