💡
Meegle作为项目管理平台，提供了高度灵活地配置，为多种类型的项目管理提供可能性。 针对需要为产品做增量迭代优化的产研团队，飞书项目全景视图、看板等多种视图模式和工作项关联、需求跟踪能力，支持把Scrum关键要素融入到飞书项目产品中，帮助团队高效落地敏捷开发实践。 。
敏捷开发概览
关于敏捷开发
敏捷开发是⼀种以人为核⼼、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个Story，各个Story的成果都经过测试验证，并通过持续集成快速交付。换⾔之，就是把一个大项⽬分为多个相互联系，但也可独立运行的⼩需求，并分别完成，在此过程中软件一直处于可使用状态。
关于敏捷方法
敏捷方法是一种有时间限制的、迭代的软件开发方法，强调以增量方式交付产品（通常称为冲刺Sprint），而不是一次性交付，缩短端到端交付周期。
敏捷方法有很多，包括Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，目前国内敏捷开发方法以Scrum 为主，主要关注：
- 一致的开发目标
- 按短迭代周期工作
- 快速交付成果
- 关注业务优先级
- 检查与调整
主要角色
- 产品负责人（Product Owner） 以用户需求为核心，产品负责人编写用户故事，排优先级，录入Backlog；
- Scrum 主管（Scrum Master） 确保 Scrum 的执行，Scrum 主管并非团队的领导（因为团队是自组织的），是规则的执行者（通常由PMO兼任）；
- 负责交付产品的团队（Development Team） 一个DT团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作；
Scrum核心节点
- 以用户为中心，由 产品负责人（Product Owner） 编写用户故事及产品需求，录入Backlog，确保Scrum 团队整体目标一致；
- 由 Scrum 主管（Scrum Master） 明确Sprint节奏并持续优化，一般1个Sprint会持续2-4周时间；
- 根据需求优先级，将整个产品的Backlog分解成若干 Sprint Backlog ，每个 Sprint Backlog 与当前人力物力条件匹配，确保目标可完成；
- 召开 待办事项整理会议（Backlog Grooming Meeting） ，由 PO 将一批希望团队在下次迭代时实现的用户故事并为团队成员说明，Scrum主管与在场成员分析用户故事，并提前拆分任务。
- 召开冲刺计划会议（Sprint planning meeting），明确具体的Sprint内需要完成的任务，标注任务的优先级并分配给每个成���。
- 进入Sprint开发周期，在这个周期内，每天需要召开“每日站会（Daily Scrum meeting）。
- 整个Sprint周期结束，召开评审会议（Sprint review meeting），将成果演示给 产品负责人（Product Owner）或业务方 。
- 团队成员最后召开回顾会议（Sprint retrospective meeting），总结问题和经验。
- 复盘结束后，按照同样的步骤进行下一次Sprint。
Meegle敏捷开发实践
Sprint开始前：产品需求一处管理，冲刺周期清晰可视
PO作为业务代表收集来自各方的需求，汇总至 Product Backlog中，并根据业务价值对Product Backlog 中的需求进行优先级排序。
| 需求搜集 | Meegle支持通过“全景视图”获取来自所有空间的全部需求“全集”，作为需求Backlog一处管理查看； PO 可以通过筛选、排序、分组对需求进行分类，分类结果可以另存为新视图“钉”在左侧视图列表中，方便后续自己及团队成员查看搜索； |  |
|---|---|---|
| Sprint管理 | 明确Sprint节奏并持续优化，Meegle支持通过独立工作项对Sprint时间、状态、负责人进行统一管理，一般1个Sprint会持续2-4周时间； |  |
| 冲刺规划会（Sprint Planning Meeting） | 根据Sprint周期，Scrum Team 通过飞书会议预约并发起 待办事项整理会议（Backlog Grooming Meeting）与冲刺规划会（Sprint Planning Meeting） |  |
| Sprint需求规划 | Scrum Team 在Sprint Planning Meeting上，在需求池视图中，根据优先级、需求文档等字段，共同挑选优先级最高的若干需求，在Meegle视图内选中，另存为新的视图，直接将被选中需求放入对应Sprint Backlog（*需确保这些需求在下一个冲刺内 Development Team 可交付完成）； 通过Meegle视图能力，直接在对应Sprint Backlog视图中进行进度管理。 |   |
| 任务排期与拆分 | Scrum Master与DT（Development Team）团队成员对需求进行拆分，拆分为不同角色需要去执行的任务（Work Plan：开发任务、测试任务等）； 通过Meegle需求详情页的节点详情，进行Task Breakout，给对应的工作节点指派负责人和对应排期时间； |  |
| 任务排期与拆分 | 通过清晰的并行节点流，将开发流程预置在流程中，可视化展示，节省拆卡时间，也方便持续进行需求流程跟进。 |  |
| 任务排期与拆分 | 通过与Meegle的集成，需求的DT团队成员可以快速被拉入飞书协同群，确保开发前及开发中的信息能够高效流通，讨论变更一处进行，减少信息差。 |  |
Sprint开发周期中：进度一目了然，看板快捷流转
DT 团队在周期内需完成需求交付工作，且在周期内要交付的需求范围是固定不变的，确保 Scrum 的按期执行。
| 需求管理 | 通过Meegle工作项关联，对一个Sprint下的需求、bug进行整体管理，并随时跟踪任务进展和负责人情况； |  |
|---|---|---|
| 进度跟踪 | 通过 飞书日历 提醒 DT member 定时参加 每日站会，每次持续时间一般不超过15分钟 通过 看板视图 同步如下信息（PO 多数情况下无需参与），并快速点击查看任务具体情况； 昨天，我为帮助开发团队达成Sprint目标做了什么？ 今天，我为帮助开发团队达成Sprint目标准备了什么？ 是否有任何障碍在阻碍我或开发团队达成Sprint目标？ |   |
| 开发完成标准【DOD】 | 为了保证流转到下个节点的质量，团队可以制定DOD （Definition of Done） 团队成员节点点击完成前，需要根据节点任务完成自查，比如是否通过静态代码的检查，开发是否通过自测等； DOD内容可作为节点表单展示，方便被团队看到； DOD可根据实际情况做出适应性调整。 |  |
| 数据报告 | Scrum Team 根据实际需求流转根据需求开发工作直至迭代完成，过程中可以通过Meegle的度量模块，包括WIP图、迭代燃尽图，持续关注整体迭代进展。 |  |
Sprint周期结束：度量实时分析，持续优化流程
Sprint结束并不意味着敏捷开发的结束，通过持续的复盘迭代和评估，总结问题和经验，为下一次Sprint作准备。
| Sprint 评审会议 | 在一个 Sprint 结束后，会进入 Sprint 评审会议 (Sprint Review Meeting)，将结果展现给PO，通过评估字段，PO及其他成员可以对于Sprint整体进行评估，后续会将这些原因聚合成几种类型的影响，在后续方案推进，和整体复盘的时候都会重点跟进优化。 |  |
|---|---|---|
| Sprint 复盘会议 | 在Review之后，下一个Sprint Planning之前，召开Sprint复盘会议（Sprint Retrospective Meeting），团队回顾刚刚完成的工作，提出保留和需要调整的地方； 通过度量模块，提前进行工时分布、优先级等维度的复盘，生成报告视图，根据数据分析结果指导下一次Sprint的优化； |  |
