精益敏捷之站会
文章首发于公众号松花皮蛋的黑板报,作者就职于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深入的理解
有些程序员其实不爱和技术领域外的人过多交流,包括上级领导,很烦他们不了解技术又不了解业务然后又喜欢问之问那的,其实这种烦恼是自己造成的,因为你没有主动和上级沟通。沟通的渠道有很多,可以面对面交流,也可以选择在会议中同步一些信息,可能你会跳出来反驳我的观点,领导那么忙,单独找他沟通太麻烦人家了,而会议时长通常很长,容易浪费时间,导致被迫晚上加班,所以沟通干脆就算了。
程序员反感开会早就司空见惯了,其他行业也一样,通常是因为会议没有太多信息价值,那比如站立会应该怎么开才合适呢?
通常觉得会议没有信息价值是因为会议内容和自己不相关,人在接收和自己不相关的信息时,容易思绪发散,长而久之就会滋生厌恶。所以站会只组织相关干系人即可,人数不宜过多。站会顾名思义就是团队站着开会,强调时间不宜过长。站会通常由领导主持,团队成员轮流发言,讲述工作事项,但是要避免长时间讨论。
在站会时团队成员应该以三段轮为模板进行讲述,一是昨天做了什么?比如昨天完成某某需求的评审、技术选型、任务分解、工时估算;二是今天要做什么?比如今天要完成某某需求的某个子任务;三是遇到了什么阻碍?比如今天要进行的子任务开发中需要某某辅助解决技术难点。第三点非常重要,能够尽早暴露问题,避免默默无闻埋头苦干,甚至工作到一半发现你理解的和人家真正需要的其实是两回事,那时骂娘还能怪谁呢,这不恰恰是我们编程时强调的快速失败嘛!
站会同时需要对于会上内容做概要记录,便于会后跟踪和解决。那会上问题,谁来推进呢?极客时间的池老师总结了一句原则,谁难受谁推进原则,在团队协作中也适用。如果这件事不做,你自己或者项目小组就会非常难受,那么就应该毫不犹豫的主动推进。
好,今天分享了避免团队人员觉得会议对项目进展没有帮助的建议,希望能帮助到你,欢迎分享给你的朋友们。
文章来源:www.liangsonghua.me
作者介绍:京东资深工程师-梁松华,在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深入的理解
- 图解精益敏捷的逻辑与实证:设计您自己的工作方式
- 何勉:第一性原理和精益敏捷的规模化实施
- 何勉:第一性原理和精益敏捷的规模化实施
- 图解精益敏捷的逻辑与实证:设计您自己的工作方式
- 精益敏捷开发: 带病迭代
- 敏捷的生产--丰田模式之精益生产
- Richard Durnall谈精益开发和敏捷实施缺陷
- 阿里敏捷教练何勉:论精益思想及精益产品开发实践体系
- 敏捷与精益: 中国特色的软件发展之路
- 精益敏捷开发: 轻量级度量
- 精益与敏捷软件开发概述
- 敏捷软件开发和精益看板管理
- 精益敏捷开发: 表格式的测试用例, 使团队成员更高效的协作
- 修复bug与解决问题--从敏捷到精益
- 为什么敏捷的未来是精益
- 敏捷和精益的升华 - DevOps
- 精益敏捷外包开发--- 思维篇
- 读书笔记--<精益和敏捷开发大型项目应用指南>
- 精益看板管理和敏捷软件开发 (转)
- 何勉:第一性原理和精益敏捷的规模化实施