利用敏捷改进质量
在固定时间，固定成本，固定范围环境，时间和成本估计通常是错误的，并且提供的压力并使事情变得更快地加剧。当发生这种情况时，交付团队需要一个出口，质量通常是第一件事，因为在一个固定的限制的世界中，它是交付团队可以控制的一件事。
质量是当您的组织以不可持续的方式运作时被拉动的杠杆。
许多公司都假设敏捷方法可以帮助他们解决质量问题。他们认为，如果他们能够改善团队级的沟通，或者在多个交付团队之间获得更好的一致性，他们就会开始看到改进。
许多公司也很快意识到Scrum和Safe原始不足。没有数量的每日突出会议或大型房间规划将解决他们的质量问题，因此他们认为他们做错了什么 - 或者敏捷根本不起作用。
用敏捷为质量铺平道路
问题是，在规模上，在多团队、依赖的组织中，单个团队的性能几乎是不相关的——这就是为什么当敏捷方法被降级到团队级别的活动时，它几乎从来都不起作用。
直到我们利用较大，垂直切片的组织，并开始整合工作，球队正在做出向上的有意，我们开始看到质量的真正改善。
但这需要一系列条件。它需要三件事:
- 团队
- 积压
- 工作测试产品
基本上，您需要创建一个环境中有一个令人欣慰的积压的环境，这些积压流入一个由六到八个人组成的团队，这些人拥有他们所需的一切，他们需要提供工作测试的产品 - 这是一个实际工作的产品的增量对业务有价值。亚博vip9通道
敏捷对交付系统的影响
所以，我们需要的是跨职能团队、清晰的待办事项、良好的验收标准、尽可能小的工作分解，这样我们就可以整合开发团队和QA团队，并在Sprint的整个生命周期中创建反馈循环。
当你有开发人员、QA, PO上的所有合作验收标准和得到一个明确的“完成”的定义,你可以想象在一个世界的团队自行车通过构建测试用例,编写代码,验证和修复缺陷更快,更快的完成。
然后我们可以走进Sprint审查，以高度的信心，该产品将适合其预期目的，它符合验收标准，并且PO将签署它。
没有3件事，你不能有超清晰度的验收标准。
这意味着你无法得到“完成”的确切定义。
无法得到“完成”的定义意味着团队将不知道他们要去做什么，并针对什么进行测试，以便他们能够获得演示，并在每个Sprint结束时理解他们何时完成。
敏捷扩展以提高质量
影响组织快速发展(敏捷)能力的最重要的事情之一是，有能力做出更改，而不会破坏交付系统中的任何东西。为组织和团队快速行动创造安全的唯一方法是通过预先超意图计划和不同治理层之间的紧密分解将执行与战略联系起来。
大多数大型组织正在处理多层治理模型这看起来像是底部的交付层，顶部的投资组合层，中间的程序/产品层。
每一层都专注于自己的质量保证类型。交付层关注的是像工艺、单元测试、TDD等等。程序/产品层主要关注产品是否满足验收标准，它是否有bug或缺陷——诸如此类的事情。投资组合层关注的是这个产品会被市场接受吗?人们会使用它吗?人们会为此买单吗?
因此，在多层多队敏捷环境中，这个想法是史诗将在三到六个月的批次中通过投资组合队列。这些是业务实际上关心的事情 - 投资倡议有美元，预亚博vip9通道计会得到回报。
史诗被分解为程序/产品层的特性，这些特性有它们自己的接受标准。特性被分解为交付层的用户故事，它们有自己的“完成”定义。
围绕着创建紧密对齐的价值流的小批量的意图级别不仅使您的组织能够快速移动，而且还提高了系统和产品的质量。工作的向下分解和向上集成，以及治理层之间更紧密的反馈循环，创建了内部固有的质量交货制度本身。
但这一切都始于这三件事。毕竟，企业敏捷的关键是真正可靠、执行良好的团队级敏捷。再加上组织高层的增强执行力，就没有什么可以限制的了。
关于这个主题的更多信息
我们最近也就这个话题发表了一篇立场论文。它被称为:
在意见书中，我们从提高质量的角度讨论了采用敏捷需要什么。我们探索:
- 如何看待质量
- 不同类型的优质大公司关心
- 要提高质量必须具备的一系列条件
- 正确的条件如何影响质量
- 常见的反模式和故障模式
- 扩展敏捷以提高企业级别的质量
你有时间一定要去看看。