Team剛剛完成了一個敏捷專案，做一下專案總結，以備以後借鑑和提高。

需求 - 溝通 – 人 - 過程 - 工具

專案要成功的最關鍵因素是什麼？軟體要快速高效又高質量的提交靠的是什麼？有人說最關鍵是專案經理，關鍵是溝通，有人說是技術設計，有人說是對需求的把握… … 從我看來，都是盲人摸象，專案要成功，軟體要快速高效又高質量的提交，靠的是多重因素的整合和平衡；首先要對需求的準確理解和把握，貫穿全流程的溝通，做專案靠人，對人/士兵的管理（物質、心理），適合組織的先進的過程（開發，測試，評審，組織，考核），還有工具的運用和整合大大提升組織效率，缺少那一樣都是不行的。成功的模式只有一個，而失敗卻有各式各樣，就是這個道理。

溝通，隨時隨地，全方位立體的，有效的，及時的溝通

溝通，溝通，隨時隨地，全方位立體的溝通。面對面、站立會議、咖啡間、IM、Email、文件、電話。上下級、跨部門、客戶，溝通，直到雙方的理解沒有Gap（鴻溝），沒有Misunderstanding（誤解）。主動溝通，有問題隨時反饋。對被動的同事，主動問他。注意溝通的效率和時間表，不要一個會議開兩個小時。如果有必要，儘量讓少的人蔘與，除非是kick-off會議。此外，溝通會影響時間表，比如你有個問題要問某人，而這個人下週開始休假了，要早做預防。否則，吃虧的是自己。

白板，任務板，Sketch，Prototype

Team位置必須坐在一起，最好是圓圈式的座位，旁邊有玻璃白板，上面畫好下一個里程碑和Release的Roadmap，玻璃白板便於馬上溝通。任務板便於大家清楚當前致力的目標和Release。對於Sketch要用好，在產品或者功能還沒有做出來以前，先把Sketch或者Prototype發給客戶看一下是否認可，獲得用好Remarks，然後再開始動手；畢竟動手了再修改代價就更大了。所以一定要用好Sketch草圖。

Stand up meeting要不要

很多人說到Scrum就要每日晨會Stand Up Meeting，但我們Team的實踐來看，並不是必須的，其實敏捷也是根據組織和專案實際情況因人而異的（有人說敏捷對結對開發人員的能力要求很高，我覺得敏捷是一種境界，良好的架構，程式碼規範，成員間非常好的默契，才能敏捷的起來）。不能拘泥於形式主義，我主張實用主義。現在不是有反敏捷、有瀑布敏捷（Water-Scrum-Fall）、實用敏捷嗎？關鍵是我們還沒有領會敏捷的深刻內涵和思想體系，不會用敏捷的思想和思維方式高屋建瓴的思考我們的開發流程，而只是依葫蘆畫瓢學個一招半式，那就真的不是敏捷了。我聽到有人說，敏捷只適用於產品型公司和小型專案，還有人說敏捷只適合於需求不穩定的專案，還有人說敏捷了就等於速度快，就等於客戶報價可以低一些，還有人說敏捷說的什麼迭代持續整合和重構都是理論，沒有考慮到實際執行起來的風險……都沒有錯，關鍵是我們還沒有領會敏捷的深刻內涵和思想體系，不會用敏捷的思想和思維方式高屋建瓴的思考我們的開發流程，而只是依葫蘆畫瓢學個一招半式，在這兒討論，說白了還是理論，坐而論道不如起而行

保證程式碼質量

如何獲得高程式碼質量？打個比方，現在要打仗了，如何打個漂亮的勝仗。我想你肯定知道答案了。那就是你的隊伍必須各個是精兵，能力強，平時訓練有素，而且還有實戰經驗，這樣的一個兵強馬壯的精兵隊伍你拉出去，只要指揮好，士氣高，就能打漂亮的勝仗。OK，現在你明白了，軟體開發何不如此？你手下的程式設計師是不是技術能力很強，是不是平時就對技術研究很深，對某科技術有很深的理解，還有很多專案經驗，是不是幹勁十足，是不是對他們做了培訓，是不是做了程式設計規範的要求，都明白了命名規範、異常處理、日誌處理、安全性、使用者許可權、配置檔案、設計模式、執行緒安全、單元測試、除錯技巧、條件編譯等專案標準處理；如果還沒有這些標準的貫徹，那你的士兵還需要培訓（訓練），這樣子上戰場會很危險。當然，有個變通辦法，讓資深程式設計師帶小弟，小弟在一邊看著，下個專案備用。當然。除了培訓以外，分享、知識庫都是團隊很重要的機制。

基礎不紮實的程式設計師程式碼質量不會高起來，比如有的C#程式設計師根本理解Task.Factory.StartNew這句話是非同步執行的執行緒池起執行緒，就把它放到同步的迴圈裡面，導致問題。再比如，有的程式設計師用匿名函式，不懂閉包，導致放在迴圈裡面每次取到的都是最後一個值。再比如有的程式設計師不深刻理解Session，就認為瀏覽器關了Session就沒有了。再比如有的C#程式設計師不理解GC以為一個類只要實現了IDisposable介面就一定會記憶體釋放……舉不勝舉，都是專案中遇到過的（注：對基礎不紮實的程式設計師進行程式碼Review管用嗎？我們專案實踐來看不管用，因為資深程式設計師很忙，不可能一行一行去看去除錯。）……所以，優秀的程式設計師都是建立在對該技術的深入理解的基礎上的。優秀的成熟的程式設計師員工都有專業化（技術方面）、職業化（服務意識、協作能力、解決問題的能力和態度）和商業化（替客戶思考和解決問題）多方面的優秀特質，才能真正的為業務創造價值。

保證程式碼質量的另外一個非常重要的方面就是測試，一定要寫單元測試，使用Moq做單元測試。這可以培養程式設計師面向介面的思維方式，如果程式碼不能做單元測試往往是耦合度很高的程式碼，所以單元測試能發現程式碼質量的問題。此外，測試組的工作要及早介入，對業務的深刻理解，重複利用bug管理工具，敏捷測試。

為需求變化和維護早作準備

在系統設計的時候，要考慮到未來可能的需求變化，做好面向變化的架構設計。但不要過度設計。（這需要深入理解商業需求）

為維護早作準備，意思是說，在編碼階段，就要考慮到系統的可維護性，設想你自己就是將來維護這個系統和這段程式碼的人，這種意識很重要。有的程式設計師以為系統提交了上線了就沒他的事情了，結果到頭來上線了出現問題，系統又沒有很好的log和trace，導致問題極難線上除錯，而線下又不能模擬真實的環境，這種情況下必須為維護而設計，提升系統的可維護性、可追溯性、可管理性。

不要過度設計和過早優化

過度設計是敏捷開發應該避免的，很多工程師都有過度設計的衝動。例如，在一個web系統還沒有看到被大規模使用的曙光以前，就設計了系統規模化，什麼叢集、負載均衡、讀寫分離、分散式快取系統……說真的，這些東西確實是好東西，但也很貴。在系統還沒有被大規模的使用者接受和喜愛之前，這樣做是否會抵消了我們把專注點放在核心功能和簡練和簡單的努力呢？時間是有限的，投資也是有限的。我們必須把有限的時間和有限的金錢用在當前最核心的功能和體驗上。有時候系統初期，可能一兩臺伺服器就足夠了。只有在看到產品有被大規模使用和使用者喜愛的曙光之後，才來增加功能和規模量。當然，你的網站功能，在你只有 10 萬用戶的時候，可能和你有 1 億使用者的時候會很不一樣。所有太多太早太頻繁的架構上的大動作可能會適得其反。這一點上，你要小心判斷。系統架構需要及早規劃，但不要提前實施和過早優化。

關注非功能性需求

也許大多數客戶和諮詢師也會聽說過神馬TDD、迭代、原型、持續整合和持續部署、Agile等時髦的詞語，這些也讓管理者很興奮，以為軟體產品是可以在很短的時間內高質量的完成的，即使完不成也可以在後面用TDD，快速迭代，不斷重構，持續整合直至持續部署的方法在進行軟體開發。這聽起來好像很美好。但其中有個很大的陷阱，那就是客戶和諮詢師，還有原型、TDD大都只關注功能性需求，而忽略了非功能性需求，比如效能問題，高可用性問題，系統維護問題（模組的耦合問題），等等。客戶和諮詢師在專案前期閉口不提這些或很少提及，但一旦功能性需求都做完了他們就會抱怨這些隱藏的非功能性需求。而像效能問題，高可用性問題，系統維護問題（模組的耦合問題）等並不是很容易重構，往往涉及到Re-design, re-architect；因此這些問題往往都在後期會成為重構噩夢，甚至可以讓你的軟體設計重新來過！更加糟糕的是，大多數客戶不願意為這些隱藏的功能重構而付錢。筆者曾經遇到過前期只注重功能性需求而後期發現效能不好而進行re-design, re-architect，這對專案管理來說有很大的挑戰，因為不單單是程式和架構重構的困難，還要面對時間和人力成本的增加，最難的是你還要面對的是團隊士氣因為不斷的rework而逐漸低落併產生厭倦和懈怠情緒。這是一個很大的陷阱。

所以，前期就要關注非功能性需求，不要急於動手，如果你能有多一些時間去和客戶討論一下需求和未來可能的變化，去調查一下實現的技術難點和細節，去和其他有經驗的人討論並推敲一下架構和設計，去思考設計上的缺陷，那麼，你的coding會變得非常地直，直到你一眼就看到盡頭，你的測試案例也會寫得非常地好，你會幾乎不需要重構，於是，你會在未來少寫很多程式碼，從而你的軟體開發會越來越輕鬆，直到技術開始換代。這就好像我們修路造橋一樣，我們需要花大量的時間勘測地形地質，分析資料，思考可能出現的各種問題（各種自然災害），評估不同的設計方案，而不是先儘快建好再說。(：磨刀不誤砍柴工) 說到這裡，有些反敏捷（反Scrum），沒錯，好的程式設計師要會做權衡/平衡，好的架構師要會做平衡，好的專案經理也要會做平衡，這非常重要。

再補充一點，有資深經驗的工程師/架構師對非功能性需求的設計和平衡很有經驗，這些經驗對系統設計和專案成功至關重要。如果你很不幸，手頭沒有這些有經驗有價值的人，而只有一堆碼農，那麼恭喜你，你可以在一張白紙上畫畫了。就開發他們的潛力吧，做好這個專案給他們積累經驗的心理準備吧，量力而行吧，小馬過河吧……實在不行你就自己上吧，畢竟公司要求用最少的錢在最短的時間內出來最優秀的東西；如果你有話語權，那就把你的困難及早讓上層知曉。

嚴格控制需求和範圍，和進度權衡，不出現資源空閒

領導一般會給專案經理壓力，要求在什麼時間提交一個版本趕進度等，這時候專案經理要麼能調整一些需求和範圍（Scope），要麼就把可能出現的問題進行報憂，因為現在如果不這樣做，你就等著現在報喜，後期報憂吧。所以專案經理一定要嚴格控制需求和範圍（scope），和進度，和質量權衡。同時要合理調配資源，不要出現專案進行中資源空閒的情況（這個在Project工具中可以看出）。

專案風險管控

專案經理要有專案風險管控能力，及時在專案進行的各個階段進行風險的預識別和管理。專案一般是前期工期鬆，風險低；而後期工期緊，風險高。所以專案經理要儘可能在專案早期能列出大部分的風險，這樣在專案的風險應該是倒三角形狀的，就是前期風險多，後期風險少。要預先把下階段可能的風險明確告訴客戶，讓客戶提供幫助來控制風險的發生，同時迫使客戶加強風險意識，不讓需求任意擴散和蔓延。在各個階段都要有雙方風險認知的會議紀要記錄。一般情況下，專案的外部依賴條件是最不可管控的風險（比如要和第三方聯調，要第三方提供API等）。其次是需求的不明確和需求蔓延的風險（需求問題佔專案成功的40%因素以上，你能控制需求，你就成功60%了）。然後還有資源的可用性（如：專案進行中核心人員流失，要知道專案進行中間換人和加人都很是問題）。

資源提供者和問題解決者

大家都知道，打仗的時候什麼最重要？對了，補給（後勤保障）。士兵上戰場了，誰做後勤？專案經理。每天都要問大家，你下一步需要什麼，你還缺什麼輸入？你有什麼問題需要我這邊配合的？程式設計師旁邊有垃圾了，專案經理去掃一下地，這就是後勤補給。所以管理者首先要理順管理者和人的關係，調整好服務的意識，做好資源源源不斷的提供、幫助大家解決問題，系統就有了潤滑劑，有了源源不斷的輸入，就能順暢的開展。否則，千里馬到你手裡也跑不快的。

管理使用者期望

對每一個Sprint提交，謹慎選擇功能集合，多和客戶溝通，管理好使用者期望，他下一階段希望有什麼功能，這些功能的優先順序如何，實現難度如何，及早告訴他下一個版本會友什麼，不會有什麼。

增加團隊成員之間的親密感

有時候如果一個團隊成員裡面有多個牛人，大家都是很有主見的人，就很容易在一些問題上爭執，甚至產生內部競爭。兩個聰明人意見採取誰的呢？緊張關係在所難免。這種糾結的合作和競爭關係是同事關係的主線。但要保持合作為重點。所以，要把這樣的狀況保持在一個健康的狀態，需要加深團隊成員的親密感。具體來說，坐在一起聊天、吃午餐、喝咖啡、散步、打球、打牌，都是增加親密感的方法，這樣拉近人與人的距離，就不會覺得有什麼競爭的緊張感了。

管理團隊目標和情緒

Scrum有一個優點就是短週期快速迭代，每週大家都有明確的目標，因為Release週期很短，大家Vision很明確，所以為什麼Sprint就是衝刺的意思。管理好團隊的目標、Vision，有明確的目標，有衝刺的幹勁。及時發現團隊的情緒波動，採取應對措施（休整，腐敗，激勵）。

保持耐心，不斷調整

技術上要重構，架構改進和提煉等。信任程式設計師，給他們時間來重構，來調整和優化架構等。管理上要重構，程式碼促進委員會，評審組等等。改進適合組織規模和業務發展的流程，目標是獲得持續、快速、更好質量的交付產品和更好的客戶滿意度、更低的成本和更高的效率。總之，要不斷努力，不斷調整，不斷嘗試新的方法，做的越來越好。要保持耐心，給員工/系統的成長/成熟一點信任和時間。

專案經理的人格魅力和以德服人

作為專案經理您必須與同事以團隊合作方式才能保證專案的順利完成，如何鼓舞團隊成員的士氣？讓大家心甘情願的與你朝著共同的目標努力。要做到這一點，人格魅力非常重要。但要讓大家真正服你，真正的服是以德服人。比如，你要求所有的手下都主動配合你的工作，但是你自己如果沒有首先要求自己主動配合大家，你就不會贏得大家的尊重。這只是一個例子而已，很多點滴細微之處會讓大家感覺到你的人格魅力，究竟是一個值得尊敬的人，還是一個不值得尊敬的、自我的、高高在上的釋出命令者。總之，做人是最要緊的，做人沒做好，做事肯定做不好了，專案多半要搞砸。

但就專案經理的專案管理能力來說，也關係到專案的成敗，比如能否引導客戶需求、對問題的透徹理解、對複雜的任務緊密跟蹤並設定輕重緩急、利用各種渠道和方法來溝通解決問題、有能力做出適當的取捨、說服客戶或領導的能力、推銷自己解決方案的能力、突破性格制約的溝通技巧、面向全域性思考的思維方式、如何合理動態分配大家的工作項使不被Block住……

總結

先寫這麼多吧，想到了再補充。

Update：現實專案管理中的一些實際矛盾

4. 專案經理兼任Team Leader的矛盾

專案經理和Team leader這兩個職位貌似是一樣的，其實不一樣。專案經理的職責包括：專案進度控制，成本控制，需求控制，風險管理，配置管理、任務分配以及與客戶相關的溝通和交流等。而Team leader的主要職責包括技術方案確認，開發計劃制定和跟蹤，技術架構設計，重要技術問題攻關，核心程式碼編寫和技術指導以及開發團隊管理。對於小公司來說，為了節約成本很可能把兩個角色讓一個人來承擔，這樣的混合角色對個人能力要求非常高，需要兩方面的專業知識，兩方面都得一手把握，壓力很大。現在很多大公司基本都將這兩個角色分拆了，專案經理就是管進度，做協調，Team Leader就負責開發相關事宜，另外還有一個角色，叫Product Manager，這個角色主要是市場和開發之前做協調了。按照我的理解，專案經理需要對專案功能和需求（產品）有非常深入的瞭解，對軟體開發過程相當有經驗，同時具有很強的溝通能力，因為客戶都是牛的一塌糊塗，你要引導客戶的需求，那是溝通功夫了得。另外，專案經理是專案總負責人，對領導對跨專案和部門也需要及時的溝通協調以獲得最佳的資源，以解決過程中的問題。而Team leader需要控制開發過程中的系統性風險，總體架構把我和關鍵核心部分開發。軟體開發過程有很多的環節，任何一個環節出現大的差錯都會導致焦頭爛額並最終專案失敗。但是在大多數公司，我們都不會稱其為失敗，一般會說：專案延期，好的延期半年，差的甚至有的延期1年！核心競爭力：開發管理＋過硬的技術能力。

5. 有限的資源和時間與按時上線的矛盾

分配任務的核心原則，就是先分清輕重緩急，作為管理者，一定要將它養成習慣。  

Update：優秀專案經理必備素質

專案經理是專案的負責人，不管發生了什麼，都能按時交付，優秀專案經理要具備這個素質。充分理解需求和範圍，充分和客戶明確詳細需求和期望，充分考慮自身團隊的技術能力、專案依賴、隊員排期衝突、負面情緒、技術方案風險、未預知的技術障礙、需求變化等。具備為功能的設計做取捨的能力，但功能取捨並不以犧牲產品的核心願景為前提。具有極強的交付能力的前提是具有極強的責任心。有了責任心，你會把專案當成自己的孩子，傾注你的全部心血，即使出現極端困難的局面也會死扛。責任，會驅使你關注專案的進度，千方百計去尋找各種資源，推著專案往前走。甚至吃飯、睡覺，走路、坐車，都想著整個專案團隊，想著他們還在加班加點，你可能很自然地給他們帶點夜宵、衝杯咖啡，犒勞員工。有了你這樣的專案經理做表率，整個團隊會鼎力支援工作，士氣非常高，技術問題也迎刃而解，得到領導稱讚和客戶肯定，專案將朝著預想的方向發展。許多開發人員抱怨專案經理一天沒幹多少事情，而工資還挺高。其實，專案經理一刻都沒閒著，他總在想著怎樣更好的執行專案計劃，調整專案進度等，腦子一直在不停地運轉，所以說專案經理是真累。