小目标就是大目标细化后的结果。主要的目标是一个阶段或一段增量的末尾。要达到那一点，项目需要在整个进程中都设立细化的目标。小目标一到两天的工夫就可以达到，以小时为单位。它有这样的好处：可以改善状态报告；因为可以知道一个小目标是否没有完成所以能够实现细粒度控制；因为大约每天都可以完成一个小目标所以会更好地激励员工；还有可以降低执行进度超时的风险。为了避免项目中的各种问题，建议小目标的设定从项目一开始时就着手实施。最好的办法是用电子表格记录和跟踪小目标的执行进度。由工具（如 MicroSoft? Project）生成的项目计划最好只用于更上层的任务。当然，只当前的阶段才划分多个小目标任务。后面的阶段在需要时再进行划分。尽管开发人员认为设定小目标是个麻烦，但是这个问题补偿了小组领导和单个开发人员定义他们自己的目标并分散项目管理和跟踪项目的工作量的能力。通常一个由技术指导定义的任务，一旦由开发人员将其细化为多个小的目标，则任务就会变得更大。有时技术指导会提供备选的、更快、更易维护的方案，在其他一些场合他也同意任务的分解并分配给任务更多的时间。尽早地实施小目标计划的工作可以避免潜在的灾难性结果的发生。
8. 以小时为单位跟踪所有的项目时间
不仅要跟踪以小时付薪的顾问和立约人所花的时间，每个项目成员所花费的时间同样很重要。这样做的好处是可以对照个人所用的时间与项目计划的时间。如果个人已经转向其他任务就要采取一些步骤。同样，实际的时间也可以对照估算的时间，估算的时间可以依次地为项目的下一个阶段或下一个项目的时间估算方法提供反馈。对小目标的全部时间的估算可以限制时限的超出，因而这些时限是可以修正的。应用小目标技术要求来自各方面的包括技术指导、小组领导和每个开发人员的时间和努力。至少每个星期，每个开发人员要以电子表格的方式提交他的工作状况，让项目主管可以在每个更上层的任务中更新完成进度的百分比。这样将使项目管理的工作量分散到其他的小组成员身上。跟踪项目时间会耗费更多的时间，但这能实现非常有效的项目管理。
9. 应对不断出现的变化
对于大多数项目，每个月项目的需求变化不会大于 5%。这些变化的产生有多方面的原因，例如没能在正确的时间提出恰当的问题、正在处理的问题发生了变化、用户改变了他们的主意或观念、商业环境发生了变化或者是市场发生了变化。功能特性蠕变都会轻易使得成本和执行进度超出预先的估计。在项目的初期阶段，项目需求中有许多缠杂不清的地方。当执行到某个阶段（通常在第二阶段的末尾）时，项目需求就必需确定下来并锁定其核心内容。一个变化的管理过程由一个所谓的“变化委员会（change board）”来执行，变化委员会由项目所涉及的每个领域的代表组成，例如业务、市场、开发、质量保证、用户文档、客户支持和项目管理等。变化委员会负责将所要做的改变交由适当的人去完成、对改变作出说明并测定来自各方的估算值的大小。在获得足够的信息后，变化委员会就可以决定接受还是拒绝这项变化。一旦接受一个变化，它将被加入到计划当中并且执行进度也要做出改变。伴随有变化的项目要比原先没有变化的项目提交得晚，但是它仍然是成功的，因为它仍然满足修正后的执行进度和股东的期望。一个项目如果在启用变化委员会之后有超过 5% 的改变，则表明项目制定得非常糟糕或者已失去了控制，最终很可能会失败。
10. 项目领导
公司的管理者委任一个执行者承担软件项目成果的责任是至关重要的。这个关键的执行者不仅要总览全局，还要获得和控制项目所需的资源来帮助和支持这个小组。同样重要的是，执行者不需要去干涉、管理小组中的一些琐碎的事。执行者要相信小组是可以委以重任的。
结束语
本文列出了帮助提高软件开发项目成功率的十点因素。遵从这些指导原则，您可以在预算和预定时间范围内更好地完成项目、保持一个高效率的小组并尽量不改变功能特性。您可以参考 Mike 的另一篇关于最佳实践的文章软件开发项目的最佳实践。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
