如果你把这本书当作《敏捷软件开发》这样的普适的软工书来读，希望从里面找到一些对日常项目有裨益的提议，就不会有什么收获。
因为这本书只教人如何采取保守主义，实用主义的策略，"挺过死亡之旅式的项目而没有损伤"。
这是个有趣的话题。
因为死亡之旅式的项目一般比较难看，所以很少书籍会从这里面去总结"最佳实践"。大家更愿意在正常项目的基础上展开论述，通过"最佳实践"指导大家避免跌入死亡之旅的尴尬田地。
可惜，死亡之旅式的项目依然充满我们周围，而每一个被挺过去的死亡之旅项目，都只作为经验存留于参加人员的记忆里。所以这本书会提醒你，总结正常项目的"最佳实践"让你更好的完成任务很重要，总结死亡之旅项目的"最佳实践"教你如何最大限度的挺过项目同样重要。
但是，人人的死法可能不同，一本求生指南救不了全世界，当你想起自己也该总结一下时，这本书50%的目的就达到了。
一、政治,政治,政治
政治，玩家，谈判。IT程序员，最不擅长的可能就是这些领域，但很多死亡之旅其实都是源于政治上，一场好的谈判可以扭转整个项目的态势，效果比N天N夜的加班顶用得多。所以，程序员也应该注意政治与谈判的基本技巧，有备而战。
书中美国式的政治与中国特色的当然很不同，但起了个头，大家就可以自己琢磨下去。
二、保守主义，实用主义放光芒
死亡之旅的项目，就是以挺过去的最高目标的，如果还带着平常项目里的技术狂热，英雄主义，就一定死得更惨。
团队组建：一定要使用即时可用的人选，不要想着可以在项目过程中对沙包进行转化。不合用的人员，首先是不能当可用兵员算入项目，如果被硬塞了，那就让他能做什么做什么，idle也好，去看复印机也好，不用费心机去不用培训，更不要安排高手去做陪练。
工具、技术、软件过程选用：
不试用任何新技术（除非合同里面要求），使用最舒适的开发环境，最简单的技术。
1.尽量不要选用团队里都没有经过培训的东西
2.尽量不要使用c/c++/smalltalk/LISP/人工智能
3.尽量呆在windows里，不要使用Unix等系统
4.尽量使用所见即所得的开发环境
5、不用非商品化的开源工具
三，需求管理
作者与XP, RUP里一样的强调，区分需求优先级，通过谈判延后或取消优先级低的需求。
而单独的OOAD方法论里，没有需求优先级和需求变更记录这些重要方面。
四，其他
太多，都在书里划了线，不记了。
看软工类的书，最重要还是自己的思考，否则很快看完，然后很快忘掉，特别是国外的情况和我们并不相同时。
