Scrum不够敏捷
作者丨K L Krithika
编译丨诺亚
翻译 | 51CTO
在过去的几年里，Scrum的受欢迎程度明显下降，尤其是那些亲身经历过该框架的低下效率的工程师们，越来越不喜欢它。
僵化的框架，在短时间的密集冲刺中执行，每个冲刺之后都有长时间的会议，正是它不受欢迎的原因。Scrum不能用于所有类型的项目，这就催生了更多的敏捷方法，如看板，XP（极限编程）和精益方法(Lean Methodology)等等。
Scrum的最初设计迎合了小型团队，在将其应用于更大的项目时导致了一些复杂性。某种程度上，它只适用于范围清晰、定义良好的项目。
为什么Scrum不够敏捷
有很多关于Scrum优缺点的文章，有些人信誓旦旦地说，“如果Scrum不适合你，那就是你做错了!”，其他人则指出该论点的谬误。Scrum的成功案例证明,明确的职责和分工有助于更好地协调和集中注意力。
当团队可以致力于框架的角色、仪式和迭代性质时，Scrum运行良好。当团队成员、利益相关者和客户之间需要明确的责任和沟通时，Scrum比看板工作得更好，看板的任务分配不那么严格。
问题在于Scrum的使用规模。虽然对该方法的优点有一些共识，但它并不适用于所有项目。工程师面临的一个常见情况是，在构建多个应用程序的团队中，在所有正在进行的故事完成之前，个人无法开始一个新的故事。已经完成任务的团队成员一直处于空闲状态，直到团队每个人都完成了他们的故事，这完全是低效的。
长时间的会议是用户的另一个痛点，在计划和会议方面投入了大量资金。大量时间被耗费在用于讨论有时只需要30分钟即可完成的故事。只涉及两个人的会议最终会波及整个团队。
替代敏捷方法
看板是流行的敏捷方法之一。它是一个可视化的工作流程管理系统，专注于持续交付和灵活性。工作项在看板上表示为卡片，通过不同的开发阶段进行。与Scrum的固定长度冲刺不同，看板允许连续的工作流程，没有预定义的时间盒。
换言之，看板方法是连续不间断的，而Scrum是不断重复一个流程来达到迭代。看板方法更适合那些需要在开发周期中处理很多不确定的工作的团队，通常用于突发请求、售后支持和优先级不断变化的项目。与Scrum不同，看板没有固定的角色或仪式，使其更适应不同的场景。
另一个流行的是XP（极限编程），它专注于工程实践以提高软件质量。它强调测试驱动开发、结对编程和频繁发布等实践。XP 鼓励开发人员、测试人员和客户之间的密切合作。
顾名思义，XP专注于软件开发的技术方面，在实践中常被那些采用其他敏捷框架的团队揉和在各自的框架中去最大限度地发掘团队成员的开发潜力。和看板方法一样，极限编程也在追求减少浪费，专注于眼下的代码开发而不是考虑明天的计划或者下个月的安排等等。
Scrum强调角色之间的划分，功能驱动开发（FDD）更专注于首席程序员，开发经理等。它适用于可以分解为明确定义的功能的项目。FDD以增量方式构建软件为中心，专注于特定于客户需求的功能或用例。它使用功能列表来指导开发。
未来会如何
即使有种种缺点，Scrum仍然非常受欢迎。大约56%的公司使用Scrum作为独立方法，其中约83%的公司将其与XP或看板或其他敏捷方法一起使用为混合模型。
最近，不得不注意到有些变化也在悄然发生。今年年初，美国第一资本投资国际集团（Capital One）解雇了整个敏捷部门，将这些角色合并到现有的产品经理中。Scrum Master监督团队的时代很可能会悄然逝去，而企业可能会在团队中接受敏捷实践，或者选择类似于Capital One实施的模型。
参考链接：
https://analyticsindiamag.com/scrum-is-not-agile-enough/
往期推荐