其他分享
首页 > 其他分享> > 京东敏捷开发秘籍分享的会议记录

京东敏捷开发秘籍分享的会议记录

作者:互联网

此笔记是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