京麦敏捷OpenSpace之旅第一期活动记录
您目前处于:技术领导力  2017-02-15

# 开场

京麦团队是一个敏捷团队,从2013年开始实践敏捷,曾受训于姜信宝、王立杰等多位敏捷大师,团队拥有多位国际认证的Scrum Master,在实践敏捷的道路中,不断迭代,进行过程自我改进,沉淀下丰富的京麦。

并在2014年荣获全球TOP 100最佳实践案例(京麦敏捷转型 —— 一起做正确的事)。

京麦团队将在2017年进行了大量敏捷的OpenSpace,敏捷 Planning Meeting、Stand Meeting、Review & Retro,以及需求工作坊敏捷分享实践,真诚的欢迎大家有时间一起前来参与交流、相互学习。


# 需求阐述会

我们将计划会议分为迭代需求阐述会和正式计划会议,那这到底是什么呢?

需求阐述会是京麦迭代过程中重要的一趴,是在进行正式计划会议之前,对需求进行的第一次筛选的。

(需求阐述会)

我们在“需求阐述会”都做了什么?

只做一件事:在产品需求池中,按照需求优先级讲解需求故事,并粗略的对故事需求进行规模(人日)评估和预估上线时间节点的确认。

你可能会问,只做这么多?是的,需求阐述会仅仅是对迭代需求的一个预估,而在计划会议上,才会真正的评估出故事规模和准确的上线时间。

为什么要区分“计划会议“和”需求阐述会”?

因为通过敏捷实践,如果没有事前对需求的梳理,对故事的评估基本都是‘拍脑袋’,而将‘需求阐述’和‘故事确认’分开,也是要做到在了解需求基础上,更加对需求的深挖。

(计划会议)

那在“计划会议”上还要做什么呢?

1. 会由团队每个小伙伴对自认领的需求进行讲解,而不是由产品了,产品在需求阐述会是从业务角度讲,在计划会议研发小伙伴是从功能拆分上讲解。

2. 每个故事被讲解清楚之后,则由团队一起对故事进行规模(人日)评估,通过‘专家和小工’一起把控,并且是被大家共同认可的。

3. 按照优先级逐个讲解,直到故事规模累计总和略超过团队最大预估规模,则不再继续评估,后续任务被自动延期,如果存在异议,则通过调整优先级的方式重新排列。

4. 在确认所有故事需求之后,由团队对故事进行任务拆分,精确到小时规模,以用于看板燃尽图统计和任务更新。

至此计划会议结束,迭代正式开始。


# Rview & Retro

10个工作日之后,京麦团队定时召开 Review & Retro,讲解敏捷实践中如何运用敏捷技巧在 Review 进行需求故事的演示和在 Retro 进行团队回顾进行自组织过程改进等。

为什么要进行 Review & Retro?

听听我们的小伙伴是怎么说的吧:

产品A:Review & Retro 对我来说是一个产品验收和确认的会议,对我很重要。

产品B:Review & Retro 中的产品验收环节是一方面,还有一方面是团队中每个人对其他人做的工作也有所了解,团队向着一个目标努力,配合默契。

测试:在 Review & Retro 中,我可以更了解团队每个人做的内容,更有效的沟通,让我们更好的安排时间保障测试。

研发:Review & Retro 能帮助团队在一次迭代冲刺之后,对工作内容有一个交付成果,让自己更有成就感。

我们在 Review & Retro 都做了什么?

1. Review 中根据本次迭代会议的故事进行交付,由团队认领的小伙伴进行演示,由运营和产品进行验收确认。

2. Retro 中对本次迭代中哪些做的好,哪些做的不好进行总结,通过“帆船模型”由每个人自由发言,头脑风暴的讨论。讨论结束后,总结解决办法,团队承诺改进。


# 总结

京麦本期的敏捷OpenSpace圆满落幕!也感谢一直前来捧场的小伙伴!

京麦敏捷OpenSpace(敏捷实战工作坊)一般是大约每两个星期一次,届时欢迎更多的小伙伴前来捧场。


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)  ©著作权归作者所有