科技战“疫”| 软件开发如何提升响应力，一文快速读懂「敏捷开发」

根据在线统计数据门户网站Statista数据显示，2018年，超过90%的软件开发采用敏捷开发（Agile Development）方式。那么究竟什么是敏捷开发，它又具有怎样的特点和优势呢？

本期极客专访中，哥白尼有幸采访到了李小波老师，就让我们跟着作为敏捷教练的他，一同走近敏捷开发，了解敏捷开发的奥义吧。

嘉宾名片

曾担任过敏捷咨询师、培训师、团队教练；曾就职于ThoughtWorks、神州数码等公司；服务过华为、DJI、汇丰、顺丰、京东等客户。

具备10年软件产品交付经验，有丰富的Web、移动端软件研发经验，担任过开发、TL、产品经理等角色。

精选问答

1
可以请您简单地介绍一下什么是敏捷开发吗？
李小波老师：

90年代，流行的软件开发方法论比较重，文档多，开发周期长，而且最终的成本、进度、质量大多不太令人满意。因此有人提出了轻量级的软件开发方法Scrum、极限编程、水晶方法等等。2001年，提出这些方法论的17位软件工程界泰斗在美国的雪鸟山庄组织了一场聚会，最终得出了2个东西：敏捷宣言（价值观）和敏捷的12条原则。

普遍认为敏捷分为三层：

上层- 价值观和原则。这一层比较务虚，没有教人具体的做事方式。

中层- 方法论。目前敏捷落地主流有2个方法论：Scrum和极限编程。方法论会告诉你团队怎么组建，角色分工，怎么进行协作。

下层- 实践。每个方法论里有诸多实践，包括需求管理，项目管理，配置管理和质量保障这几个方面如何落地。

现在的敏捷被泛化了，同时又在提大规模敏捷、业务敏捷等，甚至延伸到了软件研发领域之外，例如HR，市场销售领域等。Scrum方法论其实是一个通用的方法论，市场、内容等团队都可以采用。

我个人总结敏捷的三大特点：

聚焦价值 – 始终做最有价值的事，用最少的投入获取最大的回报；

持续改进 – 消除浪费，持续提高效率和质量；

以人为本 – 充分激发和赋能团队中的人。

2
如今很多人都在提敏捷开发，可以说一下敏捷开发为什么会这么流行吗？
李小波老师：

现在说敏捷流行，主要是说市场和客户愿意买单。

那么追根溯源，为什么企业要去做敏捷？

敏捷对企业有好处。

对外：提升用户的满意度
过去的管理方法更追求的是利用率，就是别让「资源」闲着，这个资源主要就是团队中的人，并且让专业的人做专业的事，这样效率才最高。

那为了让大家不闲着，就得让每个人的任务栏始终不空着。让专业的人做专业的事，就把工作越分越细，成立更多的职能部门。

结果呢，从客户的视角看，我提出一个需求，在各个环节都要等待（因为每个人的任务栏都是满的），而且环节又多，每个人都在忙，每个人都有自己的KPI，只管自己的一亩三分地，把我的需求当皮球踢，根本没有响应力。

敏捷的核心思想是：

在响应力和利用率之间，更倾向于响应力。

响应力高的表现是什么呢？

客户提出反馈说网站xxx功能不好用，需要改进，从他提出来改进意见到功能上线可使用，其中的周期越短，说明响应力越强。

为什么要提高响应力？因为现在市场变化快，包括竞争对手的变化、新技术出现、新政策等等。在所谓的VUCA（易变，不确定，复杂，模糊）时代，响应力就是竞争力。对客户的响应越及时，客户留下来的意愿就越强。敏捷中很多的实践就是帮助团队去提升响应力，在更短的时间内，把一个东西呈现在客户面前，以便获取用户的反馈，持续迭代改进。

回到软件开发上，以前那些非常重的方法论，接到一个需求后你要写冗长的需求分析文档，做大而全的设计，包括概要设计、详细设计，然后再编码、测试，这个过程周期太长，客户就会心生不满。

敏捷开发是轻量级的，客户提出反馈，团队内的工程师，或者需求分析师直接与客户交流，理解客户的痛点，马上开发出一个最简单的版本给到客户用，了解客户使用感受，然后再不断地迭代。这样客户有参与感，响应时间缩短，客户更加满意。

对内：降低成本
创业公司，初期可能会牺牲一点成本去追求响应力，成立特攻队，每个人都是一专多能的“特种兵”，所有人聚焦在同一个目标上，快速地完成产品，去验证想法，去占领市场。等用户数量提升后，再获取收入，降低成本，滴滴出行、共享单车无不如是。

已经上轨道的业务，用的资源越少，就有越多的资源去做新的业务。

敏捷中有许多降低成本的实践，比如：聚焦更有价值的需求。都知道开发产品有些功能都是拍脑袋提出来的，并不知道其实际价值，敏捷提倡的是别一来就做很大的软件，先把核心流程搞出来，让用户去用一用，然后通过反馈得出什么是最有价值的部分，再把精力放在更有价值的地方，这样成本就可以降低。

还有大量的自动化实践，包括自动化测试、持续集成、自动化部署等等，都可以大大降低成本，释放产能。

3
敏捷开发中每个角色的职位和分工都有什么样的作用呢？
李小波老师：

不同方法论有着不同的角色定义。

以Scrum为例，包含三个角色：

Scrum Master：帮助团队导入Scrum的专家，相当于团队的教练，让团队将Scrum很好地运作起来。

Product Owner：出预算的人，TA管理团队的待办列表，包括条目和优先级。

Development Team：开发团队是一个端到端的全功能团队，包括前后端、移动端、UI设计、需求分析、运维等等，但是开发团队里的角色就不会分得那么细，最好每个人都是多面手，响应力才会高。举例：如果当前有很多功能堆积在测试环节，一味地开发更多功能，并不能增加团队的产出，所以这个时候应该大家都戴上测试的帽子，去做测试，将瓶颈给消除掉。

有了三个角色，再加上三个工件，五个事件，五个价值观，团队就能形式上敏捷起来了。

4
敏捷开发与瀑布式开发、迭代式开发有什么区别和共同点呢？

from Martin Fowler

李小波老师：

敏捷宣言签署人之一的Martin Fowler画了这张图，这几个概念的关系就显而易见了。

这张图中首先是两种计划的方式，预测型计划和适应性计划。

预测型计划：传统的计划方式，典型的表现形式是甘特图，提前计划好什么时间做什么事情，A依赖B，B就要放在A的后面。

适应性计划：环境越不确定，越需要边走边看，这时过于详细的计划，就是浪费。较好的做法是，做一个比较粗的计划，把近期的计划做细一点，然后定期去回顾并调整计划。

预测型计划适合打靶子，适应性计划适合猎豹子。

根据此图可以得出：

瀑布开发是典型的预测型计划，跟敏捷没有半毛钱关系；

迭代开发也不等于敏捷，它也可能包含预测型计划，尤其是传统企业敏捷转型时，在旧的预算机制和考核机制下，还是非常重视「预测」；

不是做了适应性计划就是敏捷，要聚焦价值，持续改进，以人为本。

5
敏捷开发适用于任何一个项目吗？
李小波老师：

适合不适合，就像是有60分及格的标准在那，这个60分的标准很难定义的。只能说哪些项目更适合，哪些项目用了敏捷后收益更高。

哪怕是同一个项目，在不同的阶段，收益也不同。

前三个月团队对产品和市场，对团队整体产能都知之甚少，就要更敏捷一些，但是通过前三个月已经得到许多洞见了，很多事情相对确定了。

最重要的是，动态发展地看问题，持续改进，不僵化。

大胆地试，大胆地改造，找到适合团队现阶段的实践。

6
在团队中实施敏捷开发会面临什么样的挑战？
李小波老师：

实施敏捷开发面对的挑战，可以从2个维度去看。

一个是人的维度，一个是事的维度。

人：

敏捷的环境下其实对于人的心态，要开放、要学习、要拥抱变化。以沟通为例，做软件开发的人一般不太喜欢面对面交流。我归纳一个特点：能留言就不实时沟通。具体表现是，能发文字就不发语音，能发语音就不打电话，能打电话就不视频，能视频就不见面。敏捷价值观第一条个体和互动高于流程和工具，这就是一个挑战，作为团队的敏捷教练，就要营造轻松的氛围，通过团建让大家熟悉起来。

事：

不管是传统方法还是敏捷方法，都要做好需求管理、项目管理、配置管理、质量保障这四个方面。在敏捷方法里，有许多新的实践需要团队去学习。

需求管理：以前写需求的时候，需要写一个需求规格说明书，也叫做PRD，是一个比较重的文档；现在呢，敏捷团队的需求实践叫做用户故事地图、用户故事、待办列表。那就需要负责需求的人去学习这种新的沟通需求的方式。

项目管理：原来的项目管理是偏PMP那套，理清楚资源、目标、里程碑，做计划画甘特图这些；敏捷的项目管理，强调的是适应性计划，面对面的沟通，典型的活动有迭代计划会议、每日站会、迭代评审会议、迭代回顾会议等。通过燃尽图等可视化工具来暴露风险。

配置管理：原来可能几个月才发布一个版本，只在上线之前才会发布一个测试版。但是敏捷之后，最好做完之后马上让客户看到。这就对配置管理提出了要求，比如开发人员接到一个任务时，要有意识地暂存手上的工作，单独地提交，而不是和现在手上做的事情混杂在一起。这就需要有好的版本控制工具和工作流。提交后，能自动完成代码规范检查，自动化测试（单元测试、接口测试、功能测试等），自动化部署（开发联调环境、测试环境、用户验收环境、预生产环境、生产环境等），这些环境如何管理，如何灵活地创建和销毁。过程中产生的二进制文件、Docker 镜像等，都需要版本化。这一块的实践在 DevOps，持续交付的领域探讨的比较多。

质量管理：原来几个月才发一次版本，可以留一段时间去做集中测试，但是现在快速迭代，每周甚至每天都要更新多个版本，那质量如何把控呢？就需要把质量的保证工作前移，我们叫做质量内建，就是将质量管理工作内建到开发的整个过程中去。这里最核心的实践就是持续集成、自动化测试、TDD、重构、代码评审、结对编程等。

7
虽然敏捷开发的优势很多，但是为什么现在很多公司都没有用上敏捷开发呢？
李小波老师：

很多公司对外宣称都是敏捷开发的，是透明的、是高响应力的。Martin Fowler有一个概念叫做敏捷的流畅度，国内很多企业会做敏捷的成熟度评估。像是我们去给公司做敏捷开发指导，都会做一个评估，主要是考量企业的敏捷流畅度和成熟度现状。

普遍存在的一个现象是，业务压力太大，没有时间去反思自己的工作方式并进行调整。所以对敏捷，大多数公司是尝试做过，但是最终却形成了一些不好的印象。短期来看，对敏捷教练、培训师的需求是很大的，因为很多公司都在拥抱敏捷，但是在实践中遇到了许多困难，需要有专业人士去指导。

敏捷转型的挑战不在于敏捷，而在于转型。

人的心态怎么转变，如何在高压之下拥抱变化、主动学习。

所以我们在给企业提供敏捷转型服务时，会有敏捷专家和变革专家一起搭档，用引导技术、教练技术等帮助企业减少阵痛。

8
敏捷开发在中国的实践下面临着什么挑战？国内的敏捷开发是否是变相压榨劳动力？
李小波老师：

敏捷开发涉及到整个企业创造价值的方式的变化。

例如，领导的方式。

传统的领导方式更偏向于控制，叫做命令与控制型文化。而敏捷更倾向于用愿景去领导，激发和支持个体去达成目标，这对管理者也是有挑战的。

成功的转型，不仅是IT团队的变革，还涉及到市场、HR、财务、行政等。

第二个问题，也是很常见的问题。

我在培训时会强调，敏捷和加不加班没有关系。整个大环境的氛围是这样的，竞争对手、环境都随时在变化。敏捷很容易让人认为是压榨的原因是它太透明了。原来一个开发人员领一个需求，就预估一下工时，然后是自己写代码，中间是有很多「空间」的，但是敏捷的话，开发人员提交代码都是有记录的，提交频率比之前高很多，还要做代码评审、每日站会，摸鱼划水的空间就没有了。所以在做计划时，要保留一定的弹性，不要太反人性。

9
在Copell极客马拉松期间非常感谢您的悉心指导，给予了我们参赛团队很大的帮助。请问在指导期间您印象最深刻的项目是哪一个呢？
李小波老师：

笑脸检测，他们特别神秘，人狠话不多，最后体验的时候觉得很有意思，参与感很强。

10
如果大家想要更了解关于敏捷开发或者互联网方面的知识，您最推荐的书有哪些呢？
李小波老师：

《解析极限编程》

《Scrum 精髓》

《敏捷中国史》

《敏捷软件开发：原则、模式与实践》

【关于我们】Copell高配是一个极客人才社区。
通过组织与承办黑客松赛事，我们想要聚集一群具有创新与挑战精神的极客，并为社区内的极客们智能匹配最优质的机会；在这个社区里，大家可以一起黑客松，可以跨界交流，可以自由的找到属于自己的的工作方式。