《死亡之旅》 第2版

   如果你把这本书当作《敏捷软件开发》这样的普适的软工书来读，希望从里面找到一些对日常项目有裨益的提议，就不会有什么收获。
   因为这本书只教人如何采取保守主义，实用主义的策略，"挺过死亡之旅式的项目而没有损伤"。

   这是个有趣的话题。

   因为死亡之旅式的项目一般比较难看，所以很少书籍会从这里面去总结"最佳实践"。大家更愿意在正常项目的基础上展开论述，通过"最佳实践"指导大家避免跌入死亡之旅的尴尬田地。
   可惜，死亡之旅式的项目依然充满我们周围，而每一个被挺过去的死亡之旅项目，都只作为经验存留于参加人员的记忆里。所以这本书会提醒你，总结正常项目的"最佳实践"让你更好的完成任务很重要，总结死亡之旅项目的"最佳实践"教你如何最大限度的挺过项目同样重要。
   但是，人人的死法可能不同，一本求生指南救不了全世界，当你想起自己也该总结一下时，这本书50%的目的就达到了。

   一、政治,政治,政治
   政治，玩家，谈判。IT程序员，最不擅长的可能就是这些领域，但很多死亡之旅其实都是源于政治上，一场好的谈判可以扭转整个项目的态势，效果比N天N夜的加班顶用得多。所以，程序员也应该注意政治与谈判的基本技巧，有备而战。
    书中美国式的政治与中国特色的当然很不同，但起了个头，大家就可以自己琢磨下去。

   二、保守主义，实用主义放光芒
   死亡之旅的项目，就是以挺过去的最高目标的，如果还带着平常项目里的技术狂热，英雄主义，就一定死得更惨。
   团队组建：一定要使用即时可用的人选，不要想着可以在项目过程中对沙包进行转化。不合用的人员，首先是不能当可用兵员算入项目，如果被硬塞了，那就让他能做什么做什么，idle也好，去看复印机也好，不用费心机去不用培训，更不要安排高手去做陪练。
   工具、技术、软件过程选用：
   不试用任何新技术（除非合同里面要求），使用最舒适的开发环境，最简单的技术。
   1.尽量不要选用团队里都没有经过培训的东西
   2.尽量不要使用c/c++/smalltalk/LISP/人工智能
      3.尽量呆在windows里，不要使用Unix等系统
   4.尽量使用所见即所得的开发环境

   三，需求管理
   作者与XP, RUP里一样的强调，区分需求优先级，通过谈判延后或取消优先级低的需求。
   而单独的OOAD方法论里，没有需求优先级和需求变更记录这些重要方面。

   四，其他
   太多，都在书里划了线，不记了。

   看软工类的书，最重要还是自己的思考，否则很快看完，然后很快忘掉，特别是国外的情况和我们并不相同时。