在两种选择之间进行选择时，始终存在意见和可疑事实影响的风险。 选择任何方法论或工作方法，我们都会努力避免错误，并研究尽可能多的事实和细节，以做出正确的选择。
在敏捷软件开发中，这种选择也具有挑战性，尤其是在涉及Scrum和看板方面。
Scrum vs看板：两种方法，一种选择
在进行如此困难的选择之前，您可能会面临另一个与“
瀑布”与“敏捷”之间的选择有关的初步困境。 但是，您已经做出了正确的选择，现在您在敏捷开发领域面临两条独立的道路。
Scrum和看板是敏捷家族的两个分支（但是，许多人并不认为看板是一种独立的方法，并将其与其他方法分开了）。 两者都是灵活和迭代的。
有一项
调查于2018年对来自全球的101592名软件开发人员进行了
调查 。 他们中近86％的人在工作中使用敏捷。 看起来不错，对吧？
Scrum或看板：什么是最佳选择？
Scrum使人们能够解决复杂的适应性问题，同时高效地交付最高价值的产品。
Scrum框架轻巧易懂，但可能难以掌握。 它由短迭代或Sprint组成，通常持续2-3周。
团队创建了可能的迭代功能列表。 然后他们开始运行Sprint。 通常，在Sprint期间正在使用的功能不会更改。 无论如何，一开始就必须完成。
Scrum包含各种术语，概念和工件。 为了了解所有内容，请阅读和学习
Scrum词汇表或最终指南。
看板可以从创建它的地方（丰田公司）的角度进行概述。
日常的输送线生产汽车的零件。 一种特殊的机器设计用于丰田汽车的后视镜：左，右，后视镜和遮阳板的后视镜。 只需单击一个按钮，即可更改模式，从而获得新产品。
这里的关键时刻是他们可以随时更改优先级。 他们能够将机器切换到其他模式，仅此而已。
但是，如果您需要更多有关看板的理论，则可以将其视为在整个过程中管理工作的可视系统。 它可视化工作流程以及通过该过程的实际工作。
看板可帮助确定流程中的潜在瓶颈，并加以解决以提供具有成本效益的流程。
Scrum和看板之间的核心区别在于迭代长度：
- 您在Scrum中工作了2周。
- 在看板中，您甚至可以每天为开发人员提供任务。
看板更加灵活。 想象一下，昨天您向生产服务器发布了一项新功能，其中包含一些用于跟踪功能的KPI的事件。
借助分析，您的产品经理可以了解出了什么问题。 他决定对功能的逻辑进行一些更改。 他将任务放在看板中，并在专栏中提出。 程序员有空后，他将承担这项任务，并在测试后立即将其释放。 一切都会花费几天的时间。
对于Scrum，您将必须等待整个Sprint，即2-3周。
Scrum需要使用故事点数或小时数进行任务估计。 没有这个估计，您将无法形成Sprint。 而且，您应该确切知道是否要在2周内完成所有任务。
2周后，您将获得有关团队在Sprint期间成功完成的故事点或小时数的重要统计数据。 借助此信息，Scrum管理员可以预测团队在2周内的位置。
在看板中，人们也可以估算，但这是可选的。 没有团队速度。 您只考虑完成任务的平均时间，并将其计入“周期时间报告”中。
任务周期时间=在任务上花费的时间-任务开始的时间试想一下，Scrum的当前目标是完成Sprint，但是对于看板，您必须完成一项任务。
从理论到实践：我们的方式
限制w
在制品正在进行中。 限制专家可以同时处理的任务数量很重要。 是的，我们当中没有凯撒和拿破仑以令人难以置信的多任务处理技术而闻名。
当人们在一个时间单位内仅完成一项任务时，这是最佳选择。 开发人员从一项任务切换到另一项任务通常需要
15分钟 。
您需要时间来泡茶，浏览网络上的一些文章，阅读一项新任务的要求，记住您在哪里暂停并在代码中找到该位置。
请确保，从一个任务切换到另一个任务是从一条思想路线到另一条思想路线的离开，而且返回并非总是那么容易。
泳道
没有人可以避免失败，并且您的网站在工作时间内可能无法正常工作。 例如，您创建并分配任务以立即将其修复给您的DevOps工程师。
但是他正在做另一项任务，并计划明天午餐前完成它。 怎么办 绕着他旋转，轻拍肩膀并乞求改用阻滞剂不是一个好主意。 您只能做一次，但这是正确的行动方式吗？ 绝对不，这就是为什么我们使用泳道。
在此示例中，“ Blocker” Swimlane是解决方案，使开发人员立即停止执行其当前任务，将其暂停并开始进行阻塞操作。
我们还利用“ Someday” Swimlane涵盖了我们可能会在该区块下一天完成的所有任务。
Swimlane帮助搁置所有不必要的东西，使人们可以专注于重要任务。
子列
紧随其后的是“编码”列和“测试”列。 开发人员完成任务后，将其移至“测试”。 您可能认为测试人员已经开始执行此任务，但实际上，他正在执行另一项任务。 一旦开发人员将任务转移到测试中，他就破坏了质量保证的在制品限制。 这是一个真正的挑战！
实际上，开发人员可以自由地将此任务移至“测试”列，并将其保留在“编码”列中。 这也不是一件好事，因为尽管他已经完成了任务，但他的任务将保留在“进行中”列中。
但是，如果不应打破在制品限制，该如何承担下一个任务？ 子列确实可以提供帮助。 开发人员只需将完成的任务从“编码待办事项”子列移至“编码完成”即可。 测试人员会在需要时从“已完成编码”子列中执行一项新的测试任务。
最后的想法
总而言之，让我们将Scrum定义为一种灵活的开发方法，但是将看板命名为更加灵活。
Scrum在产品开发初期看起来更好，因为它有助于更轻松地管理截止日期。 此外，团队中有足够的沟通。 在开始之前，他们彻底讨论了Sprint Backlog。
他们与创作者讨论任务。 团队根据规划扑克系统估算任务。 实际上，Scrum有助于了解产品的核心。
但是，在产品发布后，您会收到用户的反馈，因此需要快速做出反应。 您开始衡量和优化产品指标，一切都会将您的开发周期分解为更小的单元，并且开始混乱地执行许多小任务。 现在正是时候召回看板，非常适合这种情况。
您是否同时应用了两种方法？ 在看板对Scrum对抗中，您最喜欢什么？