让我们从描绘场景开始。 这是开发团队的回顾性会议，团队成员正在疯狂地写下他们在便笺上的贡献，这些便笺以“疯狂，悲伤和高兴”或“保持，改进，停止，开始”等熟悉的括号为主题。我们都去过那里，对？
一旦完成了任意时间的拼写，追溯协调员便具有将笔记分组为主题的任务，然后，团队通常会对他们希望在会议的其余部分中进行更深入讨论的特定主题进行投票。 这是许多“敏捷回顾”会议的通用格式。 如果您想稍微调整一下，我请您仔细阅读“有趣的回顾展”，当然这是在阅读完此内容之后！
在过去三年中，我工作的每个团队中，我都可以说至少有一次会议，经常有更多会议，就像我描述的那样，“我们在做Scrum还是看板”问题已经出现。 。 通常情况下，要进行长时间的辩论，而很少达成共识。 我试图避免这种辩论，因为我年纪大了而且很愚蠢，因此知道这两个过程在软件开发中都可以发挥作用。 两者都为不同的人提供了不同的东西，并且都可以在项目生命周期的不同阶段应用。
那么为什么这种对话不断发生呢？
反思为什么反复进行此对话使我在根本原因上有些空白，但是，可能有多个因素在起作用，我现在将讨论其中的一些因素。
项目年龄：在Scrum / Kanban辩论中， 项目的年龄是否有意义？ 我参与了多个项目，这些项目已经运行了多年，以常规发布周期（也就是SCRUM样式）工作。 此外，我还从事一些处于初期阶段的临时看板项目。 双方都开会讨论了哪个过程更合适。 因此，我认为项目年龄并没有真正纳入其中。 但是，有时候我会在后面讨论一个过程比另一个过程更适合的过程。
团队组成：我目睹了高级工程师团队和经验丰富的团队在Scrum vs Kanban上的争论。 最近，我加入了一个由年轻工程师组成的新组建的团队，探索适合他们的正确流程。 我发现通常是开发人员/工程师对该主题最有热情。 偶尔会有其他角色的人参与其中。 但是，通常是开发商迫使问题发生的。
为什么开发人员对这个问题如此强烈？ 我的一位朋友最近指出，SCRUM的定时交付以及与敏捷方法学的紧密联系可能被用来向开发团队施加压力。 从本质上讲，这使他们对交付的速度感到自觉，并把重点放在工程上。这可能会导致出现错误或受到监视的感觉。 因此，创造力和质量等开始代替速度。 您可以同时拥有。
团队领导：根据我朋友对压力的观察，这是我觉得我们可以找到答案的地方。 我的意思是指团队的领导层，负责确定优先级的角色往往会对所使用的流程产生更大的影响。 在上一个职位上，有两名分析师和一名项目经理，他们都是团队的高级成员。 他们产生了很大的影响。 我常常觉得工程师没有勇气与他们抗衡，还是不被打扰？ 尽管围绕咖啡机的工程师抱怨他们更喜欢使用看板，但该团队最终被授权使用SCRUM。
我也是一个团队的成员，该团队的领导由技术负责人，项目经理和产品经理组成，我们使用SCRUM时没有任何内部冲突。 我认为这归结于每个人都相信的共同使命，这意味着交付过程会退居次席。 每个人都只是想提供恒定的客户价值，还有更多亟待解决的问题。
组织文化和报告路线：在上游进行领导之后，您开始了解谁是开发团队中的关键影响者。 这些是项目利益相关者，即输出报告接收端的利益相关者。 通常，中层管理人员会在职业生涯中的某个时刻在煤矿工作岗位上完成技术任务，但是像我曾经那样，他们早已毕业于电子表格，路线图，幻灯片和图表的世界。
这些人在很大程度上影响了工程团队。 我指的是诸如交付经理，项目经理，计划员，产品经理，工程负责人甚至您的CTO之类的角色。 这些角色在软件交付中起着不可或缺的作用， 但在开发过程中却不起作用 。 我是从这里的经验谈起的，所以请耐心等待。
我见过扮演以下角色的人们坚持使用Scrum：
我的理论是，SCRUM为这些涉众提供了安全感。 因为它易于理解，具有一定程度的可预测性，并且可以轻松地翻译给高层指挥人员或开发团队外部的人员。 例如，每隔几周就“冲刺”以确保目标的实现； Burndown Charts跟踪工作的交付；任何人都可以参加的每日站立会议； 并经过所有计划和回顾性思考-不喜欢什么？ 它很简单，听起来像可以轻松应用并产生结果。
相比之下，看板似乎更加不受控制和不可预测。 没有冲刺，只有在有能力的情况下才投入工作，常常使团队成员松懈来帮助他人，整理或学习。 您可以限制进行中的工作以在开发管道中创建流程。 在可能的情况下，您可以消除浪费，而无需着重估计或讲故事。 使用周期时间（天数，不是虚数）对工作进行追溯跟踪，并小批量交付。 最终，每隔几周就没有大张旗鼓地标记一个新版本，也没有营销时机。 发布是临时的。 这为工程师提供了更大程度的灵活性，因为他们不急于达到冲刺目标，也没有在冲刺结束之前感到被迫释放的压力。 意思是工作可以在准备就绪时寄出。
辩论中的其他促成因素
控制：在线路之间读取时，SCRUM不仅提供安全性，而且提供控制。 有很多时间要谨慎行事，避免做出轻率的决定，因为通常情况下，工作计划在其生命周期的一英寸内进行，积压的积压工作会在完成的工作在发布前或发布前的生产环境中等待之前进行构建，完善和修剪。 提供充分的机会来绝对确定作品的高质量，并且不会对客户或品牌构成风险。
尽管看板系统可能会积压变更。 这些更改通常在准备好时就已交付。 如果做得正确，应该每天都有稳定的小变化流向生产，并始终专注于对高价值物品进行优先排序。 如果将错误投入生产，团队应停止发布并优先解决此问题，然后再发布更多更改。 Facebook遵循“下一个版本将修复该错误”的口号。 这将重点放在质量上，折衷是增加风险。 对于任何生产问题都可能造成品牌损害的利益相关者而言，这可能不太合适。
品牌推广：我相信在SCRUM方面也存在偏见，因为人们确实喜欢品牌推广。 试想一下，如果您不是经验丰富的软件技术专家，那么您会想到，有些顾问说：
“我们需要放慢脚步，以便通过限制正在进行的工作来加快脚步”
您的反应是什么？ 我不骗你，我一直在接受CEO嘲笑这种逻辑。
另一方面，如果我们的顾问声称在SCRUM专家的专业指导下，我们将通过精心计划的“ Sprint”工作，每两周可靠地发货！ 听起来不那么吸引人吗？ 考虑到我之前提到的强制交付的心态，很容易看出为什么这种销售方式听起来很有吸引力。
项目适合度 ：经验表明，在某些情况下，SCRUM可能比看板更适合您的需求。 我发现，当产品处于婴儿期时，冲刺或装箱工作的概念非常合适。 在构建新产品时，收集反馈并迅速展示进度非常重要，因此在早期阶段，冲刺使团队能够在与利益相关者进行审核之前交付足够的内容，实质上是在衡量进度的最高需求时。
发布后，SCRUM往往会导致许多更改立即交付。 如果您的团队每月出货一次或两次，则可能会有很多更改。 就所有有效的更改以及您的客户实际上赞赏他们所钟爱的产品的大量更改而言，这都被认为是冒险的。 我认为，变化应该几乎没有引起注意。
就是说，我在团队中工作过，每两周发布一批变更确实效果很好。 业务中的每个人都每两周进行一次Show and Tell，Retro然后Planning的节奏。 主要区别在于我们共同交付的目标和对我们正在交付的工作的热情，团队中的每个人也使用该产品，并且领导力令人鼓舞。
您决定交付流程的另一个因素很可能是您的基础架构。 每周或每天部署多个版本可能不可行。 因此，较低的交付频率可能会对您的团队有效。 您的部署可能需要一些手动干预。 您可能必须让运营团队部署您的更改，因此将它们分批进行是有意义的。 在上一个职位中，我们有一个维护时段/计划内停机的概念，这意味着通知客户在此时间范围内可能发生问题。 当没有人使用该系统时，我还看到了数小时内大量分发的更改。 同样，这里的权衡是对企业的风险，即部署可能会影响业务功能，这是SCRUM运作良好的地方。
我发现，当已经有成熟的产品并且团队已切换到试验模式，尝试更改以查看为客户带来增值的方法时，看板通常会发挥最佳作用。 没有截止日期，积压的订单主要是想法，改进和支持通知单。 在这里，可以将每个开发任务引入，交付并分别进行验证。 此阶段通常在主要版本之后，即向产品中添加增量产品。 没有大爆炸的发布，客户将不得不努力地注意到正在进行的增量更改。
发布前，看板也可以工作。 它确保工程师有时间和空间来完成工作，并确定特定设计是否可以在生产中继续存在。 但是，预发布是衡量进度和按时完成工作的最高需求，胜过不可预测性。 我认为正是这种需要，驱使许多团队在项目初期就采用SCRUM，因为它专注于计划交付。
那么，如果我发现自己在SCRUM或看板辩论中该怎么办？
“放下Smack！”
我发现自己引述了The Rock —“团队使用SCRUM还是看板作为他们的项目交付框架都没有关系”（我确定他曾经在Smackdown / RAW上说过这一点？）。 重要的是，团队正在及时向客户交付有价值的工作。 怎么不重要。 正如我在开发团队以外的其他文章中所讨论的那样，这些决定对客户几乎没有影响，甚至没有影响，这就是为什么我赞同亚马逊的“客户痴迷”原则。 团队所做的一切都应该使客户受益。 我觉得开发团队经常看不到他们的客户，因为他们被诸如业务分析师和产品负责人等角色代替了客户，从而被抽象化了。 团队可能会陷入思维陷阱，因为他们正在提供没有客户的内部API-错误！ 您的同事成为您的客户，尽管这些API并非面向公众，但在设计时应考虑外部化。 为什么要为您的同事提供糟糕的服务，为客户提供更好的服务，只是让一切变得很棒，对吗？ 如果产品是面向公众的，则在每个决策或实验中都应包括客户。 确保整个团队与客户进行交流，无论是通过反馈会议，UX研究还是至少调查。
我觉得这里很重要，我很老套。 这些辩论经常发生在据称是“敏捷”的团队和组织内部，如果团队正在争论使用哪个流程来管理和跟踪工作， 那么您失败了 “敏捷” 的第一个原则是……
“流程和工具上的人员和交互”
当然，如果您是敏捷组织或团队，您不应该进行这些对话吗？ 进入团队的工作应该源于客户的协作 。 您应该与客户紧密合作，以定期演示您的工作软件。 团队如何跟踪这项工作不值得审查。 不应计划数周的冲刺和里程碑。 您应该响应客户的需求 ，在发布项目的下一个迭代之前做足够的工作。
Scrum和看板是流程。 两者都在软件中占有一席之地，但是它们似乎都是敏捷宣言的附加内容。 真正的敏捷性来自倾听您的客户并进行实验以找到适合市场的产品。 每两周没有三个小时的计划会议和回顾会议涉及相同的领域。
有一天，我想看看包含以下各列的工作墙：
我不是在建议我们大家明天走进办公室，然后大怒地将墙上的所有便条纸撕掉！ 我们尝试将更多的精力从这些内部辩论中重新定位，这些辩论从未真正得到解决，而是将精力重新分配给了客户。 与他们进行对话，而不仅仅是UX团队或产品负责人。 使客户互动成为整个团队的职责。 我已经看到开发人员从与客户交流和观察客户与他们正在构建的产品的交互中获得真正的突破，因此请尝试做更多的事情，并减少内部对流程的争论。
我很欣赏这些简短的概述，并且对我的经历非常个人化-有关更多信息，请参见：
- SCRUM
- 什么是看板
