规划与设计

1. 增量式交付

什么是增量式交付？

• 起步于粗糙的产品原型/框架

• MVP —— minimum viable product （MVP）最小可用产品

• 细节功能不完善，但是可以验证用户的整体使用场景是可以独立交付的

• 行走的骨骸 —— 没有人形，但是具备了的人所有基础框架

• 每增加一点功能，用户都能体会到价值的提升

• 持续改进 —— 一次把糖果都给小朋友，每次给一颗糖的区别

• 与用户一同寻找最终的产品

• 用户能从早期的增量，更加理解后面的需求

敏捷开发的基石是“增量式交付”。增量交付是指为及时反馈和接纳，频繁向客户交付连续改善的工作产品

增量式交付 vs. 瀑布式交付

• 交付目标确定，二者基本相同

• 目标是变化的，增量式需要投入更多的周期和资源，最终交付了同瀑布不同的目标

• 也就是说，瀑布式交付适用于目标不变的场景，增量式交付适用于目标不确定复杂变化的场景

• 然而，软件的目标总是会变化

• 

2. 两个工具解决增量交付问题：可视化产品研发

• 影响地图（Impact Mapping）

• 业务目标 ——> 功能规划

• 极度抽象的概念 —场景、用户故事—> 产品规划

• 用户故事地图（User Story Mapping）

• 功能规划 ——> 功能实现

• 抽象的功能规划 ——> 明确和极度明确的开发任务

影响地图 —— 一个价值导向的实践方法

• 使用可视化的方法，建立商业目标与产品功能的联系，并将联系背后的假设可视化出来

• 

如何实践影响地图 —— 通过四个问题达成统一认知

如何实践影响地图 —— 对复杂任务关系进行分析拆解

• 例如 100 万 玩家就是一个明确的目标（Why）

• 玩家就是一个和目标有关联的角色（Who）

• 玩家可以通过邀请朋友的方式来帮助实现 100 万玩家的目标（How）

• 如何去做，玩家邀请朋友，可以通过半自动化的形式来邀请（What）

• 将 Waht 和 Why 建立了关联

如何实践影响地图 —— 建立产品目标与功能之间的关系

解决业务和技术无法对话的问题

• 业务部门及开发部门之间的理解、沟通、协调及隔阂

• 目标到功能间联系的模糊和不一致

• 

增量式交付的真正问题

• “只见树木不见林”，重要的代办项容易淹没在各种细节中看不到原貌，难以排列优先级

• 不能明显地聚焦于用户需求

• 不能方便地了解系统提供的功能的完整性

• 不能方便地利用递增和迭代的方式去确定发布计划以及发布目标

• 这样就需要另外一个工具 —— 用户故事地图

用户故事地图（User Story Mapping）

• 透过可视化的方式，建立用户场景与技术规格之间的联系，并辅助团队有效沟通

• 第一个用户故事地图

• 

用户故事地图是框架

• 让用户在产品还没有做出来之前就可以体验到产品所提供的功能，并以二维结构呈现产品的主线功能和辅助功能， 帮助设计者决策

• 故事地图可以，帮助客户选择每个发布包含的产品特性并且进行分组根据产品特性的重要性

• 分为主干，行走的骨骼和额外的特性

• 主干级别的特性，<font color="red">不需要进行优先级排序</font>，包含在系 统中就可以了

• 行走的骨骼是可能工作的最小系统，它是基于主干功能的

• 额外的产品特性在行走的骨骼下面，并且是<font color="red">基于优先级</font>进行排序

• 

从项目到可落地的计划

• 将特性根据重要性和顺序放置到地图上后，可以根据客户的优先级和团队的速率进行平衡，来确定版本计划

• 

用户故事地图示例

一个真实的需求讨论会案例

用户故事总结

• 用户故事地图使用的三个步骤

• 一、广度优先，从左到右，讲述用户经历的重要步骤（体现交互最好）

• 二、深度优先，争对每个主流程进行细化

• 三、版本规划确认 MVP

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多 IT 技术、干货知识、热点资讯。