敏捷Scrum指南二：Scrum流程之Plan

通用流程：

1. PO讲解US，Dev Team理解并评审
2. US Point评估

公司小组流程：

1. PO分享上个月的运营数据
2. PO分享当月目标及计划
3. PO讲解US，Dev Team理解并评审
4. US Point评估
5. Sprint Plan排期
6. 团队成长

PO分享上月运营数据

为什么要分享运营数据？

• 公司价值体系，以目标为导向。
  • Team中每个人都要能看懂团队的实际业务数据，工作中不要偏离目标。
  • 方向＞努力，业务＞技术：方向不对，努力白费。
  • Team中每个人都要为团队目标负责。
• Scrum 用户故事地图：用最少的时间做最高价值的事情。
  • 通过业务数据，挖掘产品价值提升的短板之处。
  • 评估上月新增业务功能是否达到预期价值。
• Scrum之跨职能。
  • 产品是Team的产品，不是产品经理的产品。

PO分享当月目标及计划

1. PO分享当月业务计划及Deadline，TeamDev讨论计划并对计划的可执行性进行评审。
2. PO的每个US上面标注下业务目标：提升MAU、留存、创收等，同时填写功能上线后的预期运营数据。
3. 团队成员根据上个月的运营数据，评审业务目标的优先级，产品收集comments。
4. 业务计划会成为团队成长计划的参考文件。

PO讲解US

PO准备工作：

1. 当前Sprint的功能已经拆分成US（参照最小MVP原则）。
2. US的需求已经明确。详细需求增加到US卡片的描述。
3. US若是涉及到外部合作，合作方已提前沟通，可以同步进行。
4. US若是存在外部技术文档依赖，PO必须提供稳定的技术文档。文档增加到US卡片的附件。

US讲解步骤：

1. PO详细描述US的具体需求。
   1. 界面功能需求，PO需要提供交互稿或设计稿，便于理解需求。
   2. 数据统计需求。
      1. 明确期望数据的划分维度和维度的标准。示例如下：【维度】新旧用户
         1. 【维度标准】标准一：没有下单记录的用户为新用户；老用户反之。
         2. 【维度标准】标准二：没有用户记录的用户为新用户；老用户反之。
      2. 明确数据统计的范围和范围标准，常用的是时间范围。示例如下：【范围】每周
         1. 【范围标准】标准一：当前日期的最近7天。
         2. 【范围标准】标准二：上周日到当周周六。
   3. 数学公式计算需求，PO要提供明确可靠的公式。
   4. 算法需求，PO需要提供明确的数据模型。
   5. 压测需求。PO需求提供压测目的和目标数值。
   6. 技术需求，由技术童鞋自行定义需求范围。
2. Dev Team理解并讨论需求。Dev Team从职能角度理解并完善需求，异议处与PO沟通。
   • 研发人员：​​评估需求是否可以用技术实现。
     • 对需求的实现思路和技术达成一致，但是并不涉及到具体的技术细节。
     • 研发人员实现需求时，尽量考虑到技术的持续积累和业务的可扩展性。
   • QA人员：
     • 从测试场景角度思考，需求是否存在遗漏和模糊不清地带，帮PO完善需求的业务场景。
     • 关于需求的业务范围与PO&研发人员达成一致。
     • 思考如何测试&是否需要新增测试需求。
     • 理解研发童鞋的实现思路。
   • UED人员
     • 可以考虑新增需求是否会影响到产品的统一风格。
     • 随着不断膨胀的需求，目前的产品UI设计架构是否需要进行重新的规划设计。
     • 新增需求的交互方式是否符合产品用户习惯。
3. 需求讨论过程中衍生出新的需求。
   • 不紧急的业务需求由PO记录到 Product Backlog。
   • 不紧急的技术需求由Leader记录到 Dev Backlog。

US Point评估

评估工作的前提：

1. Dev Team都了解Point的计数规则，0.5、1、2、3、5、8、13等等。
   1. 小组约定俗成：US最大为5Point。每个Sprint 5Point的US不能超过3个。
   2. Dev Team对于1个Point的工作量达成了一致。
   3. Scrum中的Point指的是工作量，同一个US的Point是固定的，但不同的人去完成时工时是不一样的。
   4. 1个Point指的是1个简单增删改查需求的DoD工作量。
2. Dev Team对于DoD(Definition of Done)达成了一致。
   1. 前端完成研发。
   2. US已上线到日常。
   3. QA完成新接口的自动化。
   4. QA完成case编写&测试。
   5. 前后端完成联调。
   6. 新增功能涉及到架构调整的，研发必须完成架构设计文档。
   7. 后端完成研发，包含单测。

               之前DoD标准包含UED，Point总数相等的情况下，出现或是提前完成或是Delay的情况。虽然Scrum要求跨职能，但是UED在技术岗中的职能跨度较大，实施半年后觉得不适用于KOI组当前的业务。

              Scrum要求“轻文档重沟通”。Team实施一段时间后，发现项目文档缺少，故新增文档项。针对项目新增的核心功能以及涉及到项目技术架构变动的文档，必须同步更新。

US评估步骤：

1. 评估每个US Point。依据DoD，Dev Team每个人都说出评估的数字，去掉Point最大数和最小数，剩下的Point数字取平均值。依次评估完所有的US。
2. 计算Sprint Point总数。
   1. PO计划US的总和为Point总数的基础数N。
   2. 基础数N的增减因素：
      1. 上个Sprint的Point总数。
      2. Sprint是否有大量的项目之外的日常事务或会议。比如绩年中年末阶段。
      3. 是否存在紧急的技术需求。
      4. Team成员的精神状态：是否加班过多太疲惫，是否业务少太过松散。
      5. 项目是否存在Deadline。
      6. Sprint的人员请假或变更情况。
   3. 增加的策略：
      1. 若是需要减少，PO要从“最少功能最高价值”、业务紧急程度、US准备工作进展情况等维度，进行US优先级排序。优先级由高到底，Dev Team选取能力范围内的US。
      2. 若是需要增加，从Dev BackLog & Product BackLog中选取高优先级US。
3. US总量评估完成后，填写到看板的Current Sprint中。

Sprint US排期

US排期的基础理论：

1. 目标设置理论是强调设置目标的特定会影响激励水平和工作效绩的理论，属于过程型激励理论之一。
2. 目标设置应满足“SMART”原则：
   1. ​​​​​​​
3. 每个US就是一个小目标，给US设置Deadline，符合目标设置的Time-based原则。

US排期步骤：

1. PO把US按照优先级进行排列。
2. PO与Dev Team定义Sprint发版计划，详细说明发版时间和上线内容。
3. Dev Team把每个US按照时间顺序设置DeadLine。
4. Scrum依据US Deadline画出并查看BurntDownChat的预燃图，图表走势是否顺畅。根据图表走势调整US Deadline，最终于Dev Team达成一致。

团队成长

参照业务US拆分和排序的流程，对团队的成长计划进行US的拆分和排期。唯一的区别是，团队成长对焦的是绩效目标。主要是保证业务增长的同时，保证团队成长和个人成长。

团队成长，包含团队的技术成长和软技能成长。

之前几个季度并未针对季度的团队业务外的目标进行拆分和排期，季度结束的时候，团队成员完成度并不是很理想。一直思考的是团队成长应该是依赖于团队督促还是依赖于个人自制力，未能找到完美答案。身为团队的领队人，如何带领团队去更好的发展是我该思考的问题。也许优秀的个人依赖于个人超强的学习能力和自制力，但团队中并不是所有人都可以做到高自制力。如何让自制力一般的成员不掉队，激发他最大的潜力，是我该学习的事情，故在新的季度打算把团队成长以项目管理的方式进行管理。此计划只是试水，结果待揭晓。