当工作了一段时间后，我们每个人都会进入到一种状态，就是因循守旧，不愿意在接受新的事物和挑战。我们喜欢接受我们已经能够熟练完成的工作，我们认为我们的经验已经足够应付相应的任务。但是IT技术日新月异，如果我们不能够迎接挑战，主动承担困难和责任，我们很难再上升到一个新高度。

　　我们有评审和测试这些过程，并不是代表允许错误和不负责任，评审的目的不是用来帮你发现低级错误和不认真。由于我们每个人愿意花在评审上的时间是一定的，如果评审的输入物质量低，我们就去发现这些大毛病和低级错误;相反，如果评审输入物质量高，我们追求的就是深入的错误，这样出来的产出物自然是精雕细凿。

　　当一个软件项目团队，各个岗位和角色的人员已经到位和比例固定的时候，我们采用的软件生命周期模型一定考虑的是如何让每个成员都能够在每个阶段都能够较饱满的工作。成员的投入往往很难达到分阶段来投入，因此我们会更多考虑迭代模型和敏捷方法。项目里面的事情就那么多，始终都是需要做完的，不受到强制前置依赖的事情要尽量提前做;如果没有就要考虑把任务粒度细分，去创造任务能够提前并行开始的机会。我们并不是去破坏瀑布模型，每次迭代都是瀑布。

　　对于软件项目中，开发周期和测试周期要保持一种平衡，平衡的目标就是要保证尽可能少的返工和最短的交付时间。我们有时候对于进度压力造成的压力过多的压缩开发时间显然是不合理的，造成的后果就是往往再加上两倍的测试周期，最终的版本仍然迟迟不能交付客户使用。我们的时间都花在了过多的返工，开发和测试的沟通中。

　　编码人员如何检验和测试自己开发的功能模块是否已经完成?如果没有详细设计文档，我们的要求就是首先编码过程是否符合编码规范和界面规范，其次就是整个编码是否完全实现了需求文档中的各种业务流和业务规则，包括各种完整性和边界的校验。

　　4-5个开发人员可能配置一个系统分析员和一名测试人员，组建一个小型团队。

　　对于软件项目团队，我们必须要考虑团队的整个绩效，而整个绩效的核算正是通过我们团队整体的人力资源和其它成本的投入创造了多少价值。而对于返工量，编码生产率，缺陷密度等都必须要围绕这个整体绩效服务。简单讲，如果我们返工量少，过程做的很仔细和规范，当进度延误了2个月，在这种情况下我们是无法满足客户需求的。软件满足客户需求，创造了价值，就是绩效的衡量。

　　如果你不做项目计划，就始终无法知道你预测的准确度，也就无从谈得上跟踪和持续改进。