文档

1、什么是敏捷研发?

更新时间:

敏捷研发历史

敏捷软件开发的实践最早出现在上世纪 90 年代。当时,一批轻量的软件工程方法和框架相继诞生,它们共同的特点是,相对传统软件工程,都遵循演进和迭代的模型,过程更加轻量灵活。其中 Scrum 和极限编程 (ExtremeProgramming)在实践上最为成功,影响最大。它们都是迭代和增量的软件开发框架,区别是 Scrum 只包含管理实践,而极限编程则同时涵盖工程和管理实践。

2001 年 2 月,17 位轻量级软件工程方法的代表人物,齐聚美国发布了后来产生巨大影响的敏捷宣言(参见 http://agilemanifesto.org/),敏捷宣言陈述了他们共同认可的关于软件的开发方法的理念,同样重要的是他们找到了敏捷这个词来总领这些理念。

敏捷宣言发布后,敏捷成为了一场运动,被迅速地推广和应用。敏捷专注研发交付阶段,站在业务的角度,目标是帮助产品和研发团队提升敏捷响应能力,也就是:“更早地交付价值,更灵活地应对变化”。

敏捷研发12条原则

敏捷宣言提出的12条原则已经应用于管理大量的业务以及与IT相关项目中,包括商业智能(BI)。12条原则包括:

  1. 最高优先级的是:通过尽早和持续交付有高价值的软件,满足客户。

  2. 欣然面对需求变化,即使是在开发阶段的后期,敏捷流程就是用变化来为客户获得竞争优势。

  3. 频繁交付可工作的软件,从数周到数月,交付周期越短越好。

  4. 在项目过程中,业务人员、开发人员必须每天在一起工作。

  5. 以受到激励的个体为核心构建项目,为他们提供所需的环境和支持,相信他们可以把工作做好。

  6. 最有效的、最高效的沟通方法是面对面的交谈。

  7. 可工作的软件是衡量进度的首要标准。

  8. 敏捷流程倡导可持续开发,客户、开发人员、用户要能够共同、长期维持步调(节奏)、稳定向前。

  9. 持续地追求技术卓越和良好的设计,以此增强敏捷的能力。

  10. 简单:尽最大可能减少不必要的工作,简单是敏捷流程的根本。

  11. 最佳架构、需求和设计,来自自组织型的团队。

  12. 团队定期反思如何提升效率,并调节和调整自己的工作方式。

在工具层面,云效核心辅助企业解决12条原则中的第1条、3条、8条。

敏捷研发的3个不等式

敏捷研发,提升研发效能,首先要弄清楚要解决的问题是什么,然后才是落地解决问题的实践方法。否则问题没定义清楚,就很难有好的结果。

那实现敏捷研发、提升研发效能究竟要解决什么问题?《精益产品开发》作者何勉老师将提升效能要解决的问题,归纳为3个效能不等式。

第一个不等式,局部效率不等于高效交付?

这一点,大家应该会有同感。当我们去问各个部门或者个人时,都觉得他们很忙,效率很高。但是,我们去问业务部门或用户,却是另外一回事,他们会抱怨产品研发响应慢、交付迟、质量也不好。

这就是组织内部视角的局部效率并不等于用户视角的高效交付。这个是提升研发效能要面对的首要问题。解决它需要更有效的组织协同、更合理的交付模式,和更好的过程质量。

接下来的问题是,高效交付就够了吗?这就引出了第二个效能不等式。

第二不等式,高效交付能不等于持续高效

有的时候,为了高效的交付,我们可以采取临时动作,比如把一群人关在一起,成立一个临时项目,这样沟通协作会更便捷,这可能会达成一时的高效。但是,如果缺乏长期质量思维,当我们在做下一个项目,往往会发现问题,之前的代码和设计存在各种问题,比如可修改、可复用性很差,它们成为后续项目的负债而不是资产,长期的效率无法维持。

如何从高效交付转变成持续的高效,这是研发效能要解决的第2个问题。它对我们的工程和技术能力和实践都提出了要求。

第三个不等式,高效交付不等于业务成功

产品交付的目的是支持业务发展和业务创新。我们必须保证交付的东西,能解决用户问题,并构建可持续的商业模式,否则交付再多也没有意义。

我们认为,研发效能提升的本质就是要解化解上面的三个不等式,从而把组织内的局部效率转化为用户可感知的高效交付,并保障持续的高效和带来业务的成功。最终实现:“持续地顺畅高质量交付有效的价值”。这是效能提升的根本目标。

落地敏捷开发,需要企业里核心角色的参与,我们就以产品、开发、测试3个核心角色为例,讲解他们需要如何推进和支持敏捷开发在企业落地。

接下来我们将一步步讲解业务、产品、技术如何落地敏捷研发,走向持续交付有用价值;

负责角色

目标

管理对象

工作职责

工作空间及事项

工作流

(供参,企业可自定义)

数据度量

(供参,企业可自定义)

业务层

业务人员

响应和满足业务诉求

达成业务目标

以业务需求为核心,同时关注其下属产品需求

业务团队:

  • 收集来自客户/用户的原始诉求并录入业务空间

  • 向产品团队澄清诉求内容

  • 跟进原始诉求的交付进度

  • 原始诉求完成开发后进行验收

产品团队:

  • 评估业务团队提交的原始诉求,与业务团队共同决策是否承接

  • 对于承接的原始需求,创建或者关联依赖的产品需求

  • 产品需求完成交付后通知业务团队进行验收(自动化)

业务工作空间

可用云效“业务反馈管理空间”

  • 客户诉求

  • 用户反馈

已提出-已接受-已分析-已规划-实现中-待验收-已验收(满意度)-已发布

度量交付过程

需求交付率

需求交付准时率

需求交付满意度

度量资源投入

以业务视角看研发资源投入

以研发视角看业务需求来源占比

备注:原始诉求和主题的度量即将上线

产品层

产品交付团队 (含产品经理 及技术团队)

规划和交付产品需求

满足业务交付的短期和长期需求

以产品需求为核心,同时关注其下属的技术任务

产品团队:

  • 规划产品主题,评估主题的价值和成本

  • 将产品主题拆分到产品需求,或将需求关联到主题

  • 根据时间或者版本来规划产品需求的交付时间

  • 阶段性对产品主题进行复盘总结

产品交付空间

可用云效“产品规划空间”

  • 产品主题

  • 产品类需求

待排期-已排期-开发中-待测试-已完成

技术层

技术开发

完成技术任务并高质量和即时的交付需求

系统变更及其它个人任务

产品团队:

  • 完成产品方案的详细设计并组织产品需求评审定稿;

  • 产品需求交付之前对产品功能进行验收确认

技术研发团队:

  • 通过迭代规划安排开发计划

  • 将需求拆分成研发任务或者应用变更,完成需求的开发

技术交付空间

可用云效“Scrum敏捷交付空间”

  • 产品类需求

  • 技术类需求

  • 研发任务

待开始-已开始-已完成

测试开发

完成测试任务,确保高质量交付

测试用例和缺陷

测试研发团队:

  • 制定测试计划并执行测试

  • 发现缺陷并跟踪缺陷的修复

缺陷交付空间

  • 缺陷

  • 测试用例

待确认-已确认-修复中-已修复

总体目标

拉通端到端的交付过程,确保过程质量,对齐各个层次的工作,最终实现业务需求的顺畅和高质量交付。

敏捷开发的流程和场景

那么如何具体来落地,接下来我们将带着大家深入到敏捷开发落地过程中,以Scrum 为例来介绍敏捷开发的流程和场景(如下图):

image.png

敏捷开发之 Scrum 方法大图

我们接下来将详细从这4个大维度详细讲解如何在帮助企业的业务人员、产品经理、技术开发、测试开发在云效上落地实施敏捷研发协同。

  1. 首先产品经理会进行:

  • 需求的收集、调研和分析,形成按优先级排序的产品待办列表;

  • 对高优先级的需求,进行详细设计和澄清;

  • 通过迭代排期会,形成按优先级排序的迭代待办列表;

  • 排期完成后,需求从产品经理侧流向技术同学侧。

  1. 在需求澄清的情况下,研发团队来会:

  • 以 1~4 周的迭代周期进行持续开发和交付迭代待办列表中的内容

  • 采用每日站会来跟进计划和发现问题,并在迭代过程中持续或间歇性地交付可工作的软件。

  • 与此同时,产品经理会在这个阶段,进行下一迭代的需求设计和澄清。

  1. 迭代待办列表开发完成后,产品经理和研发团队一起进行迭代演示,交付可工作的软件。

  2. 最后,通过迭代复盘度量驱动团队持续改进。