敏捷研发历史
敏捷软件开发的实践最早出现在上世纪 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 为例来介绍敏捷开发的流程和场景（如下图）：
敏捷开发之 Scrum 方法大图
我们接下来将详细从这4个大维度详细讲解如何在帮助企业的业务人员、产品经理、技术开发、测试开发在云效上落地实施敏捷研发协同。
首先产品经理会进行：
需求的收集、调研和分析，形成按优先级排序的产品待办列表；
对高优先级的需求，进行详细设计和澄清；
通过迭代排期会，形成按优先级排序的迭代待办列表；
排期完成后，需求从产品经理侧流向技术同学侧。
在需求澄清的情况下，研发团队来会：
以 1～4 周的迭代周期进行持续开发和交付迭代待办列表中的内容
采用每日站会来跟进计划和发现问题，并在迭代过程中持续或间歇性地交付可工作的软件。
与此同时，产品经理会在这个阶段，进行下一迭代的需求设计和澄清。
迭代待办列表开发完成后，产品经理和研发团队一起进行迭代演示，交付可工作的软件。
最后，通过迭代复盘度量驱动团队持续改进。
- 本页导读 （0）