敏捷研发历史
敏捷软件开发的实践最早出现在上世纪 90 年代。当时,一批轻量的软件工程方法和框架相继诞生,它们共同的特点是,相对传统软件工程,都遵循演进和迭代的模型,过程更加轻量灵活。其中 Scrum 和极限编程 (ExtremeProgramming)在实践上最为成功,影响最大。它们都是迭代和增量的软件开发框架,区别是 Scrum 只包含管理实践,而极限编程则同时涵盖工程和管理实践。
2001 年 2 月,17 位轻量级软件工程方法的代表人物,齐聚美国发布了后来产生巨大影响的敏捷宣言(参见 http://agilemanifesto.org/),敏捷宣言陈述了他们共同认可的关于软件的开发方法的理念,同样重要的是他们找到了敏捷这个词来总领这些理念。
敏捷宣言发布后,敏捷成为了一场运动,被迅速地推广和应用。敏捷专注研发交付阶段,站在业务的角度,目标是帮助产品和研发团队提升敏捷响应能力,也就是:“更早地交付价值,更灵活地应对变化”。
敏捷研发12条原则
敏捷宣言提出的12条原则已经应用于管理大量的业务以及与IT相关项目中,包括商业智能(BI)。12条原则包括:
最高优先级的是:通过尽早和持续交付有高价值的软件,满足客户。
欣然面对需求变化,即使是在开发阶段的后期,敏捷流程就是用变化来为客户获得竞争优势。
频繁交付可工作的软件,从数周到数月,交付周期越短越好。
在项目过程中,业务人员、开发人员必须每天在一起工作。
以受到激励的个体为核心构建项目,为他们提供所需的环境和支持,相信他们可以把工作做好。
最有效的、最高效的沟通方法是面对面的交谈。
可工作的软件是衡量进度的首要标准。
敏捷流程倡导可持续开发,客户、开发人员、用户要能够共同、长期维持步调(节奏)、稳定向前。
持续地追求技术卓越和良好的设计,以此增强敏捷的能力。
简单:尽最大可能减少不必要的工作,简单是敏捷流程的根本。
最佳架构、需求和设计,来自自组织型的团队。
团队定期反思如何提升效率,并调节和调整自己的工作方式。
在工具层面,云效核心辅助企业解决12条原则中的第1条、3条、8条。
敏捷研发的3个不等式
敏捷研发,提升研发效能,首先要弄清楚要解决的问题是什么,然后才是落地解决问题的实践方法。否则问题没定义清楚,就很难有好的结果。
那实现敏捷研发、提升研发效能究竟要解决什么问题?《精益产品开发》作者何勉老师将提升效能要解决的问题,归纳为3个效能不等式。
第一个不等式,局部效率不等于高效交付?
这一点,大家应该会有同感。当我们去问各个部门或者个人时,都觉得他们很忙,效率很高。但是,我们去问业务部门或用户,却是另外一回事,他们会抱怨产品研发响应慢、交付迟、质量也不好。
这就是组织内部视角的局部效率并不等于用户视角的高效交付。这个是提升研发效能要面对的首要问题。解决它需要更有效的组织协同、更合理的交付模式,和更好的过程质量。
接下来的问题是,高效交付就够了吗?这就引出了第二个效能不等式。
第二不等式,高效交付能不等于持续高效
有的时候,为了高效的交付,我们可以采取临时动作,比如把一群人关在一起,成立一个临时项目,这样沟通协作会更便捷,这可能会达成一时的高效。但是,如果缺乏长期质量思维,当我们在做下一个项目,往往会发现问题,之前的代码和设计存在各种问题,比如可修改、可复用性很差,它们成为后续项目的负债而不是资产,长期的效率无法维持。
如何从高效交付转变成持续的高效,这是研发效能要解决的第2个问题。它对我们的工程和技术能力和实践都提出了要求。
第三个不等式,高效交付不等于业务成功
产品交付的目的是支持业务发展和业务创新。我们必须保证交付的东西,能解决用户问题,并构建可持续的商业模式,否则交付再多也没有意义。
我们认为,研发效能提升的本质就是要解化解上面的三个不等式,从而把组织内的局部效率转化为用户可感知的高效交付,并保障持续的高效和带来业务的成功。最终实现:“持续地顺畅高质量交付有效的价值”。这是效能提升的根本目标。
落地敏捷开发,需要企业里核心角色的参与,我们就以产品、开发、测试3个核心角色为例,讲解他们需要如何推进和支持敏捷开发在企业落地。
接下来我们将一步步讲解业务、产品、技术如何落地敏捷研发,走向持续交付有用价值;
负责角色 | 目标 | 管理对象 | 工作职责 | 工作空间及事项 | 工作流 (供参,企业可自定义) | 数据度量 (供参,企业可自定义) | |
业务层 | 业务人员 | 响应和满足业务诉求 达成业务目标 | 以业务需求为核心,同时关注其下属产品需求 | 业务团队:
产品团队:
| 业务工作空间 可用云效“业务反馈管理空间”
| 已提出-已接受-已分析-已规划-实现中-待验收-已验收(满意度)-已发布 | 度量交付过程 需求交付率 需求交付准时率 需求交付满意度 度量资源投入 以业务视角看研发资源投入 以研发视角看业务需求来源占比 备注:原始诉求和主题的度量即将上线 |
产品层 | 产品交付团队 (含产品经理 及技术团队) | 规划和交付产品需求 满足业务交付的短期和长期需求 | 以产品需求为核心,同时关注其下属的技术任务 | 产品团队:
| 产品交付空间 可用云效“产品规划空间”
| 待排期-已排期-开发中-待测试-已完成 | |
技术层 | 技术开发 | 完成技术任务并高质量和即时的交付需求 | 系统变更及其它个人任务 | 产品团队:
技术研发团队:
| 技术交付空间 可用云效“Scrum敏捷交付空间”
| 待开始-已开始-已完成 | |
测试开发 | 完成测试任务,确保高质量交付 | 测试用例和缺陷 | 测试研发团队:
| 缺陷交付空间
| 待确认-已确认-修复中-已修复 | ||
总体目标 | 拉通端到端的交付过程,确保过程质量,对齐各个层次的工作,最终实现业务需求的顺畅和高质量交付。 |
敏捷开发的流程和场景
那么如何具体来落地,接下来我们将带着大家深入到敏捷开发落地过程中,以Scrum 为例来介绍敏捷开发的流程和场景(如下图):
敏捷开发之 Scrum 方法大图
我们接下来将详细从这4个大维度详细讲解如何在帮助企业的业务人员、产品经理、技术开发、测试开发在云效上落地实施敏捷研发协同。
首先产品经理会进行:
需求的收集、调研和分析,形成按优先级排序的产品待办列表;
对高优先级的需求,进行详细设计和澄清;
通过迭代排期会,形成按优先级排序的迭代待办列表;
排期完成后,需求从产品经理侧流向技术同学侧。
在需求澄清的情况下,研发团队来会:
以 1~4 周的迭代周期进行持续开发和交付迭代待办列表中的内容
采用每日站会来跟进计划和发现问题,并在迭代过程中持续或间歇性地交付可工作的软件。
与此同时,产品经理会在这个阶段,进行下一迭代的需求设计和澄清。
迭代待办列表开发完成后,产品经理和研发团队一起进行迭代演示,交付可工作的软件。
最后,通过迭代复盘度量驱动团队持续改进。