全面解析“敏捷”-InfoQ

低代码到底是不是行业毒瘤？一线大厂怎么做的？戳此了解>>> 了解详情 



 写点什么

首先敏捷是什么？

敏捷可以多层面去看。你可以看虚的——价值观原则，就跟个大帽子一样。你可以看实的，那么它就是一些流程，一些实践，一些工具，所以这些都是敏捷。那就像盲人摸象一样，大家会摸到不同的地方。

敏捷的发展，《敏捷宣言》的发表是在 2001 年的时候。在《敏捷宣言》发表之前，敏捷领域的 17 位大咖（另有几位大咖据说有事未能参加），精通方法学的内容，齐聚在雪鸟滑雪场，边滑雪边讨论。而上面材料中的内容，基本上来讲，就是敏捷的指导原则了，也就是敏捷的价值观。当然除了原则，还有十二条实践，这里就不一一罗列了。

怎么判断你是不是真正在做敏捷，不是看你做成什么样子，当然做成什么样子是一个基本的判别标准，比如说你站会都没做，那肯定就还是不够，对吧？一般来讲，这样做不是敏捷的可能性比较大。那么另一方面，比较难判断的就是，你说我们的用户故事、Scrum 的流程做成这样、做成那样，那算不算敏捷？那这一点可能就会复杂一点，比较难判断。

“个体与互动高于流程与工具”，以前的方法可能是认为一套流程，放在任何地方、任何人都可以用起来，效果都差不多。那么其实敏捷这一块儿，不认为是这样。因为每个企业其实是不同的，每一块领域也不一样，你每一个人也不一样，他的互动、他的特点，他们组成团队的群体，他们的互动也是不一样。所以，敏捷的这帮人认为，我们首先要去考虑个体和互动，也就是说这批人，他们完成这个事，然后再去考虑工具怎么去支撑这个工作方式、这个流程。

所以，从某个角度来讲，很多时候在圈子里面或者跟大家交流这个敏捷应该怎么去推动的时候，我的这个基本态度就是我一定从人入手。我不建议从工具助手，而不是说不能从工具入手，而是你一定要选择。不谈具体情况的时候我一定会说从人入手。为什么？因为工具呢，他跟人的使用习惯是很有关系，比如说，这个人的使用习惯，他就是这样，就很难改进。

如果团队还没有真正的合作，所以他的看板上的列和行不断地在调整，那么当这个时候你要让他去用工具，而且一般成型的工具都有他自己的一套理论在里面，比如说你的栏位是怎样设置的，当然可以调整，但是你就要改。而且有的时候可能会想要给这个栏位去加一个规则，那这个工具可能就比较难支持。或者说这个工具秉承的理念里面就认为不应该有限制，这个时候工具就不能够支撑你当前的工作。

“可工作的软件高于详尽的文档”，就是我们一定要先考虑，软件能不能用，是不是可以正常运行。然后再去考虑有没有文档。我的观点，文档是可工作软件的工作方式在文字上的一个投影，或者一个投射。简单来讲，文档应该是软件的一个视图，可工作的软件，这个才是真正的源头，是真正的有价值的东西，能够用的东西。

“客户合作高于合同谈判”，也就不需多讲了。天天扯合同，事儿没办成，对谁都没用。最后大家都亏，最多我多亏一点儿，因为合同约束。大家要多想如何共赢。超出了合同但共赢，则大家都到的都多，这才是关键。

“响应变化高于遵循计划”，很简单就不要去碰墙嘛。这个的关键在于我们怎么去做这件事情，一个是更频繁地做计划，做计划的范围，比如需求范围。

敏捷呢，含义比较丰富。徐毅比较扣词，因为很多时候，大家虽然在谈敏捷，但谈的可能不是一个东西。那如上图所示，敏捷，用外国人的话说，敏捷就是价值观、原则、实践和工具，这样一个层次。外企一直用，觉得很习惯。后来，听到“道、法、术、器”的说法，是姜志辉讲的“道、法、术、器”，网上有视频。

重点在于，应用的时候，要能够贯穿，串通，一拉到底，通透很重要。单点做的再好，不能连城线，不能汇成面，不能成体系，是不行的。所以，“道、法、术、器”的每一个层面，都是相关联的，都有一个相互的关联和指引。比如，“道”，敏捷里说，“可工作的软件高于详尽的文档”，搞定可用的软件，比写详尽的文档更重要。那这就是一个方向了。我们的方法就是以可用的软件为进度的唯一度量。那我们怎么做到这件事情？那我们要拆。

具体做法有哪些呢？

比如说 ATDD，实例化需求，BDD。他们都是把需求拆开，拆成小的颗粒度，然后明确验收标准，然后去驱动这个开发、测试的整个过程，那么当这些全都完成之后，你就会看到他不是 100 个需求一起设计完、开发完、测试完。他不是这样去推动的。那么这样一个做完了，就是 1%，然后下一个，2%。这实际上是在实践操作的层面去具体实践和体现“可工作的软件”这个标准。那么“器”，这个工具，就是我们要去支撑前面的这个做法，这个操作方式，那么 Robotframework、Cucumber 这些工具就可以支撑。

最下面可以看到，有时候好像还是蛮容易解释他的，就是传统开发就是按阶段。而迭代开发就是可能前期，尤其是大的系统，还是要有一点点的前期预演，当然通常会有一个曳光弹扔出去，把这个路径照亮，看一下我们这个行走的骨架、我们的观念、架构是不是 OK。

最后的一个时期，还是有一个集中的验证，尤其是大的系统，有可能，是无法避免的。像互联网这样的系统，放出去然后他能够极快的修改。这个就是响应、修复的能力，越强，后面这个集中修复的部分就越少，因为你就不需要靠着集中验证来保证质量，你可以出了问题再快速响应。但是，尤其是原来像通信或者传统的软件，那可能还是有一个集中验证的过程。所以后面还是有个集中的阶段。

那么另外一个是说，即使人的能力到了，可能你们的工具、实践也不能支撑。比如说你在前期没有办法做系统测试，编不出来这个包，或者说，你没有这个手段、没有这个工具可以支持在这个时候，这么快速地只测试其中的一部分功能。或者说，这个测试的消耗特别高，那么你一定要去考虑这个成本效益。这里面就有一个比较实际的怎么去操作的考虑。

总结一下，怎么定义敏捷呢？敏捷是什么？敏捷就是，高频次地迭代、灵活地响应、持续地完善。

这个话是不是听起来好像白搭，怎么说都对？其实就是这样，从虚的、抽象的层面来看，这就是敏捷想要做的或者目标。大家如果回头去看那个敏捷宣言第一条，基本上就是这样。他说，我们最首要的目标，就是要通过及早却持续地交付有价值的软件让客户满意，其实就是这样。我们要通过高频次迭代，我要有这个能力迭代交付。然后呢，有了什么事儿，我能灵活地响应，我有这个灵活响应的能力，你不能说对不起，我响应不了。

那么除此之外呢，无非就是做法的区别。当然现在业界也有很多一直在讲什么是敏捷，或者说，敏捷跟 DevOpS 什么关系，是不是 DevOpS 就是敏捷的第 2 代，或者又有各种各样的说法。那么这个真的取决于大家对敏捷的定义。对我来讲，敏捷就是大一统，什么都是敏捷。我认为敏捷的外延在不断发展。所以从我看来，我觉得现在的一些新的趋势，都是在敏捷原则上的扩展。

具体来看怎么做呢？

其实想想也很简单，举个例子，就像吃蛋糕，会不会有人先把奶油全部吃掉，然后再吃蓝莓，再吃胚子？肯定没有人这么吃，对不对？

但是，IT 行业开发软件却喜欢这样子。前一段时间有一个形容，或者有一个说法，尤其是在现在消费者市场占主导、占主流的时候。大家这么想，以前都是因为一个企业，尤其是企业应用、企业级应用的市场占主导的时候，不可能今天上线一个应用、明天上线一个应用，大家用起来不方便。

但是消费者市场呢，搞个手机应用，憋大招，搞了 100 个特性，下个月一下子全部拿出去给消费者。那么首先不说这个速度慢，换个角度，从用户的角度来看，等了两三个月，或者好几个月，突然一下拿到一百个特性、一百个功能的这个应用。那么消费者就需要去消化这一百个特性怎么用，怎么跟他的生活结合在一起。

所以呢，这里就有一个形容，“竖着切蛋糕”。把这个蛋糕想象成架构层级！那么有些架构，还有一些装饰、修饰的结构粘住他们。总之，我们是竖着把它切完。切完的意思就是实现需求的时候，我们关心的是用户可以看见、用户愿意感知、用户认为具有独立价值的这样一个东西。那这个东西呢，通常来讲，极有可能跨越你的整个组织。

另外，做敏捷的过程中，有一个误区。以前其实最开始在讲敏捷团队应该是怎样的时候，大牛们讲的是跨职能敏捷团队，没有讲跨职能特性个人。当然有的后来说法更夸张，直接叫全能团队，或者全栈工程师。那这个就有点儿过了。包括很多大牛在之前也发表过很多意见。大家一致认为，全栈工程师，最多是一个方向，不可能是一个现实！

现实一点儿、取巧一点儿，我们可能会问，如果这个人什么都会的话，那么这个人真的什么都做吗？对吧？每次都全部自己干到底吗？那这样他一个人开发好了，他不需要跟他在一起。他如果需要跟大家在一起，大家就得想办法协作，大家想办法协作就一定在整个开发过程中需要有交互。大家在一起必然有你做这个、我做那个，这样才是一个效率比较高的做法。

然后另外一点是，开发测试。那开发当然什么都能做，但问题是，你这个开发人员，如果主要的工作百分之八十以上的时间，都是在做测试的工作的话，那请问你叫开发还是测试，对吧？

当然，更多的是说我们不能去奢求每一个人，什么都会。所以你要敏捷，要能够落下地，落地，我们必须解决规模化在大企业里面怎么去做的问题。不可能永远都是一个精英团队，对吧？精英团队毕竟是少数，一个小企业、创业企业这种小规模，小而美的团队，那也是少数。未来呢，比如说像 IBM 这种巨型企业可能会越来越少，但依然会有几百上千的员工。

这里面还有一个普世的价值看法，或者叫人文主义的说法，我们要有人文关怀。那你说，他们大，所以他就该死吗？不应该是这样，大企业也有权力从敏捷中获得收益。而从推动敏捷的人来讲，如果敏捷是好的，那就应该普惠到所有的人。所以实际推行敏捷的过程中，必须要解决规模化的问题。在推动敏捷的过程中，必须要考虑在这么大规模的情况下你怎么去推行敏捷。