更少的也许是更多的
早期，我们注意到添加详细的信息到需求也许不总是对项目有益的。对其他类型的文档也是同样的。你的质量保证计划、软件开发计划或者需求管理计划都不是项目健康的良好量度。太详细不总是更好的：你应该调整你特定项目需要的文档详细级别。决定合适详细级别的方法是关注 风险和结果：如果你添加详细信息到某一产物可以减少风险或者改进特定结果的质量，那么这个投入是值得的；否则，在更有生产力的活动上花费时间是更好的。
使用瀑布型的方法 项目经理需要付出很多的注意以详细的计划和指定需求。而使用迭代开发的方法项目经理可以根据工作中的风险来权衡的将时间花费在细化需求、架构、设计和实现上。他们会问：“什么样类型的活动可以最有效的立即降低风险呢？” 也许原型化一个方案可以处理与项目客户买进相关的风险，或者也许他们需要实际的设计、实现和测试架构以完全的处理架构方面的风险。
使项目中的每一个成员都参与到质量保证中
对于项目经理来说移到迭代开发方法需要的其他思想的改变是开始将质量保证作为一个集体的职责考虑。我通常会惊讶的听到项目经理说“我需要测试小组对我的开发人员保持忠诚，”或者“如果分析人员没有写下单个的需求，他们将不会被实现。” 当然，你的确需要测试小组来建立高质量的应用，并且失败的文档化和跟踪需求将导致问题的出现。但是如果开发人员不把质量当作自己的责任，你也就会陷入到质量问题中。为了实现这一点，你需要从通过信任你的 团队和清晰的交流你们的预期开始。假如你不能信任这些人，那么也许这些人不应该属于你的团队。
理想的情况下，项目经理应该能够宣称“我的开发人员负责交付高质量的代码；为了帮助开发人员，我们有一个测试团队，测试团队有专业的能力并可以验证被交付的代码是否是高质量的，”并且“我们的开发人员负责实现满足最终用户需要的应用。为了帮助开发人员，我们有一个分析的团队在适当的详细级别上文档化需求，并且分析人员是开发人员和最终客户之间的桥梁。” 创建交能够协同工作的团队 — 也就是说使团队中的分析人员、开发人员和测试人员能够一起工作来实现高质量的结果 — 是成功的迭代开发的关键之一。
质量保证和方法专家的新思想
为项目选择适当的形式级别（更多的不总是更好的）。
关注在整个项目周期中维护质量，但是可以是灵活的。最好的到达高质量的做法不是仅仅通过疯狂的关注检查和测试实现的，而是通过在给定时间上对需求、架构、设计、实现、检查和测试的良好平衡实现的。
采用风险驱动的过程方法。你的过程应该允许项目经理对项目当前的风险情况采用战术性的活动。
文章来源于领测软件测试网 https://www.ltesting.net/
