华为敏捷DevOps实践:产品经理如何开好敏捷回顾会议

标签: 华为 devops 实践 | 发表时间:2018-11-21 16:12 | 作者:devcloud
出处:http://www.iteye.com

大家好,我是 华为云DevCloud 项目管理服务的产品经理  恒少:)

作为布道师和产品经理,出差各地接触客户是常态,经常和华为云的客户交流、布道、技术沙龙,但是线下交流,覆盖的用户总还是少数。我希望借 线上的平台,和用户持续交流华为在研发效能提升上的思索和考虑。

<恒少出品,必然妥妥干货,必定理论联系实践>,因为软件无银弹,探索始终在路上

-----------------------干货分割线--------------------------------------

开篇小故事:前几年,一本叫《沉思录》的书在国内突然曝光度很多,因为前某国家领导人“摆案头,读百遍”。《沉思录》是古罗马皇帝马可·奥勒写给自己的书,内容大部分是在鞍马劳顿中写的。其实有一句“我们所听到的不过只是一个观点,而非事实 我们所看到的不过只是一个视角,而非真相”

全员都参加的回顾会议,其实就是希望能通过全员视角,全员的观点来回顾做的好的,做的不好的,改进之。从敏捷宣言,到敏捷的诸多实践(如Scrum),到DevOps,都一直提倡回顾这种形式。

其实回顾这种形式,并不是敏捷/DevOps专属的,在华为最早的CMM流程中,也有类似的活动。有时候团队碰到域郁闷,痛苦的时候,还会主动自发的开。

所以,回顾,我一直认为这是人类作为一个智慧物种相比其他生物的一个重要区别。我有的时候回通过回顾会议来判断这个团队会不会成功。最极端的,如果甚至都没有人想着要约大家一起回顾,这个团队极大概率要88了。

华为内部不仅研发交付团队,连一线的市场团队,在重大的市场项目,交付项目的过程中都会定期进行回顾会议,算是华为内部这么多年积累的一个很好的实践。

必须鲜明表达的观点——回顾有三个不是

1.不是“回溯”。“顾”和“溯”一字之差,在中文的语境中,却会导致变成刨根问底。

2.不是“批评与自我批评”。“批评与自我批评”是一个很好的形式,但是会导致团队陷入一种不必要的紧张和犯错感。

3.不是“问责和处罚”。软件的不确定性,不可见性,复杂性,易变性决定了软件开发过程总会有些磕磕盼盼,我们提倡的是改进,不是惩罚

从华为这么多年的实践来看,上面的三种情况都出现过,所以提醒大家要小心。

这么些年实践过来,我们发现出现以上情况,也是因为步子走得太快,低头玩手机^_^,忘了“回顾”的初心:

1.For a better future;

2.Learn from past;

3.Take action in present.

回顾会议的基本原则

1.对事不对人。举个例子,我们可以说“代码评审不充分,所以代码缺陷较高”,不能说“某帅哥评审不认真”,当然夸人帅还是可以的哈^_^。

2.聚焦于下次能否做得更好。还举同样的例子,我们可以说“这个迭代代码评审不充分,下个迭代我们怎么才能保证更充分的评审”。

3.从系统角度思考改进,而非个人。我们可以说“团队的工作安排上,导向上是不是不重视代码评审?”。

回顾会议的Step by Step

1. 确定参与人(Who)

a)团队所有成员都参加。

b)领导是否参加,试情况,如果领导参加利大于弊,就邀请,否则还是算了^_^

c)如果是重大的项目发布或项目结束的回顾会议,还应该叫上所有对项目有付出的成员。

d)建议指定一个会议引导人,可以是敏捷教练,也可以是团队成员轮流(团队成员建议熟读本文)

2.选择合适的场所(Where)

a)如果条件允许,离办公位尽可能远一点,避免有同学中途又回去处理工作了

b)尽可能不要使用传统会议室的布局,围坐一个大桌子那种不好。可以拉几把椅子围成一个半圆形。

c)需要有白板,或者墙壁可以贴个大白纸

 3.准备回顾的内容(What)

a) 准备上个迭代的客观数据,特性、需求、缺陷等数据,如果使用了像DevCloud这样的敏捷管理工具,准备数据其实很快的,甚至不用特别准备,现场打开就可以,类似如下这样

b) 团队成员上个迭代的感受,可以认为是主观数据的收集。

c) 每日站立会议的要点。每日站立会议中都会提出并跟踪解决一些问题,回顾这些问题也可以帮助我们审视过程中的情况。恒少之前专门写过如何开好站立会议的实践文章《 华为敏捷 /DevOps 实践:如何开好站立会议》,可以参考。

d) 准备一个规则,会议开始前贴出来或打印出来或投影仪投出来。规则是为了保证会议的纪律和效率,比如不能随便打断别人讲话,每人发言时长,会议时长(建议10~12人的团队,限定在1小时内)

  4. 回顾会议的过程(How)

a) 准备和引导——明确目标。重申回顾会议的目标和原则,让成员重拾回顾的“初心”,发布公示如下的回顾宣言,重申会议纪律,时长。准备和引导环节是让大家放下手机,进入回顾会议状态的必要环节,无论开过多少次,都不应该省掉。

b) 数据、过程的回放——建立共同的全景。展示本迭代的度量数据,如果有使用类似DevCloud的敏捷管理工具,可以直接打开系统。全景的数据展示回顾,让视角更全面。对于一些“历经劫难”的迭代,可以画一个时间线,把这个迭代发生的重大的一些事件按照时间顺序展示出来,帮助团队成员回顾都发生了什么

c) 提出见解——我们如何才能做得更好。可以通过头脑风暴,全员参与,有很多种分类的方法,如下图中是分为“Good”(下个迭代哪些好的方法可以继续保持),“Could Better”(下个迭代可以哪些地方可以做得更好),Improvements(新的改进的具体想法)。可以采用“有限投票”的方式,每个成员有5票(比如小磁贴或直接记正字),大家共同团队层面需要重点改进的。其实投票未排进Top的改进,如果不需要组织和团队来推动,个人也可以实施的改进,也应该支持。

d) 确定措施——想清楚就干,才有诚信。识别了重点的改进项,为每一个改进项指定计划,执行的措施,需要更高层面去解决的措施需要单独列出来,项目Leader会后要发挥“死缠烂打”的精神去骚扰领导了,同时每个改进措施都应该明确一个责任人,如果没有明确的责任人,大家都会认为是别人的事情。

e) 结束会议——果断结束,绝不拖泥带水。将会议中达成共识的措施和计划整理记录下来,如果使用了敏捷管理的工具系统,可以直接输入到系统中,记录为Story或者任务。 

来自实践中的一些坑和雷

1.不持之以恒。那什么几天打鱼,几天晒网的可不行。恒少,恒少,就是能持之以恒,哈哈。

2.理想主义。团队级的回顾会议应基于现实,而非理想,或者说理想可以有,诗和远方也可以有,但是回顾会议还是应接地气。

3.沉迷于细节。程序员有的时候特别认真,容易把问题引入到技术细节,这样会导致议题发散。

4.只开会,没有吃的,好饿。皮一下,为了调节会议氛围,可以准备些吃的,补充能量,大脑才能激发

最后的最后,每个迭代回顾会议,都不要忘了感谢辛苦码代码的自己,也不要忘了感谢为了心中教堂而努力的所有团队成员的。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [华为 devops 实践] 推荐:

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

华为敏捷DevOps实践:产品经理如何开好敏捷回顾会议

- - 研发管理 - ITeye博客
作为布道师和产品经理,出差各地接触客户是常态,经常和华为云的客户交流、布道、技术沙龙,但是线下交流,覆盖的用户总还是少数. 线上的平台,和用户持续交流华为在研发效能提升上的思索和考虑. <恒少出品,必然妥妥干货,必定理论联系实践>,因为软件无银弹,探索始终在路上. -----------------------干货分割线--------------------------------------.

再谈DevOps实践和价值(12.11)

- - 人月神话的BLOG
今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化,其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论,DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应,也就是DevOps = Dev Agile Ops Agile.

对DevOps实践的一些思考01(1.15)

- - 人月神话的BLOG
最近1到2年的博客文章,我谈微服务架构的比较多,而专门谈DevOps的比较少,包括对DevOps支撑平台和DevOps实践的一些关键点思考. 19年准备对DevOps这块进行深入的了解和实践. 在18年12月11日,当时写过一篇对DevOps实践价值的思考,其中的重点是在谈DevOps,容器云和微服务架构框架的三元一体化.

中小团队基于Docker的devops实践 - 掘金

- -
笔者所在的技术团队负责了数十个项目的开发和维护工作,每个项目都至少有dev、qa、hidden、product四个环境,数百台机器,在各个系统之间疲于奔命,解决各种琐碎的问题,如何从这些琐碎的事情中解放出来. devops成了我们不二的选择. 文章是基于目前的环境和团队规模做的devops实践总结,方案简单易懂,容易落地且效果显著.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.

2019十大最佳DevOps工具

- - IT瘾-tuicool
【编者的话】DevOps落地重要的一方面是选好工具集,本文介绍了最流行的DevOps工具. 开发和运维的集成翻开了软件开发的全新篇章. 如果你还是DevOps的新手,或者正在寻求改进已有流程的方法,那么第一道关卡就是调研哪些工具最适合你的团队. 本文整理了工具列表,为大家选择所需的工具提供详实的参考信息.