发布计划

发布计划的目的是提交一份计划以交付产品价值的增量。

涉及哪些人?

发布计划是涉及以下角色的协作工作:

  • Scrum 专家 – 为会议提供帮助
  • 产品所有者 – 表示产品积压工作的常规视图
  • 交付团队或敏捷团队 – 提供对技术可行性和依赖性的深入了解
  • 利益相关者 – 在围绕发布计划作出决策时作为可信赖的顾问
积压工作

计划会议之前

在开始之前,发布计划需要:

  • 由产品所有者管理的排位产品积压工作
  • 来自团队有关整体功能、已知速度和技术影响的输入
  • 高级愿景、市场和业务目标
  • 承认是否可能需要新的产品积压工作项

发布计划清单

  • 您的产品所有者在哪里?
    确保有人能够作出有关重大功能的决策,无论是分析人员、产品经理或高管。
  • 您是否有已排位的积压工作?
    产品所有者希望在此版本中包括 5 到 15 个高级功能。在索引卡上写下每个功能。
  • 如何调整项的规模?
    建立用于规模调整的常用基准线。考虑将一组代表不同团队的个人聚在一起,共同调整一打或更多产品积压工作项的规模。
  • 谁将参加?
    受到此版本影响的所有人都要参加此会议,以帮助制定计划、识别依赖性以及提交版本。
  • 后勤计划
    提前创建一个日程。请考虑空间大小。提前与 Scrum 专家或团队领导审核日程。提供分组讨论室、活动挂图和便利贴以及茶点。
  • 多个或分布式团队怎么样?
    如果每年只有 4 次计划,可以考虑购买飞机票。或者,为每个分布式团队分配一个秘书,以便从白板向敏捷项目管理工具输入计划信息。如果都是现场会议,请为每个团队使用分组讨论室。
  • 我是否需要帮助?
    这是一个昂贵并且可能非常大型的会议。如果之前没有举行过大型分组会议,特别是涉及多个团队的情况,请考虑聘请经验丰富的服务商提供帮助。

所需的材料

  • 发布的目标和日程
  • 组织工具:工作协议、停车场、通信和后勤计划、问题和顾虑、依赖项和假定、决策
  • 高接触:活动挂图或白板以及记号笔
  • 高科技:投影仪、可以访问所需数据和工具的计算机以及共享计算机的方式
  • 计划数据(如下所示)

计划数据

  • 先前迭代和发布的结果
  • 来自利益相关者有关产品、市场状况和截止日期的反馈
  • 来自先前发布和回顾的操作计划以及 SMART 目标
  • 项和要注意的缺陷
  • 开发和体系结构信息
  • 来自先前迭代或估算的速度
  • 组织和个人日历
  • 来自其他团队和主题专家的用于管理依赖项的输入

输出

  • 发布计划和承诺
  • 要监控的问题、顾虑、依赖项和假定
  • 发布积压工作的所有新项
  • 对改善未来计划会议的建议

日程

  1. 开场
    欢迎致辞,复查目标和日程,组织工具和业务赞助商的介绍。除了 典型的开幕致辞,业务赞助商如果还能够分享一些有关此次发布的重要性以及团队未来的工作计划,将会非常有用。
  2. 产品愿景和路线图
    提醒团队要有更远大的理想。
  3. 先前发布中的开发状态、体系结构的状态、先前迭代的结果
    讨论可能会影响计划的所有新信息。
  4. 发布名称和主题
    检查当前状态(因为这与您的路线图主题有关),并协同决定对名称和主题的调整,以实现该发布的特定的当前业务目标。
  5. 先前发布和迭代中的速度,或您的估算速度
    介绍将要用于此发布的速度(如果可用)。
  6. 发布计划和迭代数
    审查关键里程碑和特殊事件,然后协同决定 发布和发布中的迭代的时间框。
  7. 问题和顾虑
    对所有已知的问题和顾虑进行签入并按需进行记录。
  8. 复查并更新“已完成”的定义
    复查“已完成”的定义并根据技术、技能或自上次发布以来的团队更改进行相应的更新。
  9. 积压工作中需考虑的情景或项目
    显示要考虑排定到此发布中的建议产品积压工作项。
  10. 确定规模调整值
    如果速度为未知,请就将要用于发布计划的规模评估值达成一致。
  11. 用于发布的情景的粗略规模调整
    交付团队在考虑发布后确定项的大小并拆分较大的项以便用在发布中迭代。产品所有者和主题专家将解答澄清问题并制定验收标准和适当的情景拆分。Scrum 专家将促进协作。
  12. 将情景映射到发布中的迭代
    交付团队和产品所有者基于规模和速度将项移动到迭代。Scrum 专家将提供帮助。
  13. 新问题和顾虑
    根据先前的工作对所有新的问题和顾虑再次进行签入并按需进行记录。
  14. 依存关系和假设
    对计划期间的所有依存关系或假设进行签入并进行记录。
  15. 提交!
    Scrum 专家对计划进行投票。交付团队和产品所有者就其当前所了解的情况表示此计划是否为最佳计划,同时每天致力于推动计划向下一级别(迭代)深入。
  16. 通信和后勤计划
    复查并更新此发布的通信和后勤计划。
  17. 停车场
    处理停车场—所有项目均应为已解决或转为操作项。
  18. 操作项和操作计划
    处理操作计划—将操作项分配给所有者。
  19. 回顾会议
    由于我们希望这些会议对所有人均有用,因此我们会征求针对会议本身的反馈。
  20. 关闭
    庆祝成功的计划会议!

反馈

需要更多帮助? CA Agile Central 社区为您提供一站式自助和支持。要将反馈或支持请求提交到 CA Agile Central 支持、获取解答并与其他用户协作,请加入我们的 CA Agile Central 社区