一款产品的整个生命周期可以分成五个阶段，即概念阶段、孵化阶段、验证阶段、运营阶段和业务退市阶段。除概念阶段外，每个阶段都至少包含一个产品迭代周期，每个产品迭代周期中又分为准备期和交付期。
产品版本周期
准备期
目标是让参与该产品版本周期的所有角色对期望解决的业务问题以及最小可行性解决方案达成共识。准备期是团队成员共同探索发现与决策的过程，从最初要解决的业务领域问题出发，业务、产品研发运维团队一起研讨，共同了解和认识业务问题的全貌，并定义业务目标与衡量指标，找出所有可能性解决方案，再通过精炼手段，从备选解决方案中挑选并制订最小可行性解决方案。
迭代期
目标是通过快速迭代，最终验证或解决该业务问题。交付期由多个迭代组成，在下一迭代前对要开发的需求进行详细的分析，并在下迭代开始前，确保所有参与者对需求的验收条件理解一致，更早的发现存在风险的需求，及时沟通和准备。在不断的迭代过程中实现需求的持续流动。
需求拆分的利与弊
瀑布开发方法将工作任务按照活动阶段来拆分，比如需求分析工作、概要设计工作、详细设计工作等等，每个阶段的工作进行再分解，划分不同模块的需求分析工作、概要设计工作等等。这种拆分方式使得只有项目进入测试阶段时各个模块才在一起进行联调，经常导致联调和测试阶段发现的缺陷多，风险很高，也有可能由于需求的变更导致实现的软件无法满足当前的需求。
持续交付2.0建议尽可能从业务的角度出发，将大块业务需求拆分成多个小的业务需求，对这些小的需求进行评估和优先级排序后，分批进行迭代交付，从而尽可能早的得到可运行的产品。
需求拆分的收益
- 建立共识，协调工作：产品经理需与需求相关的角色一起对需求进行拆分，对每个需求的上下文进行充分的讨论，让各个角色对需求的目标、质量标准和验收条件达成一致，从而降低沟通成本，减少不必要的浪费。
- 小批量交付，加速价值流动：将大需求拆分之后进行小批量的开发和测试，从而尽早地交付软件，实现产品的变现，将小批量迭代不断累积价值，加速价值的流动。
- 低成本拥抱变化：在分批交付的过程中，一旦发生突变，比如需求变化或者有更高优先级的需求插入，团队可以快速将手中的需求完成或放弃，投入更加紧急的需求当中。
- 多次集成，及时反馈质量：小批量需求的迭代，版本周期更短，可以提前发现当前版本的缺陷并修复，容易做到质量内置。
- 鼓舞团队士气：每个小迭代的新功能可以很快被用户使用并得到反馈，尽早变现，团队的士气容易高涨。
需求拆分的成本
- 显式成本：产品经理由于不具备深厚的技术背景，需要跟各种角色一起完成需求的拆分，这种做法跟瀑布开发方法相比，显然在项目前期的沟通成本更高。
- 分批开发、测试和部署的迭代成本：分批迭代之后，为了达到交付质量，必须每个迭代都要验证，由于验证次数的增多，验证投入的成本会增加，版本发布的部署成本也会增加。
总结
需求拆分的收益很容易理解，但是也不能忽略其所带来的成本，降低成本是持续交付2.0中的关键问题。
需求拆分方法
技术债也是需求
技术债，团队在设计架构或者开发过程中，基于短期目标选择了一个方便实现的方案，但从长远考虑，这种方案会带来长久的消极影响。另外，技术债还包括影响软件交付速度或业务响应速度的所有重复性且需要花费较长时间的手工操作，比如手工准备测试环境，手动回归测试等。
INVEST原则
将大需求拆分成用户故事story，判断story是否合理的6的原则如下：
- independent：独立低耦合
- negotiable：可协商，story用来提醒团队和干系人要进行讨论，而不是直接下发
- valuable：有价值，story对客户或用户来说是重要有价值的
- estimable：可估算，开发story所需的工作量必须是可评估的
- small & similar size：规模小且适中，必须足够小，尽可能要再一个迭代内完成（一般建议3天），多个用户故事间的差异不宜太大
- testable：可验证
五大拆分方法
路径拆分法
根据用户使用场景中的不同路径进行拆分。
例如：支付订单，可选择微信、支付宝和银行卡支付，按照支付路径的不同，就可以拆分成三个story；如果银行卡的渠道还需要支持不同种类的银行卡，工作量多大，可以根据不同的银行卡支付路径继续拆分。
按接触点拆分
接触点就是用户与系统之间的交付通道。
- 比如移动端和PC浏览器是两个不同的接触点，PC浏览器又可以按照不同的浏览器进一步拆分，比如Safari，Chrome等。也可以按照工作量将接触点重新组织，尽量使得每个小需求的工作量基本相同。
按数据类型和格式拆分
- 比如文件上传，文件有不同的文件格式，包括csv，txt，xml，excel等，每种不同的文件格式可以作为单独的story。
按规则拆分
规则是业务规则或者技术规则。
- 比如选择最佳配送路线的需求，可以建立一个基础需求（拥有一条线路），一个完善需求（时间最短的线路），两者之间是递进依存的关系，”时间最短“只是其中一种规则。
按探索路径拆分
遇到一些很陌生的事物和不确定的实现方案，比如新框架和技术等，可以将对陌生事物的试验性探索逐步拆分成不同的探索故事。
需求分析与管理工具
将一堆的需求拆分成一大堆的小需求，如何管理大量的需求呢？有效的组织和管理，对提供团队的交付效率非常重要。
用户故事地图
用户故事地图
用户故事地图用结构化的二维视图统一团队成员的思想模式，从用户主流程和业务紧急度两个维度共同分析。横轴是主要活动描述，纵轴是优先级，根据地图中需求所处的位置来进行分批实现。比如，目标一就是一个最小可行性解决方案，可以首批交付。
用户故事树
用户故事树
可以从”产品-特性集-用户故事“，也可以按照”产品-用户-特性集-用户故事“等多个级别来组织所有需求，并标记完成情况，让所有人了解项目实施进展。
依赖关系图
用户故事地图是从业务角度来讨论和确认用户故事的，而依赖关系图是从依赖角度来建立用户故事之间的关联关系。虽然希望所有用户故事之间都是相互独立的，但是实际中却是不容易实现，难免会有一定的依赖关系。
需求管理数字化平台
目前市场上有很多需求管理平台，能够极大的提高各角色之间的协作效率，能够更高地保存与组织众多用户故事及需求内容，甚至做到需求与源代码的自动关联。
团队协作管理工具
协作管理工具可以帮助团队提升沟通和协作的效率，最重要的特征就是信息透明和可视化。
团队共享日历
包括团队时间表和个人非工作时间表。
- 团队时间表：对各角色参与的常规活动提前进行时间安排，可以让所有参与者根据团队时间表来规划个人的工作时间和节奏，减少不必要的协调成本。表中规定了每个迭代周期中的各种例行协作时间点和内容。
- 个人非工作时间表：个人将自己可预期的非工作时间提前标记下来，如自己已计划的年假，或者可预期的事假等等，需要保证及时更新。
团队回顾
所有团队成员一起共同对过去一段时间中的团队协作状态进行总结，以便继续保持那些良好的协作习惯，同时持续发现协作中存在的可提升空间，共同探索改进方案。团队参与者是过去一段时间中参与产品准备和交付的所有成员，避免出现经常有人缺席的现象。团队回顾的产出是一个团队达成的可执行的改善行动列表，并且每一项都要指定一个跟踪者，负责跟踪该行动的执行情况。
可视化故事墙
精益的思想强调价值流动，消除各环节中的等待。完整的故事墙需要体现当前迭代的所有内容和状态，包含从需求产生到功能上线的全过程。
可视化故事墙
明确完成的意义
多人协作过程最容易出现理解不一致的问题，团队应该尽可能对每类任务都定义”完成“的标准，这也是质量内建原则的体现，团队成员需要完成哪些活动，交付物达到什么标准，才能表示该需求已完成，可以走向下一个循环。
网友评论