敏捷开发在百人规模企业的落地实践分享

文章略长，通过本文你将了解以下问题：1、敏捷开发的全流程；2、如何保障敏捷开发的落地；3、敏捷开发的管理和度量；4、敏捷开发管理常用工具等。

随着公司业务的快速发展和团队规模的日益增长，你可能会发现：

• 业务需求端到端交付周期长，已经无法满足快速响应客户的需求；
• 团队成员被动性接受任务，自主性和自驱力不强；
• 各种固化的流程、缺失的文档，难以继续推动产品质量提升和开发效率提高；
• ……

以上都有可能是我们决定转型敏捷的原因。但我们知道，敏捷开发只是一种指导思想和原则，敏捷开发并没有给出具体的实践步骤，它希望团队通过实践，找到属于自己的敏捷实践，从而解决问题达成目标。在敏捷转型过程中，团队会经历犹如刮骨疗伤般的阵痛，但同时团队的管理思维、研发协作、组织文化、产品质量等方面也会得到长和规范化。

接下来会结合以往的实践经验，介绍我们敏捷团队走完一个迭代所涉及的环节和内容，希望给即将或已经进行敏捷实践的个人、团队带来一些思考和参照。

 

一、敏捷开发的流程

关于什么是敏捷开发？什么是Scrum？这些概念性的问题网上已经有非常丰富的资料，所以这里就不做过多的赘述。延伸阅读《 敏捷开发：Scrum框架概述 》

敏捷研发是涉及整个软件工程的理念与实践，它的本质是迭代和增量式软件开发方式，防止出现严重偏离客户需求，达到快速响应市场变化的目的。

敏捷开发比较注重的地方是组织文化、流程以及工具的结合体而且缺一不可。缺少工具支持的敏捷研发无法实现“高速”；缺少组织文化支持的敏捷研发会让团队成员之间无法团结一致完成共同的目标。

在敏捷开发中，强调持续集成交付有价值的成果。把产品项目整个任务进行拆分成多个小批量目标，根据优先级进行迭代式推进，每个小批量任务完成后都是可交付给到客户使用的，缩短客户等待周期反馈周期，及时根据反馈结果进行调整，以此达到客户满意度。

根据近些年实施敏捷开发的经验，要成功实施敏捷开发需要根据公司的业务特点、自身组织实际情况，制定适合自己的Scrum流程而切记邯郸学步。

1. 版本规划

在版本规划时，建议综合考虑客户的价值、整体质量与范围、进度、预算等限制条件。常见版本四种发布规则 ，团队采用最适合的即可：

• 在每个冲刺后发布，而是把多个冲刺的结果合并为一个版本进行发布；
• 发布和冲刺保持一致，即冲刺结束后立刻进行版本发布；
• 按特性发布，即每次做完一个特性就进行一次发布，我们管这种发布也叫持续交付；
• 按需发布，它是综合以上发布，按业务方的需求来选择何时发布。

不管你采用哪种方式进行发布，大多数组织实践中发现最好能够稍微做一些长期的规划，有利于整体统筹规划。

有些组织可能用别的名称来代替，比如：长期规划「放眼于多个冲刺」、里程碑「各版本与重大里程碑一致」。

 

2. 团队管理

Scrum框架下有三种常见角色：产品负责人「Product Owner」、Scrum主管「Scrum Master」、团队成员「Scrum Team」。

根据我们开发中的实际情况将角色分为以下四种：

• 项目经理：相当于Scrum主管，负责协调团队内部合作，召集站立会议，把控项目整体进度；
• 产品经理：相当于产品负责人，负责决定应该做什么工作，明确工作项、评定优先级，拟定待办事项Backlog清单的内容，确定各个事项的优先顺序；
• 开发人员：开发人员是项目开发任务具体的实施者。他们负责完成开发任务，及时反馈开发进度；
• 测试人员：测试人员是项目测试任务具体的实施者。他们负责制定测试计划，编写测试用例，创建以及回归缺陷。

如有有需要，Scrum团队还可以根据项目需求添加其他岗位人员。

 

3. 需求梳理

项目开始前，由产品负责人收集来自各方需要、期望和诉求，明确工作项、评定优先级，整理出Backlog待办事项列表，常见的条目信息表达形式为用户故事。在冲刺计划会议上，Scrum团队从产品待办列表中挑选其中事项组成Sprint Backlog。

产品负责人对需求任务设置优先级，结合自身情况自定义需求状态，利用「子任务」进行细化和拆解，设置任务归属于不同的资源池，形成完整的故事结构。

敏捷开发也无法帮助团队解决需求优先级/功能优先级排序的问题，所以我们是通过一款工具 （PingCode） 建立标准化的产品优先级模型，数据化评估客户最需要的功能，确保产品目标与公司经营目标保持一致。

 

4. 迭代计划

在迭代开始前，需要有一个迭代计划会议。在会议中安排迭代中要做的工作以及确定迭代目标。在迭代计划会上，产品负责人需要告诉团队迭代待办列表中条目实现的优先级顺序。团队承诺在迭代中他们能够完成多少个条目。在迭代的过程中，任何人不能单方面擅自变更冲刺内容。最终的计划是由整个Scrum团队协作完成的。

在每个迭代/版本开始前，交付团队和需求方就应当在计划会议上针对下一个迭代/版本要交付的范围进行讨论，交付团队就讨论结果，做出在迭代结束时一定会交付约定范围的需求的承诺。

 

5. 跟踪迭代进度

迭代目标明确后，即将进入迭代冲刺。一般迭代周期为1至4周左右。

在整个迭代过程中，需要由Scrum Master 确保团队在无外界干扰的情况下全力以赴的冲刺。在冲刺的过程中，建议采用可视化管理方式将迭代过程和工作必须对执行工作的人员和接受工作的人员都是可见的。（后面我们将会整理一些可视化工具和数据指标。）

 

5.1每日站会

迭代开始后，团队在每日站立会议「Daily Scrum Meeting」中对每天工作进行迭代跟踪。会议围绕以下三个问题展开：

• 我昨天做了什么？
• 我今天计划做什么？
• 有什么问题阻碍了我？

保证Scrum Master和团队成员可以快速处理障碍，集中精力进行目标冲刺。同时建议站会结束后，将比较有价值的信息同步到Wiki中。

5.2 关注团队进度

除了应用可视化看板、每日站会可以监控项目进度和风险以外，还有一个特别好用的实践，即燃尽图。

燃尽图以图形化方式展现了剩余工作量与时间的关系。要求团队每日更新工作进度，养成良好的更新习惯。从图中可以了解团队计划，把握团队进展以及知晓工作步调是否一致。同时可以及时发现问题并做出改进。通过甘特图能随时查看迭代的具体进度以及每个项目成员的任务分工情况，做到分配合理。

6. 迭代评审

迭代冲刺的结果是潜在的可交付的产品增量，那么如何来评估冲刺目标完成的结果呢？

接下来要进行另外一个事件，即迭代评审会议。这个事件是让开发团队向利益相关者展示他们在本次Sprint中取得的成就，根据DoD“完成的定义”和验收标准，验证增量，这些增量应该是：已经开发、测试完成、经过整合的和已经记录的。

在迭代评审期间，团队和利益相关者将评审在这次迭代冲刺中完成了什么，以及环境发生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。PBI也可能会进行调整以适应新的机会。这里需要注意，迭代评审是一个工作会议，团队应避免将其仅限于展示。

 

7. 迭代回顾

迭代回顾会议的目的是规划提高质量和效能的方法。应当对整个迭代的过程进行回顾，检视最近一个迭代冲刺中有关个体、交互、过程、工具和需求完成情况如何及遇到哪些问题，这些问题是如何解决或未解决的。

团队识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个迭代冲刺的迭代待办列表中。如果需要，可将重要的信息更新到Wiki中，让团队成员时时可见。

 

二、敏捷开发的落地保障

产品项目研发采用敏捷开发模式，首先得建立符合敏捷开发模式的组织团队，强调团队稳定、目标明确协作一体化，团队参与全过程、为质量负责。再好的敏捷开发流程不付诸行动，也是虚无的妄谈。

流程标准不一定是精确管控或对产品质量提升提供决定性的因素，但可以保障产品质量的下限。为实施敏捷开发流程，从管理与团队支持、敏捷教练与培训、项目试点、持续改进与扩展等四方面进行展开。

针对敏捷开发流程实施落地，从如下方面进行保障：

 

1、敏捷意识先行

任何组织的变革中，总会有小部分“抵触者”的存在，碰巧如果这些人影响力很大，对项目的推广非常不利。在敏捷开发流程实施过程中，必须做到意识先行。如对敏捷开发的误解，很容易造成管理人员，团队成员对敏捷开发产生抵触情绪。

因此需要对敏捷开发的成本与价值，从管理层到基层员工认知上达成共识，即统一思想、统一认知。

 

2、敏捷基本机制和运行规则

Scrum三三五五：

• 三个角色：产品负责人 ScrumMaster和产品团队
• 三个工件：产品backlog、迭代Backlog和产品增量
• 五个活动：迭代、迭代计划会、每日站会、迭代演示会和迭代总结会
• 五个核心价值观：专注、尊重、承诺、勇气和开放

 

3、高效敏捷团队

打破职能，全员参与：采用敏捷开发模式，原来按职能规划的团队组织必须调整，全部团队成员必须贯穿项目，对项目最终质量负责。由于敏捷开发强调持续迭代开发、快速交付，因此人员角色职能可以模糊化，一起做好软件的质量保证。

团队氛围：实施敏捷开发初期，选择相对积极同学参与组建敏捷团队，不要过于追求完美。先形似后神似，成功开展前两个迭代很重要。每日三赞，表现好的同学，站会及时提出表扬，做的差的以引导为主。总结会议或技术分享，营造轻松氛围，真实反馈，相互讨论，互相促进。

敏捷的组织文化中，相对以往的瀑布流程，敏捷更关注人，因此敏捷测试组织应该以人为导向，是一种驱动、自组织、协作式的文化氛围。

 

4、双周交付模型

为实现业务的快速迭代，而提出双周发版的交付模式。贯彻的总体原则为：评审、开发、测试完全并行，以两周为固定周期，以需求维度持续交付。

要落地一些准备工作，例如统一版本排期的时间表、确定项目中各个角色的交付时间，让PM、UI、客户端RD、服务端RD和QA，各角色都能够清晰的知道自己接入的时间点，并在规定的时间点交付内容。由于各角色的任务和分工得到了明确，减少了协作中的沟通成本，各角色也可以如齿轮一样，持续产出交付给下游团队，整个交付周期效率得到了有效的提升。（业务维度AB组各个角色分工详情示意图「美团」）

双周模型中关键点：

• W1需求评审：周三PM组织三方评审业务需求+埋点需求+UI需求。
• W2排期：周三API RD出排期，周四客户端RD出排期，UI产出视觉初稿。客户端RD排期需细化至需求可提测时间点，便于QA、PM和UI提前协调测试、验收时间。
• W3接口评审+服务端先行开发：接口文档，UI资源周四前到位。
• W4客户端开发，周四API提测（最晚）。
• W5客户端开发+冒烟测试：RD开发完后直接冒烟测试，以需求维度交付给QA，不需要等到最后一天集中冒烟测试；需求交付后，PM与UI可介入验收环节。
• W6客户端测试+周二服务端上线：客户端一轮测试结束前，PM与UI应完成需求验收。
• W7灰度+周二全量理想状态一个版本的周期为五周半。

W3时，PM会继续组织三方评审；W4时，API继续开发下版本；W5时，客户端RD会继续下一个版本的开发。

 

5、敏捷开发工具支撑

敏捷开发中非常强调公开、透明、直接有效的沟通，这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。通过“可视化的管理工具”让所有人直观的看到所有需求池、UserStory、Task、燃尽图和Bug的状态及之间的流动。为使团队成员快速适应敏捷开发流程，将流程标准固化到可视化的管理工具。

这里分享国内外的几款顶级敏捷开发管理工具。

PingCode

这是国内最好用的研发全流程管理工具之一，曾在2021年获得由36氪发布的研发项目管理榜TOP1，被广泛用于敏捷开发项目管理，以及需求收集、需求管理、产品路线规划、kanban/瀑布项目管理、测试管理、缺陷管理、文档管理、效能度量以及与外部工具集成等。支持saas、私有部署等购买方式，价格仅为Jira的30%-40%。【PingCode官网】

详细的敏捷开发解决方案大家可通过以下文章了解《 PingCode是如何做敏捷开发项目管理的 》

Jira

Jira是全球范围内软件开发的先驱。该品牌于2002年由Atlassian公司在澳大利亚创立，最初是一个问题跟踪工具，此后逐渐发展为多任务的项目管理软件，能够很好的支持敏捷开发项目管理。但自从2020年停售国内本地版后（一定意义上对国内用户禁售），所以这可能会带来一定的风险，但也丝毫不影响其地位。【官网：Atlassian.com】

三、敏捷管理和度量

 

1、定性管理

• 增量是一个Sprint完成的所有产品待办列表总和以前Sprint所产生的增量的价值总和。
• 冲刺计划：对冲刺期间工作范围及工作量的详细评估；
• 每日站会：团队成员共享任务进度和面临的问题，提供相关Sprint任务剩余时间的报告，保持目标方向；
• Sprint总结会议：分享进展顺利，表现优秀的地方；进展不佳及改进思路，可以帮助Scrum团队和流程的持续改进；
• 团队满意度：定期了解Scrum团队满意度，可以提升敏捷文化，减少团队冲突和流程问题。

 

2. 定量管理

• 燃尽图「Brundown Chart」：比较直观显示冲刺过程中完成了多少故事点以及还剩下多少故事点，有助于预测冲刺范围是否会按时完成；
• 敏捷速度「Velocity Chart」：衡量团队在过去几个Sprint中平均完成的故事点数即产能，用于预测团队在新的Sprint中的表现。也可以用于提升团队产能的衡量指标。但Scrum团队之间比较不具备参考意义；
• 累积流量图「Cumulative Flow Diagram」：用于显示任务状态-在sprint，发行版或跨软件团队。它可以可视化流程中的瓶颈–在任何工作流程阶段中，成比例的大量任务表明存在问题。例如，在验证或测试阶段图表中的大“气泡”表示该阶段资源不足；控制图（Control Chart）、缺陷数等；

度量的目的是为了使Scrum团队更加聚焦交付增量目标，通过过程指标不断修正和持续改进，而非以考核和监督为目的。

 

四、敏捷开发落地总结

在敏捷开发流程实施落地的过程中，深刻体会到企业敏捷的落地是理想和现实的激烈碰撞。敏捷开发管理实施落地不是一蹴而就，也没有银弹。

敏捷开发，其实就是PDCA方法在软件开发领域的应用，以期望实现高质量、可控、可预测的交付产品。其核心在于一个持续优化的闭环。

内容整理自公众号：24kTeach，原文： https://mp.weixin.qq.com/s/Tz6DjkfXTj7V_hQ0f7Zr0g