Scrum 框架下玩转敏捷实践

敏捷实践特色一：DoR

DoR 是什么？

DoR（Definition of Ready），敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是 Definition of Ready，简略称之为“DoR”。

在该敏捷团队中， DoR 的具体做法包括以下几点:

输入：

1.需求 - 清晰的用户故事 User Story

2.设计 - 被批准的 UI/UX

3.流程图

时间：迭代开始之前

参与人员: 跟该用户故事有关的群体，包括开发、测试，必要时产品经理，产品设计师等同事都被招呼过来，在确认满足 DoR“输入”的前提下，一起讨论并得出 DoR 的“输出”。

输出：

1.验收标准 AC（Acceptance Criteria）

2.测试策略 - 使用什么样的测试覆盖

3.对于产品性能的影响

4.依赖识别

5.子任务的拆分

DoR 输入输出示意图（流程图+测试策略）

DoR 的一隅

作用：

1.确保需求和设计在迭代前 ready（准入条件）。

2.确保团队成员对产品需求（Know What），功能实现和测试策略（Know How）足够清晰。

3.避免功能实现或者测试点遗漏，尤其是非功能部分的需求。

4.质量内嵌(Build-in Quality)，争取第一次就把事情做对，提高质量

5.思路清晰，提高交付效率。

6.每次 DoR 热烈的讨论过程都是一次增进团队各角色之间相互理解和支持的机会。

敏捷实践特色二：CI/CD

CI/CD 是什么？

CI(Continuous Integration) - 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

CD(Continuous Delivery) - 是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

为了实现持续集成/持续交付(CI/CD)的目标，敏捷团队使用了 Jenkins Pipeline 工作流框架来进行具体实现。

具体做法：

1.一个特性一个开发分支。

2.鼓励开发人员尽早地经常地集成代码。每次集成前必须运行并通过单元测试（Unit test）和被影响的端到端测试，建立开发团队对开发产品的信心。（持续集成）

3.合并回主分支发起合并请求（Merge Request）时要通过静态代码检查，单元测试覆盖率检查，并且要按照 DoR 阶段输出的测试策略进行单元测试，集成测试以及端到端自动化测试等。

4.在发布之前，把代码部署到的 Stage 环境中进行更多的测试， 比如在更多的浏览器上测试，覆盖更多的测试场景以及性能方面测试等等。

5.如果代码在 Stage 环境通过测试，会自动发布验收（Acceptance）的内测版本，通过验收后可以继续部署到生产环境中。（持续发布）

基本作用：

1.通过静态代码扫描，保证没有静态错误。

2.通过单元测试，保证没有单元测试错误。

3.单元测试覆盖率不低于目标分支，保证没有降低单元测试覆盖率。

4.保证没有构建/部署错误。

5.通过指定范围的端到端自动化测试。

通过使用 Jenkins Pipeline 框架实现 CI/CD，可以在以下几方面获益：

1.通过 CI/CD，开发人员能够尽早地发现和解决代码中的问题，在成为下游主要问题之前进行修复，以降低错误代码导致的长期开发和业务成本。

2.通过 CI/CD，可以增加产品的发布频率，持续不断的软件版本发布也会根据用户对应用程序的反馈，允许开发团队对其进行及时微调。

3.通过 CI/CD，可以保证每个发行版本的风险较低。当使用 CD 方法发布时，开发团队也会更有信心，因为在整个开发生命周期中，所有内容都经过了多次测试，保证了代码质量。

CI/CD 示意图

敏捷实践特色三：打造学习和分享型团队

为了满足客户的要求和实现公司的战略目标，产品开发的需求不断涌现，团队成员也在不断地增加，新员工的有效培训以及产品的快速交付是团队面临的两大挑战。

培养学习和分享的团队文化是快速提高团队整体生产力的有效方法，而团队的生产力是保证产品快速交付的必要条件。

为了营造知识技能分享的氛围，打造学习型团队，敏捷团队主要采用了以下实践：

导师机制（Mentor 机制）- 每个新员工都有一个 mentor。新员工入职第一周，导师和团队要组织“迎新餐”欢迎新同事的加入，让新员工快速和大家熟悉起来，融入团队。另外，导师负责给新员工制定有效的学习计划，帮助新员工快速成长，迅速参与到项目当中，也可以培养老员工的领导力，增强团队互助氛围。

结对编程 - 每个开发同事都有一个结对的同事。结对编程可以帮助新人快速成长，提高团队整体技能；不同的思维碰撞，让编程充满乐趣和更多可能。

团队结对编程

Code Review - 每个同事的代码都需要 pair 和一个资深同事的 review，规范编码习惯，采用“四眼原则”。

DoR - 这个环节上文有介绍，绝对是一次知识分享思想碰撞的好机会。

技术方案、实现设计探讨 - 技术方案的“讲解和提问”互动环节以及具体实现设计（比如类图）的讲解让大家的知识和技能得到进一步的分享和交流，是一个充分深入的学习机会。

团队探讨技术方案照片

这样的敏捷实践，赋予了整个敏捷团队信任与透明，相互尊重和支持的工作环境，让大家能够乐于配合并且积极接受挑战。

Scrum 敏捷框架是“容易理解却难以掌握”的一种敏捷框架。敏捷的价值观为道，敏捷原则为法，实践为术。以道法指导术，以术彰显道法，让敏捷的价值观和原则具象于不同的敏捷实践中，让敏捷真正落地。

敏捷教练主要心得：

1.保持开放积极的心态，多聆听来自不同职能不同角色的声音。综合判断并采取相应的应对措施。

2.多看到团队的成长，一个敏捷团队的成长需要时间。当问题很多的时候，尤其需要耐心的引导和帮助。尤其要重视 Scrum 回顾会议。

3.根据团队的实际情况，采用不同的敏捷实践，并适时调整改进。

4.明确各角色的职责，并保证各角色尽到自己的职责并且能彼此顺畅地合作。

后记：

在 Scrum 创建之初，Scrum 之父，敏捷软件开发运动的领导者之一 Ken Schwaber（肯·施瓦伯）就指出 Scrum 敏捷框架只是一个起点，他建议人们从原装的 Scrum 入手以保持稳定的过程框架，并进而自行发挥。

基于 Ken 的建议，个人认为凡是不违背敏捷精神的研发管理方法，均为敏捷。所有的敏捷实践者以敏捷框架为基础，结合公司和产品的实际情况，凭着经验技能和直觉，去践行适合自己所在环境的敏捷实践方法。

以创造价值为核心，让团队能够享受工作带来的乐趣，使其获得协作的满足感，并生成强大的凝聚力。

让团队充满能量并不断追求卓越的敏捷之路，任重而道远，是我们所有敏捷教练应致力的方向。与君共勉。