敏捷产品需求

关注一下下嘛，亲

需求牵一发而动全身，在敏捷开发过程中，如何帮助团队梳理、规划、澄清、管理和拆分需求呢，我们是这么玩滴~

需求的基本单元

大声说出一个需求的

who、what、whay

这就是用户故事

也是需求的基本单元

梳理需求

整个迭代过程中

产品经理和SM牵头发起

需求梳理活动

其目的是提早暴露

下个迭代需求的问题

也即不希望带着问题

进入下个迭代计划会

造成计划会效率低下

甚至计划会失败

在此，我们会使用DoR

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

下图是一个团队的DoR示例

规划需求

用户故事地图

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

通过地图，可以帮助

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

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

用户故事地图保证了

用户体验的完整性

呈现了用户使用我们

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

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

澄清需求

沟通漏斗和知识诅咒

会造成人们沟通的困难

在产品开发过程中

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

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

明确其验收标准

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

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

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

相比一般的规格说明

实例更加场景化

能够激发参与和深度讨论

基于具体的实例

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

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

实例化需求的用例子

可以用来分析和澄清需求

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

最后再通过测试验证需求

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

澄清完需求后

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

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

敏捷开发计划扑克实践

最大的价值不是估算

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

是一种共识的可视化

管理需求

在整个迭代过程中

通过Scrum五会

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

需求的相关问题

通过Kanban方法

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

以此来帮助团队

更加顺畅地交付产品上线

在管理迭代需求的过程中

团队需要重点关注

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

才能交付上线（DoD）

这关系到需求交付的质量

下图是一个团队的DoD示例

拆分需求

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

我们的时间往往被承诺

人力成本是固定的

质量是底线

特性列表往往也不能协商

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

将可变性引向低成本方向

也就是去调整需求的细节

需求拆分

可以有效地帮助团队

去思考需求的复杂度

找出MVS（最小可行方案）

需求拆分

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

按工作流步骤切分

按不同业务规则切分

按主要工作切分

按简答/复杂切分

按不同类型的数据切分

按不同界面切分

延迟性能优化

按操作切分

拆分出一个探针（预研）

随机自相似性

根据随机自相似性

在任何组织任何团队

都会遇到需求

不知该如何

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

这里提供一套解决方法

以缓解产品开发团队

需求之痛

不这么玩的

请开始你们的摩擦~

-----

曝个帅照：）