在敏捷中，shift的左概念意味着什么？

Question

在敏捷中，shift的左概念意味着什么？什么是敏捷和转移左概念？如何在软件开发生命周期中使用它

Answer 1

简单地说，术语“移位-左”意味着在开发周期的早期集成QA。另一种思考它的方法是:尽早测试，经常测试。左移-最终提倡质量保证而不是质量控制。

在传统的瀑布开发中，QA和测试直到开发完成后才开始，通常是在瀑布的底部。如果您查看看板或Scrum板(如Jira或Trello )，QA和测试就在右边，因此这可以称为shift-right。

通过敏捷和Scrum开发，我们的想法是在一个更迭代的循环中更快地发布产品/代码。

当您以传统的瀑布或右移方式开发软件时，可能会出现以下副作用：

• 制作软件和修复bug需要花费更多的时间和金钱。发现错误后开发或后部署总是花费更多的时间和金钱来修复。
• 该软件包含更多的bug，从而产生技术债务，因为您要等到开发完成后才开始测试。
• 任何延迟或瓶颈都归咎于QA团队，即使这些延迟是在开发链上进一步创建的。
• QA没有足够的时间在发布前进行足够的测试。
• 信息仓。信息是不共享的，或者团队成员只关心他们的拼图。

当你采取一种向左移动的方法时，你会在开发开始之前更多地强调过程和发现错误。它是关于积极主动而不是被动的。一些好处：

• QA与其他团队功能协作-- PM、UX、开发人员、DevOps等等。
• QA能够对需求和设计提出质疑。这使得团队能够在需求和设计中发现bug，在开发开始之前就可以修复这些缺陷，这样可以节省时间和金钱。需求缺陷是当需求中存在歧义时。
• 尽早回答问题可以让团队理解开发一个特性的“原因”以及需求的目的，这就清晰了。获得清晰性可以防止错误的发生。模糊的设计和需求是big存在的一个重要原因，因为devs和QA可能有不同的视角、问题和关注点。
• QA能够在开发开始之前开始测试计划和编写测试用例。
• QA可以创建测试自动化的计划和策略，甚至开始编写自动化测试用例。Devs还可以运行现有的测试自动化。
• 整个团队拥有质量，而不仅仅是QA。

在过去的4到5年里，我一直主张在我工作过的球队中选择左转。我经常发现，在使用Scrum方法时，shift-left发生的更多，也更容易被接受。如果你正在使用敏捷瀑布，一个更快的瀑布版本(几周而不是几个月/年)，那么左移就不那么被接受了，尽管左移仍然可以被利用。