京东敏捷开发秘籍分享的会议记录
作者：互联网
此笔记是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