軟件

期限是每個專案經理都繞不過去的坎兒。1.

敏捷式軟體開發 (Agile Software Development)概述如同前文所述，可以把敏捷看做一種問題解決方式。下面我們就從敏捷問題解決方式的角度解讀敏捷式軟體開發 (Agile Software Development)。敏捷式軟體開發 (Agile Software Development)軟體開發是問題本身和問題解決能力不確定的一種典型情況。軟體項目起源於人的構想，隨著時間不斷變化。項目團隊對項目的認識隨時間不斷加深，成員能力不斷提升，工作方式和過程改變導致團隊開發能力不斷變化。

題目源自《拯救大兵雷恩》。話說每日立會作為Scrum實施的先鋒隊，戰鬥在Scrum的最前沿。然而它孤軍深入，面臨覆滅的危險。如何拯救？其實在上一篇部落格中已經隱約提到了拯救的辦法，估計各位看官並未注意。不過也不必擔心，且讓我慢慢道來。1.

要成為一個好的專案經理需要學會逆水行舟。雖然順水推舟有時也能到達目的地，但學會逆水行舟，你才能到達任何地方。“雖然很有道理，但我認為現實不允許，很多項目都有規定的期限。中途還有給客戶示範效果，往往實際項目中都是按最後上線日期來進行專案規劃管理的。”“寫得不錯，但是有些建議過於理想化了。畢竟說得很有道理，但實際中具體做起來又不是那麼一回事了。”這是兩位網友對《軟體專案經理新手上路》的評論。這話很有道理，也是在現實生活中碰釘子碰出來的。在項目中確實存在很多限制，我們應該順應限制，順水推舟，否則會很難

“專案經理張三經過開發人員李四的座位時，突然發現李四在看一本書《如何成為專案經理？》。張三就問李四，你還不是專案經理，看這本書幹嘛？李四回答道，如果等到你這個時候再看，就太晚了。”忘記在哪一本書上看到的了，印象深刻。1. 專案經理的成長路線 回到經典的專案管理問題。如果你是專案經理，現在項目組沒有能力在期限前完成工作，你是：1. 優先確保項目，犧牲人 ——> 指向B區2. 優先確保人，犧牲項目 ——> 指向C區3. 項目與人兩者兼顧     ——> 指向D區你的選擇是什麼呢？1

誰是你的敵人，這是個問題。是他們與你為敵，還是你與他們為敵？有句話說得好，心中無敵，則天下無敵。1.

老好人式的專案經理並不少見。他們人很好，希望讓每一方滿意。1. 小故事最近，張三有些煩惱。張三是位資深的開發人員和專案經理，同時他也是個典型的老好人。他勤勤懇懇，任勞任怨，開發能力優秀，對每個人都是那麼好。因為客戶突然提出了一些比較無理的要求，但是張三是老好人嘛，所以張三就帶領團隊加班加點，努力完成。可惜客戶的要求實在太緊，在上線後出現了一個比較嚴重的Bug。客戶對項目團隊的工作很不滿意，但是考慮到項目團隊認真的態度，沒有追究。2.

軟體專案經理，這是廣大開發人員嚮往的職位。隨便抓個開發人員問問他的職業規劃，他會告訴你“我的計劃是現在專心做開發學技術，3年到5年的時間後轉向管理。”在開發人員看來，專案經理的收入更高，加班更少。然而在絕大多數公司你都可以找到足夠多的技術培訓，卻沒有針對專案經理的培訓。看來要成為專案經理，一切都要靠自己摸索。有沒有這樣一本手冊，只要讀了它就能提高管理能力？我的偶像溫伯格提到過一本，並且推薦《門後的秘密》，然而這本書的內容對於新手專案經理而言過於高深。於是萌發了自己寫點東西的想法。這本小冊子由一系

“思考可以很複雜，但行動一定要簡單。”每日立會遠不像看起來那麼簡單，瞭解它背後的複雜內涵，有助於掌握和使用它。但如果過於在意它的複雜性，出左腳還是右腳就成為了一個問題。1.

如果你內向，同時覺得自己夠聰明，就去做軟體開發人員吧。這是我當時為什麼從事軟體行業的原因。而且，我發現不是我一個人這麼想，中國內向的聰明人實在是太多了。這些人都認為，相對於面對人而言，他們更善於面對電腦。他們最常做的就是，給我問題，讓我編程解決它。如果你是團隊的一名開發人員，你的團隊成員都是內向的聰明人，你會怎麼做？如果有一天你被提升為軟體專案經理，你的團隊成員都是內向的聰明人，你能怎麼辦？1. 做自己 1.1

改進是每個專案經理都會遇到的頭疼事。1. 小故事張三有點煩惱。張三興沖沖的到一個項目入職了，躊躇滿志，這次一定要幹點成績出來。因為入職前，領導找張三談過，項目目前存在不少問題，需要改進。在經過一段時間的調研後，張三拿出了一整套改進方案。張三將整套方案提交給領導，領導看了第一眼，說很好，我需要再研究研究。過了幾天，領導還沒研究完。張三去找領導，領導開始拖延，主意不錯，但是是否適合我們公司，還需要觀察和研究。最後，所謂改進不了了之，張三很失望。2. 常規想法很奇怪，這麼好的改進方式，領導居然會拖延，

領導要的是計劃，還是……？1.

技術衝突是技術出身的專案經理經常碰到的事情。一開始只是技術討論，討論著討論著就變成了技術衝突。1. 小故事張三最近的心情很糟，這起因於一次技術爭論。在解決一個技術問題的時候，張三和李四的設計不同。從張三的角度來看，李四的設計簡直糟糕透頂，但卻怎麼也沒有辦法說服李四。於是張三就小小的動用了專案經理的權力，強制使用了自己的方案。沒想到遭到李四的強烈抵制，到最後李四竟然提出了辭職。張三也因此受到了領導的批評，所以他很鬱悶。他怎麼也想不通，他為交付更好產品的努力竟然導致這麼個結果。2.

軟體以人為本，這是一個值得討論的話題嗎？1. 回顧“軟體工廠” 至今還記得在我國九十年代中期興起，兩千年左右火爆的

有朋友最近看了《軟體專案經理新手上路》，就問我，你在寫什麼啊？其實我也在思考這個問題，為什麼我從一開始就否定了軟體專案管理而要寫軟體專案經理呢？最近才逐漸瞭解自己的想法，多點兒人味兒。我想寫的是一個活生生的專案經理，而不是剝離人味兒的專案管理。請允許我在此引用一句名人名言。“#彼得聖吉第五項修鍊# 我深信，流行的管理體系的核心問題是致力於使一切趨於平庸。它迫使人們越來越辛苦的工作，以彌補一種缺失，即人們在一起共同工作處於最佳狀態時所特有的精神和集體智慧的缺失。”引自《第五項修鍊》，轉自@章顯洲-

這個題目挺讓我滿意的。1.

《軟體以人為本》由此開始進入實戰部分，先從Scrum的實踐開始吧。1.

小時候使用過剪報進行知識收藏管理，後來還想借鑒圖書館的卡片做知識管理，不過面對浩瀚無涯的知識，這些手段都顯得很有局限性，查詢、重構也非常麻煩。後來使用了電腦之後，才重新恢複了個人知識管理(PKM) 的興趣。這裡分享一下我使用個人知識管理軟體的經驗： winpim(友情強檔)：其實不算是一款個人知識管理軟體，它的主要功能是通訊錄的管理，後來也擴充到任務、日記、備忘錄、郵件的綜合管理。不過它是我購買最早的一款正版軟體，當作通訊錄用了沒多久我就將其改用作日常資料的收集整理，一直用到現在，winpim標

有朋友在問，《軟體專案經理新手上路》到底寫的是什嗎？翻來覆去，案例後面還是案例，再加上一些主觀的判斷（我自己認為是客觀，只描述結果，裡面可能有些主觀的詞彙）。有人形容，這一系列文章就像恐怖片，專案經理真不容易；有人說，不知道樓主要表達的是什麼意思；有很多人發現案例比較有意思，有些共鳴或反對；還有人給出了自己的案例；有人受困於類似的案例，希望找到答案。如果前面所有的文章和案例都只是個引子，大家會不會很抓狂？1. 案例總結這所有的文章和案例都從不同的側面關注專案經理這個人。1.1

原文首發於圖靈社區。http://www.ituring.com.cn/article/196很多軟體開發人員很困惑，自身的職業發展是怎樣的？靠譜的公司怎麼那麼少？很多軟體公司很困惑，軟體開發人員怎麼招聘，怎麼培養，怎麼用？為什麼靠譜的軟體開發人員那麼少？如果你有上述疑惑，在思考職業的軟體開發人員應該是什麼樣，這本書可以給個參考。1.