以下是我在工作中总结并常使用到的方法，个人觉得挺实用。
1．分解任务到最小单元
最小里程碑非常好用，我在实际工作中可以说是屡试不爽。将大的任务拆分为若干小任务有助于更准确地进行估算，发掘出没有考虑到的其他方面的工作活动，同时可以进行更加准确和精细的状态跟踪。选取最小里程碑的尺寸时，要能满足准确估算的要求。我认为比较合适的尺寸是将任务细分至5到15个工时，或者1到3天。忽略任务通常将导致进度的偏差。将大型问题分解为较小的部分，可以揭示更多必须完成的工作细节，从而提高准确估算的能力。
2．为任务设计行动检查列表即checklist。好处是毋庸置疑的，帮助每一个小组成员识别和评估已解决和有待解决的相关工作。
3．做好进行测试（或者质量控制活动）后要返工的准备
我经常（过去甚至是每次）做这样的任务列表：假设每一个测试活动都能取得成功并顺利地进入下一阶段的开发工作。但是，几乎所有的质量控制工作，例如测试和评审（主要是同行评审），都会发现缺陷或者值得改进的地方。项目进度或者工作分解结构应该把进行每一轮质量控制活动后的返工工作作为一个单独的任务进行考虑。要根据过往的经验对返工时间进行估算。
4．安排时间实施过程改进
团队的成员或许已经淹没在给他们分配的项目任务当中，但是假如想让团队的软件工程能力提升到更高层次，必须投入一些时间用于过程改进。必须从项目进度计划中预留一部分时间，因为软件项目本身就包括一些过程改进活动以帮助下一个阶段或下一个项目更加成功。不要让项目成员把100%的时间都投入到项目任务中（公司恨不得员工150%投入，其实员工在那里磨洋工），否则他们没有时间做出任何主动的改进。其中一些过程改进可能很快就会获得回报，而另外一些改进则只有到下一个项目时才能完全收回投资的成本。将过程改进工作看成维系开发组织工作效率的战略投资是很有必要的。我认为过程改进好比是高速公路的建设过程：它虽然在一定时间内降低了每一个人的速度，但是它一旦建设完成，道路就会变得更顺畅，交通流量也会变得更大。为项目（阶段性）总结和回顾留点时间吧。
我在毕业后的第一家企业和上海的某国有企业就是这么做的，效果还不错。不过在国内大多数小企业中，想达到这样就有点YY了。
另：(进度)计划之工时与工作天
我08年做某个项目，与分析人员、开发人员一起精心估算严格到工时，得出的开发工作量是800工时一个人人，公司安排两个技术员，我得出的周期是800/8(每天工作时间8小时)/5（每周5天）/2人=10周，因为项目不是很紧，如果适当加一点班的话，可以应对一些没考虑的事情或者是某些风险，这样计划是两个半月。
实际上做了四个多月！并且是在经常加班的情况下完成的！事后项目组成员一起分析，发现我们的评估没有问题，我们也没有遇到意想不到的问题，用户也挺配合，就是一个普通常规的项目而已。问题出在哪里？问题出在，我们每天8小时这个工作系数错了，完全有问题！
试问我们在不加班的情况下，哪个人每天有效的工作时间有8小时？太假了。具体细节就不提了，我曾经就这个问题问过很多同事，他们有的说4个小时，有的说6个小时，总之没有谁说7个小时以上的。每天有效工作5个小时就不错了！那么我经历过的那个项目就该这么计算了：800/5(每天工作时间8小时)/5（每周5天）/2人=16周！四个月，基本吻合。
按照小时、而不是按照日历天来安排进度，基于工作量而不是日历时间进行工作评估。在不加班的情况下，每天的有效工作时间是5到6小时，而不是8小时——老板看到我的这种说法会不高兴了。
|