Agile还是Scrum，这可真是个难题

全文共3704字，预计学习时长11分钟

图源：bbs.photofans

对于哈姆莱特而言：

生存还是毁灭，这是个问题。

 

对于程序员来说：

 

Agile还是 Scrum，同样是个难题！

 

Agile大有益处，Scrum同样优点颇多；作为程序员，识别两者区别，是一种硬性要求。

旧约·以西结书18:20

唯有犯罪者，他必死亡。儿子不必承担父亲的罪孽，父亲也不必承担儿子的罪孽。

创建敏捷软件大有毗益。

 

如果你不赞成，那可能是因为你还不太明白它们的概念。

 

一些人和我说，他们觉得“敏捷”糟透了，对此我常常觉得不可思议。深入了解情况后，我越来越清楚他们讨厌它的原因，他们是在实践上出了问题——比如不合理地强迫团队提高工作效率——这实际上与敏捷价值观背道而驰。

 

问题是，许多资料无法解释好敏捷、敏捷相关框架（比如LeSS、SAFe、Scrum等）和实践（编写用户故事、迭代周期、待办事项）三者之间的区别。如果区分开这些概念，很容易将特定实践的缺陷所造成的问题归咎于敏捷。

 

实际上，大多数开设敏捷培训的咨询公司都有一个既得利益：概念模糊永久化。如果能将他们的特定框架和教的敏捷的整体概念融合在一起，他们可以使团队更加依赖他们费用高昂的培训。

 

有些人可能会说，这样敏捷与其他概念混在一起以至于变得没有意义，但我认为此说法有失公允。如果你能区分开它们（我希望能帮到你！），敏捷的核心理念仍是十分有价值的工具，可用于思考如何区分有效团队。

 

图片：“敏捷顾问”与首席技术官交谈

实际上，敏捷宣言只给出了4个价值观和12个原则。值得注意的是，这些价值观和原则并不是凭空产生的。它们是对看似运行良好的东西的概括，是对大多数公司环境中渗透在“瀑布式”软件开发中的官僚、僵化和层级思维的反应。在这里我不会对瀑布化问题做详细说明。现在只需记住，瀑布式软件开发同敏捷开发的每个价值观和原则都大相径庭，因此通常不是很有效。

 

敏捷宣言内容如下：

 

敏捷价值观：

 

一、个体和互动 > 流程和工具

二、工作软件 > 详尽文档

三、客户合作 > 合同谈判

四、响应变化 > 遵循计划

 

敏捷原则：

 

一、最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。

二、即使到了开发后期也要欣然应对需求变化。为提高客户竞争优势，敏捷过程需要掌控变化。

三、经常性交付可运行的软件，交付周期从几星期到一两个月不等，越短越好。

四、项目中业务人员和开发人员必须保持时刻合作。

五、以积极奋进的员工为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

六、对开发团队而言，最高效、有用的信息传递方式是面对面交谈。

七、可运行的软件是项目进度的首要度量标准。

八、敏捷过程倡导可持续开发。责任人、开发人员和用户要共同维护开发步调的稳定延续。

九、不懈追求技术卓越，良好设计能增强敏捷能力。

十、以简洁为本，它是极力减少不必要工作量的艺术。

十一、自组织团队能做出最好的架构、需求和设计。

十二、团队定期反思如何提高成效，并依此调整自身表现。

 

关于敏捷，以上就是你真正需要知道的一切。

 

注意，敏捷宣言并没有规定具体的实践。它并不能准确地告知你该做什么，什么时候做，怎么做，或者使用什么样的工具。相反，它给出的是一般性的指导方针，让你想出同团队状况最契合的方案。如果你想找敏捷的缺点（一定会有），你应该用一种与上述概念相关的方式来表达想法。不过，我认为只要有在高效团队中工作的经验，会立即意识到大部分内容是如此直观，太过明显。

 

图片一名工程师首次向同事解释敏捷宣言

然而，这些观点说得简单并不意味着人们能简单理解并运用它们。读到像是“自组织团队”之类的概念时，人们很容易附和点点头，但并不能充分认识到这同真正的工作环境有多么不同，因为在真正的工作环境中管理者会规定团队结构、指导团队成员完成工作。

 

一般来讲，改变文化和心态很难，但告诉人们遵循预先定义的步骤和过程却很容易。敏捷作为一种价值体系变得越来越流行，那些曾长期销售此模式的项目管理组织和咨询公司并没有立即消失。他们不想改变既定的商业模式，所以加倍努力销售“敏捷框架”。

 

在各类敏捷框架中，Scrum是普及最广、采纳度最高的框架，所以接下来会主要介绍它。实际上，Scrum在技术上比敏捷宣言出现得早，而敏捷的部分灵感来自于Scrum等框架的良好运作。所以好消息是Scrum并不是很糟糕（等我写了关于SAFe的文章！），实际上还相对简单。然而，我认为它在实现其宣称的1：1关联的价值观方面，确实存在一些问题。

图源：pexels

Scrum与敏捷的一个主要区别在于，它实际上规定了你可以做什么以及如何组织工作。规定性方法的危险性在于，一个团队可以在没有任何人改变心态或价值观的情况下选择并开始运行Scrum。这种“实际上并不是敏捷状态的Scrum”可能会很粗糙，我认为这是导致“反敏捷情绪”的根源。这种环境中的问题可以以无数种不同的方式表现出来，包括（但不限于！）以下内容：

 

1. 敏捷大师最终表现得像项目经理，他们试图保持现状—去掌控而不是支持团队

2. 团队可能会过分专注于匆忙“完成”工作，而不考虑工作的价值或质量

3. 在没有对先前发布的内容进行任何迭代的情况下，迭代周期不断产生新特性

4. 团队过分依赖专业化及工作交接，而没有找到在团队中并行或交叉传播技能集的方法

5. 管理者在scrum团队中走单一流程，限制了单个团队的自组织能力

6. 建立团队实际上并不基于团队所需技能

7. 团队进行工作回顾，但不解决已出现的问题，因为他们永远看不到事情的变化

 

图片：一位敏捷大师和开发者为即将进行的迭代会议做准备

这些都是明显错误实践Scrum的例子，但并不一定是对Scrum本身的控诉。我认为更模糊的一点是，“好的”框架似乎与敏捷性相冲突。尽管Scrum可以定制，但如果最后定制得太多，就不再像Scrum了。下一部分我将根据本人的经验举一些例子。我并不是在宣称绝对的、普遍的准确性，而是希望能在你思考如何实践时，给你更多的思考点。

 

Scrum中（也许）可以摒弃的东西：

 

1．有时候，我们不需要一个专门的敏捷大师。相反，团队可以定期自我管理并轮流担任敏捷大师。这为有能力的员工增加了一个额外的表现工作能力的机会，并在团队中创建了一种更好的流程所有权意识。但对于一个缺乏敏捷素养或需要大量保护以避免外部干扰的团队，我不推荐这样做。

 

2．偶尔我会在无需专门的产品负责人的团队中工作。在这个团队中，产品分配不是由产品负责人完成，而是在团队内部完成。作为团队中的设计师，我倾尽全力来填补这个空缺。如果你开始这样的尝试并发现很难获得共识，团队可以集体确定采购订单以提高团队中集中决策的能力。

 

3．我们摒弃了大部分关于迭代周期和迭代策划会议的概念。迭代周期使一些团队从一贯的年周总结变为更频繁地总结，但是如果团队在迭代发布上一向较频繁，那么这个迭代周期效果就不大了。迭代并不鼓励中期变化，但敏捷应该鼓励变化！我们切换到看板上更多的连续任务流。这也使我作为一个设计师更容易在需要时进行更微观的用户体验调整。

 

4．我们完全摒弃了故事、史诗、特写等方面的严格要求，只是在最自然的层面上跟进我们需要做的事情。这使得任务跟进变得更简单、更容易理解，而且似乎并没有降低我们的组织性，也没有改变以客户为中心的原则。要说有什么发生改变，那就是它能让我们更多地关注客户价值，而非客户数量。公平地说，史诗/特性/用户故事命名法并不出自Scrum官方指南，而是一种很常见的做法。

图源：pexels

Scrum中（应该）保留的东西：

 

1. 定期回顾。每日回顾也可以，但似乎不回顾长一点的周期就不能看到一些全面的问题。在这里我将分享一些关于工作回顾的想法。

2. 限时每日站会（daily standups）。这有助于将大家的思维集中在同一方面，减少了其他会议，并发掘需要大家一起做的工作。

3. 做待办清单，清单中列出团队要做的事、要细致做的事、需要定期改进的事，将其作为工作优先事项划分机制。这使得工作跟进和对优先事项进行简练调整的管理变得很容易。

4. 专业跨职能团队减少外部依赖。这对于不总是处于等待或匆忙状态的工作至关重要。

5. 我还可以列出更多条内容，但我认为这已经表达了我们决定为什么继续或放弃某些事情的总体思路。我们也并未一次性做出所有决定。随着时间的推移，我们尝试了不同的角色，经历了不同的过程，根据对我们来说最有效的东西来做出改变。

 

图片：一支老牌团队展示合作能力

重要的是，要有意识地思考你在做什么以及如何做得更好。我认为像敏捷这样的概念使我们更容易讨论。

比如说：如果这篇文章为你提供了更多的参考来巩固或表达你对敏捷的看法，那就是一种成功。

 

 

留言 点赞 关注

我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）