TL;DR： 但凡没有触及反应只重视流程的，都是田园灵敏，只下降不可控，但不进步可控。
灵敏经过20年的开展，根本现已成为了软件开发行业的事实规范。现在，不管公司规模的大小，谈到项目办理根本都是默许灵敏。市面上也有不计其数的灵敏训练、灵敏赋能、灵敏教练在推广灵敏的各种东西、各种办法、各种活动。可是，灵敏究竟是什么却很少有人说的清楚。许多人会说灵敏是项目办理的办法论，这没有错，那用这个办法论要到达什么效果呢？让项目运转的更顺畅？更快？本钱更低？读者能够先自己回答，然后继续。
作为一名开发工程师，这些问题同样困扰了我好久，从2017年开端触摸灵敏开端，直到2022年我才了解灵敏究竟是什么。期间我也在各种公司阅历过了各种的灵敏实践，但事实上，在我这5年的阅历中，没有一次碰到了灵敏的实质。在经过正规训练、老“流氓”的教育、阅读灵敏大佬的著作之后，我终于了解了灵敏是什么，本文将为读者呈现我自己的了解。或许不对，但我自认为至少比一般的灵敏邪教大忽悠深入一些。
灵敏的前史
这段主要由ChatGPT生成，我做了一些收拾。讲灵敏前史的材料数不胜数，这儿主要是为了介绍灵敏诞生的背景，以便后边更好的了解中心。
灵敏由更早的瀑布模型开展而来。瀑布模型是20世纪早期最早的软件开发办法之一，它选用线性和阶段化的开发进程，一般包含需求剖析、规划、编码、测验和保护等严格定义的阶段。每个阶段在前一个阶段完结后才开端，开发是次序进行的。这种模型在处理复杂和改变频繁的项目时体现欠安，由于它难以应对需求的改变和客户反应。
在20世纪80年代和90年代，一些软件开发者开端测验选用增量和迭代的办法来改善瀑布模型的缺乏。他们认识到将开发进程划分为小的迭代周期能够更灵活地应对需求改变，并进步开发速度。这些努力为后来灵敏办法的兴起奠定了根底。这能够大致认为是“小瀑布”。极限编程（XP）办法是从增量和迭代开发的实践中开展而来，它强调协作、自安排团队、快速反应和测验驱动开发。XP的提出者Kent Beck等人在20世纪90年代末将这些实践正式安排成一个办法论。XP的成功启发了其他灵敏办法的诞生。
在2001年的Snowbird会议上，一群软件开发者提出了灵敏宣言，其间包含XP的实践者。宣言强调了灵敏办法的中心原则，如个体和互动胜过流程和东西、可作业的软件胜过翔实的文档等。这个宣言标志着灵敏办法的正式呈现，并推动了灵敏开发的广泛传播。跟着时刻的推移，许多不同的灵敏结构和办法，都在软件开发中得到使用和改善。这些结构供给了详细的指导和实践，协助团队更好地使用灵敏原则来办理项目。
所谓的灵敏流程
从灵敏的前史中能够看到，灵敏的呈现便是为了处理瀑布形式难以应对改变的问题，而需求是一定会变的，所以这也解释了为什么现在根本没有人会用瀑布了。可是，瀑布并没有死，而是在许多公司了演化成了小瀑布。许多公司，比方我之前的一家公司，只是把瀑布的周期缩短了，比方从本来的6个月变成1个月，但在这1个月的周期里，实践的其实还是瀑布的办法。这种办法并没有处理应对改变的问题，只是削减了需求应对的改变数量和大小，这也是常见的一种田园灵敏的办法，归于最初级阶段，根本只要一个名字，其他都没有。
为了继续深入，我得先介绍一下灵敏的一些流程，这儿以最常见的Scrum为例，这个结构根本能够被认为是灵敏的中心，其他的大多依据它之上，以下为了方便还是称为灵敏。
先介绍灵敏中的3种人物：
-
Product Owner（以下简称PO）：PO负责产品的事务价值，包含写需求，定优先级，定完结规范，并终究接收产品。一般这个人物在互联网公司里由产品司理担任，不过实践上许多事务负责人是真实的PO。
-
Scrum Master（以下简称SM）：SM负责协助团队履行Scrum结构，安排后边的各种灵敏活动，消除团队中或团队间的障碍，往往在干活的眼里最没用的人，一般由项目司理担任，也很有或许被懂灵敏的干活的兼任，一个吃力不讨好的活。
-
Developer（以下简称干活的）：这儿的Developer是广义的，产品、规划、开发、测验都能够算在内。主要使命便是干活，交给产品。
再介绍3种产出物：
-
Product Backlog：这是一个优先级列表，其间包含一切要开发的特性、使命和改善主张。PO负责办理backlog，并依据事务价值和优先级对其间的项进行排序。
-
Sprint代办清单：来自backlog，在planning会议上产出，记录每个sprint要做什么。号称不能改变，实践便是扯淡，后边会说怎样应对改变。
-
可交给产品增量：干活的完结的产品，一般至少是一个独立的事务功用，由PO在review会议上进行检验。
最终是5种要害的活动：
-
Sprint：一个有限时刻的开发周期，一般继续1到4周，干活的在期间完结他们在planning会议中挑选的作业。
-
Sprint Planning Meeting：冲刺计划会议。在冲刺计划会议中，干活的与PO协商决议鄙人一个Sprint中要完结的作业，挑选backlog中的一些需求。
-
Daily Scrum：每日站会，应该是干活的最深恶痛绝的一种无意义会议，号称不超越15分钟，实践上常常不受控制。在这个会议上应该共享各自的进展、遇到的问题以及当天的计划，可是一般没人听，这个活动是办法主义的重灾区。
-
Sprint Review Meeting：冲刺评审会议，PO在此检验已完结的作业并找茬儿。这个会议很重要，理论上只要做到了完结的定义，PO找的茬儿只能依照新需求走。
-
Sprint Retrospective Meeting：冲刺回顾会议，办法主义第二重灾区，号称用于团队自我反思和改善的时刻。团队评论上个sprint期间的作业，探讨哪些方面运作杰出，哪些需求改善，然后制定改善计划。可是我就没见过有用的，根本等于浪费时刻。
好了，以上便是灵敏的Scrum结构的流程，价值观我省略了，没有任何价值。花了这么多篇幅介绍灵敏的规范流程，是为了阐明田园灵敏的另一种办法——视上述流程的契合程度界定田园程度，契合的流程越少，田园程度越高。是的，就算是彻底依照规范流程做，也依旧是田园灵敏。可是假如采纳要害的流程，现已能够有一些效果了，比方PO决议backlog、sprint迭代周期、sprint完结交给产品增量等等。为什么即使依照规范流程运转，也依旧被我称为田园灵敏呢？这就触及到了灵敏的中心。在揭晓最有价值的内容之前，我们先考虑一下，项目办理的意图是什么？
为什么要项目办理？
问题在本文的最初现已提出了，这儿直接说我自己的结论。项目办理是保下限的，让一般人的在一起也能比较高效的协作，而且对外供给可预计的产出。单考虑项目办理自身只会添加本钱并下降功率，究竟直观的看，上面讲的一系列流程都不直接发生价值。项目办理的价值在于削减不可控要素带来的耗费，然后进步整体团队的干活功率。
所以项目办理最要害的中心是可控，目标可控，资源可控，危险可控，进展可控，质量可控，产出可控，本钱可控，等等……在介绍前史环节，瀑布形式的最大的问题便是离开端越远越不可控，这些不可控叠加到后期就会导致项目崩溃。这便是为什么各种田园灵敏也依然有价值，尽管这些形式没有有效的进步可控性，但经过缩短每个开发周期，削减了不可控的要素，让不可控的要素在一段较短的时刻内就被消化一次，这个周期一般不会超越1个月。这在很大程度上处理了不可控要素的堆集问题，也给了各种田园灵敏形式生存空间。当然，如上面所说，田园灵敏也有凹凸之分，遵从的流程越多，削减的不可控要素也就越多，所以看起来越挨近真实的灵敏，市面上绝大多数灵敏的训练也停步在这个阶段。
尽管流程削减了不可控，可是怎样进步可控呢？先说一种不切实践，但却真实可行的办法——进步团队本质，招募顶尖的人才，靠顶尖人才自己进步可控性。世界上仅有少数几家公司能够做到，由于这要支付许多的人力本钱，而且给招的人供给很高的自由度和信任，彻底仰仗人才自己的发挥，据我所知，只要Netflix号称是这个形式。马云也说过，最好的团队是至情至性，实践上便是这个道理。除了这种不切实践的办法，有没有关于普通人也适用的呢？有，真实的灵敏形式能够逐步添加团队的可控性。
灵敏的中心
反应
只要能经过每个sprint为下个sprint供给反应的灵敏流程，在我看来才脱离了田园灵敏的范畴，能真实添加项意图可控性。乃至反应自身比上面那些流程都重要，由于添加了可控性，一起也必定削减了不可控。下面说一说这个反应是怎样发生的，详细的作用是什么，为什么反应能够添加可控性。有3个条件条件：
-
每个sprint的时刻是固定的。项目安稳运转之后，sprint周期不应该再改变，也没有改变的必要。
-
关于一个相对安稳的团队来说，每个sprint干活的数量是根本固定的，由时刻决议，这儿不考虑加班的情况，尽管这也是常态。
-
关于单位使命（下面把单位使命称为1个story point）耗费时刻根本是固定的，比方在同一个项目中写一个规范增删改查的页面的时刻应该差不多。可是这个时刻详细需求多少，是一个未知数。
只要求解这个未知数，就能够比较精确的知道每个sprint能完结多少单位使命，每个sprint的可控性也就进步了。下一个sprint中，只要story point数量 * story point时刻约等于sprint的中的总时刻，就能够在sprint开端的时候有足够信心，认为下一个sprint是能够完结的。
求解的进程靠的便是反应，经过对比story point的实践耗费时刻和planning中的预期耗费时刻，就能够让预期的数字逐步趋近实践情况，这便是反应发生的办法。Story point自身是一个笼统的概念，代表使命复杂度单位，关于每个团队来说都是不同的。关于干活的来说，Planning中最重要的作业便是预算该sprint中要做的每个使命的story point，让总的story point加起来约等于之前sprint的story point。之前sprint做了多少story point是在Retro中衡量产品增量得到的，所以我说不做这个事儿的Retro都是办法主义。这个数据不或许是彻底精确的，可是一般来说，经过3个左右的sprint之后，团队关于自己的情况就会有一个比较清醒的认知，预算和实践的出入也会在可控范围内，所以，灵敏成功添加了项意图可控性，但这还是只要一半的中心。
技能来了
有人或许会说，3个条件很难做到，一般的项目都是前面按部就班，后边天天加班。使命耗时也千差万别，到后边任何改动都举步维艰。是的，这便是项意图常态，形成的问题的原因，大部分却不是灵敏项目办理能够处理的，而是需求一开端就规划合理的代码架构。这儿我用的是代码，而非技能，由于技能架构过于粗粒度，单单决议技能栈，划分几个微服务，用什么中间件是不能处理问题的，出问题往往是代码完成的办法。这是灵敏的另一半中心，也是为什么灵敏尽管是项目办理的办法论，一开端却是由一帮写代码的开发提出，成果现在反而变成了开发不想写代码之后的退路，也是挺挖苦的。
从极限编程开端，灵敏的提出者们就开端致力于研究怎样减缓代码腐坏，让项意图出产功率在相对长的时刻里能够保持安稳，TDD便是他们提出的一种处理办法，靠许多的测验，保证对代码功用的全掩盖，削减修正代码时的顾虑，保证需求更改的开发速度。这个问题的中心还是一句陈词滥调的话——“高内聚，低耦合”。但怎样实践却是一个巨大且复杂的论题，在不同的技能领域也有不同的计划，本文就不多说了。要害在于，灵敏形式是需求技能合作的，否则怎样反应也是可控性越来越低，出产功率越来越低，只不过作为项目办理者，能够经过反应更早的发现这个情况。
Bonus：Sprint中修正怎样应对？
这是另一个极为常见的问题，尽管跟灵敏的中心没有太大的关系，可是这儿也拿出来说一说。先说结论，中心便是一个字——“换”。这个问题触及到灵敏中3个人物的分工。任何对需求的更改都应该由PO建议，可是这个理想情况，很少能有这么专业的PO，所以下面就分红PO建议和干活的建议两种情况。
假如是PO建议，那么由PO决议优先级，实质上这便是一个需求重新评价的新需求，可是由所以替换老需求，所以当时的sprint会发生一个空间。假如这个空间能够放置新需求，那么比较简单，直接放进来替换老需求就能够了，常呈现在老需求还没有做的情况下。假如这个空间放置不了，比方老需求现已做了一半，那么就有两种挑选。一种是能够推后，那么就直接推后到下一个sprint中，假如不能推后，不考虑加班的情况下，需求PO决议把不重要的需求挪到下一个sprint直到腾出足够的空间，再把这个需求放进这个sprint中。假如加班的话，那就看PO和干活的之间的友情了……不过，在合理的sprint周期下，这种情况应该是少见的，假如总是呈现相似的情况，阐明sprint的周期不合理，或者PO不称职。
假如是干活的建议，且不需求与PO评论，那么优先级是不变的，评论的话就变成PO建议了。所以问题便是在当时sprint中把旧需求换成新需求，这时就只需求考虑时刻。在时刻超出的情况下，要么自己消化，要么在daily会议上及时提出来，大家一起想办法，除此之外，没什么其他好办法了。这也是daily会议最大的价值所在，不触及此的daily都是办法主义。
总归，这是无法防止但应该尽量防止的问题，假如常态化，那就阐明项目现已开端呈现比较大问题了，也是一个警示信号。
总结
市面上介绍灵敏的材料许多，触及灵敏中心的很少，这导致了灵敏开展到现在现已违背的初衷。作为或许是前端开发里最了解灵敏的人，我写这篇的文章的意图是站在开发的视点，让广大的干活的了解你要遵从的规则，知道什么是有用的，什么是大忽悠，取其精华，去其糟粕，更好的应对各种田园灵敏实践。本文或许会遭到许多灵敏人士的进犯，进犯的越多就越阐明戳中了一些痛点。当然，我也欢迎合理的评论，我觉得办法论尽管虚，但在实践中还是有价值的，协助更多人捉住价值，便是我写本文的意图。最终，引荐一本灵敏宣言提出者的小书——《灵敏整洁之道——回归本源》，我的大部分观点都出自本书，很薄，值得一看。
