持续交付2.0 第六章 业务需求协作管理 读书笔记

产品生命周期的5个阶段

• 概念阶段：回答市场机会，客户需求的紧迫性，企业自身的竞争优势，产品的可行性以及自身产品团队能力等问题。
• 孵化阶段：考察产品核心功能的完善度、满足典型目标用户的核心述求程度，小范围实验用户的反馈等问题
• 验证阶段：主要关注最小核心功能集的用户体验、早期用户的反馈、盈利模式，以及产品技术核心团队的问题定性与加大资源投入的可行性。
• 运营阶段：运营阶段则主要关注市场环境变化，客户繁华需求的存在性，以及投入产出比等。一旦这些要素不满足企业的预期，就应该考虑产品退市。
• 退市阶段：除概念阶段外，每个阶段都至少包含一个产品版本周期如图6-1所示

image.png

每个产品版本周期中，又分为准备期和交付期，它由多个迭代构成，每个迭代至少包含一个持续交付8字环，用于解决一个或一组业务领域问题，如图6-2

image.png

6.1 版本周期概述

6.1.1 准备期

准备期时团队成员共同探索发现与决策的过程，核心人物时达成业务理解与目标的共识。从业务领域问题出发，业务人员，产品研发运维团队一起讨论，共同了解和认识业务问题的全貌，名定义业务目标与衡量指标，找出所有的可能性方案，经过精炼，选出最小可行试验方案。
参与人员：
业务方个角色代表
IT方个角色代表
在允许条件下，尽可能保障准备期的参与者参与交付期工作。

准备期要回答的问题
找出最小可行解决方案，
大约需要多久才能执行并验证完成。（关键决策点）

准备期的主要工作内容

1. 目标阐述与理解：业务代表讲解当前这个产品版本周期内所需达成的重要业务目标，以及相关的业务上下。
2. 业务领域角色与流程识别，及解决方案的探索：全体参与者共同讨论并识别该业务问题所涉及的主要业务流程与流程中的业务角色，并找到尽可能多的解决方案。
3. 重大风险识别与验证：识别各种方案中的业务与技术风险，并组织人员对那些影响决策的重大风险进行快速验证。
4. 精炼并达成最小可执行方案共识：从众多的解决方案中挑选并定制最小可行方案。
5. 评估与计划：都i最小可行解决方案进行初步的工作量与实践聘雇，定制相应的交付计划。

6.1.2 交付期

团队在迭代刚刚开始后，立即着手对后续迭代开发的需求进行详细分析，并在下一个迭代开始前，确保所有参与者对需求的沿海收条件理解一直，达成共识。在这种情况下，一些需求可能会横跨两个迭代。
在这种模式下，每个角色在同一个迭代中会有多种任务
产品人员：

1. 及时回答其他角色对本次迭代需求提出的疑问。
2. 及时验收需求
3. 组织及其他角色为后续迭代的内容进行需求筛选与分析。

开发人员：

1. 开发当前迭代需求
2. 及时修复bug
3. 参与后续迭代需求分析

测试人员

1. 及时验收刚刚开发完成的需求
2. 验收已被修复的缺陷
3. 参与后续需求分析。

6.2 需求拆分的利与弊

传统瀑布开发的弊端

• 测试集成的时候，整个软件才可见，业务方看才到软件，发现与预期不一致太晚

• 市场变化太快，刚刚实现的软件已经无法满足当前的实际需求。

  
  
  image.png

提倡的方式，以用户的视角来拆分大的需求

image.png

6.2.1 需求拆分的收益

拆分后的细粒度需求可以让团队更早地进行集成和质量验证工作，及时发现问题与缺陷，并在每个迭代结束时都能够得到包含相应用能的可交付软件。
做法：

1. 建立共识，协调工作。
   a. 传统模式，需求文档由产品经理完成，在评审会宣读。内容量大，短时间内，测试，开发，产品很难就需求的理解达成一致。
   b. 对需求按业务拆分，拆分时所有角色的成员都需要参与，充分讨论，从而统一需求的理解。
2. 小批量交付，加速价值流动
3. 低成本拥抱变化
   a. 遇到市场突然变化，可以快速完成或放弃手中的现有任务，插入高优先级的任务，适应市场变化。
4. 多次集成，及时反馈质量
5. 鼓舞团队士气

6.2.2 需求拆分的成本

显示成本：将产品意外的角色卷入需求拆分过程，非常必要，但是增加了沟通成本。
分批开发，测试和部署的迭代成本：需求拆分的目标时粉笔迭代交付，为了达到质量交付，每个迭代结束前都要进行验证，增加了验证次数，投入更多成本。

image.png

6.3 需求拆分方法

6.3.1 需求的来源

1. 业务人员提出的业务功能需求。
2. 为了保障业务需求的实现与运行而必须满足的非业务功能需求。
3. 符合安全合规性而产生的安全开发需求

进入交付期后，每个迭代的需求列表中，来源来自以下7部分

1. 从原始需求列表中选出的待实现需求
2. 在需求细化过程中新发现的需求
3. 已知且需要修复的线上生产系统缺陷
4. 线上技术运营需求
5. 前期预言需求，它是指团队目前尚不具备能力，但为了实现某一业务需求而做的准备工作
6. 技术债务需求，指因早期业务进度压力而积累的技术债改进需求
7. 辅助测试需求，为了便与测试和验收，需要开发的测试辅助工具

6.3.2 技术债也是需求

技术债的类型

1. 设计与质量债务。指设计没进行进一步考虑后期需求，代码质量低
2. 自动化率债务。指部署，环境准备等工作大部分依赖于人工。

6.3.3 参与需求拆分的角色

让业务，产品，开发，测试一同参与需求拆分。

6.3.4 不平等的INVEST原则

• INVEST原则是用于检测用户故事是否拆分得当的6个原则。
• independent（独立）：用户故事必须彼此独立，低耦合
• negotiable（可协商）：在进入开发前，故事卡用来提醒团队和干系人要进行讨论，而不是直接作为产品人员与开发人员之间的契约来使用
• valuable（有价值）：用户故事对用户或客户来讲必须是重要的，有价值的。
• estimable（可估算）：开发团队必须能够估算创建用户故事所需的工作量。
• Small & similar size（规模小切适中）用户故事必须足够小，尽可能要在一个迭代内完成（建议用户故事的开发工作量应该少于3个工作日）并且多个用户故事之间的开发量不宜差异过大。
• testable（可验证）：用户故事必须是可以被验证的。

无法完全满足时，至少要满足可估算，规模小且可验证，即EST>INV。

6.3.5 五大拆分技法

1. 路径拆分法：指根据用户使用场景中的不同路径进行拆分。

image.png

image.png

6.3.6 用户故事的七大组成部分

1. 编号
2. 名称：功能及目标概要
3. 描述：简单介绍这个功能的上相问和业务目的与要求。
4. 技术备忘：简单记录每次讨论过程中一些重要技术点，可能会包括一些设计信息。
5. 前提假设：在对该用户故事进行估算或启动实现时，应该满足那些前提假设
6. 依赖关系：该用户故事依赖那些内外需求
7. 验收条件：该用户故事达到交付标准的定义及描述

6.4 需求分析与需求管理工具集

6.4.1 用户故事地图

image.png

6.4.2 用户故事树

微课看清产品特性全貌，可以使用树状方式进行用户故事管理，按照产品—特性集—用户故事，或者产品—用户—特性集——用户故事等多种级别来组织。

image.png

6.4.3 依赖关系图

依赖关系图从依赖角度来建立用户故事之间的关系。

image.png

6.4.4 需求管理数字化平台。

Jira

6.5 团队协作管理工具

6.5.1 团队共享日历

团队时间表：指对多角色参与的常规活动提前进行实践安排，它可以让所有角色都根据这一固定时间表来规划个人的工作时间与节奏，减少不必要的协调成本，团队时间表中规定了在一个迭代周期中的各种例行协作时间点和内容。

image.png

个人非工作时间表：是指一个团队的工作工作日历，团队中的每个人都将其可预期的非工作时间提前标记下来，比如休假等。

image.png

6.5.2 团队回顾

团队回顾是指所有团队成员在一起共同对过去一段时间中团队协作状态进行总结，以便继续保持那些协作良好的习惯，同事改进出现的问题。团队人员轮流主持。在前期对主持人的要求较高，重点在于要让参与人感到“安全”。并在会议中维持这种安全感。回顾会议会产出团队共识的可执行改善行动列表。并且每个行动都要有一个指定的跟踪者，负责跟中执行情况，并在下次会议汇报执行结果。改善列表不宜过长。聚焦少量改进即可。

6.5.3 可视化故事墙

image.png

6.5.4 明确完成的定义

6.5.5 持续集成——详见第九章

6.5.6 验证故事

image.png