WangZiqi敏捷不是“单一”方法敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快、更小地为客户交付价值。它不是将一切都押在“大爆炸”版本上，而是以小增量交付结果。不断评估需求、计划和结果，因此您可以快速响应变化。以上是敏捷的通用定义。而当我们动态地回顾过去几十年敏捷开发的历史时，围绕着敏捷这个词的框架、实践、理论等等五花八门。早期有Scrum、XP、Crystalmethod、DSDM、FDD等框架，还有Kanban与TPS的融合，后来敏捷的概念日渐普及。在此期间，出现了一些新方法，如ModernAgile、HeartOfAgile等。另一方面，DevOps运动、精益方法、反康威行动也如火如荼。如果我们仔细阅读敏捷宣言背后的十二条原则，不难发现敏捷与它们之间的默契。从这个角度来看，将敏捷描述为单一的方法未免太狭隘了。既然一个定义被否定了，那么一个定义就必须被肯定。“BeingAgilenotDoingAgile”这句话在社区流传已久，其巧妙之处在于敏捷本身就是一种思维方式。在瞬息万变的技术环境和瞬息万变的市场中，如果软件开发活动想要快速响应外部变化以高效完成业务目标，寻求一种方法来对抗VUCA/BANI/RUPT/TUNA（随便你怎么说））环境道是必然的。敏捷应运而生。但是，由于它所面对的环境是极其复杂和无规律的，当然敏捷不可能是一种或两种方法。它首先是价值观，然后伴随着方法、框架、实践等，总体上呈现出与时俱进的发展。、行业的进步，以及人们对软件开发活动认识的不断加深，都在不断演进，与价值观相似的其他理论或方法相互包容。敏捷并没有解决软件的复杂性《没有银弹：软体工程的本质性与附属性工作》曾经说过：没有任何技术或方法可以在十年内将软件工程的生产力提高十倍。无论数字如何，软件开发是一项复杂且不确定的活动这一事实仍然存在。从对立统一的角度来看，软件的优良品质往往与其令人苦恼的品质相反。更改软件的成本可能非常高或非常低。有无数种方法可以构建相同的软件。即使在功能完全一致的情况下，也有两种完全不同的可能：容易扩展和复杂死板。这是因为软件开发活动本身就是一个高熵的活动。如果构建软件的方式是单一的、循序渐进的，就不会有这样的区别。在XP2002会议上，经济学家EnricoZaninotto提到，在软件开发和制造过程中，不可逆性是复杂性的主要驱动因素之一。敏捷方法通过减少不可逆性而不是解决它来适应复杂性。复杂性的其他驱动因素。这个描述恰恰指出了敏捷的根本要点，不是解决软件开发活动本身的复杂性（目前看来是不可能的），而是尽力去处理它。这就必然导致这种应对方式本身就必须要灵活。它倾向于通过建立对软件开发活动特征的控制，在特定情况下推导出特定的解决方案，而不是依赖单一固化的过程或方法来解决问题。问题。一个想要从敏捷中获益的企业如果仅仅购买咨询、培训等服务，并没有在实践中自发地提升组织对自身业务和软件开发本身的认知（当然框架和实践是有用的，即使在不知道它背后的价值逻辑，一些实践也能带来收益，比如持续集成），但它们只能从敏捷的收益中获益。正如DaveThomas对“能否以及如何购买敏捷性？”这个问题的回答。inGOTO参考：不，你不能，但你可以购买有助于解决此问题的润滑剂。它（指敏捷）来自于实践和经验，你不能仅仅通过咨询、阅读、上课等方式获得，它来自于不断的试错。你需要发展隐性知识（你甚至不知道你知道的东西）。所以你买不到敏捷，除非有人发明了一种机器，你把头盔戴在头上，按下一个按钮，你就会说西班牙语。你可以购买工具、经验，但你仍然需要大量的工作，也许需要数年时间才能完成。灵巧是知行的功夫。王阳明的心学哲学有知行合一的认识论，即知行本为二字，一技不能二分。知实处是行，行明察处是知。相信这样的场景大家应该并不陌生：在估算用户故事的工作量时，其中一位表示：“我认为这个故事的工作量是三分，因为涉及到很多结构调整。”，另一位说：“我同意你的看法，但在我看来，借助IDE工具，这些调整并不困难，我们应该尽可能地做一个版本，所以我认为只有两点。”在这个讨论中，实际上混淆了两件事。一方面是对故事的认可（价值、技术思路、风险、难度等），另一方面是基于共同的认知，成本是多少（所谓积分).前者称为澄清，有助于识别风险，使团队对故事达成共识，并使后续工作能够更好地开展。同时，这样的过程有利于成员之间知识和经验的交流。关键是要获得正确的粒度，我们需要具体地讨论对价值、风险、努力等的影响，但不要再谈下去了。综上所述，另一个人的说法，“而且我们应该先做一个版本尽可能简单”是不明确的，观众无法理解它有多“简单”，有多“简单”只是对应不同的价值观和费用。如果是这样的描述：“而且我们应该先做一个尽可能简单的版本，它应该只修改现有应用程序的XXX处的XXX，而不应该涉及XXX和XXX……”，大概是讨论的基础点会更扎实。后者称为估计，这是一种有很多误解的技术。MartinFolwer在他的bliki中指出，估计的目的：对我来说，当你面临重大决策时，估计很有价值。这一点其实是很多做estimation的人忽略的一点，他们经常这样回答：我想知道每次迭代我们能完成多少工作！如果你问，那又怎样？有人说，好让我在开发人员不达标的时候指着他们的鼻子说，你看，你自己答应了自己，但你做不完，你说呢！通过波动迭代完成的工作量来识别哪些迭代可能存在问题（比如交付的顺畅性、技术债务积累的负面影响）的想法，是有原因的，但往往有更好的方法来识别这些问题（比如要分析故事在每个阶段停留的时间长短，技术债务的定期评估等）。还有人说，我希望通过这个来控制项目能够在约定的时间内，在约定的范围内交付。乍一看，这确实是一个稳健的想法，但以时间和范围为目标，与敏捷概念本身相去甚远。敏捷总是向着价值奔跑，时间和预算只是约束，我们无非是在有限的时间和金钱条件下探索什么是最有价值的，然后又快又好地完成。如果我们半年前就定了一个目标，即使这个目标是一成不变的政令，但这种思维也是死板的、教条的。综上所述，敏捷功夫就是知行合一的功夫。您必须实践并理解理论。如果你失去一个，你就失去了所有。只有在实践中丰富我们的认知，以认知指导实践，反复循环，抽象与具体知识并重，才能达到真正的敏捷。敏捷性要求管理人员响应一线需求。也许当敏捷先驱们吹嘘从敏捷中获得的好处时，用词太华丽了。一些大公司听他们的耳朵，看着他们每况愈下的财务报表，他们也把目光转向了敏捷。有一段时间，大规模敏捷风靡一时。我们看到SAFE、LESS和Scrum@Scale等框架如雨后春笋般涌现。这些框架的出现，率先在大规模敏捷测试领域种下了开发的新苗。然而，另一方面，他们依然基于理论的至高点，只是从象牙塔中眺望外面纷乱的现实世界。不用说，构建一个全功能的团队已经被长期以来团队级的敏捷经验所充分证实。DevOps运动的起源故事也证明，只生产中间产品的部门或团队在处理即使是很小的变化时也会出奇地笨拙。在团队级敏捷方面，很多大型敏捷框架巧妙借鉴了现有的Scrum、Kanban、XP等方法，但在如何组织多个敏捷团队上却出奇地一致。无论是SAFE的AgileReleaseTrain，LESS的HeadOfProductGroup，还是Scrum@Scale的SoS，似乎每个敏捷团队都抽出一两个关键角色，与管理层组成精英团队远离用户发号施令，带领各团队披荆斩棘，砥砺前行。事实上，如果团队自己无法处理好业务，需要“精英班”的指导，那和以前没什么两样——整个组织的业务，全靠一小群“聪明人”的智慧。和大多数“聪明人”。无法使用大脑的人形机器。而如果团队能够处理好，就不需要“聪明人”来变聪明了。相比之下，更重要的是足够的权利和资源。SuperCell的成功令人羡慕。在他们的经验总结中，他们提到信任而不是控制。CEOIlkkaPaananen说，“我是开发团队的服务员。”误解：管理层不释放其持有的权利和资源。比起前台支持业务团队，还是想着管控。在一个大的组织中，要想敏捷，不仅一线员工要学会响应市场的需求，二线的管理者和组织的操作人员也要学会响应到一线的需求，就像在TPS生产的pull模式一般。如果涉及到管理层，那就脱节了。如果一线夹在市场变化和二线控制之间，就不会敏捷。结语事物的发展有时会呈现出螺旋上升的特点。上世纪在《科学管理原理》的影响下，诞生了作为人类工业进程里程碑的流水线生产方式。是第一个。20世纪末的软件开发领域，随着软件危机的持续发酵，流程变得更加死板、死板，人的重要性又重新凸显出来。2001年在犹他州雪鸟的一次聚会上，敏捷方法的发起者和实践者提出了我们今天所熟知的四个价值观：个体和交互高于流程和工具工作软件高于详细文档客户合作高于合同谈判响应changeishigherthanfollowingtheplan这一段之前还有一句话：我们一直在实践中探索更好的软件开发方法，在做的同时帮助别人。我一直认为这是敏捷宣言中最好的一句话。它确立了最基本的起点，从工匠的执着到对价值的追求，以及理想主义光辉下朴实务实的态度。
