敏捷-第六章 产品规划与发布规划

Scrum框架

愿景声明/陈述/说明书（Vision Statement）

• 愿景应该能够回答以下问题:
  1、项目的目的是什么？
  2、项目工作成功的定义是什么？
  3、项目成果交付后，未来将如何才能变得更好？
  4、项目团队如何知道自己偏离了愿景？
• 愿景声明/陈述是对项目的简要、高层级描述， 介绍了项目的目的，并激励团队为项目做出贡献。
• 愿景声明/陈述应该清晰、简明和可行的：
  1、用强有力的词句或简短的描述对项目做出概括;
  2、描述可实现的最佳成果;
  3、在团队成员脑海中形成一幅共同的、有凝聚力的画面;
  4、激发人们对实现成果的热情
• PO和团队共同制定愿景，并与主要干系人进行沟通
• 长达数年的项目愿景可能需要定期校正（如每年）

项目章程 Project Charter

• 每个项目都需要一个项目章程，这样项目团队就能了解项目之所以重要的原因、团队的前进方向、以及项目的目标。
• 项目章程包括以下内容：
  1、Why：为什么要做？ ——项目愿景/项目目标
  2、Who：谁会从中受益？ ——项目愿景/项目目标的一部分
  3、What：达到哪些条件才意味着项目完成？ ——项目的发布标准
  4、How：我们将怎样合作？ ——预期的工作流

注意：虽然有内容交叉，但项目章程与愿景声明的作用不同：
愿景声明更强调产品愿景/项目愿就本身
项目章程更强调正式立项
项目章程就像圣旨: • 正式启动项目、 • 正式授权PM (钦差大臣)

团队章程 Team Charter

• 团队章程(团队契约)将规定团队成员之间彼此互动的方式。团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们作为团队的最大能力
• 团队章程包括以下内容: 
  1、团队价值观，例如可持续的开发速度和核心工作时间；
  2、基本规则，例如有关一个人在会议上发言的规定；
  3、团队规范，例如团队如何对待会议时间;
  4、工作协议，例如DoR如何定义，这是团队开始工作的前提;DoD如何定义，这样团。队才能一致判断完整性;考虑时间盒;或使用过程限制

小结：团队章程共同制定和遵守；

项目路线图的7个步骤

愿景->产品路线图->发布计划->冲刺计划->每日例会->冲刺评审->冲刺回顾->发布产品

敏捷规划

多层级规则

用户角色的识别(基于用户故事研讨会)

识别并整合角色，设置角色画像/人物画像Persona/虚构角色

需求层级

• PS. 每项需求可能并不需要完成上述全部规模所定义的内容。例如，在完成其它高优先级需求的开发之前，或许你不需要花时间去分解低优先级的需求；反之，你可以在创建一个具体的用户故事， 而不需要考虑史诗级别的定义
• 每个用户故事必须在一个迭代里完成（一个迭代可完成6~10个用户故事）
• 每个特性必须在一个发布里完成
• 每个史诗可以跨越几个发布

细化/梳理（Refinement/Grooming）

• 滚动式规划--近期工作详细规划、远期工作粗略规划
  1、PO和团队讨论用户故事，细分并提供细节信息和验收标准等
  2、PO对用户故事进行优先级排序
  3、团队估算用户故事故事点数

• 待办事项列表PBL（Product Backlog）
• 待办事项PBI（Product Backlog Item）通过用户故事来描述

优先级排序技术

• MoSCoW模型
  Must Have ：必须有的，重要且紧急的
  Should Have ：应该有的，重要但不紧急的
  Could Have ：可以有的
  Wont Have ：不会有的，明确排除
   
• 多票制（Multivoting）
  圆点投票：不同颜色代表不同的权重。向每人提供规定数量的彩色点，然 后他们将彩色点放在其认为最重要的需求上，最后汇总每个功能的选票
• 优先矩阵(Prioritization Matrix)
  1、价值-成本矩阵(工作量或持续时间，容易程度与工作量相反)，价值高和成本低优先
  2、价值-时间矩阵(时间临界即紧急程度)，价值高和紧急优先
  3、价值-风险矩阵 价值高和风险高优先

• 四要素的加权最短优先作业WSJF(Weighted shortest job first)
  1、WSJF=CoD/Effort =(商业价值+时间临界值+风险减少值) /工作量
  2、常用修正的斐波那契数值来估算 
  PS.在星期的规划时，常用(价值点故事点)作为优先级排序的依据

风险调整的待办事项列表 Risk-Adjusted Backlog

• 把风险值视为价值的一部分
• 准确来说，风险值是指其威胁减少值或机会增大值

估算技术

• 绝对估算
• 相对估算(故事点)
  1、亲和估算
  2、计划扑克
• 决策
• 宽带德尔菲举手表决(五指投票)

估算精准度与阶段的关系

• 不确定性随着时间不断降低，估算的精准度随着时间而不断提升
• 滚动式规划 Roling-wave

估算技术:绝对估算(理想日/理想小时)

考虑以下几种情况:
1) 参加各种会议等，实际工作时间会减少。
2) 其它工作如大家每天都有很多电子邮件要处理。
3) 一些工作方法如结对编程(Peer Programming)等
4) 成员偶尔请假等。
所以第一次Sprint可以取50%有效工作时间。随着大家对 Scrum了解的深入和对产品认识的加深，这个系数会逐步提升上来到75%。
例:美式足球比赛是由4个15分钟组成的，但是现实中比赛不会在60分钟内完成，而由于休息、广告、受伤、节目回放等，甚至长达180分钟

估算技术:相对估算(故事点)

• 亲和估算(Affinity estimating将产品待办项规模相近的放在一起，组成一组。例如使用类似T恤衫尺码(如小号、中号、大号和特大号)作为估算尺度
  
• 计划扑克/估算扑克(Poker Planning)参与者出牌，再进行讨论。是一种协作式的相对估算技术采用修改的斐波那契数列:1，2,3,5,8,13,20,40,100
  1、主持人阅读某一个用户故事/功能，估算者可提问·
  2、之后出示卡片，代表估算
  3、团队一起讨论估算值
  4、直到达到一个可接收范围(一般循环3轮)
  

注意:不同团队的故事点基数及总量不同!(参照物不同)

估算技术:决策

• 宽带德尔菲(Wide-Band Delphi)
  是德尔菲法的变型，包含更多的沟通和协作。先个人估算，然后大家公开讨论，再重新个人估算和公开讨论。重复该过程，直到结果趋同。一般德尔菲技术严格要求匿名(不讨论)，有效避免从众效应和光环效应
  
  相较于一般的德尔菲，宽带德尔菲是专家匿名投票后会开放空间让大家交流和讨论
• 举手表决(Fist to Five) 
  是从投票方法衍生出来的-一种决策形式。不断进行举手表决，直到团队达成共识(所有人都伸出3个以上手指)
  

准备就绪定义DoR（Definition of Ready）

• DoR指用户故事被认为是充分理解并能开始构建，整个团队一致同意所需完成的一系列条件 准备就绪定义DoR（Definition of Ready）
• DoR已经被当做一种特殊的DoD（准备的完成定义）

用户故事DOR的标准如下：

• 清楚表达业务价值
• 有开发团队能够理解的足够多的细节，这样就能针对是否能够完成PBI做出明智的决策
• 已经识别出依赖关系，不存在阻碍PBI完成的外部依赖关系
• 为了完成PBI，团队人手配备齐全PBI做过估算、足够小、很容易在一个迭代中完成
• 接受标准清晰且是可以测试的(或者INVEST原则)
• 如果有性能标准的话，性能标准是已经定义并且可测试的
• 团队清楚在迭代评审中如何演示PBI

完成定义DoD（Definition of Done）

• DoD是在待办项被商业干系人接收之前/发布之前，由PO和团队一致同意完成的一系列条件/质量验收标准
• DoD还可在许多细节层面上创建，通常在用户故事级别、迭代级别、发布级 别和产品级别上定义

用户故事DOD的标准如下：

• 完成的定义(DoD)
• 设计评审完成
• 代码完成
  • 代码重构完成
  • 代码是标准格式
  • 代码已加注释
  • 代码已提交代码已检查
• 最终用户文档已更新
• 完成测试
  • 完成单元测试
  • 完成集成测试
  • 完成回归测试
  • 完成平台测试
  • 完成语言测试
• 零已知缺陷
• 完成接收测试(AC)
• 已在生产服务器上线

考点：经常质量有问题说明DOD未定义验收标准。

速度/速率 Volatility

速度，即迭代中实际完成功能的故事点之和。刚开始的速度基于经验估算， 之后团队通过综合历史表现，来更准确地计算出速度 平均速度=20
例如，本次发布共58个故事点，平均速度为20，即本次发布需要3次迭代

制定发布计划

根据产品待办事项列表规划发布和迭代

MVP与MMF

• MVP最小可行产品 （Minimum Viable product）：用最快的方式、最少的精力进行开发，获得客户对产品的反馈
• MMF最少可售特性 （Minimal Marketable Feature)：已经确认是有价值的产品特性，可以开发出来进行销售
• 有时候二者并无完全区别。不过一般MVP的概念更强调产品创新时尽快做出样机以供验证(迭代)， MMF更强调稳定市场环境下的增量可售功能

故事地图 Story Mapping

• 根据用户故事商业价值和用户通常对它们的执行顺序进行排序，以便团队能够对将要构建的内容有共同的理解
• 与之相比，PBL主要按照商业价值来进行优先级排序

影响地图lmpact Mapping

• 仅仅研发敏捷是不够的，更重要的是业务敏捷(Business Agility)!
• 影响地图是2012年由敏捷大师Gojko Adzic提出的。通过结构化的显示，将业务目标(why)和产品功能(what)之间建立关联，让团队清晰地看到每一个功能对业务目标是怎样影响的，确保每一个功能都是有价值的

影响地图 vs 故事地图及PBL

• 影响地图是对新产品组合或新产品需求进行探索性理时的一种工具
• 故事地图是对当前已经较为明确的用户故事集合进行梳理，以便团队对产品的所有需求有一个整体的视角，做到即看见树木又能看到森林两个地图可以组合使用，相得益彰:
  1、影响地图可以产生产品组合，然后使用故事地图来整理各个产品
  2、影响地图可以产生产品的具体功能，然后使用故事地图或PBL来组织开发

非功能需求(NFR,Non-Functional Requirements)

• 非功能性需求代表了系统行为的约束
  1、宏观的非功能需求一般纳入功能需求的DoD
  2、较孤立的非功能需求可以作为Backlog的事项
• 常见的非功能性需求类型如下:
  性能( performance ):响应时间、产量、资源利用率
  准确性( accuracy)可重用性( reusability)
  可维护性( maintainability)
  可靠性( reliability)
  易用性( usability)
  安全性(security)
  容量( capacity)