京麦敏捷OpenSpace之旅第一期活动记录
|
# 开场 京麦团队是一个敏捷团队，从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 (文／张松然) ©著作权归作者所有 |
