《死亡之旅》第2版

如果你把這本書當作《敏捷軟體開發》這樣的普適的軟工書來讀，希望從裡面找到一些對日常專案有裨益的提議，就不會有什麼收穫。

因為這本書只教人如何採取保守主義，實用主義的策略，"挺過死亡之旅式的專案而沒有損傷"。

這是個有趣的話題。

因為死亡之旅式的專案一般比較難看，所以很少書籍會從這裡面去總結"最佳實踐"。大家更願意在正常專案的基礎上展開論述，通過"最佳實踐"指導大家避免跌入死亡之旅的尷尬田地。

可惜，死亡之旅式的專案依然充滿我們周圍，而每乙個被挺過去的死亡之旅專案，都只作為經驗存留於參加人員的記憶裡。所以這本書會提醒你，總結正常專案的"最佳實踐"讓你更好的完成任務很重要，總結死亡之旅專案的"最佳實踐"教你如何最大限度的挺過專案同樣重要。

但是，人人的死法可能不同，一本求生指南救不了全世界，當你想起自己也該總結一下時，這本書50%的目的就達到了。

一、政治,政治,政治

政治，玩家，談判。it程式設計師，最不擅長的可能就是這些領域，但很多死亡之旅其實都是源於政治上，一場好的談判可以扭轉整個專案的態勢，效果比n天n夜的加班頂用得多。所以，程式設計師也應該注意政治與談判的基本技巧，有備而戰。

書中美國式的政治與中國特色的當然很不同，但起了個頭，大家就可以自己琢磨下去。

二、保守主義，實用主義放光芒

死亡之旅的專案，就是以挺過去的最高目標的，如果還帶著平常專案裡的技術狂熱，英雄主義，就一定死得更慘。

團隊組建：一定要使用即時可用的人選，不要想著可以在專案過程中對沙包進行轉化。不合用的人員，首先是不能當可用兵員算入專案，如果被硬塞了，那就讓他能做什麼做什麼，idle也好，去看影印機也好，不用費心機去不用培訓，更不要安排高手去做陪練。

工具、技術、軟體過程選用：

不試用任何新技術（除非合同裡面要求），使用最舒適的開發環境，最簡單的技術。

1.盡量不要選用團隊裡都沒有經過培訓的東西

2.盡量不要使用c/c++/smalltalk/lisp/人工智慧

3.盡量呆在windows裡，不要使用unix等系統

4.盡量使用所見即所得的開發環境

三，需求管理

作者與xp, rup裡一樣的強調，區分需求優先順序，通過談判延後或取消優先順序低的需求。

而單獨的ooad方**裡，沒有需求優先順序和需求變更記錄這些重要方面。

四，其他

太多，都在書裡劃了線，不記了。

看軟工類的書，最重要還是自己的思考，否則很快看完，然後很快忘掉，特別是國外的情況和我們並不相同時。

《死亡之旅》 第2版