敏捷

敏捷开发自2001年提出敏捷软件开发宣言后有20年，但在中文里很少有一篇文章详细介绍敏捷开发。因此本文从敏捷开发，敏捷开发的历史，敏捷开发的分类，敏捷宣言（价值观），以及敏捷精髓等方面详细阐述了敏捷开发。本文的最后还列举了敏捷在除了软件行业以外的应用，比如硬件、人力资源、市场、等等。

企业越做越大，敏捷也要求规模化。虽然敏捷从一开始是小团队，但依然可以适用于多团队的。不过这个时候要十分小心规模化的方法和方式……

本文用一个生动的故事来描绘了3种不同的管理风格。故事来自于一个虚构的村庄，当你处在这样一个场景下，你会如何进行交通管理？对应于工作中，处于类似的场景下你会如何管理呢？是微观管理还是大妈管理还是专家管理？

Scrum之类的框架非常适合解决业务问题，并且公司不断过渡到敏捷以实现目标。但是，如果他们忘记了敏捷只是一种方法论（一种实现目标的手段）而不是目标本身，就会出现问题。 斯科特-邓恩（Scott Dunn）写了一篇很棒的文章，讲述了与管理层突然”变得敏捷”的决策有关的陷阱（和恐惧）。它反映出它是一个简单的实现方式（如更换供应商），而不是一个需要在观念上进行重大改变的框架，这是一种错觉。 “亚马逊正在这样做。” 这些都是很好的指标，表明企业尚未明确定义为什么要使用敏捷，以及”为什么？” 与公司合作过渡到敏捷或教学认证的Scrum课程时，这是我首先要提出的问题之一。 我经常得到诸如以下的答案： 我们想迅速适应变化 我们要不断改进 我们想更定期地交付 从表面上看，这些听起来像是伟大的目标，并且与我们从敏捷方法学中期望的结果一致。 但是，即使你没有明确定义目标，但即使听起来不错的目标也会引起问题和挫败感。 你怎么知道你选择了正确的目标？ 假设我的朋友告诉我他想在未来12个月内再赚10万美元。我可能会鼓励他对这个目标进行压力测试，看看这是否是他真正想要的。 “五个为什么”是一种发现问题的根本原因的公知方法，它也可以很好地发现追求目标的根本动机。 如果我问我的朋友为什么他要这10万美元，他可能会回答说这是为了改善自己的地位，或者他说他想彻底改造自己的房屋。 如果我们再加上一个”为什么”，我们可能会发现更深层次的关于这些事情对他而言重要的内容。然后他可能会说地位对他很重要，以向他的父母证明他的成功。或者，他想进行改造，以便能在一天工作结束时回家会很高兴。 当你继续研究为什么某些重要内容时，你可以开始回顾最初的目标并提出以下疑问：这是正确的目标，并且定义明确吗？ 例如，也许我的朋友不需要10万美元就可以向父母证明自己成功了，也许他只需要一些生活指导就可以意识到自己足够好。也许他一天结束以后想要回家所需要的所有东西都是问候他最好的朋友。 一个好的目标也需要好的指导方针 经过一番讨论，我的朋友决定他绝对想要的就是现金。 他应该如何实现呢？ 他可以抢银行。或通过庞氏风格的加密货币骗局获得资金。 他应该考虑那些选择吗？ 好吧，由于我的朋友不是犯罪策划者，所以他很有可能会被抓住并失去自由。他也是一个非常体面的人，所以犯罪的想法可能会让他不高兴。 大概不是。 显然，我们认识到，除了选择正确的目标之外，他还需要想一下如何实现该目标（例如不违反法律）以及不损害对他来说很重要的事情（例如他的自由和价值观）的指南。 当你有正确的目标，但执行错误 我认识一位高级副总裁，他想利用Scrum改善协作。 对于这种敏捷框架而言，这是一个完美的目标。但是，他还认为，只有团队实际合作才能实现协作。结果，他把每个人都搬进了一个狭窄的小房间，并坚持所有的工作和讨论都在那儿进行，整个团队都参与其中。 这不仅不舒服；这也意味着以前在家里工作了几天的一名会员现在每天要往返三小时。 士气和工作质量开始受到影响。当我进来看看为什么敏捷对他们不起作用时，我首先问他为什么要改善协作。 他告诉我，他希望团队成员： 了解其他人在做什么，找出差距，或查看成员在哪里过度工作，以便他们可以互相帮助 自信而迅速地讨论问题的解决方案 以简单明了的方式相互交流 而且我们意识到，这些东西实际上都不需要任何人坐在别人旁边。 副总裁再次审视局势，意识到”协作”并不意味着必须坐一起，而且我们能够重新审视他们为实现实际目标而可能采取的不同方式。 当你忘记原因时，很容易被分裂 我与一个刚加入团队的Scrum Master一起工作。当她发现他们修改了一些规则时，在她眼中，他们没有正确地执行Scrum。作为Scrum Master，她觉得纠正团队，确保每个人都以正确的方式做Scrum是她的职责。 为此，她仔细研究了规则，强调了团队的错误并建议他们应该怎么做。但是她推得越多，推倒的人就越多，这变成了无休止分歧的有害环境。 我问她为什么强制采用这些工作方式如此重要。她回答： “因为那是我以前与以前的团队一起工作的方式，所以我们真的很成功。” 我请她描述该团队的情况，并分享她为什么认为他们在一起表现很好。 “我们做到了。即使我们犯了错误，我们也是彼此的啦啦队。我们知道彼此的长处，我们从不担心踩脚，我们真的很乐意进去并尽自己最大的努力。” 当我们退后一步时，我们发现她对规则的严格性造成了紧张、不信任和生产力下降。她的总体目标是成为一支高效能的敏捷团队，但她的短期行动与之直接冲突。 如果你想避免类似的敏捷问题，请参考以下建议： 压力测试目标并确保目标明确 如果你的组织正在向敏捷过渡，请鼓励经理在可能的情况下对这些目标进行压力测试。保持好奇：找出真正重要的内容。消除歧义性与团队协作所要实现的模糊性，这样你就可以通过自己的方法来发挥创造力，而不是被任意的规则所束缚。 考虑一下你愿意支付的费用，以及你不会受到损害的地方。团队士气重要吗？吸引更少的客户以实现承诺，提供更可靠的服务并建立更多的重复业务是否更好？ 在团队层面追求目标 我最喜欢的非敏捷书籍之一是Daniel Coyle撰写的《文化守则》。在其中，他研究了使某些团体成功的因素，并向领导者展示了如何建立凝聚力、积极进取的文化。在运动队中，他发现成功通常与团队成员做出的许多无私的传球有关，与个人如何将团队的成功置于个人荣耀之上。 我认为成功的敏捷团队也会发生同样的事情。与我一起工作的一个团队按时交付，但显然设计师天天加班。成员在计划和挑选任务时没有考虑自己的个人能力，而是开始考虑团队能力。他们认为，如果一个人在挣扎，他们会都很难受。开发人员放弃了自己的一些积压项目，花一些时间学习设计并尝试提供帮助。团队在短期内降低了速度，但从长远来看，由于他们拥有更加广泛的技能，他们开始提供更多的东西。如果他们只是专注于在每次迭代中提供尽可能多的功能，那么这种长期的进展可能永远不会发生。 敏捷是否在帮助你实现目标？ 我希望知道你的经历。目标是否明确定义和理解？还是你曾经觉得自己正在遵循以流行语为基础的商业计划？使用Scrum和敏捷解决业务问题或实现目标时，你发现什么效果很好？ 所有你的敏捷是怎么样的呢？ 是否有关注到最终目标呢？ 敏捷转型过程中你还有哪些困惑呢？ 欢迎留言讨论……

简单说就一句话，敏捷文档的特点是易于使用且易于更新。 精简文档的目的是帮助你（作为读者）找到问题的答案，而不是自己掌握详细的答案。涉及到IT系统和代码的文档时，尤其如此。代码本身应该是该问题的最好答案。文档应仅帮助指引寻找答案的方向。 打个比方，一本书的内容好比是代码，好的文档就是这本书的目录，而不是本书的摘要。目录非常简短且易于阅读，并且更新频率很低。目录通常是分层的（比如部分、章节、小节），这样查看会更快。 接下来我们看一些文档的反模式。 反模式＃1 – 没有文档 在许多组织中，没有文档是最常见的反模式。经常发生这种情况是因为他们没有阅读或错误解读了”敏捷宣言 ”的一部分， 其中说：”尽管右项有其价值。” “无文档”的相近模式是”随心所欲的文档”模式。我们还是用书的类比，没有任何文档说明你需要阅读和记住整本书（因为没有目录），才能知道在哪里能找到问题的答案。这种反模式的后果是人们需要花费很长的时间才能进入工作。这会导致信息孤岛、组件团队、局部优化、扩展困难等问题。 反模式2 – 过于详细文档 为了克服反模式＃1，一些组织认为，详细的文档就是答案。还是用书的类比，这就像写本书的摘要。问题是随着书的内容不断更新，要保持摘要更新需要大量的工作。而且一旦不更新，就无法再使用了。这意味着情况与反模式1相同。 反模式3 – 需求作为文档 这是一种奇怪的文档类型，但是某些组织将有关功能需求的详细信息保存成文档。问题在于这些需求只是增量，即系统中一个状态与下一状态之间的差异。要了解当前状态，你需要构建全部。如果这些增量中有丢失，则说明文档（需求文档）不受信任。这可能比没有文档更糟糕，因为这只会使读者感到困惑。

我什么时候不使用TDD？ Alex Bunardzic一直是有关TDD及其反对者的 Twitter 话题中的一员。他的担忧之一是TDD的支持者同意TDD并不总是合适的，但没有说什么时候不用TDD。让我们探索一下。 亚历克斯的担忧似乎在于他正试图让组织中的人员使用TDD，其中许多人提出了异议。这些异议之一是，甚至专家都说他们并不总是使用TDD，所以我们为什么要在这里使用TDD。 现在，如果您接受销售培训0^，那么您将要教的一件事是如何处理异议。第一项也是最强大的技术是忽略它们。在销售中，您可能会继续提出反对意见，这就是为什么我们很多人讨厌被出售的原因之一。 我没有卖任何东西，但似乎Alex负责在他的公司中销售TDD，所以我们可能有不同的担忧。我在写和讲授思想上的关注是可以理解的。我很乐意将决定权交给听众。如果我每月都有这么多TDD销售的配额，我可能会有所不同。 尽管如此，我确实知道有些情况下我通常不使用TDD，并且我或多或少乐于谈论它们。或多或少是因为TDD主题似乎不断地深入我的灵魂。无论如何，这里是： 我什么时候不用TDD？ 让我数一数：我*有时*不用TDD的… 当手头没有合适的TDD工具时； 当我不知道如何测试某事时； 当输出本质上是可见时（可视化）； 当程序是一个简单的，会扔掉的。 让我们通过示例进一步探讨其中的每一个情况。 当没有像样的测试工具可以立即使用时，我通常不用TDD。 一个例子是我iPad上的Codea Lua。它没有附带TDD工具，而且很长一段时间没有可用的工具。我很喜欢写一个玩玩，因为在Lua中反思很有趣，但从未真正得出我喜欢的东西。 然后出现了CodeaUnit，它工作得非常好，我最近在示例TDD会话中使用了它。但是请参阅以下部分。 另一个示例是Second Life的脚本语言LSL。该语言非常初级，不包含反射功能，这在您尝试生成一个体面的TDD框架时非常重要。如果没有可用的工具，则我用TDD的频率将比理想情况低。 但是请注意：缺少一个不错的工具并不是不使用TDD的很好理由。通常，我在Lua或LSL上的开发所花的时间要比遵循TDD学科所需的时间长。我怎么知道？我对使用TDD和不使用TDD时会发生的事情非常有经验，因此我很容易认识到缺少测试会伤害我的情况。 最好的迹象是调试会话需要更多的时间。这总是表明更多测试时我‘会做得更好。 如果工具不易使用，您是否应该考虑不使用TDD？ 我认为这不是很好的理由。几乎可以肯定的是，无论您使用哪种语言，都可以使用一个很好的TDD工具。对我来说，如果是只写一些小小的一次性程序的人，寻找和学习该工具的投资*可能*不值得。您正在专业地工作。对于您来说，投资可能是值得的。 很可能，这对我来说是值得的。在没有TDD的情况下工作会使我更经常地进入调试模式。即使对于我的小型项目，TDD的价值也可能存在。我将自己不这样做的原因归咎于懒惰，说实话而不是出于智慧。 当输出本质上是可见（可视化）时，我通常不进行测试。 在Codea / Lua中，人们经常编写一些代码在屏幕上绘制运动对象。在《第二人生》中，我经常编写脚本来在虚拟世界中移动事物。尽管这些脚本中的某些部分可能会从TDD中受益，但总会有一些-其主要功能使我不知道如何有效地使用TDD。 让我们举两个例子。 想象一下，我想在iPad屏幕上绘制一个蒸汽引擎。该图片的一部分将是引擎驱动轮，该驱动轮会随着火车的移动而旋转。推杆安装在该轮的半径中间附近。该推杆的轮端绕转0^左右。该杆的另一端在连接到蒸汽活塞的另一根水平杆的推动下水平地前后移动，该水平杆只是来回运动。 我们的任务是在轮子旋转时针对每个角度计算推杆的位置。为了弄清楚该如何做，我绘制了一些草图并做了一些几何处理（通常使用直角三角形），直到我弄清楚了在每个方向盘上的远端在哪个位置。 显然，当车轮为零时，推杆完全远离车轮，其端点为l + r，其中r为推杆圆的半径，l为杆的长度，假设车轮位于零位置。 当车轮处于180度时，终点将在l-r处。当车轮位于90或270时，终点将为…sqrt（l ^ 2-r ^ 2）。同时，如果角度为θ，则起点为 rotBy（θ）。 大概。多一点的几何使我相信终点是sqrt(l*l - y*y) - x，其中x和y是起点的相对坐标。 也许，有一种更好的方法来计算终点。它一定是某种 sin或cos (正弦或余弦)功能或类似的东西。但是这种方法很好用，因为我们有能力在两点之间画一条线。 所以我只是编写了代码，看起来像这样，没有进行大量清理： -- Loco function setup() theta = 0 -- degrees deltaTheta = 1 origin = vec2(600,600) radius = 200 rodRadius = radius/2 rodLength = 500 end function draw() background(40, 40, 50) strokeWidth(5) drawWheel() drawRod() theta = theta + deltaTheta end function radians(angleInDegrees) return angleInDegrees*math.

译者：Nikijv 审校：Bob Jiang 英文原文 一个Twitter的帖子问”敏捷”是否反管理，以及”敏捷”为什么经常看起来很像反管理。简单写一下，本文中我个人的观点是敏捷软件开发如敏捷宣言所设想的那样，并不是反管理。这比反管理更激进：这是一种完全不同的管理方法。 敏捷软件开发仍然比当今的认知更激进，相当的不幸，包括大部分品牌和方法，在我这个有点老的男人对云观点大喊大叫的时候，也被大多数较小的”敏捷”供应商所采用。 敏捷软件开发正如我们所定义的那样，对于业务与开发间的日常协作较为频繁，以维持增量的可工作软件。这样团队称为自组织团队，尤其要说明的是：最好的架构、需求、设计来自这些自组织团队。 原则上很清楚，软件、架构、设计等一切工作都源自于团队，从团队中涌现。 例如，需求不来自于一些业务单元，而是通过中央委员会进行传递，然后传递到一些传统部门或项目部门直到它落在一些程序员的办公桌上。 这不是”反”管理。这根本不涉及解决类似于预算工作、人员补偿、评估性能或者其他”管理”关心的主题。 当然，敏捷软件开发提出了一个新的、不同于软件产品制作的管理。尤其通过基于工作软件的可持续生产使用的自组织、增量、速度技术，是解决软件开发应该被管理的新方式。 敏捷是反管理的么？我不这么认为，敏捷明确反泰勒式的管理，而支持推动管理。 同样，像所有好人一样，我们更乐于好的富有成效的管理，强烈反对贫瘠、无效、有害的管理。 但是我想建议这个底线是： 如果一个组织试图通过任何传统的方式控制团队的选择，该做什么以及如何做的选择来管理敏捷软件开发，这样很可能他们做错了。 如果你是敏捷的支持者，你试图与传统管理达成某种中间状态或和解，有可能你也是没有真正理解敏捷软件开发的根本意图。 一、scrum在发光 考虑到Scrum的构想，最流行的敏捷方法如果不是最有效的，那什么是？ Scrum称为自组织的团队，包括产品负责人，被授权于全部权利和责任，负责大型组织团队的投资回报率。Scrum团队中Scrum开发者的开发团队，必须包含交付产品增量的”全部必要技能”，一个被集成、测试过的、可工作软件包括团队迄今为止产生的所有价值元素。 Scrum承认Scrum团队是嵌入式的，以某种方式，在一个组织中，组织提供了资金（投资），干系人关心Scrum团队做了什么。敏捷团队通过每个冲刺向干系人展示他们已完成的工作，邀请并听取干系人的意见。Scrum团队与全权负责的产品负责人决定下一个冲刺做什么以及怎么做。 冲刺审查是Scrum团队及其嵌入组织之间的完整接口。 关于Scrum仍然有些问题没有解答，同样这些问题在上面Twitter的帖子中也涉及到了。Scrum不会告诉你如何预算，如何决定补偿，如何评估性能等等。 在Scrum课程中，人们经常询问各种管理职能。有个经典实践可以回应，课程上小组在便利贴上写下他们能想到的所有管理职能。他们可以把这些便利贴放到下面4个位置：开发团队，产品负责人，Scrum教练以及其他。 将会有两件事发生。首先，许多传统管理职能转移到一个或多个Scrum团队元素。由团队分配任务，由产品负责人决定要构建什么，由Scrum教练支撑和引导等等。有趣的一点是，总有些管理职能被贴到其他堆中。Scrum甚至不会建议如何做这些：这已经超出了Scrum的范围。 然而，很明显，Scrum打算不管这些超出范围的管理职能是什么，它们与团队的首要接口，可能只通过冲刺审查。尤其是除了产品负责人，没有人可以要求团队做任何事情，Scrum对”经理”在Scrum团队运行时可以做什么做了非常具体的限制。 二、敏捷软件开发是反管理么 敏捷软件开发需要一种新的管理方式，在团队规模上，团队内部拥有对产品的所有权利和责任，而且最主要的接口是检查实际演变的产品。 不一定是”反管理”，但一定与某些类型的管理背道而驰，尤其是源自于泰勒主义更具有侵入性的形式——福特主义，将工作视为机器，工人几乎没有权利或仲裁。尽管敏捷软件开发肯定要求从团队内部而不是外部应用这些概念，但与戴明和统计过程控制等概念的对立程度要小得多。 但我觉得主要的概念已经相当清楚：敏捷软件开发是一种完全不同的管理方法，尽可能的把权利和责任下放给团队。这种管理方法对于如何走得更远没有设置上限，但它设定了一个相当严格的下线，这个下线是嵌入在团队内部的产品做什么以及如何做。 三、这些想法的限制是什么 这很难说。我们通过敏捷团队的成长能力去决定谁在团队谁不在团队，这对薪酬和评估有很大影响。我们开始听到团队中的谁直接与客户合作，客户有时基于固定价格安排，或者更常见的基于运行速率为产品提供资金。 今天，更多的限制是被组织强加的——试图做”敏捷”，这些限制中有很多是明显错误的。有时组织没有从战略上很好地理解最好的管理是如何的。我通常认为,个人管理结构应在敏捷之前就位：不同的团队成员”属于”一个或另一个经理,而该经理则继续尝试对团队成员的行为进行控制。 坦白讲，自组织团队被授权，而这导致冲突、混乱以及很多时候应该做敏捷组织主要来源走向黑暗敏捷。这个观点是正确的。 底线，敏捷软件开发提倡不同的管理方式，很可能与一些过时的管理观念不相容，不幸的是，这些观念在今天仍然相当普遍。 反对的？不。完全不同？是的。 原文链接

日期：2019年3月27日 今天和朋友聊天的时候，提到了一个问题（也是我在CSM敏捷认证课程中碰到的问题）。 通常我会在课程上做几个简单的调查： 有多少人是开发者？ – 不会超过1/3 有多少人看过敏捷宣言？ – 令人惊讶，比例低到吓人 尽管有很多学员说我们已经在实践敏捷（其实他们的原话是，在推敏捷），但没有看过敏捷宣言。这个着实让我意外。 和朋友一起分析了一下，为什么开发者不会关心敏捷。原因如下： 刚入职场的开发者，焦点在如何快速提升技术能力上，如 python, react, vue 等 大概3-5年的开发者，至少都是开发组长（team leader）。这个时间点最应该来看一下敏捷，但是这个时候也是这个人最忙、最挑战的时刻。天天忙到焦头烂额，到处擦屁股，开会………… 提升到管理者之后，身背绩效指标，就一个目的，完成绩效是第一位，其他都要让步。（所以短期目标和长期目标之间，一直在选择短期目标，没有时间选择长期目标） 所以综上，敏捷是作为一名开发者最应该了解学习的技能，它完全可以融入到日常工作中去。 如果你是开发者，你了解过敏捷吗？ 你认为敏捷是什么，你工作中有哪些地方用了敏捷？对你的工作帮助大吗？ 如果有问题，欢迎大家通过issue进行讨论 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。 转载请注明出处！ 关于作者 BoB Jiang 和BoB面对面学习Scrum HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档