用户故事地图

刚学完敏捷课程的时候觉得自己什么都会了，不管是日常敏捷实践还是精益，XP 或者是TDD. 你敢问我，我就敢告诉你这些都是什么. 但是随着时间推移，在敏捷的环境里工作越久越觉得自己知道的太少了，太不具体了. 

项目需求，是一个项目成功与否很重要的部分，看了很多关于项目需求的资料，引用其中一篇，记录下自己的理解跟经验以及遇到的问题。

原文链接：http://kuaibao.qq.com/s/20180506G17A7400?refer=cp_1026

需求牵一发而动全身，在敏捷开发过程中，如何团队梳理、规划、澄清、管理和拆分需求

需求的基本单元：who、what、whay

这就是用户故事

也是需求的基本单元

梳理需求

整个迭代过程中

产品经理和SM牵头发起

需求梳理活动

其目的是提早暴露

下个迭代需求的问题

也即不希望带着问题

进入下个迭代计划会

造成计划会效率低下

甚至计划会失败

在此，我们会使用DoR

来梳理把控进入计划会的需求质量

下图是一个团队的DoR示例

规划需求

用户故事地图

是组织和规划产品需求的神器

通过地图，可以帮助

我们看到需求的整体和关联

及时暴露产品设计过程中的问题

用户故事地图保证了

用户体验的完整性

呈现了用户使用我们

产品方案的端到端的场景路径

打通了产品设计和开发计划

澄清需求

沟通漏斗和知识诅咒

会造成人们沟通的困难

在产品开发过程中

我们要做到以终为始的沟通

开始开发前，充分澄清需求

明确其验收标准

并保证相关人员对需求的一致理解

实例化需求方法从场景出发

以用户的操作实例来澄清需求

相比一般的规格说明

实例更加场景化

能够激发参与和深度讨论

基于具体的实例

更加便于沟通中的双向确认

保证理解的一致和场景覆盖

实例化需求的用例子

可以用来分析和澄清需求

这些例子随后会转化为测试用例

最后再通过测试验证需求

当产品经理使用实例化的方式

澄清完需求后

团队每个人对需求进行估算

以此可视化团队对需求的理解是否一致

敏捷开发计划扑克实践

最大的价值不是估算

而是可以帮助团队对需求的理解达成共识

是一种共识的可视化

管理需求

在整个迭代过程中

通过Scrum五会

来梳理、跟踪、演示和回顾

需求的相关问题

通过Kanban方法

来透明迭代需求的进展、问题和风险

以此来帮助团队

更加顺畅地交付产品上线

在管理迭代需求的过程中

团队需要重点关注

一个需求满足了什么样的条件

才能交付上线（DoD）

这关系到需求交付的质量

下图是一个团队的DoD示例

拆分需求

在很多关键产品交付过程中

我们的时间往往被承诺

人力成本是固定的

质量是底线

特性列表往往也不能协商

所以，我们只能从细节入手

将可变性引向低成本方向

也就是去调整需求的细节

需求拆分

可以有效地帮助团队

去思考需求的复杂度

找出MVS（最小可行方案）

需求拆分

我们可以从以下维度来思考

按工作流步骤切分

按不同业务规则切分

按主要工作切分

按简答/复杂切分

按不同类型的数据切分

按不同界面切分

延迟性能优化

按操作切分

拆分出一个探针（预研）

随机自相似性

根据随机自相似性

在任何组织任何团队

都会遇到需求

不知该如何

规划、梳理、澄清、管理的问题

这里提供一套解决方法

以缓解产品开发团队

需求之痛

不这么玩的

请开始你们的摩擦~

发表于: 2018-05-06

因为有你便成了我们

原文链接：http://kuaibao.qq.com/s/20180506G17A7400?refer=cp_1026

腾讯「云+社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。