項目百態(深入理解軟體項目行為模式)
Bear在這裡買的
amazon的參考
-----------------------------------------------------------
作者：(美)德馬科|譯者:金明
出版社：人民郵電
ISBN：9787115244888
出版日期：2011/03/01
頁數：208
人民幣：RMB 39 元
-----------------------------------------------------------
Copy from http://book.douban.com/annotation/13942043/
模式1 玩的就是心跳
組織相信一直處於忙碌狀態才是正常的，事情沒有優先順序，只要是緊急的事件，就會去做，沒有一種任務管理的機制。這實際會降低開發效率。
模式2 快，趕上
行動力強，迭代開發，快速出原型。
模式3 死魚
即使所有人都知道項目不可以完成，也沒人說出來。在沒償試之前，你就說不能完成，會被人認為你沒信心，害怕挑戰，不努力工作等。
模式4 歡樂的鼓掌會議
完全是一種形式的，領導在講話，而且拒絕在會議上提出的問題。
模式5 保姆型專案經理
保姆型專案經理類似于英式保姆，負責保護專案成員，為專案成員的成長等提供幫助。對專案成員的能力瞭若指掌，在分派任務、制訂計畫等時會尋求最佳的契合點。
模式6 牽涉性疼痛
發現不了根本問題，往往只注意到表面表現，解決了這些問題，也無法根除根本問題。
模式7 明日複明日
緊迫感是實際行動的重要催化劑。如果目標訂的過於粗，時間過於長，往往在項目的前期，成員無法感到緊迫，這個時候往往工作效率是比較低的。
模式8 眼神交流
讓成員在一起工作，讓他們有眼神交流，可以更準確、清晰的傳達資訊，增加彼此的瞭解，能獲得最佳的整合效果。
模式9 情緒戒指管理
經理不是基於擺在專案面前的風險、決策和問題為彙報專案狀態，而是基於團隊的活動、付出和熱情。
模式10 忠實信徒
個體把某種思想派系作為真理來膜拜，與聖典稍有偏差即被認為是褻瀆神靈。
專案上的忠實信徒會讓工作止步不前，他們不去專注於內容，反而為方法爭執不休。
模式11 出租靈魂
從業者願意放棄長期練就的技能或者技術。
當某個情景下，用另一種技術能更好的實現當前任務時，那就採用這種技術，即使讓你放棄長期堅持甚至精通的技術並不容易，你要能忍受暫時的不適。
模式12 系統開發旅鼠週期
雖然組織流程很明顯地需要定制，但專案團隊依然盲從於未定制的標準。
模式13 清空“板凳”
組織變得如此精簡，以致於失去任何一個關鍵人物，都會演變成一場災難。
所以，要預留一些板凳人員，他們技能較全面，在任一個關鍵人物離開時，他們都能頂上去，以防止項目的中斷。
模式14 面對面
分散式團隊通過各地之間大量的面對面交流機會，以建立使遠距離團隊合作成為可能的熟悉感和可靠感。(視頻會議也有一定效果)
讓分散式團隊成員有面對面的機會，面對面可以增加他們的熟悉度與信任感，在後續一起合作時會更高效。如果缺乏面對面的交流，其中一個團隊往往會以高傲的態度對待其他地點的團隊。
模式15 我給了你鑿子，可你為什麼不是米開朗基羅
經理購買工作、潛意識裏希望它們可以賜予團隊技能。
“工具的成本不僅僅是工具的價格”。擁有恰當的技能去使用工具，才是最關鍵的。
模式16 主面板
強弱團隊都使用主面板，但用的目的及方法不一樣，面板表達的意義也是不同的。
團隊前進動力並非緣于對成功一腔熱情，而是對批評心有餘悸。團隊成員從他們的領導那裏秉承了這一特點。
模式17 無休止的集體會議
允許無休止的爭辯，最終肯定無法達到任何一項決定。
一定要有決策機制，不能允許無休止的爭辯。要讓成員認識到，最終，一旦做出決定，大家都要無條件接受。
模式18 幼犬和老狗
年輕人更有活力，可以帶動組織裏年齡比較大的員工，讓他們也充滿活力，老年人這時候往往不敢粗心大意，應付工作等。
模式19 影評人
影評人是團隊成員或者公司內部的旁觀者，他們認為自己給專案帶來的價值在於指出問題所在或者將會出現問題的地方，卻不把解決問題視為自己的職責。
影評人的特徵：即使自己所處的專案失敗了，他們也能成功。(認為自己指出了專案中的缺點，從而獲得了個人成功)
影評人認為自己的成功與專案的成功是涇渭分明的，而且經常快到專案結束時才參與進來。
之所以存在“影評人”，原因是有些組織的管理文化允許甚至是讚揚影評人，鼓勵影評人的出現。
模式20 單一問責
項目的每件任務都清晰地映射到僅僅承擔單一職責的個體身上。每個人都十分清楚自己承擔的職責，以及自己同事承擔的職責。
插曲 項目秘密
聽上去無關痛癢的詞句背後，是並不友善的深層含義。
比如“進度表有些激進”往往意味著“我們有麻煩了”，“這是一次學習經歷”意味著“我們真的搞砸了”等。
模式21 蘇式風格
交付的產品包含了客戶要求的功能，但客戶並不喜歡。
原因是缺乏與客戶的溝通，產品出來之後，往往與客戶認為的不同。
模式22 自然權力
能力吸引權力。
即如果自己在某方面或某領域具有相應的很強的能力，則應該有制定相應決策的能力，而並不是僅僅有領導來決策所有。
模式23 萬籟俱寂的辦公室
辦公室太安靜，凸顯出團隊已經失去了活力源泉。
模式24 白線
通過聲明需要修改的系統/業務領域與直接交互的外部世界之間的每個介面來定義專案範圍。一旦該工作完成，系統範圍就將不再有任何的歧義，你已經借助於介面繪出了白線。
模式25 沉默即同意
利害相干人無法區分屈服的沉默和同意。
模式26 稻草人
快速完成原型開發，以獲得早期的回饋和認識。
模式27 偽造的緊急性
僅僅是為了遏制成本，專案的截止日期被強行安排得非常緊張。
信徒的緊急性會引發偽造風險。容易引導組織沒有抓住真正的商業機會去從事高價值的項目，而高價值的專案風險是值得去嘗試的。
模式28 時間清除了你的手牌
經理在專案初期的決定對專案的影響最大。
所有優秀的專案經理都要知道何時需要亮出自己的牌，好讓時間無法贏過他們。(也經常因為前期專案沒有緊迫感，導致專案會出現延期、交付品質差等問題……)
模式29 Lewis與Clark
專案團隊在前期投入精力，探索新領域並發掘潛能。
前期進行專案預研，判斷可行性。
模式30 短鉛筆
連續不斷的削減成本，開始影響到組織完成任務的能力。
模式31 節奏
團隊通過定期交付，建立起工作的節奏。 (迭代)
模式32 加班預兆
如果在早期專案成員就已經開始加班，很有可能說明專案已經出現了問題，開發人員可能知道專案是不可能完成的了，而且恐懼文化充斥於組織內部，人們怕專案失敗會承受責備，所以，通過不斷的加班，來確保當專案失敗時自己不會受到責備。
模式33 撲克之夜
來自組織各個部門的雇員聚集在一起，參加與工作角色並無關聯的活動。可以讓人們之間增加聯繫，多了一份朋友關係，在工作中更加容易溝通、交流等，為別人做起事來也更積極。
模式34 錯誤的品質關卡
項目中的品質保證工作著眼於格式檢查，而這些工作根本不能給真正的產品品質帶來任何改善。(只注意形式，不注重真正的內容)
模式35 測試之前先測試
讓測試貫穿於整個項目。
模式36 蘋果酒屋規則
專案團隊成員罔顧或者繞過那些由專案工作無關人士制定的規則。
成功的專案需要有一些規則和定義良好的流程。但是，規則制訂者眼中的世界和規則遵守者棲息的世界必須得存在耦合的地方。
模式37 說，然後寫下來
專案團隊在交談間得出了決定，然後立刻用書面形式記錄下來以供交流。
模式38 專案中貪多求全
貪多求全會放慢速度，導致淨收益降低。
給任務安排優先順序，把高價值的任務放前面，低價值的放後面。
模式39 巨神阿特拉斯
團隊領袖(幾乎)善長一切事情。
他 們也是精神領袖，帶領著項目成員完成一個個的項目，但領袖起到非常大的決定作用，而且自己完成很多細節工作。不過一旦這個領袖離開了團隊，就會出現很多問 題了，因為團隊成員已經完全依賴于那個領袖了，很難再為團隊找到這樣的領袖。不過對這個領袖本身而已，因為事無巨細，所以可能無法帶領更大的項目團隊。如 果要帶領更大的團隊，需要放權，讓更多的團隊成員來決策、執行。
模式40 所有人都穿著衣服是有原因的
資訊冗餘會導致注意力渙散。
模式41 同事預審
在招聘過程中，讓將來與應聘者共事的人也參與進來。如果大家都不喜歡應聘者時，那就毫無疑問pass掉。
模式42 浮潛與水肺潛水
不同形式的分析活動貫穿項目的整個生命週期。偵察時用浮潛，審查時用水肺潛水。
模式43 一切都是該死的介面
要強調介面，介面極易出現問題。防止出現任何一個工作組在任何一個介面上做出不恰當假設的可能性。
康威定律：產品反映了製造該產品的組織結構。
對於介面，這一點尤為正確：專案中複雜的人類介面容易導致複雜的產品介面。
模式44 藍色區域
藍色區域即是那些沒有明確要要做的事情，而又沒有被明確禁止的。
組織裏存在這樣一種人是幸運的，在完成自己本職的工作基礎上，會自覺去完成藍色區域中的任務，他們以項目利益最大化為指導原則。
模式45 消息美化
壞消息在組織裏沒有被準確地向上傳達。
因為人們總是討厭那些傳遞壞消息的人，所以人們源於恐懼，在壞消息傳遞的過程中，會讓消息看起來沒那麼壞。所以在傳遞過程中，壞消息慢慢的就變成了普通消息，甚至是好消息。
模式46 慢慢地道出事實
公司文化迫使人們把令人不安的消息埋在心底。
因為如果是你發現了雜亂不堪的現象，領導可能就會讓你去清理，所以就會導致很多人發現問題之後保持沉默。
模式47 殘局遊戲
迭代開發
模式48 音樂製作人
根據員工興趣，讓他們組織起來，也為他們提供展現的平臺。
模式49 記者
記者是指那些把準確報告這個目標與讓專案成功這個目標完全分開的專案經理。
記者類似于組織裏面的“影評人”，把自己的成功與專案成功分開。
模式50 空椅子
添加一把椅子，為專門負責協調所有子專案的人準備的。
模式51 我的堂兄文尼
爭論的關鍵在於說服別人。
模式52 特性湯
產品誇耀自己繁多的零碎特性，其中很多對於解決客戶真正的業務需求幾乎毫無幫助。
要避免不斷往產品中添加無關緊要的特性。
模式53 資料品質
資料本身有錯誤，卻去尋找更好的軟體來處理資料。而不是從根本上來解決資料錯誤的問題。
模式54 本
一些人對工作的熱愛大於對薪水的熱愛。
要留住這些人，不要因為他們熱愛工作，就把一些離職人員的工作都交給他們，當他們工作壓力太大時，要麼對工作的興趣消失，要麼會離職走人。
模式55 禮數小姐
要對事不對人，不要拒絕批評。
模式56 全神貫注
儘量專注於一個專案，如果同時處理多個專案時，在項目之間切換是會有一定的浪費的。
模式57 “棒球不相信眼淚！”
組織文化不鼓勵人們表露情緒，進而使得衝突只能暗中進行。
應該讓員工表露自己的情緒，激情有時會掀起怒火，但撲滅這怒火是達成宏偉目標必須償付的代價之一。
模式58 鐵窗喋血
把所有的未能達成、和諧的情景都歸咎於溝通不足。溝通成了替罪羊。 衝突其實是自然的，要把注意力放在有效解決衝突的技巧上。
模式59 按期交付，每回都不例外
不能完全以交付上期為標準，這樣容易導致為了趕時間交付，即使品質還不達標的時候。版本後期容易出問題。
模式60 食物++
項目團隊成員定期在一起享用他們的食物，而且如果可能，整個團隊會在一起策劃和準備這些食物。
實際上是通過成功完成“做飯、吃飯”這樣的日常小項目，來增加團隊的凝聚力，提高活力等。
模式61 沒人在意的交付物
沒有人在意的交付物，不要去開發。
模式62 隱藏的美
“美到極致不是增無可增，而是減無可減。”
所有設計，都存在美學元素。要懂得欣賞別人工作成果中的美。
模式63 我不知道
組織營造出能講真話的氛圍，即使講真話意味著無法立即給予答復。
如果說出“我不知道”，會提出當前存在的問題，可能別人有思路或很容易解決。
模式64 烏比岡湖兒童
經理給出的績效排名不能有效地區分出執行力的強弱。
那些能力很強的，沒有得到相應的績效，而那些能力弱的，因為慢慢分給他們更少的工作，當工作少到一定程度之後，他們可能也能完成自己的工作，所以，他們的績效可能也不差。
模式65 互相教學
項目的利害相干人明白每個人都能從其他人那裏學到很多東西。
每個人都能從其他人那裏學到很多東西。消費者和開發者要各自向對方學習需求，必須深刻理解消費者的需求才能產生正確的產品和服務。
模式66 意氣相投
遊 擊隊，他們非常快速的完成所有事情。他們允許開發流程的簡化，讓你覺得軟體發展流程中的很多部分其實沒必要那麼正式。他們可以有高的驚人的生產率，也可以 驚人地富於破壞性，這取決於如何引領和指導他們。這樣的團隊是逐漸形成的，通常圍繞著一兩位引人矚目的領袖人物形成的。
模式67 十字槽螺絲帽
顯而易見的想法可能不會很快被接受。
模式68 可預測的創新
團隊在自身對創新的需求和老闆對可預測性的需求之間做出平衡。
模式69 瑪莉蓮•明斯特
在有些組織中，開發人員就是君王，而在有些組織中，他們只是無名小卒。
即同樣的人，因為所處的環境不同，待遇什麼也是不同的。
插曲 剪輯掉的底片
模式70 布朗運動
在專案願景尚不明朗的情況下，團隊成員就被添加到專案裏面。
在前期都加進來，為了讓員工都利用起來，往往會使決策很倉促，項目就會更亂。
(在《最後期限》中有對這塊的詳細論述)
模式71 大聲地、清楚地
要清晰的表達專案的目標。
擁有正確的目標至關重要。讓每個人都始終意識到自己的目標會給專案以及自己開發的產品產生巨大的影響。
模式72 安全閥
為了化解工作中的緊張氣氛，團隊發明了紓解壓力的活動，並深化為團隊生活的一部分。
做為經理，如果發現團隊在安全閥活動上面花了一點時間，不要反對，也不要鼓勵，因為這是團隊自己的娛樂時間，他們清楚怎麼利用這段時間。
模式73 巴別塔
開發出團隊成員和利害相干人都能理解的通用語音。
模式74 驚喜
死死抓住獎勵和資金模式的組織從來得不到獎勵。
模式75 冰箱門
團隊成員定期把各自的工作成果展現給團隊所有的人。
模式76 明天會是晴空萬里
經理相信未來的平均進度會超過過去的平均進度。
因為之前遇到過很多突發事件，導致的進度比較慢，所以經理認為後續進度會趕上來。但往往沒有意識到，後面也會有很多突發事件，所以在制定計劃時，就要考慮好。
模式77 堆積
利害相干人，不斷的往項目中添加特性。 (類似于特性湯)
模式78 變更時節
迭代！即如果有需求變更，也要放到下個迭代中，但前提是迭代週期不要太長。
模式79 造紙廠
組織通過迄今產出文檔的重量和數量來衡量進度。
模式80 離岸荒唐事
領導們被低廉的工人薪資所吸引，啟動了離岸開發計畫，使得在各個開發地點之間溝通的難度劇增。
模式81 作戰室
如果有可能，為項目組提供一個作戰室，裏面貼滿了進度、待辦任務之類的，讓團隊成員進去之後明確的感受到當前專案的進度等。
模式82 什麼味道
所有的員工都需要知道他們的組織聞起來如何，從而可以決定做出如何反應。
模式83 不從教訓中學習
團隊認識到自己的錯誤，卻一次一次地重蹈覆轍。
學而不思則罔，需要認真的總結過去的失敗，然後制定下一步改進的措施，以及執行。
模式84 不成熟的想法神聖不可侵犯
團隊願意鼓勵、呵護即使看起來不成熟的想法。
模式85 滲漏
人們有時候為了讓自己看起來進度正常，可能會在嘗試比較難以完成的任務之後，轉而去實現容易實現的任務，以此在前期可以表現正常。但這可以隱藏風險，到後期才會暴露出來。
模式86 範本僵屍
專案團隊使用範本---而不是對於產品交付所必需的、經過深思熟慮的iytk---來驅動自己的工作。
流程是死的，人是活的，按需進行調整，不能頑固的完全按照範本來，靈活的處理一切。
