软件工程 - 敏捷开发

阅读文章大约需要3分钟

一、关于敏捷开发

敏捷以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件开发在构建初期被切成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个互相联系，但也可独立运行但小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发通常有以下几点：

• 敏捷开发就是scrum、极限编程；
• 敏捷开发就是每天站立会议、每两周一个sprint（字母意思是冲刺，可以理解为迭代）；
• 敏捷开发就是把需求变成故事，把故事写在便签上贴到白板，然后根据状态移动到不同的列；
• 敏捷开发就是用看板软件来管理项目。

要理解敏捷开发，我们要了解其诞生背景。在2001年那会，瀑布模型还是主流，我们知道，瀑布模型是一种“重型”的开发模式，整个流程走完通常周期很长，少则数月，多则数年，长周期导致风险增加、难以响应变化。
敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。

二、敏捷开发的路线

1.测试驱动开发
它是敏捷开发的最重要的部分。我们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的story，记录在story Card上。然后两个人同时在电脑前，一个人依照story，从业务需求的角度来编写测试代码，另一人看着他并且进行思考，如果有不同意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。

2.持续集成
在以往的软件开发过程中，集成是一件很痛苦的十七，通常很长时间才会做一次集成，这样的化，会引发很多问题，比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如次频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即时集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试、包括单元测试、功能测试；确认编译和测试是否通过，最后发送报告。当然也会做一些其他的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有个火山灯用来标志集成的状态，如果是黄灯，表示上一次通过，开发这时候获得代码是可用而可靠的；如果显示为红灯，上一次集成未通过，需尽快定位失败原因从而让灯变绿。

3.重构
相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》、Joshua的《从重构到模式》、《重构-改善既有代码设计》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。

4.结对编程
在敏捷开发中，做任何事情都是Pair的，包括分析、写实现代码或者重构。pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在公司，还有很多事都是pair来做，比如学习、翻译、做PPT。

5.站立会议
每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1.你昨天做了什么？ 2.今天要做什么？ 3.你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。

6.小版本发布
在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快适应。

7.较少的文档
其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应来客户的需求以及系统API的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug 要高效。如果用书面文档或者注释，某天代码变化来，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化来，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得代码不加注释对话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。

8.以合作为中心，表现为代码共享
在敏捷开发中，代码是归团队所有而不是哪些模块对代码属于哪些人，每个人都有权利获得系统任何一部分对代码然后修改它，如果有人看到某些代码不爽对话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。

9.现场客户
敏捷开发中，客户是于开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快的速度得到客户的反馈。

10.自动化测试
为来减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言，自动化测试工具，能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作，包括Selenium开源项目。

11.可调整计划
敏捷开发中的计划是可调整的，并不是像以往的开发过程中，需求分析-概要设计-详细设计-开发-测试-交付，每一阶段都是有计划的进行，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。
敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。

三、敏捷开发解决了什么问题

如果你读仔细了敏捷宣言，你会发现，宣言中右边的内容其实都是瀑布模型核心的内容：流程和工具、详尽的文档、合同谈判、遵循计划。
虽然敏捷开发并未对瀑布模型的价值进行否定，但也表明了瀑布模型做的还不够好，同时提出一套自己的价值观。
比如说，我们开始做一个新项目，需要从客户那里收集整理需求，如果按照传统的软件开发模式，我们需要在开发前获得所有需求，然后和客户签订合同，在发布前都不会轻易修改需求。
但是如果我们采用敏捷开发模式开发项目，那这样做显然违背敏捷的价值观：“客户合作高于合作谈判”。
所以如果是敏捷开发，在每个迭代后，都应该向客户收集反馈，然后在后面的迭代中，酌情向客户收集反馈，然后在后面的迭代中，酌情加入客户反馈修改的内容。
结合敏捷开发提出的背景，你其实不难发现，敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题，用一种轻量的，敏捷的方法来改善甚至是替代它。
这些年敏捷开发也是一直这样做的。瀑布模型的典型问题就是周期长、发布烦、变更难，敏捷开发就是快速迭代、持续集成、拥抱变化。

总结、

敏捷开发是一套价值观和原则。对比瀑布模型和敏捷开发，差异还是很大的，瀑布模型面向的是过程，而敏捷开发面向的是人。敏捷开发要解决的，恰恰是瀑布模型中存在的一些问题。
在要不要使用敏捷开发的这个问题上，不用过于纠结，看好敏捷开发，那就放心去用，觉得时机还不成熟、还不够了解，就先试点或者只是先借鉴其好的实践。
软件开发，最核心的是人，而不是用什么方法，以前没有敏捷开发只有瀑布模型的时候，也一样诞生了很多伟大的软件，像Windows、office。现在有敏捷开发，更多的是让我们多了一些选择。