流程-任务系统
　　这一步是非常关键的，其中重要的工作是功能评估。功能评估建议用Xmind软件来做，评估好了再录入到我们的任务系统。参考：

　　如果项目经理不是项目所需技术领域的专家，那么在评估的时候，叫上技术团队领头人一起。但是一个好的项目经理，即使是自己不熟悉的技术领域，自己也应该有一个比较准确的评估。
　　任务评估时间还应该包含开发人员自测的时间。
　　当任务都评估好了，可以录入到我们的任务系统了。录入任务系统之后，是做迭代计划。
　　在我们的任务系统中，开发计划是通过迭代来做的。建议每一周提一个迭代，多不超过2周一个迭代。开发人员只需要关心当前这一个迭代里面的所有任务，至于具体先完成哪个任务，如无特殊要求，都应该让开发人员自行安排或者项目经理给一些建议。
　　每一个迭代要求明确的开始和结束日期。一旦结束日期到，应该把迭代里面未完成的任务移到下一个迭代。也是说，迭代日期到，迭代的进度是。对于有些只完成了一部分的任务，在我们的任务系统中，要么你可以拆分任务把已完成的部分拆分出来，要么你也可以把整个任务移到下一个迭代。
　　开发人员完成功能开发之后，首先要经过全面的自测。一个聪明的开发人员应该在自测的时候解决绝大多数BUG。经过自测的产出物应该是具有很高质量的，特别是高质量的UI和UX。自测通过才能提交给测试团队，或者项目经理。做不到这一点的开发人员应该被淘汰。
　　自测完成之后，填写工时记录，将进度标记为，将任务状态标记为完成（不是关闭）。
　　流程-测试
　　如果没有测试团队，测试应该由项目经理负责。
　　测试中报的BUG要提交到任务系统。测试人员提交BUG的时候不需要评估时间，并且也不需要指派。项目经理把所有未指派的BUG列出来，然后进行时间评估，然后再指派给某个开发人员。
　　BUG也是属于迭代的。如果不是那么紧急的BUG，可以暂时不安排到迭代里面，可以等到后再去修复BUG。
　　流程-完成
　　测试团队测试通过，项目经理可以根据实际情况看是否需要再检查一遍。或者检查的力度到什么程度，这都由项目经理自行决定。检查通过，任务状态标记为关闭，任务完成。
　　问题 – 团队间等待
　　开发过程中，可能各个技术团队之间的衔接会出现等待。比如客户端开发的开发人员，在做到某一个功能的时候，结果UI设计或者API还没有准备好，那么只能等起。
　　这种衔接等待是无法避免的，我们只能尽可能降低等待的时间。我们是这样解决的：
　　在我们的任务系统中，我们会加一个任务标签，叫“紧急任务”。注意这里是标签，不是优先级也不是任务类型。一旦出现这种等待，等待的人给被等待的人建一个“紧急任务”。如果等待的人没有新建任务的权限，那么交给其团队负责人创建。我们也建议你把这类任务同时放到一个任务分组里面，并且加个快速查询。
　　等待的过程中，开发人员可以用假数据或者假UI来代替，等数据或UI准备好后再替换。
　　问题 – 需求变更
　　需求变更是任何开发团队都无法避免的问题。我们要做的是把需求变更对项目造成的影响尽可能降到低。
　　通常情况下，只有紧急的需求才会放到当前的迭代，否则变更的需求都应该放到以后的迭代。如果放在当前的迭代，那么需要把当前迭代中的部分任务移到下一个迭代。并且跟客户沟通好这个计划的改变。
　　需求变更时，一定要将需求更新到需求管理系统（原型和任务系统），不管变更的需求造成的工作量有多大。这一点是很多项目忽略的。举个例子，用户完成注册，本来系统送100金币，某天客户过来说改成送200金币，结果程序员花了几分钟时间将100改成200了事。过了几个月，新同事加入项目，看需求系统里还是写的100，去问项目经理，项目经理说什么时候改成200了。于是这个需求管理系统再没有人相信和使用了。所以这一点非常重要。
　　需求变更时，要按照本文开始的流程图一步一步走，因为是新的需求从流程入口进来了。
　　项目管理中经常还会遇到其他棘手的问题，扰乱项目计划，让项目管理失去了对进度和质量的控制。