[size=large]專案管理沙龍的第一次聚會紀要[/size]
會議的主題是專案管理和敏捷。敏捷是近幾年的熱門話題，也是最讓人誤解的名詞了。
有人在會上提了這樣的例子：
[quote]兩個人a和b爬山，b不管三七二十一，直接上山朝目的地行進，結果半路遇到沒路，就折回來再重新走一條路，這個就叫「敏捷」。而a呢，先繞山走了三圈，制定出乙個完美的計畫，並且進行風險評估，設計應對方案，然後還劃出幾個里程碑，最後開始實施，到了山頂，人們叫這個為「瀑布式專案管理」。並且現在都認為b會先到目的地。[/quote]
這個例子引起了大家的反對。並認為最早寫這個例子的人肯定不懂敏捷。相比而言，其實敏捷更重視計畫和階段的劃分，而且在過程跟蹤上的力度也比傳統方法要緊密。
[size=medium]這就提出了「什麼是敏捷」的話題。[/size]
有人首先強調了敏捷方法和傳統的指令式專案管理方法在目的上的一致性，就是以達成專案目標（進度、成本、質量、團隊等）為目的。但是他們是[b]兩種完全不同的解決思想的產物[/b]。
傳統的專案管理方法首先普遍認為員工是一種需要用嚴格約束來驅動他們工作的，而監管他們的人就是專案經理。幾乎所有關鍵的專案工作壓力都集中在專案經理身上，由pm進行任務的分解、評估、工作分配和任務跟蹤，還需要對過程資料的收集和評估等，當pm出現差錯、懈怠或者不勝任的時候，專案就會陷入混亂和停滯。在團隊氛圍上，普遍士氣不高，沒有明確的團隊激勵機制。
但是敏捷方法採用的是相反的思想，他們首先強調的人的因素。希望通過充分調動人的積極性，將專案管理的職責分攤到每乙個人，每乙個人在履行自己的工作承諾的同時，也參與專案組的所有管理工作。通過持續的「計畫-實施-檢查-改進(pdca)」工作迴圈，保證團隊和參與的每乙個人都得到提高。敏捷方法的主要激勵機制是「成就感」，所以團隊氛圍普遍較高昂。在bpm和aom的scrum實踐中，有明顯的感受。
另外有人舉了例子：
[quote]乙個人a在早上八點準備從深圳出差到北京，但是到機場的時候誤點了，於是他就上了一輛taxi，讓司機b開車去北京，並且要求中午就要開到。
[/quote]
很明顯這是乙個很過分的要求，深圳到北京這麼遠，很明顯不可能4個小時到達。用數學公式來解釋，就是[b]「速度×時間」遠遠小於了「距離」[/b]。所以這個是乙個不可能完成的任務。
但是把同樣的場景放到軟體開發專案中，卻有不同的結果：客戶a要求在某個期限內完成專案，作為專案經理的b很可能就答應下來，但是結果要麼是無法完成，要麼就是完成質量不高，導致後期返工。
目前最常見的問題是專案組無法評估專案的規模，也不知道專案組的實施能力，從公式[b]「距離=速度×時間」[/b]來看，專案組當然也就無法評估專案結束所需要的時間了。面對客戶的無理要求，這樣的亂答應也就毫不奇怪。
通過過程資料收集和評估，來獲取專案的實施能力、規模、質量、進度資料，是專案經理的一項重要工作。但是在傳統的專案管理方法中，實施起來並不容易。一般要達到cmmi3或4的企業才能達到這樣的能力，但是通過scrum方法的實施，在前兩個迭代之後，就基本可以獲得這些資料了。
[color=red]為什麼實施scrum之後就可以短時間內做到？[/color]這個是沙龍中提出的又乙個問題。實際上敏捷採用的管理策略是一種「人民戰爭」的策略，通過發動「群眾」，提高大家的主動性，平等和積極地參與專案的日常管理。有這麼多人，通過每日例會和其他的頻繁溝通，來平等獲取專案的各種資訊和狀態。這樣當然比傳統的乙個專案經理單打獨鬥要有精力，而且更細緻，更全面。更重要的是專案組員獲取的「任務」，基本都是自己感興趣的甚至就是自己發現的，工作幹勁上是傳統專案管理手段所不能達到的。
所以「敏捷」的管理力度更強、更深入、全面和細緻。而且從實際來看，敏捷的專案管理者並不需要擁有比傳統方法的專案管理者更高的能力，相反還更輕鬆一點。
討論中並不是所有人都認可敏捷。實際上scrum中的做法不是什麼新發明的，都是傳統專案管理中已經大量應用的技術，比如需求的功能點評估，專案過程資料收集和評估，設計方法等，專案管理過程中只需要堅定地朝專案目標前進，只要是好的方法都可以拿過來實踐，我們就可以在scrum的基礎上來發展出一套符合自身特點的敏捷過程。傳統的專案管理方法也可以採用敏捷的一套做法，慢慢把自身敏捷起來。
不過有人立刻就此觀點提出了異議。從公司目前兩個專案組的scrum實踐經驗可以看到，敏捷過程（至少是scrum方法）中充滿了一些隱喻的做法，比如評估point和評估hours並行進行，相互印證；比如backlog打分過程的知識傳遞和博弈；比如每個迭代的「計畫會議-每日例會-回顧會議」這個pdca的迴圈過程；比如team work的團隊責任原則，等等。缺少這些基礎的價值觀，「敏捷」就不再是敏捷了，而不納入這些價值觀，傳統的專案管理方式也永遠不能「敏捷」起來。
當然，敏捷方法也有自身的缺點。首先乙個就是缺少乙個人去關注全域性，關注架構。但是很快有人提出，敏捷只是一種專案管理方法而已，把這個缺點說是敏捷的缺點也有點牽強。繼續討論之後，我們發現在實施敏捷的時候，還是不能忘記每個角色的分工和側重點，雖然號稱是「平等」，但是架構師依然要多關注架構，測試工程師也依然不能忘記產品的「可測試性」。
敏捷的初衷就是要拋棄各種條條框框，所以敏捷實施過程中，也並不存在什麼「必須」去做的方法，哪怕是敏捷的核心價值觀，也沒有什麼固定的做法。靈活是敏捷的表現，但是「靈活」並不等於「粗糙」，事實上敏捷就是拒絕「粗糙」的，我們要看到敏捷的「靈活」背後所蘊含的「細膩」的各種實踐。我們在去看《敏捷宣言》：
[quote]敏捷軟體開發宣言
我們一直在實踐中探尋更好的軟體開發方法，
身體力行的同時也幫助他人。由此我們建立了如下價值觀：
個體和互動 高於 流程和工具
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計畫
也就是說，儘管右項有其價值，
我們更重視左項的價值。[/quote]
可以看到，所謂的「敏捷」方法，就是秉持敏捷理念的專案管理方法。
但是在敏捷的實施過程中，並不都是一帆風順的。乙個流暢的敏捷管理過程，機器的輔助是相當重要的，比如關鍵的「持續整合」。
[size=large]總結[/size]
雖然這次討論的主題是「專案管理和敏捷」，但是話題涉及到了專案管理的很多方面。會議氣氛熱烈，有很多精彩之處，個人比較滿意。但是因為是初次沙龍，所以會議話題有些分散，有些同學希望主題能夠更加明確一些。
期待下次更好。
it專案管理第一次作業
例子專案組合，專案集和專案通常都涉及相同的相關方，還可能需要使用同樣的資源。從組織的角度來看專案 專案集和專案組合管理 專案與運營會在產品生命週期的不同時點交叉，例如 opm 指為實現戰略目標而整合專案組合 專案集和專案管理與組織驅動因素的框架。opm 旨在確保組織開展正確的專案並合適地分配關鍵資源...
IT專案管理第一次作業
1.描述projects programs portfolio operations 和 opm 的概念 projects 專案是為創造獨特的產品 服務或成果而進行的臨時性工作。program 專案集是一組相互關聯且被協調的專案 子專案集和專案集活動，以便獲得分布管理所無法獲得的效益。portfol...
團隊第一次會議紀要
1 會議討論內容紀要，誰說的內容 肖洋 首先來討論一下我們目標使用者的痛點 宋泊然 解決那些想考研但沒有辦法了解考研流程和考研資訊的使用者痛點 肖洋 就是解決使用者無法獲取資訊的痛點 宋泊然 讓那些入門考研的學生可以找已經考研的學長學姐了解資訊。肖洋 也可以解決考研的學生在考研路上比較孤單的問題 張...