飞书项目是面向复杂产研团队的专业项目管理平台，提供了高度灵活地配置，为多种类型的项目管理提供可能性。针对需要为产品做增量迭代优化的产研团队，飞书项目全景视图、看板等多种视图模式和工作项关联、需求跟踪能力，支持把Scrum关键要素融入到飞书项目产品中，帮助团队高效落地敏捷开发实践。

敏捷开发概览

关于敏捷开发

敏捷开发是⼀种以人为核⼼进行迭代循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个 Story，各个 Story 的成果都经过测试验证，并通过持续集成快速交付。换⾔之，就是把一个大项⽬分为多个相互联系，但也可独立运行的⼩需求，并分别完成，在此过程中软件一直处于可使用状态。

关于敏捷方法

敏捷方法是一种有时间限制的、迭代的软件开发方法，强调以增量方式交付产品（通常称为冲刺 Sprint），而不是一次性交付，缩短端到端交付周期。

敏捷方法有很多，包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，目前国内敏捷开发方法以 Scrum 为主，主要关注：

• 一致的开发目标
• 按短迭代周期工作
• 快速交付成果
• 关注业务优先级
• 检查与调整

主要角色

• 产品负责人（Product Owner） 以用户需求为核心，产品负责人编写用户故事，排优先级，录入 Backlog；
• Scrum 主管（Scrum Master）确保 Scrum 的执行，Scrum 主管并非团队的领导（因为团队是自组织的），是规则的执行者（通常由PMO兼任）；
• 负责交付产品的团队（Development Team） 一个 DT 团队通常由 5 至 9 名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作；

Scrum 核心节点

1. 以用户为中心，由产品负责人（Product Owner） 编写用户故事及产品需求，录入 Backlog，确保 Scrum 团队整体目标一致；
2. 由 Scrum 主管（Scrum Master）明确 Sprint 节奏并持续优化，一般1个 Sprint 会持续2-4周时间；
3. 根据需求优先级，将整个产品的Backlog分解成若干Sprint Backlog，每个Sprint Backlog与当前人力物力条件匹配，确保目标可完成；
4. 召开待办事项整理会议（Backlog Grooming Meeting），由PO将一批希望团队在下次迭代时实现的用户故事并为团队成员说明，Scrum主管与在场成员分析用户故事，并提前拆分任务。
5. 召开冲刺计划会议（Sprint planning meeting），明确具体的Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。
6. 进入 Sprint 开发周期，在这个周期内，每天需要召开“每日站会（Daily Scrum meeting）。
7. 整个 Sprint 周期结束，召开评审会议（Sprint review meeting），将成果演示给产品负责人（Product Owner）或业务方。
8. 团队成员最后召开回顾会议（Sprint retrospective meeting），总结问题和经验。
9. 复盘结束后，按照同样的步骤进行下一次 Sprint 。

飞书项目敏捷开发实践

Sprint 开始前：产品需求一处管理，冲刺周期清晰可视

PO 作为业务代表收集来自各方的需求，汇总至 Product Backlog 中，并根据业务价值对 Product Backlog 中的需求进行优先级排序。

需求搜集

飞书项目支持通过“全景视图”获取来自所有空间的全部需求“全集”，作为需求 Backlog 一处管理查看；

PMO 可以通过筛选、排序、分组对需求进行分类，分类结果可以另存为新视图“钉”在左侧视图列表中，方便后续自己及团队成员查看搜索。

Sprint 管理

明确 Sprint 节奏并持续优化，飞书项目支持通过独立工作项对 Sprint 时间、状态、负责人进行统一管理，一般 1 个 Sprint 会持续 2-4 周时间；

冲刺规划会

根据Sprint周期，Scrum Team 通过飞书会议预约并发起待办事项整理会议（Backlog Grooming Meeting）与冲刺规划会（Sprint Planning Meeting）。

Sprint 需求规划

在Sprint Planning Meeting上，Scrum Team 会从需求池视图中，根据优先级、需求文档等字段，共同挑选优先级最高的若干需求，在飞书项目中一键另存为新的视图，直接将被选中需求放入对应Sprint Backlog（*需确保这些需求在下一个冲刺内 Development Team 可交付完成）。

通过飞书项目视图能力，直接在对应 Sprint Backlog 视图中进行进度管理。

任务排期与拆分

Scrum Master 与 DT（Development Team）团队成员对需求进行拆分，拆分为不同角色需要去执行的任务（Work Plan：开发任务、测试任务等）；

通过飞书项目需求详情页的节点详情，进行 Task Breakout，给对应的工作节点指派负责人和对应排期时间；

通过清晰的并行节点流，将开发流程预置在流程中，可视化展示，节省拆卡时间，也方便持续进行需求流程跟进。

通过与飞书项目的集成，需求的 DT 团队成员可以快速被拉入飞书协同群，确保开发前及开发中的信息能够高效流通，讨论变更一处进行，减少信息差。

Sprint开发周期中：进度一目了然，看板快捷流转

DT 团队在周期内需完成需求交付工作，且在周期内要交付的需求范围是固定不变的，确保 Scrum 的按期执行。

需求管理

通过飞书项目工作项关联，对一个 Sprint 下的需求、bug 进行整体管理，并随时跟踪任务进展和负责人情况。

进度跟踪

1. 通过飞书日历提醒 DT member 定时参加每日站会，每次持续时间一般不超过15分钟；
2. 通过飞书项目看板视图同步如下信息（PO 多数情况下无需参与），并快速点击查看任务具体情况；
   1. 昨天，我为帮助开发团队达成Sprint目标做了什么？
   2. 今天，我为帮助开发团队达成Sprint目标准备了什么？
   3. 是否有任何障碍在阻碍我或开发团队达成Sprint目标？

开发完成标准 DOD 设定

为了保证流转到下个节点的质量，团队可以制定 DOD （Definition of Done）：

• 团队成员节点点击完成前，需要根据节点任务完成自查，比如是否通过静态代码的检查，开发是否通过自测等；
• DOD 内容可作为节点表单展示，方便被团队看到；
• DOD 可根据实际情况做出适应性调整。

数据报告

Scrum Team 根据实际需求流转根据需求开发工作直至迭代完成，过程中可以通过飞书项目的度量模块，包括 WIP 图、迭代燃尽图，持续关注整体迭代进展。

Sprint周期结束：度量实时分析，持续优化流程

Sprint结束并不意味着敏捷开发的结束，通过持续的复盘迭代和评估，总结问题和经验，为下一次Sprint作准备。

Sprint 评审会议

在一个 Sprint 结束后，会进入 Sprint 评审会议 (Sprint Review Meeting)，将结果展现给 PO，通过飞书项目评估字段，PO 及其他成员可以对于 Sprint 整体进行评估，后续会将这些原因聚合成几种类型的影响，在后续方案推进，和整体复盘的时候都会重点跟进优化。

Sprint 复盘会议

在评审会议之后，下一个 Sprint Planning 之前，召开 Sprint 复盘会议（Sprint Retrospective Meeting），团队回顾刚刚完成的工作，提出保留和需要调整的地方；

通过飞书项目度量模块，提前进行工时分布、优先级等维度的复盘，生成报告视图，根据数据分析结果指导下一次 Sprint 的优化。