互联网公司的「敏捷开发」流程是怎么样的？典型的敏捷团队是什么样？

一个故事带你了解敏捷流程

在讲道理之前，我先讲个故事。

最近某公司负责人一直在思考这件事，“冬季如何让更多的人参加户外运动”。然后在某个下雪天，他惊讶的发现路上竟然一个雪人都看不到，这时他灵机一动，“如果现场有一些造型奇特的雪人，会不会让更多人参与户外运动呢”。

于是他回到公司跟核心团队交换了想法，随后经过初步的市场调研和反复的讨论，负责人决定在这一方向上投入一些研发力量进行市场验证。

经过产品研发部门的细化，雪人的实现路径慢慢的清晰起来，于是负责人决定投入三个敏捷团队来“堆”这个雪人，那为了保障跨团队的协作效率，相关团队有这么几个重要的工作契约：

1. 全团队只有一个产品总决策人，每个敏捷团队驻扎一名产品负责人。

2. 每两周全团队要同步一次雪人的研发状态和下一步的研发目标（遇紧急问题需及时沟通）。

3. 三个敏捷团队有各自的“待办列表”，但总体“需求”来源于大目标。

4. 各敏捷团队要有持续交付能力，需定期集成一次，每两周要有一个全局版本。

从全团队的计划会议上，所有人明确了第一个开发周期的目标：一个戴帽子的雪人（MVP 版本）。

那么第一个开发周期的目标确定后，各敏捷团队内部召开了内部计划会议。

团队一采用的是 Scrum，他们第一个开发周期的目标是“实现一顶能戴的帽子”；

团队二采用的是看板，他们第一个开发周期的目标是“实现一个个圆圆的头”；

团队三采用的也是 Scrum，他们第一个开发周期的目标是“实现一个结识的身体”。

他们约定了各自的对接时间和关键协议，然后在随后的两周时间里，每个团队开始了各自的研发任务。当然除了既定的业务目标，每个团队也把自己第一版的 CI/CD 搭建了出来（非功能性需求）。

两周后，第一版雪人在预发布环境中亮相，因为内部已经经历了验收和跨部门的联调，所以这次的预发布过程中没有遇到什么大问题。两天后，雪人被投放在指定的地点，根据数据埋点显示，当天现场有很多人围观，引起了不小的轰动，负责运营的团队在现场也收集了很多反馈。

后来负责人召集核心团队对第一版雪人的发布进行复盘，同时对发布后的数据进行了分析，最终负责人决定在这个方向上继续投入，随即负责人召集产品研发部门规划了下一阶段的工作。

第二个开发周期的目标确定后，各敏捷团队的”待办事项列表“都更新了。这三个敏捷团队根据最新的”待办事项列表“对这个周期的工作进行了规划，然后开始了新一轮的开发，接着第二版雪人如期投放，吸引了更多的人到户外参加现场活动。

之后是第三次迭代、第四次迭代……随着时间的推移，各个敏捷团队的交付能力越来越强。为了最大化的发挥敏捷团队的创造力，负责人做了如下要求：

1. 每个新特性必须有独立的测试。

2. 每个生产环境的变更必须通过严格的测试测试（在 CD 中通过单元测试、集成测试、性能测试等）。

3. 在不影响其他”雪人部位“、不影响大版本规划的前提下，各个”雪人部位“可以按需部署，用于快速响应游客的诉求、修复雪人的缺陷。

后来雪人在不断的产品迭代中走向正轨……

那这种方式就是典型的互联网公司的「敏捷开发」流程

我总结这个流程就是：

相信通过这个故事你对敏捷开发流程已经有所了解，下面我将结合我们团队的经验，讲述一个完整敏捷流程闭环是什么样的，典型的敏捷团队是什么样？内部又有什么样的流程的？，以及我们常使用的辅助工具PingCode

何打造一个完整敏捷流程闭环

在一个健康的互联网公司中，一个明智的决策通常要经过充分的调研和评估，然后才能成为各个部门的目标。当然定目标绝不是喊口号，它包含两部分的内容：

1. 目标是什么

2. 如何检验我们正在向目标走。

而在这个过程中，各个关键角色的目标要进行对齐，所有人的步调要保持一致，由下向上及时反馈目标进展。

（我们使用 PingCode Goals 进行各个关键角色的目标对齐）

那对于产品研发部门来说，产品的研发进度无疑是非常重要的。如果我们对一个产品目标进行分解，会形成一个产品的关键路线图（或者称为用户故事地图），在这个路线图中分布着不同的产品特性和其完成时间。

（我们在 PingCode Plan 规划路线图）

接着这些”需求“被分级分类后放在各个开发团队的”产品待办列表“中。

（使用 PingCode Plan 规划程序增量）

进入到一个 Scrum 团队中，他们在自己的”产品待办列表“中就可以看到按优先级排序的各类需求。

（使用 PingCode Agile 管理敏捷团队的开发工作）

Scrum 团队会根据综合因素（通常包含：优先级、工作量、依赖关系、非功能性需求的比例等等）安排每个开发周期的工作，他们在每个开发周期结束时都会产出一个可以交付的程序增量。随后我们将所有的 Scrum 团队完成的服务进行集成，形成一个全局版本，部署到生产环境中。

（使用 PingCode Plan 管理各 Scrum 团队的版本）

最后我们再对不同的功能点进行追踪，对各类活动数据进行分析，为后续的决策提供数据支持，这便形成了一个完整的闭环。

这里我之所以把”敏捷开发流程“拉的这么长，是因为今天的敏捷已经不是”团队级别“的概念了。20 年前敏捷开发试图解决业务团队与开发团队之间的矛盾，而今天敏捷开发是一种思维方式，这种思维方式将为整个组织进行赋能。

那对于今天雪人的故事而言，整个组织就是在用敏捷的方式响应新的”需求“。如果只有研发部门采用敏捷开发，那今天故事的结局会不一样；如果只有一个研发团队采用敏捷开发，那故事的结局会更不一样。当然今天雪人的故事中有很多夸张的因素在，很多事情并不是一蹴而就的，基础设施也需要时间来演进。

PingCode

说到这，我们再回到团队级别的敏捷开发中，毕竟能落地的才是真的。

典型的敏捷团队是什么样？内部又有什么样的流程的？

首先，我认为敏捷开发绝不是一种或几种固定的开发框架，虽然我们在实施敏捷开发时确实也离不开这些框架，但敏捷最大的价值是它传达出来的价值观。

其次，我认为使用 Scrum 和看板这样成熟的框架是十分必要的，标准化的研发流程容易产生规划化效果，说人话就是容易复制。那么典型的敏捷团队是什么样？内部又有什么样的流程的？

我首推 Scrum，放图：

（这是一个由 8 人组成，开发周期为 2 周的 Scrum 团队，主要负责产品研发）

这个团队在开始一个新的 Sprint 之前，PO 会及时更新左侧的产品待办列表，他通常按照优先级进行排序，并对列表里的工作项复杂度有个大概的认知。

在第一周周一的早上 10 点，Scrum Master 组织所有人参加计划会议：首先由 PO 说明这个 Sprint 的目标，再对待办列表进行讲解。然后由开发团队对用户故事的规模进行预估，在团队容量允许的情况下，将用户故事放入这个 Sprint 的工作列表中。之后由开发团队对 Sprint 的工作列表进行承诺。

（使用 PingCode Agile 开计划会议）

散会后各自回去主动领任务开始干活，当开发工程师开始一项工作时，他会从主分支 checkout 出一个特性分支，然后基于这个分支提交新代码，当开发完成时，他会向主分支提交 Pull Request（或 Merge Request），这会自动触发 CI 流水线（执行静态检查、单元测试等），CI 流水线通过后，需要另一位开发工程师手动 Code Review，只有 Code Review 通过后代码才会合入主分支，这会自动触发 CD 流水线（执行集成测试、部署测试环境等）。

部署完成后关掉相关的开发任务，领取下一个开发任务。

（关联开发数据）

每天早上 10 点，Scrum Master 组织所有人开站立会议，每人花 2 分钟同步一下工作进展。

（使用 PingCode Agile 开站立会议）

第二周周五下午 4 点左右，Scrum Master 组织所有人开评审会议，由每个任务的负责人演示其完整的工作，由 PO 确定 Sprint 目标是否完成，版本什么时候对外发布，新增 bug 的紧急程度等等。

第二周周五下午 5 点左右，Scrum Master 组织所有人开回顾会议，每个人说一下团队做的好的和不好的地方，有哪些改进方案等。

（使用 PingCode Agile 开回顾会议）

第二周周五晚些时候，最新的版本部署到预发布环境中。

第三周（新 Sprint 的第一周）周二的晚上，部署最新的版本到生产环境中。

对于自管理能力强，或者周期性不强的团队选择看板，放图：

（这是一个由 5 人组成，开发周期为 1 周的看板团队，主要负责基础服务维护）

这个团队非常注意”流动的感觉“，为了保证让工作流动起来，他们定义了 5 个栏：需求、设计、开发、测试和部署，其中设计、开发和测试都有明确的“完成的定义”和在制品的限制。

有任何需求给到这个团队的时候，直接在需求列创建一个工作项即可。

当设计同学准备处理下一项任务时，他只需从上一栏中拉过来即可，但是当他想将任务拖到已完成时，这项工作必须满足设计栏的“完成的定义”。

就是说所有的方案必须通过评审，并且将影响方案告知相关方。当他不把这个任务拖到已完成的时候，那么下游的开发同学不会继续处理这个任务，这项任务将一直卡在”设计正在做“这一栏里。

当开发同学准备处理下一项任务时，他只需从上一栏的已完成中拉过来即可，当他要完成一项任务时，要提交相应的代码，覆盖单元测试并通过 CI，然后再通过 CD 部署到 Test 环境中。

当测试同学准备处理下一件工作时，他只需从上一栏的已完成中拉过来即可，为这个任务写相关的自动化测试并执行通过，然后再把任务拖到已完成中。

最后由部署同学拖动任务到部署栏中，部署这个最新的版本。

他们每天早上都会看着看板开早会，说一下当前的工作进展。在这个过程中，如果有一项工作长期被卡在某一栏中，将很容易被发现，如果有大量的工作被卡在某一栏时，这时将暴露出这个团队最大的瓶颈问题。这样的方式让他们的工作状态一目了然。

（使用 PingCode Agile 的看板管理一个基础框架的研发流程）

类似这样的 Scrum 和看板团队组成了一个大型的研发部门，这个部门有自己的季度目标，每个月至少会开会一次部门同步会，他们会同步所有项目的工作进展和下一步的工作计划，就像雪人的故事一样……

敏捷开发的流程就是这样的，PingCode提供的标准化研发流程也是这样的。

在这里我强烈推荐大家来体验一下。

附上链接：PingCode

文/孙敬云（个人公众号同）