标签：需求 会议记录 秘籍 教练 用户 反馈 敏捷 京东 列表

此笔记是Bob老师15年在PMCaff线上做的一次分享，供大家参考学习。

活动管理的敏捷实践：

没记。。。

途牛敏捷实践：

1:用户故事地图,做最重要的故事；梳理MVP之后；

2：梳理研发的接口，因为接口用了很多；拆分了4大类接口，有几十个，然后验证，已验证是否满足需要；

3：scrum方式来开会梳理风险；

4：定期梳理产品列表；

京东内部敏捷方式：

1：透明，迭代，反馈，教练   中间是价值。一个核心：价值，四个基本点；透明，迭代，反馈，教练

所有模型都是错的，但都是有用的

1）一个核心价值：

做软件开发的目的是什么，为了解决用户问题，要找到用户需求，用户的问题是什么；一定要做有价值的事情；可不可以通过其他方式解决；

实践：

产品待办列表（produce backlog）

好的产品待办列表ODDE     O:排序的，有一个唯一顺序，按价值排序，按容易度排序。优先级p1:马上做，p2:必须要做的，p3：还可以，有时间最好做，p4：基本不会做，但问题是所有需求都会事p1,p2，如果都是p1,p2需求，如何处理；

敏捷里有一个需求唯一顺序，价值高的排前面，价值低就排在后面；

D：详略得当：当前要做的需求和下一个要做的需求都是详细的，要做成什么样子都想好了，参考值一个需求大概2-3天内就能做完的；

下一个要做的就是粗粒度的，如要做用户登录，但没有想细节；

2-3个月要做的，下一个版本要做的，

ios版本要做，版本规划就是

D:动态的，产品列表当前的条目不是一成不变的，粗粒度的会有一个产品待办需求，有些可能可能根据实际情况调整

E：估算过的，为什么要估算，按价值排序，按容易度排序

一定要管理好，

2）透明

在软件开发透明尤其重要，因为软件开发很多工作不可见，做出来的软件也没有交付给用户，所以也是不可见的，所以导致业务方一直加需求。

研发团队状态和进度一定要透明，

实践：

任务版，一定要从物理任务版开始，方便大家随时查看，成本也低，也方便大家做各种调整；不推荐电子形式，不便于团队查看到底进展到什么程度；

把核心确定后，产品列表出来后就弄一个任务版

3)迭代

盒子（Box）理论（限制）

迭代就是重复做事情，重复做事情就是盒子理论，一定要有限制，时间盒子限制，资源盒子限制；

注：用时间盒做限制，2-3周，一般建议2周，到2周就结束了；然后回顾，review，每两周团队拿出一些真正的成果，潜在可交付的软件，然后才可以拿给用户看看；

4）反馈

开发的软件为什么不能满足用户的需求，传统的都是做完了才给用户用，才有用户使用的反馈；

获取用户反馈

实践：（scrum）

每日站会：昨天完成了什么，今天打算完成什么，工作中有没有碰到问题？不超过15分钟；超时违背站会原则。每个人都获得了其他团队进展信息反馈；

评审会议（review），不是演示会议，不是demo show，评审会议，十分钟。为收集反馈，用户使用软件后有没有什么反馈，有没有什么问题；

所有研发人员，拿起笔，拿起值，让产品人员介绍完成了哪些功能，然后让用户操作使用软件，然后所有开发技术记录用户操作不下去了，

使用问题，或者表情发生变化；或者表情发生了变化，都需要记录下来，反映倒产品列表中；

回顾会议

一起反思工作模式能不能更好，回顾会议，一定要产生行动计划，并具有可操作性，行动计划做的不好，太抽象，可能效果不好；如改善沟通效率。。应该记每周2，周4产品和技术沟通，这样才是可执行；

5）教练

一定要有教练，新团队敏捷转型，教练知道哪些敏捷，哪些是非敏捷的，让教练有强有力的提问，做一个例子你们看看是怎么做的；

要么是内部教练，要么是外部教练

标签：需求,会议记录,秘籍,教练,用户,反馈,敏捷,京东,列表
来源： https://blog.csdn.net/kun20031029/article/details/115715812

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。