author:李小波
根据在线统计数据门户网站Statista数据显示,2018年,超过90%的软件开发采用敏捷开发(Agile Development)方式。那么究竟什么是敏捷开发,它又具有怎样的特点和优势呢?
敏捷开发背景
90年代,流行的软件开发方法论比较重,文档多,开发周期长,而且最终的成本、进度、质量大多不太令人满意。因此有人提出了轻量级的软件开发方法Scrum、极限编程、水晶方法等等。2001年,提出这些方法论的17位软件工程界泰斗在美国的雪鸟山庄组织了一场聚会,最终得出了2个东西:敏捷宣言(价值观)和敏捷的12条原则。
普遍认为敏捷分为三层:
上层- 价值观和原则。这一层比较务虚,没有教人具体的做事方式。
中层- 方法论。目前敏捷落地主流有2个方法论:Scrum和极限编程。方法论会告诉你团队怎么组建,角色分工,怎么进行协作。
下层- 实践。每个方法论里有诸多实践,包括需求管理,项目管理,配置管理和质量保障这几个方面如何落地。
现在的敏捷被泛化了,同时又在提大规模敏捷、业务敏捷等,甚至延伸到了软件研发领域之外,例如HR,市场销售领域等。Scrum方法论其实是一个通用的方法论,市场、内容等团队都可以采用。
Monstarlab梦思特中国认为敏捷的三大特点:
聚焦价值 – 始终做最有价值的事,用最少的投入获取最大的回报;
持续改进 – 消除浪费,持续提高效率和质量;
以人为本 – 充分激发和赋能团队中的人。
敏捷开发、瀑布式开发、迭代式开发的区别与共同点
敏捷宣言签署人之一的Martin Fowler画了这张图,这几个概念的关系就显而易见了。
这张图中首先是两种计划的方式,预测型计划和适应性计划。
预测型计划:传统的计划方式,典型的表现形式是甘特图,提前计划好什么时间做什么事情,A依赖B,B就要放在A的后面。
适应性计划:环境越不确定,越需要边走边看,这时过于详细的计划,就是浪费。较好的做法是,做一个比较粗的计划,把近期的计划做细一点,然后定期去回顾并调整计划。
预测型计划适合打靶子,适应性计划适合猎豹子。
根据此图可以得出:
- 瀑布开发是典型的预测型计划,跟敏捷无关;
- 迭代开发也不等于敏捷,它也可能包含预测型计划,尤其是传统企业敏捷转型时,在旧的预算机制和考核机制下,还是非常重视「预测」;
- 不是做了适应性计划就是敏捷,要聚焦价值,持续改进,以人为本。
敏捷开发流行的原因
- 对外:提升用户的满意度
过去的管理方法更追求的是利用率,就是别让「资源」闲着,这个资源主要就是团队中的人,并且让专业的人做专业的事,这样效率才最高。
那为了让大家不闲着,就得让每个人的任务栏始终不空着。让专业的人做专业的事,就把工作越分越细,成立更多的职能部门。
结果呢,从客户的视角看,我提出一个需求,在各个环节都要等待(因为每个人的任务栏都是满的),而且环节又多,每个人都在忙,每个人都有自己的KPI,只管自己的一亩三分地,把我的需求当皮球踢,根本没有响应力。
敏捷的核心思想是:
在响应力和利用率之间,更倾向于响应力。
响应力高的表现是什么呢?
客户提出反馈说网站xxx功能不好用,需要改进,从他提出来改进意见到功能上线可使用,其中的周期越短,说明响应力越强。
为什么要提高响应力?因为现在市场变化快,包括竞争对手的变化、新技术出现、新政策等等。在所谓的VUCA(易变,不确定,复杂,模糊)时代,响应力就是竞争力。对客户的响应越及时,客户留下来的意愿就越强。敏捷中很多的实践就是帮助团队去提升响应力,在更短的时间内,把一个东西呈现在客户面前,以便获取用户的反馈,持续迭代改进。
回到软件开发上,以前那些非常重的方法论,接到一个需求后你要写冗长的需求分析文档,做大而全的设计,包括概要设计、详细设计,然后再编码、测试,这个过程周期太长,客户就会心生不满。
敏捷开发是轻量级的,客户提出反馈,团队内的工程师,或者需求分析师直接与客户交流,理解客户的痛点,马上开发出一个最简单的版本给到客户用,了解客户使用感受,然后再不断地迭代。这样客户有参与感,响应时间缩短,客户更加满意。
- 对内:降低成本
创业公司,初期可能会牺牲一点成本去追求响应力,成立特攻队,每个人都是一专多能的“特种兵”,所有人聚焦在同一个目标上,快速地完成产品,去验证想法,去占领市场。等用户数量提升后,再获取收入,降低成本,滴滴出行、共享单车无不如是。
已经上轨道的业务,用的资源越少,就有越多的资源去做新的业务。
敏捷中有许多降低成本的实践,比如:聚焦更有价值的需求。都知道开发产品有些功能都是拍脑袋提出来的,并不知道其实际价值,敏捷提倡的是别一来就做很大的软件,先把核心流程搞出来,让用户去用一用,然后通过反馈得出什么是最有价值的部分,再把精力放在更有价值的地方,这样成本就可以降低。
还有大量的自动化实践,包括自动化测试、持续集成、自动化部署等等,都可以大大降低成本,释放产能。
敏捷开发的角色分工
不同方法论有着不同的角色定义。
以Scrum为例,包含三个角色:
Scrum Master:帮助团队导入Scrum的专家,相当于团队的教练,让团队将Scrum很好地运作起来。
Product Owner:出预算的人,TA管理团队的待办列表,包括条目和优先级。
Development Team:开发团队是一个端到端的全功能团队,包括前后端、移动端、UI设计、需求分析、运维等等,但是开发团队里的角色就不会分得那么细,最好每个人都是多面手,响应力才会高。举例:如果当前有很多功能堆积在测试环节,一味地开发更多功能,并不能增加团队的产出,所以这个时候应该大家都戴上测试的帽子,去做测试,将瓶颈给消除掉。
有了三个角色,再加上三个工件,五个事件,五个价值观,团队就能形式上敏捷起来了。
敏捷开发中可能面临的挑战
实施敏捷开发面对的挑战,可以从2个维度去看。
一个是人的维度,一个是事的维度。
人:
敏捷的环境下其实对于人的心态,要开放、要学习、要拥抱变化。以沟通为例,做软件开发的人一般不太喜欢面对面交流。具体表现是,能发文字就不发语音,能发语音就不打电话,能打电话就不视频,能视频就不见面。敏捷价值观第一条个体和互动高于流程和工具,这就是一个挑战,作为团队的敏捷教练,就要营造轻松的氛围,通过团建让大家熟悉起来。
事:
不管是传统方法还是敏捷方法,都要做好需求管理、项目管理、配置管理、质量保障这四个方面。在敏捷方法里,有许多新的实践需要团队去学习。
需求管理:以前写需求的时候,需要写一个需求规格说明书,也叫做PRD,是一个比较重的文档;现在呢,敏捷团队的需求实践叫做用户故事地图、用户故事、待办列表。那就需要负责需求的人去学习这种新的沟通需求的方式。
项目管理:原来的项目管理是偏PMP那套,理清楚资源、目标、里程碑,做计划画甘特图这些;敏捷的项目管理,强调的是适应性计划,面对面的沟通,典型的活动有迭代计划会议、每日站会、迭代评审会议、迭代回顾会议等。通过燃尽图等可视化工具来暴露风险。
配置管理:原来可能几个月才发布一个版本,只在上线之前才会发布一个测试版。但是敏捷之后,最好做完之后马上让客户看到。这就对配置管理提出了要求,比如开发人员接到一个任务时,要有意识地暂存手上的工作,单独地提交,而不是和现在手上做的事情混杂在一起。这就需要有好的版本控制工具和工作流。提交后,能自动完成代码规范检查,自动化测试(单元测试、接口测试、功能测试等),自动化部署(开发联调环境、测试环境、用户验收环境、预生产环境、生产环境等),这些环境如何管理,如何灵活地创建和销毁。过程中产生的二进制文件、Docker 镜像等,都需要版本化。这一块的实践在 DevOps,持续交付的领域探讨的比较多。
质量管理:原来几个月才发一次版本,可以留一段时间去做集中测试,但是现在快速迭代,每周甚至每天都要更新多个版本,那质量如何把控呢?就需要把质量的保证工作前移,我们叫做质量内建,就是将质量管理工作内建到开发的整个过程中去。这里最核心的实践就是持续集成、自动化测试、TDD、重构、代码评审、结对编程等。
敏捷转型的挑战不在于敏捷,而在于转型。人的心态怎么转变,如何在高压之下拥抱变化、主动学习。