几年之前我还是个野生程序员的时候，对“敏捷”这个词是有些抗拒的。那时候，要么是没有想法、懒得去理会，要么就是主观上拒绝：
肯定又是些无所事事的人弄出来的无聊概念，帮他们自己刷存在感的东西
敏捷，就是那些咨询公司弄出来给别人洗脑的，理念太空，根本无法落地
那些一大堆概念都是些什么鬼？条条框框太多了，运作起来太麻烦了
不用敏捷，我们现在不也挺好的吗？敏捷跟我有什么关系？
但后来我却选择加入了 ThoughtWorks，这个传说中的敏捷大本营，一方面因为很多出名的书都是 ThoughtWorks 的人出的，另一方面也想亲入虎穴一探究竟。而如今，历经敏捷项目的洗礼，我已经成为专职的一线咨询师，为众多大型企业提供敏捷转型过程中的技术指导。
1他们
在一些朋友看来，我自从换了工作，就开始在群里转发一些敏捷相关的文章，发表一些感言。在转发这些内容的时候，我经常用到的叙事口吻是“他们”：
他们的代码真的写了好多测试。
有时候要开一整天的会，我真不知道他们是怎么撑下来的。
感觉跟着他们一起做测试驱动开发好像没那么难。
这段时间里，我让自己成为一个“警惕的观察者”。不管是主观上的警觉，还是故意在外人面前将自己打造成这样的一个形象。生怕在我还没有觉察到的时候就已经被敏捷洗脑了；同时也希望在曾经的好友面前以尽量理性、中立和客观（理中客）的形象示人。不过，这不妨碍在他们看来，我已经被洗脑了。
后来我了解到，这如同学习新知识过程“守破离”中“守”的阶段。“守”的过程既是获取新认知的过程，也是与过去的认知做比较和更新的过程。观察现象——对比质疑——私下学习——拨开疑云，大体就是这样的不断重复，在不断了解新实践的过程中，也同步去认识它、理解它。
渐渐地，一系列疑问得以解答，使得我最终接纳了敏捷开发思想，并认为它是适用于现代开发团队中的工作方法。
2疑问
在过去我待过的团队中，一直有两个无法解答的问题。那时作为技术经理，我经常被别人问到一些无法用自己经验回答的问题。
做完这个功能，你估计需要多少时间？
为什么大家在办公室显得很安静、气氛有点压抑？
在成功学的洗脑课程中，有一句被强调最多的话：“失败一定有原因，而成功一定有方法！”那么，我们过去回答不了的上面这些问题，也回答不了由它们导致的管理上的难题，其根本原因又是什么呢？获得管理上成功的方法又是什么呢？
我带着这两个问题离开了之前深度参与的创业项目。与朋友分享了要探索新征程的想法之后，他真诚地邀请我加入他的创意，并希望由我来带领团队一起续写新的故事。我猛然间发现，其实虽然之前在团队里担任所谓技术经理的职位，但我真正给团队带来的帮助似乎更多的只是一个有经验的工程师给新手的指导。那时候，第三个疑问产生了：
如何去做好一个团队带头人？应该安排团队成员每天做什么？
这些疑问不得到解答，我就如同掉下井底的青蛙，虽然能听见外面世界的声音，却只能看到井口大小的世界。
3答疑
加入新团队后不久，这些疑问就完全得到了解答。
第一个要实现的需求就是一个“明星”功能，集成第三方系统的调查问卷。团队很快组织了需求计划会议，并细致地过了一遍第一期要完成的目标、实现这个目标要包含的业务范围、具体又包含哪些步骤（用户故事）。
目标：发出问卷链接，并将数据收回来。
范围：选取模板、发送链接、收回数据、发送提醒邮件
步骤：
管理员在外部系统中创建好模板（不需要开发）
用户可在 XX 页面中使用选项来选择问卷模板（系统自动将外部系统中的模板名字同步到本地系统）
用户可在 YY 页面中使用链接发送调查表单，客户收到包含链接的邮件
系统自动将外部系统中收到的数据同步到本地系统中以供使用
如果没收到提交数据，系统自动在7天后自动发出提醒邮件，客户再收到一封包含链接的邮件
接着开发人员和测试人员对还不够详尽的细节提出问题，讨论获得一致，一起对各个步骤大致估计所需时间。每个用户故事并不确定由谁来做，而是大家一起就其中的细节进行讨论，并就所需时间形成一致：有的人说需要 3 天，有的人觉得 2 天就够了。他们会叙述自己的想法，并最终达成共识。
这项活动，以及之后的迭代过程中，基于这个会议的开发过程解答了我第一个疑问。
他们有一个角色叫BA，会写一个个的用户故事来描述需求，一两天就可以完成一个故事。明确的前提条件和验收标准（从哪里开始做，做到哪里为止），让开发工作变得有节奏感，需求不清楚的时候随时就这个需求的范围进行讨论。
相比于拿别的产品做个演示，甩一句“就照这个做”，然后就天天催进度、做出来之后又说不对劲的产品经理，有一个专门负责业务、随时可以叫过来讨论的BA让开发人员感到倍感轻松。
江湖上传言说敏捷不需要文档，原来是谬误。敏捷并没有说不需要文档，只是说认为团队成员之间的沟通协作比详尽的文档更重要。所以，用户故事仍然是会包含必要的描述内容的。要写清楚为什么要做这项功能以及验收标准等。
团队一起估计时间的过程，不光可以消除特定人估计时的无助感，更重要的是它让所有人都了解用户故事的细节，在后续开发中谁都可以参与开发。
相对较小的用户故事，估计起来要比一整个功能（比如对整个调查问卷功能进行估计）估计起来靠谱得多。即使有特定的用户故事估计不准确，其影响范围也是可控的。
把所有故事的估计时间相加，即为整个功能所需要花费的时间。
估计只是帮助做计划的一种方法，在后续开发过程中，如果发现比当初估计的要复杂，或者简单的情况，需要与 BA、PM 等角色一起更新这个估计值，从而帮助团队及时完善一开始制定的迭代计划（如果必要，可以加入一些、减去一些或者修改一些）。
这样，我发现开发团队的时间原来是需要管理的，而管理时间这件事其实也需要花些心思才能做好。这时候，如果你问我某项功能需要多久做好？我会告诉你，让我来拆分一下功能，粗略估计就成为了可能。
而后面的其它疑问也很快得到了解答。
关于团队气氛，如果一个团队里每个成员都在闷头做自己的工作，独自面对自己的交付压力和技术挑战，成员之间互相帮不上忙，他们的气氛一定不会太好。而如果所有人通力配合工作在相同的功能上，一起理解消化业务，一起解决技术问题，共同做技术决策，并分担解决缺陷（BUG）的责任和压力，那么团队的气氛怎么会不好呢？
最后一个问题，关于团队。
团队里大家的角色是如何分配的，规模又应该多大？团队之间应该如何配合？这就不难回答了。
典型的业务功能团队以及后来出现的微服务团队，都很好的诠释了团队结构和规模问题。有一个论述产品设计和组织结构关系的康威定律，值得我们深入思考。团队带头人？我突然反应过来，一定要有这个角色么？如果大家都能很好地运作了，那其实这个所谓带头人的作用是很淡化的，这也就是所谓的自组织团队了。如果一定要一个带头人，那他的职责一定是确保这样一种自组织的机制在团队中持续地运作下去。
4所以，我被洗脑了吗？
也许你可以这样认为。
我现在是接受了敏捷思想的，其中还有一些工具和方法，我还在持续学习过程中。不过，“洗脑”这个词本身其实具有一定的预设立场，它是那些质疑者的说法。
那么，重新回到问题本身。敏捷是什么呢？它会将人们洗脑吗？
敏捷不是什么宗教，它只是一种生产软件的思路，一种倡议。它倡议，通过加强团队成员间的交流协作，尽快交付高质量、有价值的软件，让团队以良好的响应性来拥抱软件的变化。为了符合这种思路，它一般又会有一些典型的实践方式。我们可以说哪些实践是由敏捷方法所推荐的，因此是“敏捷的”；而哪些实践是不推荐的，因此是“不够敏捷的”。但不会说哪种是好的，哪种是不好的。
比如，敏捷的：
自主提交代码，尽早集成；
自动化一切，包括环境初始化；
代码由团队共享，随时重构和优化。
不敏捷的：
逐次代码提交都需要他人审查并批准的管控；
手动部署生产环境；
不让他人修改自己编写的代码。
但这些“不敏捷”的条目，基于团队具体情况，可能实际操作起来更可行，就可以根据目前的阶段去施行，并向着更敏捷的方向去持续改进。类似的还有，敏捷不会说团队一定要开站会，站会一定要在早上开等等……相反，如果要求团队一定要做某件事，其实它与敏捷思想是背道而弛的。我们应该遵循敏捷理念去对实践进行改良，以适应团队实际情况。
事实上，“敏捷”一词来源于英语 Agile，这一英文词汇也类似于中文中的形容词“敏捷”一词，其适应性相当广泛。人们往往用它来形容业务的灵活性，思路的开放性等。
因此对于敏捷来说，并不存在什么洗脑不洗脑的说法。它只是一种风格，一种态度。只要你运用这种思路和风格去让团队协作越来越好，开发出来的软件质量越来越好，那就是敏捷的。敏捷中典型的具体实践方法有 Scrum、XP 和 Lean 等。此外，近年被广为谈论的 DevOps，也已经成为了敏捷软件方法的典型实践。
原文发布时间为：2018-07-21
本文作者：陈计节
本文来自云栖社区合作伙伴“DBAplus社群”，了解相关信息可以关注“DBAplus社群”。
