为什么？有些任务不能等到下周吗？在周末之前完成所有工作是否很重要？不，不是那么重要。所有这些都是由于“执行任务很糟糕”这一事实所致。
Scrum不再是一种敏捷开发方法
我得出的结论是，对Scrum的工作过程过于重视。或者至少，人们对此过于关注，其表达方式如下：
- 可以在sprint的最后一天完成用户故事。但是下周一完成工作已经是“任务转移”了。
- - ( , ), , , , , .
- , , , . , , , ( , ).
结果，Scrum不再帮助我们实现目标。这种项目管理方法现在限制了我们。
通过以上所有内容，我可以注意到我的团队成员开始对所发生的事情感到不满意。这影响了我们创建的质量。程序员更关心的是按时完成任务，而不是达到期望的质量水平。
在这一点上，我们开始寻找其他组织工作的方式，寻找另一个更适合我们工作方式的敏捷框架。
然后我们找到了看板（kanban）。
什么是看板？
看板是一种生产管理方法，起源于1950年代的丰田公司。当时，丰田使用的董事会分为三列：“计划中”，“进行中”，“完成”。在生产线某处出现瓶颈的情况下，该框架使Toyota可以更有效地分配资源。
然后，当很明显使用看板可以提高软件开发的速度时，看板被转移到了技术领域。
Scrum和看板框架的比较
近年来，Scrum和看板一直在努力成为领先的敏捷框架。尽管Scrum排名第一，但看板正在逐渐传播。如果您比较它们怎么办？
如果我们以Scrum为基础并将其与看板进行比较，则会得到以下结果：
- , ().
- .
- «». , .
- , , .
- () -.
可以在这里找到Scrum和看板之间的更详细的比较。
看板为开发团队提供了相当高的灵活性。与Scrum相比，用户故事是以更自由的方式执行的。但是自由是责任。尽管看板不需要开发人员每两周提交一次，但这种管理开发的方法具有自己的控制权。例如，这些是诸如周期时间和系统吞吐量之类的度量。
全部与指标有关
如果没有专门的指标，就无法评估工作的有效性（或低效率）。让我们看一下Scrum和看板中使用的指标。
▍Scrum指标
应用Scrum时，使用以下指标和图形：
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
这些指标不太可能帮助您改善工作流程。
“速度”不衡量成品子系统的发布速度。此度量标准仅测量与用户故事相关的已完成工作步骤的数量。如果故事花费的时间比计划完成所花费的时间长，那么该指标就毫无意义。
“开发人员的承诺与完成的任务量之比”完全不应该被视为指标。该“指标”将对结果的承诺进行比较。不用说，这可能导致人们关闭并重新打开任务只是为了完成任务。
倦怠图是我个人从未非常关注的东西。这主要是由于这样的图表通常看起来像下面的图表。
倦怠图
为什么会这样？假设您从一块空白板开始，然后开始并行工作，例如，从三个用户故事开始。这些故事可能以相同的速度处理，这就是为什么在倦怠图中可以看到如此强大的向下运动的原因。而且，如果团队中只有一名测试人员必须测试所有任务的工作结果，那么他将成为团队的瓶颈。
▍看板指标
我认为指标是看板优势中最重要的。看板有许多不同的指标，可帮助您更好地了解团队的状况。例如：
- 团队吞吐量 在给定时间段内完成的用户故事的数量。
- 周期 自工作开始以来完成历史工作所需的天数。这里使用诸如置信区间之类的度量。最常见的是85％的信任度。
- 累积流程图 这样的图表使您可以可视化根据用户故事解决问题的过程。该图应类似于下图所示。
累积流程图
Jira有一个插件，可让您利用所有这些指标。对于Jira-Agile指标，这是 ActionableAgile。它使用与管理工作相同的平台帮助探索与团队绩效相关的指标。
看板适应
使用“纯”看板不提供使用Scrum时所需的某些操作。但是，这种项目管理方法具有足够的灵活性，可以允许在操作似乎有用的情况下将其添加到工作流中。
回顾是最重要的会议类型之一。在这些会议上，团队成员可以谈论他们所取得的成就，进展不太顺利以及可以改进的地方。回顾是一个平静的事件，您可以在其中谈论自己的问题并向那些为自己的成功所做的出色工作的人表示祝贺。
尽管在看板中不需要闪回（闪回在Scrum中每个Sprint的末尾都有），但我们发现它们很有价值，因此没有放弃。实际上，我们甚至每周开始做一次，而不是像以前那样每两周一次。这使我们能够对任何问题的发生做出更快的反应。我们还使用这些会议来分析团队指标并检查工作流中是否存在问题和瓶颈。
我们已经从Scrum时间中节省了一个元素，这在使用看板时是可选的。它是关于估计处理用户故事所需的时间。这是在澄清历史任务的过程中完成的。 Scrum使用这些估计值来更好地理解什么适合冲刺。您可能会认为，由于看板中没有冲刺，因此无需进行故事评估。但实际上并非如此。
估计完成用户故事所需的时间有助于确保所有团队成员对处理故事时需要完成的任务范围有相同的了解。如果某人给故事打8分，而某人给3分，那么显然我们需要继续讨论这个问题。在评估时间安排时，可能有人会考虑其他人不知道的一些问题。以某人的理解，用户故事工作的范围应包括其他人不这样认为的内容。
实际上，所有这些都促使团队成员进行讨论。
当发生这种情况时，很明显，并不是每个人都清楚需要在某个用户故事上完成多少工作。
另一个常见的情况是这样的：整个团队都对故事的辛苦程度给予了很高的评价（通常所有分数都超过8分）。这说明了不确定性。这意味着我们正在谈论很多工作，或者正在解决非常困难的问题，这使团队成员感到不愉快。在这种情况下，最好将用户故事分成几个较小的故事，并更清晰地定义工作目标。
结果
作为第一种广泛的敏捷方法，Scrum将永远留在我们心中。但是，随着公司采用连续部署方案，使用时间有限的sprint不再有意义。
总会有一些Scrum可以在其中表现出色的特殊项目。但是，鉴于公司越来越多地使用敏捷方法的事实，看板将逐渐取代Scrum脱颖而出。
什么最适合您？Scrum还是看板？
