最佳实践:不要盲目的将最佳实践作为必须遵守的戒律，但可以作为生成自己最佳方法的起点。
1.正式的风险管理
2.对接口达成一致的意见。包括硬件接口，软件接口已经你的系统同外部系统之间的接
3.同行评审。包括检查，走查，评审等等。虽然这些概念众所周知，但团队由于这些活动将减慢项目的速度，因此它们在死亡之旅项目中常常被忽略。虽然大多数人在理智上都同意同行评审非常有用，但在死亡之旅项目的那种沉重压力下，每个人都会考虑尽快的完成自己的工作，而压根想不起需要其它团队成员来评审自己的工作产品。
4.基于度量的进度和管理。这就是我们应该依据以往项目的度量结果来安排进度和进行估算。但当我们没有出现死亡之旅项目的时候，很少有人去注意和记录这些有用的度量历史数据。没有这些历史数据的记录，我们就很难在新的项目中做出准确和客观的估算。
5.多设置短周期的检查点和里程碑。与其每隔两三个月设置一个里程碑，还不如按星期或天来设置短期的里程碑或检查点。迭代开发或Daily Build可以帮助我们达到此目的。
6.项目计划和项目的实际进度在整个项目范围内保持透明。
7.针对质量目标进行错误跟踪。这种观点重点在于尽早的在开发过程中发现，跟踪和记录问题。不仅能够预测最终系统的缺陷水平，还可以用最小的花费来解决问题，而不用一直等到项目的系统测试阶段。
8.配置管理。不管是被称为版本控制或源代码管理，配置管理在大多数压力巨大的项目中都是必须的。
9.以人为本。必须要对项目和团队成员给予足够的重视。
最差实践:相对最佳实践而言，往往惨痛的教训更让我们记忆犹新。避免灾难往往比追求完美更加重要
1.如果采用相似项目的统计结果来作为比较标准，不要期望进度的压缩程度大于10%。
2.不要为了压缩进度而接受新技术。(新技术引入的学习成本和使用风险往往大于其对生产率提高所做的贡献)
3.不要强迫大家在项目中使用那些与具体用户相关的解决方案。
4.不要鼓吹万能方法。(在管理层建议采用某中新工具或方法来拯救项目时必须注意)
5.项目的关键路径上存在着依赖于外部因素决定的活动
6.参与项目评审的一大堆人在评审开始前都不做任何相关的准备(因此也不要期望有很好的评审效果)
7.如果软件功能的缩减量小于10%，就不要期望能从超过10%的进度滞后中恢复过来。