的需求边界
软件不是十全十美的，需求的迭代是永无止境的。需求的迭代周期是不定的，与其在最终版本中包括所有的需求，不妨在这期间发布若干个小版本，明确每个小版本的需求边界。这好比长跑途中的若干个里程碑，每跨过一个里程碑就意味着向重点又前进了一步。
每个小版本都包含有限的功能需求，测试工程师可以针对这些功能需求同步展开测试工作，提早触发Bug，尽量争取测试时间。客户也可以从这些小版本中提前看到真实系统的雏形；随着版本的逐步升级，项目距离发布日期也越来越近，和需求的差距也越来越小。
工欲善其事，必先利其器。我们可以利用一些现成的工具来管理需求边界和跟踪Bug，比如JIRA。JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件，其提供了问题跟踪管理、问题跟进情况的分析报告、项目类别管理、组件/模块负责人、项目email地址等功能。许多著名的开源项目都采用了JIRA。
通过JIRA，可以整合客户、项目经理、开发人员、测试人员，使各种角色各司其职，团队内部信息能够很快得到交流和反馈，潜在的问题提前暴露，促进项目的可控。
JIRA以工作流的思想融合了项目管理、任务管理和缺陷管理等思维，允许设定项目的模块和版本，并为每个需求设置预期日期，将任务的处理指定到人。 JIRA允许为每个项目设置优先级，比如Blocker、Critical、Major、Minor、Trivial，标识每个任务的重要程度。如果任务定义了优先级，那么在每个人的桌面上，任务会自动排列。这点对于多任务的项目尤其重要。
预见到需求迭代的被动性后，Diapers项目团队在Diapers项目上全面启动了JIRA进行项目管理，将需求分解细化后进入JIRA，排定任务的优先级并指定到人，确定每次小版本发布的需求编号，不定期的发布小版本。结合SVN等版本控制工具，Diapers项目团队能够将功能需求迭代的粒度控制到最小，项目逐步推进，客户对项目的进度有充分的了解，项目经理也能够准确把握项目的进度，团队中充满了乐观的情绪。
5、安抚团队成员的情绪
项目经理应该把握项目的进展情况以及客户的真实需求，也要知悉客户的需求底线，更要在必要的时候安抚团队成员的情绪。
工程师对于冗长的需求说明书有天生的恐惧感，开发周期拉得太长，似乎需求迭代无穷无尽。如果需求的迭代周期不在可控范围之内，项目的发布边界模糊不清，项目发布的日期自然也遥遥无期。由此带来的结果是团队每天紧赶慢赶的跟踪需求迭代，消化处理新的需求，工作气氛也是高度紧张。每一次需求迭代，都会进一步增加这种紧张情绪。
当原始需求第一次被抽象出来的时候，团队的第一要务是快速构建原型系统作为和客户沟通的主要媒介和依据，项目经理应该引导团队把握这一点。
之后的每一次需求迭代，项目经理要将需求分解细化，控制需求的粒度，并且确定优先级，消除团队成员的焦急情绪，按照先后顺序逐步的处理每一个粒度的需求，以发布每阶段的小版本为阶段性的目标。在这个过程中，需求细化到最小粒度，还需要注意到每个需求之间的关联关系，关联的需求要优先集中处理，是降低每个小版本之间的耦合度。
Diapers项目自从将需求细化成一个个任务并进入JIRA控制之后，软件工程师每天的只需要按照顺序处理JIRA上面的任务，并及时将代码以最小粒度的形式通过SVN工具提交；测试人员根据发布边界所指定的版本号从SVN下载最新代码测试，确认并关闭相应的任务；项目经理引导团队成员遵循规范的需求迭代程序，有条不紊的处理需求，轻松应对需求迭代。