老翅寒暑

會議的主題是項目管理和敏捷。敏捷是近幾年的熱門話題，也是最讓人誤解的名詞了。 有人在會上提了這樣的例子： 兩個人A和B爬山，B不管三七二十一，直接上山朝目的地行進，結果半路遇到沒路，就折回來再重新走一條路，這個就叫“敏捷”。而A呢，先繞山走了三圈，制定出一個完美的計劃，并且進行風險評估，設計應對方案，然后還劃出幾個里程碑，最后開始實施，到了山頂，人們叫這個為“瀑布式項目管理”。并且現在都認為B會先到目的地。

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

會議的主題是項目管理和敏捷。敏捷是近幾年的熱門話題，也是最讓人誤解的名詞了。

有人在會上提了這樣的例子：

兩個人A和B爬山，B不管三七二十一，直接上山朝目的地行進，結果半路遇到沒路，就折回來再重新走一條路，這個就叫“敏捷”。而A呢，先繞山走了三圈，制定出一個完美的計劃，并且進行風險評估，設計應對方案，然后還劃出幾個里程碑，最后開始實施，到了山頂，人們叫這個為“瀑布式項目管理”。并且現在都認為B會先到目的地。

這個例子引起了大家的反對。并認為最早寫這個例子的人肯定不懂敏捷。相比而言，其實敏捷更重視計劃和階段的劃分，而且在過程跟蹤上的力度也比傳統方法要緊密。

這就提出了“什么是敏捷”的話題。

有人首先強調了敏捷方法和傳統的指令式項目管理方法在目的上的一致性，就是以達成項目目標（進度、成本、質量、團隊等）為目的。但是他們是兩種完全不同的解決思想的產物。

傳統的項目管理方法首先普遍認為員工是一種需要用嚴格約束來驅動他們工作的，而監管他們的人就是項目經理。幾乎所有關鍵的項目工作壓力都集中在項目經理身上，由PM進行任務的分解、評估、工作分配和任務跟蹤，還需要對過程數據的收集和評估等，當PM出現差錯、懈怠或者不勝任的時候，項目就會陷入混亂和停滯。在團隊氛圍上，普遍士氣不高，沒有明確的團隊激勵機制。

但是敏捷方法采用的是相反的思想，他們首先強調的人的因素。希望通過充分調動人的積極性，將項目管理的職責分攤到每一個人，每一個人在履行自己的工作承諾的同時，也參與項目組的所有管理工作。通過持續的“計劃-實施-檢查-改進(PDCA)”工作循環，保證團隊和參與的每一個人都得到提高。敏捷方法的主要激勵機制是“成就感”，所以團隊氛圍普遍較高昂。在BPM和AOM的SCRUM實踐中，有明顯的感受。

另外有人舉了例子：

一個人A在早上八點準備從深圳出差到北京，但是到機場的時候誤點了，于是他就上了一輛taxi，讓司機B開車去北京，并且要求中午就要開到。

很明顯這是一個很過分的要求，深圳到北京這么遠，很明顯不可能4個小時到達。用數學公式來解釋，就是“速度×時間”遠遠小于了“距離”。所以這個是一個不可能完成的任務。

但是把同樣的場景放到軟件開發項目中，卻有不同的結果：客戶A要求在某個期限內完成項目，作為項目經理的B很可能就答應下來，但是結果要么是無法完成，要么就是完成質量不高，導致后期返工。

目前最常見的問題是項目組無法評估項目的規模，也不知道項目組的實施能力，從公式“距離=速度×時間”來看，項目組當然也就無法評估項目結束所需要的時間了。面對客戶的無理要求，這樣的亂答應也就毫不奇怪。

通過過程數據收集和評估，來獲取項目的實施能力、規模、質量、進度數據，是項目經理的一項重要工作。但是在傳統的項目管理方法中，實施起來并不容易。一般要達到CMMI3或4的企業才能達到這樣的能力，但是通過SCRUM方法的實施，在前兩個迭代之后，就基本可以獲得這些數據了。

為什么實施SCRUM之后就可以短時間內做到？這個是沙龍中提出的又一個問題。實際上敏捷采用的管理策略是一種“人民戰爭”的策略，通過發動“群眾”，提高大家的主動性，平等和積極地參與項目的日常管理。有這么多人，通過每日例會和其他的頻繁溝通，來平等獲取項目的各種信息和狀態。這樣當然比傳統的一個項目經理單打獨斗要有精力，而且更細致，更全面。更重要的是項目組員獲取的“任務”，基本都是自己感興趣的甚至就是自己發現的，工作干勁上是傳統項目管理手段所不能達到的。

所以“敏捷”的管理力度更強、更深入、全面和細致。而且從實際來看，敏捷的項目管理者并不需要擁有比傳統方法的項目管理者更高的能力，相反還更輕松一點。

討論中并不是所有人都認可敏捷。實際上SCRUM中的做法不是什么新發明的，都是傳統項目管理中已經大量應用的技術，比如需求的功能點評估，項目過程數據收集和評估，設計方法等，項目管理過程中只需要堅定地朝項目目標前進，只要是好的方法都可以拿過來實踐，我們就可以在SCRUM的基礎上來發展出一套符合自身特點的敏捷過程。傳統的項目管理方法也可以采用敏捷的一套做法，慢慢把自身敏捷起來。

不過有人立刻就此觀點提出了異議。從公司目前兩個項目組的SCRUM實踐經驗可以看到，敏捷過程（至少是SCRUM方法）中充滿了一些隱喻的做法，比如評估point和評估hours并行進行，相互印證；比如backlog打分過程的知識傳遞和博弈；比如每個迭代的“計劃會議-每日例會-回顧會議”這個PDCA的循環過程；比如Team Work的團隊責任原則，等等。缺少這些基礎的價值觀，“敏捷”就不再是敏捷了，而不納入這些價值觀，傳統的項目管理方式也永遠不能“敏捷”起來。

當然，敏捷方法也有自身的缺點。首先一個就是缺少一個人去關注全局，關注架構。但是很快有人提出，敏捷只是一種項目管理方法而已，把這個缺點說是敏捷的缺點也有點牽強。繼續討論之后，我們發現在實施敏捷的時候，還是不能忘記每個角色的分工和側重點，雖然號稱是“平等”，但是架構師依然要多關注架構，測試工程師也依然不能忘記產品的“可測試性”。

敏捷的初衷就是要拋棄各種條條框框，所以敏捷實施過程中，也并不存在什么“必須”去做的方法，哪怕是敏捷的核心價值觀，也沒有什么固定的做法。靈活是敏捷的表現，但是“靈活”并不等于“粗糙”，事實上敏捷就是拒絕“粗糙”的，我們要看到敏捷的“靈活”背后所蘊含的“細膩”的各種實踐。我們在去看《敏捷宣言》：

敏捷軟件開發宣言

http://agilemanifesto.org/iso/zhchs/

我們一直在實踐中探尋更好的軟件開發方法，

身體力行的同時也幫助他人。由此我們建立了如下價值觀：

個體和互動 高于 流程和工具

工作的軟件 高于 詳盡的文檔

客戶合作 高于 合同談判

響應變化 高于 遵循計劃

也就是說，盡管右項有其價值，

我們更重視左項的價值。

可以看到，所謂的“敏捷”方法，就是秉持敏捷理念的項目管理方法。

但是在敏捷的實施過程中，并不都是一帆風順的。一個流暢的敏捷管理過程，機器的輔助是相當重要的，比如關鍵的“持續集成”。

總結

雖然這次討論的主題是“項目管理和敏捷”，但是話題涉及到了項目管理的很多方面。會議氣氛熱烈，有很多精彩之處，個人比較滿意。但是因為是初次沙龍，所以會議話題有些分散，有些同學希望主題能夠更加明確一些。

期待下次更好。