最近很多初学者问什么是敏捷软件开发。发现自己一两句话解释不清楚，就索性写了一篇文章。敏捷就是快速反应，为什么要快？看看这么多996公司就知道，市场变化越来越快，客户要求也越来越高。为了满足用户的需求，他们每周发布一个版本。我们一个人坚持三个月，怎么能不被打得满地都是？问题是如何快速响应？先来看一个场景：1、残酷的现实。软件开发的主要问题之一是客户心目中的需求难以描述。出来吧，我们通常的应对方式是这样的：先花几个月整理需求，天天跟客户讨论，画几百页流程图，写几千页文档，最后把客户搞糊涂了。接下来是详细的设计、开发、测试，我们强大的技术团队开始调动，一切都严格按照计划进行，一切看起来都很完美，看来项目很快就要圆满结束了！但是客户的验收测试给了我们一个打击：这个界面为什么少了一个选项？为什么不能重定向接口？该功能需要领导者的后门。另外，为什么我的业务规则不能更改？什么？它是否硬编码在代码中？根本不管用！每个人都很沮丧，几个月的努力似乎付之东流。从这个场景可以看出，我们从客户那里得到的需求描述和需求文档，其实和客户真正想要的软件相去甚远。在瀑布开发模型中，验收测试发现的问题纠正起来代价非常大。2.改进一个想法自然而然地产生了：为了避免最后出现习惯性崩溃，能否让客户经常做验收测试？让他们经常使用一个可以工作的软件，从而告诉我们哪里还存在不足？什么地方出了错？这样我们就可以快速修改，这样我们就会轻松很多！我们可以把软件开发分成小的开发周期，比如每个周期持续两三个星期，在这两周的几天内完成一个或几个功能，然后让用户试用。如果有问题，我们会第一时间反馈，我们会在下一个开发周期第一时间改正。这样才能逐步接近客户的最终目标。这还带来了一个额外的好处，无需花费大量时间分析和整理冗长的需求文档。听起来很美，不是吗？但是仔细想想，这里的问题也不少。1.摒弃了冗长的需求文档，但还是要描述需求。有必要发明一种简单的描述形式，主要用于促进客户与开发团队之间的沟通。这种新形式称为用户故事。这是用户故事的示例：这是一张卡片，背面记录了需求的讨论和验收标准。用户故事主要突出：谁做了什么，带来了什么商业价值。2、如何决定每个小开发周期开发什么（我们称之为迭代）？用户故事必须有一个估计和一个大小。如果太大，一次迭代开发不完，就必须拆分。我们需要按照优先级对需求进行排序，按照优先级从高到低的原则进行开发。3.不想设计架构？上来的时候，按优先级选择需求，直接进行迭代开发，把架构师放在一边，合适吗？架构的工作肯定还是要做的，在正式的迭代周期开始前就需要架构设计。但与设计一个全面的架构设计不同，我们需要一个随着迭代的进行而进化的进化架构。4.详细设计怎么样？在每次迭代开始时，团队将这些用户故事拆分成小任务。这个拆分过程相当于详细设计。对于一些特别复杂的，比如算法，当然可以写文档帮助大家理解。5、既然是迭代开发，在本次迭代周期中难免要修改上一次迭代周期的代码。如何保证原有功能不被破坏？不能每次都手动重测吗？这绝对是一个很大的难度，答案是自动化回归测试，包括单元测试和功能测试。开发人员在编写代码的同时，还需要编写自动化的单元测试。测试人员需要开发自动化的功能测试，这样一旦代码被修改，就可以运行它们来检查现有功能是否被破坏。像持续集成这样的基础设施是必不可少的，每一天，每一小时，甚至每一次代码提交都会触发编译、打包、部署、测试等流程。6、这么短的开发周期，测试人员如何测试？开发和测试需要同时进行。开发在明确需求的时候，需要测试参与。开发是编码，测试人员是写测试用例，等待一个用户的故事开发好后，可以马上投入测试。7.开发和测试之间似乎需要紧密协作。他们如何沟通？必须是面对面的交流。有什么问题就到对方座位上去问。大家最好坐在一起，转头就可以商量。、尽量减少使用效率低下的电话、QQ/微信等工具。开发团队每天召开15分钟站会，展示自己的进度和计划，保持进度透明，及时暴露问题，解决问题。8、客户什么时候可以验收？任何时候都欢迎，但我们更希望迭代结束后，此时功能稳定。我们会给客户演示，告诉他这次迭代完成的工作，并邀请他测试软件，给我们反馈。当然，客户可能会发现问题，甚至提出新的要求，我们对此表示欢迎，我们要与客户合作，而不是对抗。除了给客户做示范，我们也会反省自己，看看哪里做得好，要继续保持下去；做的不好的地方要继续改进。您可能明白这种漂亮的迭代开发方法并不容易实现。如果给它起个名字，可以叫：敏捷软件开发。【本文为专栏作家“徐磊”原创稿件，转载请通过作者微信公众号devopshub获得授权】点此查看该作者更多好文
