敏捷开发,你首先要了解这些知识

在2001年2月以前,“敏捷”一词意味着“反应(多指动作或言行)迅速快捷”,从2001年开始,这个词对于软件开发人员来说拥有了更多的意义。由17个人组成的一组自称为无政府组织的团体(敏捷联盟)出现了,他们聚集在美国犹他州雪鸟滑雪圣地来定义敏捷的软件开发过程。这17个人主要由软件开发领域的软件顾问和思想的领导人构成。此次会议共同起草了敏捷软件开发宣言,其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述:

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

当下,“敏捷”已经成为互联网和软件开发领域的业界潮流,几乎人人都说在敏捷,那到底什么是敏捷呢?

什么是敏捷

敏捷在广义上指一种思想或指导原则,本身并不是一种具体的可执行的方法,当然敏捷的方法有很多,这个我们后面会说到。它倡导由跨职能成员组成的自组织团队进行增量式、迭代式的开发,尽早地交付产品并获取反馈,从而不断地演进产品。它旨在交付高质量的产品并建设团队的响应能力。

为什么敏捷

千禧之初,美国在计算机行业已经走了有几十年,瀑布流、螺旋模型、快速迭代…各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善,但互联网的加速发展让传统方法显得笨重,难以快速适应变化。这也是上面我们提到的雪鸟会议的背景。

敏捷最大的特点是响应变化,其实也是顺应了信息化时代瞬息万变的特征。

敏捷对比迭代

相比迭代式开发两者都强调在较短的开发周期提交软件,敏捷的周期可能更短,并且更加强调队伍中的高度协作。

敏捷对比瀑布

传统瀑布模型是最典型的预见性的方法,对于产品研发的过程定义非常明确,严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。团队通常也是按照过程由单一智能的人员组成,只对相应的过程负责。我们常说「计划赶不上变化」,在当下的这样日新月异的环境中,更是如此,频繁的需求变更相信是所有研发人员的噩梦。因此,传统瀑布模型的长反馈链显然不能满足复杂多变的环境。而且由于按过程分工,导致每个环节之间只专注于过程,而缺少对产品整体的认识,也带来了透明性不足、容易低谷潜在成本的问题。

当然也并不是说所有的场景都不应该用瀑布模型,至少对于一般的制造领域,依然还是最适用的模式。

敏捷方法

说了这么多关于敏捷的知识,那到底怎么来实践敏捷呢。前面说到敏捷并不是一种具体的方法,那运用敏捷理念的方法到底是什么。老实讲,方法真的很多:

软件开发之韵,Software Development Rhythms

敏捷数据库技术,AD/Agile Database Techniques

敏捷建模,AM/Agile Modeling

自适应软件开发,ASD/Adaptive Software Development

水晶方法,Crystal

特性驱动开发,FDD/Feature Driven Development

动态系统开发方法,DSDM/Dynamic Systems Development Method

精益软件开发,Lean Software Development

AUP(Agile Unified Process)

Scrum

XBreed

极限编程,(Extreme Programming)

探索性测试

ATDD

每个方法都有各自的特点,但都围绕敏捷的核心理念。这次我们重点介绍一下 Scrum,也是运用最为广泛的一种敏捷方法。

Scrum 介绍

在介绍详细 scrum 前先说明几个概念:

● Scrum:在英语是橄榄球运动中争球的意思,scrum 即为这样一种方式,大家一拥而上,团队是球员,球是产品目标,人员环环相扣,围绕着产品目标进行工作。

● Sprint:字面意思是短跑冲刺,一个开发阶段被认为是一次冲刺,一个个冲刺首位相连,构成一个项目。通常一个冲刺为期1-4周。

● User Story:即用户故事,是从用户的角度来描述用户渴望得到的功能。形式通常为“作为一个<角色>, 我想要<功能>, 以便于<商业价值>”。比如,“作为招聘网站注册用户,我想要查看最近3天发布的招聘信息,以便于我看到最新的招聘信息”。

● Story Point:故事点用于对用户故事复杂度或者工作量的描述。

Scrum 角色

Scrum当中定义了许多角色。按照对开发过程的参与情况,这些角色被分为两组,即猪组和鸡组。这个分组方法的由来是一个关于猪和鸡合伙开餐馆的笑话:

一天,一头猪和一只鸡在路上散步。鸡对猪说:“嗨,我们合伙开一家餐馆怎么样?”猪回头看了一下鸡说:“好主意,那你准备给餐馆起什么名字呢?”鸡想了想说:“叫‘火腿和鸡蛋’怎么样?”“那可不行”,猪说:“我把自己全搭进去了,而你只是参与而已。”

猪是在 Scrum 过程中全身投入的各种人物,他们在项目中承担实际工作。他们有些像上边那个笑话里的猪,要把自己身上的肉贡献出来。

● 产品负责人(Product Owner)代表了客户的意愿。这保证了 Scrum 团队在做从业务角度来说正确的事情。产品负责人编写用户故事,排出优先级,并放入产品订单。

● Scrum 主管(Scrum Master) 促进 Scrum 过程,他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum 主管确保 Scrum 过程被按照初衷使用。Scrum 主管是规则的执行者。

● 负责交付产品的团队(Team)。一个团队通常由5至9名具有跨职能技能的人(设计者,开发者等)组成,承担实际的开发工作。

鸡并不是实际 Scrum 过程的一部分,但是必须考虑他们。敏捷 方法的一个重要方面是使得用户和利益相关者参与到过程中的实践。参与每一个冲刺的评审和计划,并提供反馈对于这些人来说是非常重要的。

● 用户 软件是为了人而开发的。有人说,“假如森林里有一棵树倒下了,但没有被人听到,那么它算是发出了声音吗?”同样地,人们可以说,“假如软件没有被使用,那么它算是被开发出来了么?”

● 利益相关者(客户,提供商) 影响项目成功的人,但只直接参与冲刺评审过程。

● 经理 为产品开发团体搭建环境的人。

Scrum 工具

第一类工具是会议,虽然说工程师很通常比较反感会议,但是必要的会议是很关键的,尤其是这么一个强调配合和变化的团队,必须确保信息对称。

● 冲刺计划会议(Sprint Planning Meeting):在每个冲刺之初,由产品负责人讲解需求,并由开发团队进行估算的计划会议。会议结束后意味着一个 Sprint 的正式启动。

● 每日站立会议(Daily Standup Meeting):团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名。会上每个团队成员需要回答三个问题:

昨天你完成了那些工作?

今天你打算做什么?

完成你的目标是否存在什么障碍?(Scrum主管需要记下这些障碍,重要的其实是第三个问题,站会的核心目的也是为了尽快发现问题,解决问题。)

● 评审会议(Review Meeting):在冲刺结束前给产品负责人演示这个阶段的研发成果并接受评价的会议。

● 回顾会议(Retrospective Meeting):在冲刺结束后召开的关于团队自我持续改进的会议。

第二类工具是文档,虽然敏捷宣言中强调“工作的软件 高于 详尽的文档”,但是必要的文档是确保大家有一致目标的基础,当然这里的文档也是非常简洁明了的。

● 产品订单(Product Backlog)即需求池,以用户故事的形式描述所有的用户需求。每项需求需要评估优先级。

● 冲刺订单(Sprint Backlog)是大大细化了的文档,包含团队如何实现下一个冲刺的需求的信息。冲刺订单通常挑选自优先级较高的用户故事。冲刺计划会议上需要对冲刺订单中所有的用户故事评估出 Story Points,以确保该冲刺能够有效推进。

第三个工具是燃尽图,它是一个公开展示的图表,用于体现剩余工作量,横轴表示时间,纵轴表示工作量。这种图表可以直观的表达任务进展状态以及预测何时工作将全部完成。

Scrum 流程

最后来一张图,完整的说明 Scrum 的实施流程。

1.首先产品负责人会收集来自各个渠道(管理层、团队内部、利益相关者、客户、用户)的用户需求,用用户故事的形式整理到产品订单中,并定义出优先级。

2.然后通过冲刺计划会议开展一个新的冲刺,冲刺订单来源于产品订单中优先级较高的用户故事,整个团队会在这个会议中拆解具体的执行任务,并用故事点(Story Point)的方式评估每个研发任务的工作量,确保所有工作是符合整个团队的产能大的。

3.接下来会开始固定周期的冲刺,每天 Scrum Master 都会组织站会,确保信息同步以及问题及时被发现和解决。冲刺阶段大家都可以关注团队燃尽图,了解研发整体进展。

4.冲刺临近结束,会进行评审会议,产品负责人会对研发成果进行评价,确保最终交付成果。

5.冲刺结束后,会进行回顾会议,总结上个冲刺有哪些做得好的,哪些做得不好的点,然后有 Scrum Master 整理出改进方案。

6.一个冲刺结束,紧接着会迎来新的一个冲刺,以此循环。

作者:姜翔,Teambition Product VP