qileilove

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

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

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

　 　溝通，溝通，隨時隨地，全方位立體的溝通。面對面、站立會議、咖啡間、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）、實用敏捷嗎？關鍵是我們還沒有領會敏捷的深刻內涵和思想體系，不會用敏捷的思想和思維方式高屋建瓴的思考我們的開 發流程，而只是依葫蘆畫瓢學個一招半式，那就真的不是敏捷了。我聽到有人說，敏捷只適用于產品型公司和小型項目，還有人說敏捷只適合于需求不穩定的項目， 還有人說敏捷了就等于速度快，就等于客戶報價可以低一些，還有人說敏捷說的什么迭代持續集成和重構都是理論，沒有考慮到實際執行起來的風險……都沒有錯， 關鍵是我們還沒有領會敏捷的深刻內涵和思想體系，不會用敏捷的思想和思維方式高屋建瓴的思考我們的開發流程，而只是依葫蘆畫瓢學個一招半式，在這兒討論， 說白了還是理論，坐而論道不如起而行，所以積極實踐，加深對敏捷內涵的深刻理解，尋找適合自己組織的最佳敏捷實踐方法才是良策。這樣子思想理順了，我們就 不會拘泥于Stand Up Meeting到底要不要的問題了。

　　保證代碼質量

　　如何獲得高代碼質量？打個比方，現在要打仗了，如何打個漂亮的勝仗。我想你肯定知道答案了。那就是你的隊伍必須各個是精兵，能力強，平時訓練有素，而且還有實戰經驗，這樣的一個兵強馬壯的精兵隊伍你拉出去，只要指揮好，士氣高，就能打漂亮的勝仗。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住……

　　總結

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