业务需求协作管理

业务需求协作管理

软件产品的生命周期

·一款产品的整个生命周期可分成以下5个阶段，即概念阶段、孵化阶段、验证阶段、运营阶段和业务退市阶段

概述

• 概念阶段：需要清楚回答市场机会、客户需求的紧迫性、企业自身的竞争优势、产品的可行性以及自身产品团队能力等问题
• 孵化阶段：需要考察产品核心功能的完善度、满足典型目标用户的核心诉求程度，小范围实验用户的反馈等问题
• 验证阶段：需要关注最小核心功能集的用户体验、早期用户的反馈、盈利模式，以及产品技术核心团队的稳定性与加大资源投入的可行性
• 运营阶段：需要关注市场环境变化、客户泛化需求的存在性，以及投入产出比等
• 退市节点：当运营阶段不能满足企业的预期，就应该考虑产品的退市步骤了

产品版本周期

简述

• 一个产品版本周期包含准备期和交付期
• 准备期的目标是让参与该产品版本周期的所有角色，对期望解决的业务问题，以及最小可行解决方案达成共识
• 交付期的目标是通过快速迭代，最终验证或解决该业务问题

分析

准备期

概述

• 准备期是团队成员共同探索发现和决策的过程，核心任务是达成业务理解与目标共识
• 有时候，人们会将这个准备期称为“迭代0”或者“启动期”
• 准备期的参与者通常包括有决策权的业务各方代表与IT方角色代表，因为进入交付期之前需要对最小可行解决方案达成共识，做出决策。尽可能保证准备期的参与者能够参与交付期的工作，至少应该保证准备期的主要参与者能够参与。通过这样，可以使交付期中的相关决策也能更精准
• 准备期不但要有最小可行解决方案，还要回答“它大约需要多久才能执行并验证完成”

准备期的工作内容

• 目标阐述与理解

  业务代表讲解当前这个产品版本周期内所需要达成的重要业务目标，以及相关业务上下文。参与者应积极参与与互动，以便充分理解业务
  

• 业务领域角色与流程识别，及解决方案的探索

  全体参与者共同讨论并识别该业务问题所涉及的主要业务流程与流程中的业务角色，并找到尽可能多的解决方案
  

• 重大风险识别与验证

  识别各种方案中的业务与技术风险，并且组织人员对那些影响决策的重大风险进行快速验证
  

• 精炼并达成最小可行方案共识

  从众多解决方案中挑选并制定最小可行解决方案
  

• 评估与计划

  对最小可行解决方案进行初步的工作量与时间评估，制定相应的交付计划
  

交付期

概述

• 在准备期得出的初步计划达成共识后，团队即可进入交付期
• 交付期也可以由多个迭代组成，各迭代周期应尽量保持一致
• 团队在当迭代开始后，需要着手对后续要开发的需求进行详细分析，并在下一个迭代开始前，确保所有参与者对需求的验收条件理解一致，达成共识。提前分析的收益有两点：一是更早发现还存在风险的需求，提前进行沟通和准备；二是一旦提前完成了当前迭代的内容，可以从下个迭代需求列表中选择一些需求进行开发，没有间断

人员职责

• 产品人员

  及时回答其他角色对本次迭代需求提出的疑问
  
  及时验收在本迭代中完成的需求
  
  组织其他角色，为准备后续迭代的内容进行需求筛选与分析
  

• 开发人员

  开发当前迭代中的需求
  
  及时修复测试人员发现的缺陷
  
  参与后续迭代的需求分析与用例评审
  

• 测试人员

  及时验收刚刚开发完成的需求
  
  验收已被修复的缺陷
  
  参与后续迭代的需求分析，并对其进行测试用例分析，组织测试用例评审
  

需求拆分的利与弊

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

需求拆分的收益

• 建立共识，协调工作

  在持续交付模式下，进行需求拆分时，与该需求相关的所有角色均需参与，
  以保证每个需求的边界上下文都被充分讨论，从而让各角色对该需求的目标、质量标准和验收条件达成一致
  

• 小批量交付，加速价值流动

  进行小批量开发和测试，从而尽早地交付软件，让用户更早地使用软件
  

• 低成本拥抱变化

  在分批交付过程上，在遇到突发情况时，团队可以快速将手上的任务完成（或放弃），
  然后投入新插入的高优先级需求
  

• 多次集成，及时反馈质量

  通过小批量开发可以方便的进行联调和测试，以及及早的修复在此过程中发现的缺陷
  

• 鼓舞团队士气

  每个迭代开发的新功能都立即被用户使用，并且得到反馈，团队就会收到鼓舞（无论是点赞还是吐槽）
  

需求拆分的成本

• 需求拆分时的显式成本

  在需求拆分得过程中，将产品经理（通常不具备深厚的技术背景）与其它角色卷入这个需求拆分得过程中，
  一同参与和确认是非常必要的，此种方式会在项目前期增加更多的沟通成本
  

• 分批开发、测试和部署的迭代成本

  分批迭代交付时，为了达到交付质量，每次都需要进行验证，以确保已交付的所有软件功能正确运行，在此过程中需要投入更多的人力成本
  

需求拆分分析

在准备期结束后，得到了最小可行解决方案的需求列表，但是，此列表中的需求并非粒度足够细，也不一定完全明确可以直接指导开发工作。此后，我们要以“渐进明晰”为原则，每个迭代都应该做一些需求分析与细化工作

需求的来源

• 最小可行解决方案的需求来源

  业务人员提出的业务功能需求。这些需求构成了整个产品版本的基础需求
  
  为了保障业务需求的实现与运行而必须满足的非业务功能需求。例如性能问题、自动缩扩容要求
  
  符合安全合规而产生的安全开发需求
  

• 交付期的需求来源

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

参与需求拆分的角色

在持续交付模式下，拆分用户故事的工作通常由产品经理、开发人员、测试人员一并参与，这样可以让彼此更多的掌握产品需求上下文，也能更多的增加对业务需求和用户故事的了解，并深入了解产品需求和用户故事的全部意图，通过不同的角色思考，找到更多更好的方式来实现这些需求

不平等的INVEST原则

INVEST原则是用于检验用户故事是否拆分得当的6个原则

6个原则

• independent（独立）

  用户故事必须彼此独立，低耦合
  

• negotiable（可协商）

  在进入开发前，故事卡用来提醒团队和干系人要进行讨论，而不是直接作为产品人员与开发人员之间的契约来使用
  

• valuable（有价值）

  用户故事对用户或客户来讲必须是重要的，有价值的
  

• estimable（可估算）

  开发团队必须能够估算创建用户故事所需的工作量
  

• small & similar size（规模小且适中）

  用户故事必须足够小，尽可能要在一个迭代内完成（建议用户故事的开发量应该小于3个工作日）；
  并且多个用户故事之间的开发工作量不宜过大
  

• testable（可验证）

  用户故事必须是可以被验证的
  

SMART原则

·即具体的（specific）、可衡量的（measurable）、可达成的（achievable）、相关的（relevant）和有时间限制的（time bound）

五大拆分技法

• 路径拆分法

  路径拆分法是指用户使用场景中的不同路径进行拆分。例如用户在电商网站购物以后，需要支付订单，
  既可以选择微信支付，也可以选择使用银行卡支付
  

• 按接触点拆分

  所谓接触点就是指用户与系统之间的交互通道。例如移动端应用和PC浏览器是两种不同的接触点
  

• 按数据类型或格式拆分

  例如上传文件，文件格式包括CSV、XML和Excel，那么我们的用户故事可以直接拆分成3个
  

• 按规则拆分

  规则是指业务规则或者技术规则
  

• 按探索路径拆分

  在开发过程中，遇上一些对团队来说都很陌生的事物或不确定的实现方案，此时可以将此类事物逐步拆分成不同的探索故事。
  此类事物有较大的不确定性，因此需要作为高风险点管理，时刻关注其进展。例如使用某种新的框架或技术
  

用户故事（User Story）七大组成部分

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

需求分析与管理工具集

用户故事地图

• 用户故事地图既是一种团队沟通工具，也是一种需求分析管理工具
• 常被用于产品版本周期中的准备期
• 每张用户地图上，横轴是该地图拥有者的活动主路径，在横轴之上是主要活动描述，可以称为史诗故事（或者功能集）。在横轴之下（纵轴），每个史诗故事的下方是该史诗故事拆分出来的更细粒度的用户故事。纵轴标识根据显示目标制定的业务优先级，即高优先级的在上面，次之的放在下面

用户故事树

• 使用树状方式进行用户故事的管理，可以方便的查看产品特性的全貌
• 按照“产品-特性集-用户故事”或者“产品-用户-特性集-用户故事”等多种级别来组织，并且标记完成情况，使所有人了解产品的进展

依赖关系图

• 用户故事地图是从业务角度来讨论和确认用户故事，而依赖关系图是从依赖角度来建立用户故事的关联关系
• 大型复杂项目通常会由多个团队共同完成。不同团队开发的用户故事之间也会存在依赖关系，通过依赖关系图可以让你更容易组织和管理这些需求及其交付进度

需求管理数字化平台

• 在分布式团队的环境中，数字化需求管理平台是提高团队协作效率的必备工具

团队协作管理工具

团队共享日历

简述

• 共享日历是一种有效的团队时间管理方法
• 共享日历可以分为两种：一是团队时间表；二是个人非工作时间表

分析

团队时间表

• 团队时间表是指多角色参与的常规活动提前进行时间安排，它可以让所有角色都根据这一固定时间表来规划个人的工作时间与节奏，减少不别要的协调成本，团队时间表中规定了在一个迭代周期中的各种例行协作时间点和内容
• 这个时间表的制定需要多角色共同商定，尽可能满足每个角色的时间需求，避免因经常发生事件冲突而导致时间表失效的问题

个人非工作时间

• 个人非工作时间是指一个团队的工作日历
• 团队中的每个人都将其可预期的非工作时间提前标记下来，如自己已计划的年假，或者可预期的事假
• 时间表发挥作用的一个重要前提是“及时更新”

团队回顾

• 团队回顾是指所有团队成员在一起共同对过去一段时间中的团队协作状态进行总结，以便继续保持哪些良好的协作习惯，同时持续发现协作中存在的可提升空间，共同探索改进方案
• 团队回顾会议的参与者应该包括在过去一段时间中参与产品准备或交付活动的所有成员。这种针对改善团队协作方面的会议也应该周期性举行，并避免经常有人缺席线性
• 在会议开始前，主持人应该让参与者感到“安全”，并在会议过程维持这种“安全感”。在讨论过程中，要求意见表达者使用正确的表达方式，例如“我看到了…我的感觉是…我想…这么做是不是会更好…你觉得呢？”。一旦发现表达者或信息接收者过于情绪化，主持人应该及时提醒，并设法解决情绪上的矛盾
• 回顾会议的产出是一个团队达成共识的可执行的改善行动列表，并且每一个行动项都要指定一个跟踪者，负责跟踪该行动的执行情况，并在下次回顾会议时呈报执行结果。这个改善行动列表不宜过长，每次都应该聚焦少量最重要的改进项，以确保能够切实执行，否则会使会议流于形式

可视化故事墙

• 采用卡片墙方式对需求进行管理，即将用户需求写到卡片上，并根据当前状态或者所处阶段，放置于对应的位置
• 常见的有两种方式：一是根据任务状态（To Do/Doing/Done）进行简单分类；二是根据迭代需求的研发状态（待开发/开发中/待测试/测试中/测试完成/待发布）进行分类管理

明确“完成”的定义

• 团队应该尽可能对每类任务都定义“完成”（Done）的标准，这也是验证环质量内建原则的一种体现
• 通过对“完成标准”的定义，可以加强团队成员的质量意识，规范团队质量行为，而这些“完成”的定义不但应该让大家知道，而且应该显式张贴出来，以便在工作中时刻受到提醒

持续集成

故事验证

• 当开发人员准备开发前，应该与产品和测试人员共同对该用户故事的7项内容进行快速审查，并达成共识
• 开发人员开发完成后，应该进行自测，再让产品人员在自己的开发调试环境上做快速验收（也称为迷你演示）
• 没有发现明显问题或严重问题，再转交测试人员对这个用户故事马上进行全面验收
• 故事迭代流程：共识-开发-自测-迷你验收-故事验证