第六章：业务需求协作管理
业务需求协作管理贯穿于整个软件产品版本周期，涉及与业务软件交付相关的所有角色，包括业务人员、产品及运营人员、开发人员、测试人员和运维人员等
目标是通过改善各角色在持续交付“8”字环各环节中的交互协作流程，有效且高效的完成业务问题的分析、业务方案的实施和结果验证工作，并确保所有需求不遗漏，被完整跟踪
产品的整个生命周期（5个阶段）
概念阶段：需要清楚回答市场机会、客户需求的紧迫性、企业自身的竞争优势、产品的可行性以及自身产品团队能力等问题
孵化阶段：考察产品核心功能的完善度、满足典型目标用户的核心诉求程度，小范围试验用户的反馈等问题
验证阶段：主要关注最小核心功能集的用户体验、早期用户的反馈、盈利模式，以及产品技术核心团队的稳定性与加大资源投入的可行性
运营阶段：主要关注市场环境变化、客户泛化需求的存在性，以及投入产出比
业务退市阶段：运营阶段的要素不满足企业的预期，可考虑产品的退市步骤
除概念阶段以外，每个阶段都至少包含一个产品版本周期。
在每个产品版本周期中，又分为准备期和交付期。它们由多个迭代构成，每个迭代至少包含一个持续交付“8”字环，用于解决一个（或一组）业务领域问题
产品版本周期概述：
准备期（迭代0或启动期）：团队成员共同探索发现与决策的过程，是一个先发散后聚焦的过程。
参与者通常包括有决策权的业务方各角色代表与IT方各角色代表
核心任务是达成业务理解与目标的共识
目标是让参与该产品版本周期的所有角色对期望解决的业务问题以及最小可行解决方案达成共识。
主要包括以下工作内容：
1.目标阐述与理解：业务代表讲解当前这个产品版本周期内所需达成的重要业务目标，以及相关的业务上下文。参与者应积极参与互动，以便充分理解业务
2.业务领域角色与流程识别，及解决方案的探索：全体参与者共同讨论并识别该业务问题所涉及的主要业务流程与流程中的业务角色，并找到尽可能多的解决方案
3.重大风险识别与验证：识别各种方案中的业务与技术风险，并且组织人员对那些影响决策的重大风险进行快速验证
4.精炼并达成最小可行方案共识：从众多的解决方案中挑选并制定最小可行解决方案
5.评估与计划：对最小可行解决方案进行初步的工作量与时间评估，制订相应的交付计划
交付期：由多个迭代组成，各迭代周期应尽量保持一致
目标是通过快速迭代，最终验证或解决该业务问题
团队应该在当前迭代刚刚开始后，立即着手对后续迭代要开发的需求进行详细分析，并在下一个迭代开始前，确保所有参与者对需求的验收条件理解一致，达成共识
以上做法会有两个收益，一是更早发现还存在风险的需求，提前进行沟通和准备，二是一旦提前完成了当前迭代的内容，可以从下个迭代需求列表中选择一些需求进行开发，没有间断
每个角色会有多种任务
产品人员：
及时回答其他角色对本次迭代需求提出的疑问
及时验收在本迭代中完成的需求
组织其他角色，为准备后续迭代的内容进行需求筛选与分析
开发人员：
开发当前迭代中的需求
及时修复测试人员发现的缺陷
参与后续迭代的需求分析与用例评审
测试人员：
及时验收刚刚开发完成的需求
验收已被修复的缺陷
参与后续迭代的需求分析，并对其进行测试用例分析，组织测试用例评审
同时开发人员与测试人员还要应对生产环境出现的问题，及时进行分析与解决
需求拆分的利与弊
利于持续交付的需求拆分总原则：坚持以业务视角对需求进行分解
需求拆分的收益：
建立共识，协调工作：需求拆分时，与该需求相关的所有角色均需参与。每个需求的边界上下文都应被充分讨论，从而让各角色对该需求的目标、质量标准和验收条件达成一致
小批量交付，加速价值流动：将较大的需求进行拆分后，就能够进行小批量开发与测试，从而尽早的交付软件，让用户更早的使用软件
低成本拥抱变化：在分批交付过程中，一旦在开发过程中遇到突发情况，团队可以快速将手中任务完成（或放弃），然后投入新插入的高优先级需求
多次集成，及时反馈质量：小批量需求开发完成后无法马上交付给用户，我们也可以进行联调与测试。如果发现软件缺陷，则可以及时修复
缺陷过多，可能是3种原因：
开发人员对需求理解尚不到位
研发质量标准没有得到很好的贯彻执行
团队成员之间沟通不充分，有很多误报现象
鼓舞团队士气：每个迭代开发的新功能都立即被用户使用，并且得到反馈，团队就会收到鼓舞
需求拆分的成本：
需求拆分时的显式成本：将其他角色卷入需求拆分的过程，会在项目前期增加更多的沟通成本
分批开发、测试和部署的迭代成本：分批迭代交付，为了达到交付质量，需要进行验证，以确保功能正确运行。验证次数增多，则对应的验证投入成本会增加
需求拆分方法：
需求的来源：
进入交付期前，最小可行解决方案的需求列表中，需求来源由以下3部分组成
业务人员提出的业务功能需求。这些业务需求构成了整个产品版本的基础需求
为了保障业务需求的实现与运行而必须满足的非业务功能需求，例如因页面响应时间要求而产生的性能需求、因成本控制而产生的自动扩缩容要求等
符合安全合规性而产生的安全开发需求
进入交付期后，每个迭代的需求列表中，需求来源可以包括以下7个部分
从原始需求列表中选出的待实现需求
在需求细化过程中新发现的需求
已知且需要修复的线上生产系统缺陷
线上技术运营要求
前期预研需求，它是指团队目前尚不具备能力，但为了实现某一业务需求而做的准备工作
技术债需求，它是指因早期业务进度压力而积累的技术债改进需求
辅助测试需求：为了便于进行需求验收，需要开发的测试辅助工具
技术债也是需求：
技术债：指技术团队在设计架构或者开发的过程中，基于短期目标选择了一个方便实现的方案，而从长远考虑，这种方案会带来长久的消极影响
技术债产生的原因：
满足眼前需求，没有更进一步考虑。即使后续增加功能也没有进行适当重构
低质量代码（硬编码、魔术数字、重复代码等）
对持续交付模式来说，还有一种“技术债”，即影响软件交付速度或业务响应速度的所有重复性且需要花费较长时间的手工操作，例如手工准备测试环境、手工回归测试、手工部署与发布等
参与需求拆分的角色：
传统瀑布开发模式：产品经理（或业务分析师）撰写需求规格说明书
持续交付模式：产品经理、开发人员、测试人员等都参与用户故事的编写
不平等的INVEST原则：
Independent（独立）：用户故事必须彼此独立，低耦合
negotiable（可协商）：在进入开发前，故事卡用来提醒团队和干系人要进行讨论，而不是直接作为产品人员与开发人员之间的契约来使用
valuable（有价值）：用户故事对用户或客户来讲必须是重要的，有价值的
estimable（可估算）：开发团队必须能够估算创建用户故事所需的工作量
Small & similar size（规模小且适中）：用户故事必须足够小，尽可能要在一个迭代内完成（建议用户故事的开发工作量应该少于3个工作日）；并且多个用户故事之间的开发工作量差异不宜过大
testable（可验证）：用户故事必须是可以被验证的
一些比较复杂的用户需求，很难同时满足这6个原则，但至少要满足可估算、规模小且可验证，及EST>INV
假如无法独立交付，但在较短时间内可以独立开发和独立验证，且不影响当前完成的软件功能，则也是可行的
SMART原则：具体的（specific）、可衡量的（measurable）、可达成的（achievable）、相关的（relevant）、有时间限定的（time bound）
五大拆分技法
路径拆分法：根据用户使用场景中的不同路径进行拆分，例如用户在电商网站购物以后，需要支付订单，可以选择微信支付，也可以选择银行卡支付，这就可以拆分为两个故事卡
按接触点拆分：所谓接触点就是指用户与系统之间的交互通道，例如移动端应用和PC浏览器是两种不同的接触点
按数据类型或格式拆分：例如有一个软件，用来做数据统计和分析。其中有这样一个需求，用户可以通过文件形式向软件系统导入数据，文件格式包括csv、xml、excel
按规则拆分：规则是指业务规则或技术规则
按探索路径拆分：在开发过程中，团队总是遇到一些对团队来说都很陌生的事物或不确定的实现方案。此时可以将对陌生事物的试验性探索逐步分拆成不同的探索故事
七大组成部分：
用户故事（最早来自极限编程的十二最佳实践，称呼交付迭代中的需求，用户故事刚刚诞生的初始形式）：
作为 ……一个xxxxx用户……
为了完成 ……yyyyyyy业务……
我希望能够 ……使用zzzzz功能……
7个组成部分：
1.编号：方便记录与跟踪
2.名称：该功能及其目标概要
3.描述：简单介绍这个功能的上下文和业务目的与要求
4.技术备忘：简单记录每次讨论过程中的一些重要技术点，可能会包括一些设计信息
5.前提假设：在对该用户故事进行估算或启动实现时，应该满足哪些前提假设
6.依赖关系：该用户故事依赖哪些内外需求
7.验收条件：该用户故事达到交付标准的定义与描述
需求分析与管理工具集：
用户故事地图：
用户故事地图的概念来自《用户故事地图》，既是一种团队沟通工具，也是一种需求分析管理工具
常被用于产品版本周期中的准备期
它用结构化的二维视图统一团队成员思维模式，从用户主流程和业务紧急程度两个维度共同分析，并可以定期将该地图取出，重新审视与修订
用户故事树：为了看产品特性的全貌，可以使用树状方式进行用户故事的管理
依赖关系图：从依赖角度来建立用户故事之间的关联关系
需求管理数字化平台：类似看板
团队协作管理工具：
团队共享日历：
团队时间表：对多角色参与的常规活动提前进行时间安排，它可以让所有角色都根据这一固定时间表来规划个人的工作时间与节奏，减少不必要的协调成本，团队时间表中规定了在一个迭代周期中的各种例行协作时间点和内容
个人非工作时间表：指一个团队的工作日历。团队中的每个人都将其可预期的非工作时间提前标记下来，如自己已计划的年假，或者可预期的事假
团队回顾：
所有团队成员在一起共同对过去一段时间中的团队协作状态进行总结，以便继续保持那些良好的协作习惯，同时持续发现协作中存在的可提升空间，共同探索改进方案
参与者：过去一段时间中参与产品准备或交付活动的所有成员
回顾会议的产出是一个团队达成共识的可执行的改善行动列表，并且每一个行动项都要指定一个跟踪者，负责跟踪该行动的执行情况，并在下次回顾会议时呈报执行结果。改善行动列表不宜过长，应该聚焦于少量最重要的改进项。
可视化故事墙：
将用户需求写到卡片上，并根据当前的状态或者所处的阶段，放置于相应的位置
需包含需求产生到功能上线的全过程
明确“完成”的定义：
多人协作过程最容易出现的就是理解不一致
团队应该尽可能对每类任务都定义“完成”的标准
持续集成：
将需求分解成更细粒度后，团队多人可以并行开展工作，同时也应该将工作成果持续集成在一起，并确保达到质量标准
故事验证：达成共识 -> 开发 -> 自测 -> 迷你验收 -> 故事验证
