该帖子同步发自：(yanglinux的博客  访问该博客)

     以下是我在工作中总结并常使用到的方法，个人觉得挺实用。

      1．分解任务到最小单元

最小里程碑非常好用，我在实际工作中可以说是屡试不爽。将大的任务拆分为若干小任务有助于更准确地进行估算，发掘出没有考虑到的其他方面的工作活动，同时可以进行更加准确和精细的状态跟踪。选取最小里程碑的尺寸时，要能满足准确估算的要求。我认为比较合适的尺寸是将任务细分至5到15个工时，或者1到3天。忽略任务通常将导致进度的偏差。将大型问题分解为较小的部分，可以揭示更多必须完成的工作细节，从而提高准确估算的能力。

       2．为任务设计行动检查列表即checklist。好处是毋庸置疑的，帮助每一个小组成员识别和评估已解决和有待解决的相关工作。

       3．做好进行测试（或者质量控制活动）后要返工的准备

我经常（过去甚至是每次）做这样的任务列表：假设每一个测试活动都能取得成功并顺利地进入下一阶段的开发工作。但是，几乎所有的质量控制工作，例如测试和评审（主要是同行评审），都会发现缺陷或者值得改进的地方。项目进度或者工作分解结构应该把进行每一轮质量控制活动后的返工工作作为一个单独的任务进行考虑。要根据过往的经验对返工时间进行估算。

       4．安排时间实施过程改进

团队的成员或许已经淹没在给他们分配的项目任务当中，但是假如想让团队的软件工程能力提升到更高层次，必须投入一些时间用于过程改进。必须从项目进度计划中预留一部分时间，因为软件项目本身就包括一些过程改进活动以帮助下一个阶段或下一个项目更加成功。不要让项目成员把100%的时间都投入到项目任务中（公司恨不得员工150%投入，其实员工在那里磨洋工），否则他们没有时间做出任何主动的改进。其中一些过程改进可能很快就会获得回报，而另外一些改进则只有到下一个项目时才能完全收回投资的成本。将过程改进工作看成维系开发组织工作效率的战略投资是很有必要的。我认为过程改进好比是高速公路的建设过程：它虽然在一定时间内降低了每一个人的速度，但是它一旦建设完成，道路就会变得更顺畅，交通流量也会变得更大。为项目（阶段性）总结和回顾留点时间吧。

我在毕业后的第一家企业和上海的某国有企业就是这么做的，效果还不错。不过在国内大多数小企业中，想达到这样就有点YY了。

另：(进度)计划之工时与工作天