白话敏捷软件开发

最近有不少初学者问什么是敏捷软件开发， 我发现一两句话也说不清楚， 索性写一篇文章。

敏捷的意思就是反应迅速，  为什么要反应迅速？  看看那么多996公司就知道了，  市场变化越来越快，客户要求越来越高，  为了满足用户的需求，  人家一个星期发一个版本， 我们仨月才能憋出一个来 ， 那还不被打的满地找牙？

问题是如何才能反应迅速？  先来看一个场景：

1

残酷的现实

软件开发有一大难题就是客户脑子中的需求难于描述出来， 我们通常的应对方法是这样：

先花上几个月整理需求， 天天和客户座谈， 画出几百页的流程图， 写出上千页的文档， 最后把客户都快搞晕了。

项目经理

这是您要的软件需求吗？

（看到这么多的文档） ： 嗯， 应该是。

客户

项目经理

那就请您在需求确认书上签字吧

（心里犯嘀咕， 但是一想，反正是我先给你个首期款，怕啥？ ） ： 签就签！

客户

项目经理

（非常高兴的宣布）需求分析阶段结束了， 项目成功进入下一个阶段： 概要设计！

然后是详细设计， 开发， 测试，  我们强悍的技术团队开始发动， 一切都严格按照计划进行， 一切看起来都很完美， 看来项目马上成功结束了！

但是客户的验收测试给了我们当头一棒： 这个界面怎么少了一个选项 ？    那个界面怎么不能跳转 ， 那个功能需要给领导一个后门， 还有， 我的业务规则怎么不能改？  什么？ 在代码中写死了？  唉，你们做的系统啊， 根本就不能用 ！

每个人都很郁闷， 几个月的辛苦开发看来要付诸东流了。

从这个场景中能看出的是，  我们从客户那里得到的需求描述和需求文档， 其实离客户真正想要的软件还差的很远。 

在瀑布式的开发模式下，验收测试发现的问题，要想改正代价是非常高昂的。

2

改进

一个想法自然而然就浮现出来： 为了避免到最后习惯性崩盘，能不能让客户经常性的做验收测试？ 

让他们经常性的去使用一个可以工作的软件， 从而告诉我们那些地方还有欠缺 ？ 那些地方做错了？  这样我们可以迅速的修改， 这样我们就会轻松多了 ！

我们可以把软件开发划分成一个个小的开发周期， 例如每个周期就两三周时间， 在这两周之内我们完成一个或几个功能， 然后就让用户去试用， 有问题立刻反馈，在下一个开发周期马上改掉。 这样就可以逐步逼近客户的最终目标。

这还带来了一个额外的好处， 不用花费巨长的时间来分析，整理冗长的需求文档了。

听起来很美是不是？  但是仔细想想这里边的问题很多。

1.  抛弃了冗长的需求文档， 但还是得描述需求啊

需要发明一个简单的、主要用来促进客户和开发团队沟通的描述形式，  这个新的形式叫做用户故事， 这里有个用户故事的例子：    

这是一个卡片， 背面还会记录下针对需求的讨论和验收标准。

用户故事主要彰显的是： 谁做了什么事， 带来什么商业价值。

2.  怎么决定每个小开发周期（我们称之为迭代吧）要开发的东西？

用户故事得有估算， 得有大小， 太大了一个迭代开发不完 ， 还得拆分一下。

我们需要对需求按照优先级进行排序， 按照优先级从高到低的原则来开发。

3. 不要架构设计了吗？

一上来就按优先级选择需求， 直接进入迭代开发， 把架构师撂在一边，合适吗？

架构工作肯定还是需要的，在正式的迭代周期开始之前需要架构设计， 但是和设计出面面俱到的架构设计不同， 我们更需要演进式的架构， 随着迭代的推进而进化。

4. 那详细设计怎么办？

在每个迭代开始的时候，团队在一起把这些用户故事给拆分成一个个小的任务， 这个拆分的过程就相当于详细设计了。  对于一些特别复杂的，例如算法， 当然可以写文档，帮助大家理解。

5. 由于是迭代式开发， 这个迭代周期修改上一个迭代周期的代码在所难免， 怎么保证不破坏原有的功能？ 总不能每次都手工重测一遍吧？

这个绝对是一大难点， 答案就是自动化的回归测试， 包括单元测试和功能测试。

开发人员写代码的同时，也要写下自动化的单元测试，   测试人员需要开发自动化的功能测试， 这样一旦有了代码的修改，就可以运行它们， 检查现有功能有没有被破坏。

像持续集成这样的基础设施是必不可少的，   每天，每小时，甚至每次代码提交都会触发编译，打包、部署、测试这样的过程。

6.  这么短的开发周期， 测试人员怎么测试啊？

开发和测试需要同步进行， 当开发在澄清需求的时候， 测试需要参与， 当开发在编码的时候， 测试人员在编写测试用例，等到一个用户故事开发完，马上就可以投入测试。

7. 看来开发、测试之间需要紧密的协作， 它们之间怎么沟通？

肯定是面对面的沟通， 有问题就跑到对方的座位那里去问，大家的座位最好在一起， 扭头就可以讨论，   尽可能减少效率不高的电话、QQ/微信等工具的使用。

开发团队每天都开一个15分钟左右的站会， 展示自己的进展和计划， 让进度保持透明，  及时暴露问题，解决问题。

8. 客户什么时候可以做验收测试？

随时欢迎， 但是我们更倾向于迭代结束以后， 这时候功能会稳定下来， 我们会给客户做一个演示， 告诉他这个迭代完成的工作， 邀请他也测试一下软件， 给我们反馈。

当然客户可能会发现问题， 甚至提出新的需求， 我们表示欢迎， 我们要和客户合作，而不是对抗。

除了给客户演示之外，我们自己还会反思一下，看看有那些地方做的好，要继续保持；  那些地方做的不好， 要持续改进。

估计你也明白了，这种看起来很美的迭代化开发方法实施起来挺不容易的， 如果我们给它起个名字的话， 可以叫做：敏捷软件开发。 

你看到的只是冰山一角， 更多精彩文章，参见《码农翻身文章精华》

公众号：码农翻身

“码农翻身”公众号由工作15年的前IBM架构师创建，分享编程和职场的经验教训。

编辑推荐

掘金是一个高质量的技术社区，从移动开发到架构设计，编程语言到开源类库，让你不错过互联网开发的每一个技术干货。长按图片二维码识别或者各大应用市场搜索「掘金」，技术干货尽在掌握中。