前记：
在铃盛，每一个产品项目都有着自己独特的敏捷玩法。在这里给大家介绍一下我比较熟悉的一个项目团队是怎么玩转敏捷的。
首先晒一下团队成员照：
敏捷团队部分成员照
该项目参与的团队有以下基本特点：
1.采用Scrum敏捷框架
2.3个Scrum研发团队，3个PO，1个ScrumMaster
3.每个团队都有开发测试成员，负责产品特性端到端的交付
4.每个Scrum团队人数7~9人
对于熟悉Scrum敏捷框架的朋友来说，这样的团队组成并不陌生。那么是什么让这个团队在Scrum敏捷框架下独具一格，不断成熟并高效运作呢？我想是跟团队对优秀敏捷实践的不断追求和践行是分不开的。
这里介绍几个该团队行之有效的敏捷实践供大家参考，欢迎交流指正。
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(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的建议，个人认为凡是不违背敏捷精神的研发管理方法，均为敏捷。所有的敏捷实践者以敏捷框架为基础，结合公司和产品的实际情况，凭着经验技能和直觉，去践行适合自己所在环境的敏捷实践方法。
以创造价值为核心，让团队能够享受工作带来的乐趣，使其获得协作的满足感，并生成强大的凝聚力。
让团队充满能量并不断追求卓越的敏捷之路，任重而道远，是我们所有敏捷教练应致力的方向。与君共勉。
本文作者：Sara Lu, 铃盛软件Sr. Scrum Master, CSM, CSP, SSM , PMP, PMI-ACP,曾在诺基亚Nokia通信技术有限公司，库卡KUKA机器人有限公司担任Scrum Master。 拥有7年以上敏捷教练工作经验，对Scrum和SAFe等敏捷框架有着丰富的实践经验。
