其他简友广场想法

让DevOps团队高效沟通的小方法【看板】

2020-06-08  本文已影响0人  lazy_zhu

需要沟通改善的小故事

人物:小白(平台),小顾(测试),培培(部署),老朱(管理)
时间:2019-12-25(圣诞节)
事件:推送SSD盘有时推送不掉的问题。


老朱:“小白,推送SSD盘上线了没?这个功能很重要。”
小白:“小顾还没测试好吧,你问下呢?”
小顾:“我测试好了啊!”
小白:“啊,测试好了,这个需要让培培准备部署吧”
老朱:“培培,部署了没有?”
培培:“不对啊,有问题,高总监给的版本是4.1.8的,线上环境是4.2.6,4.2.8的版本,这些版本还没测试?”
老朱:“小顾,4.2.6,4.2.8 测试好了吗?”
小顾:“我不知道啊,高总监只给我4.1.8,我就测试了4.1.8,金龙早就测试完出报告了。”
小白:“哦,我还有些机器是4.1.8的服务,先上”
大家继续扯蛋ing.......(正好是圣诞节,做点和蛋有关的事也算过节)

问题来了:项目延期2周没发布,东大客户已经和我们半毛钱关系都没有了,我们还在扯?团队成员没有及时沟通导致都在忙,经没有往一处使

什么叫完成?

DevOps中的完成
从需求到交付上线使用。
公司层面的完成
从接到客户订单到向客户收到帐。

DevOps的完成在公司层面的完成是“其中”一段作业时间。这段作业时间,我们经常搞事情。(需求完不成,交付上不了线,上线一堆Bug,使用起来锅超大。)我们对“完成”的认知不统一,需要有一个载体来呈现每个阶段的完成。这边给大家介绍一个很好用的载体“看板”。

看板是什么?

丰田看板是传达“何物,何时,生产多少数量,以何种方式生产,搬运。“ 看板更像是一个传票,传递着上一道工序的信息,往下传递。看板"并非"是一个项目管理的手段或工具,而是一个组织内部持续改进的起点。是整个持续改进的一块内容,比如流程中的瓶颈、流程中的不稳定因素等,有没有定期去review现状。我们想要工作持续改善,经常会问一些问题:

看板的形式

TODO,Doing,Done看板

大家看1分钟,看能不能发现看板的问题。

我们想要看板给DevOps团队解决以上问题?反映DevOps的问题,给我们持续改善的原数据

如何一眼看穿我们的问题,看板的改造

改善后的看板
  1. 取消Do,Doing,Done,将问题直接暴露在当前环节,一个需求交付是一条价值流。
  2. 研发阶段:设计,沟通,需求确认,都可以放到研发阶段,以单独的便签纸体现。
  3. 测试阶段:体现出测试左移和右移,尽量缩短交付周期,延长线上环节(延伸到投产环节)。
  4. 部署阶段:明确交付周期,体现交付次数,每次交付一个任务标签。
  5. 重叠度:便签重叠越多说明延期越严重。在研发阶段重叠可能出现技术问题;测试阶段重叠可能bug较多;部署重叠可能自动化程度不够或研发未从运维角度考虑上线难度。
  6. 完成标示:每个环节完成,整齐贴在“结束时间”上。当一个需求交付完成,所有的阶段会整齐排成一行。

看板辅助每天站会沟通

有了看板,集中站在看板前同步信息,为减少站着疲劳和防止话题延伸太深,每个人简单同步三个问题和三个动作。

  1. 三个问题
    1). 我昨天完成了什么任务?
    2). 我今天打算做什么任务?
    3). 我遇到了哪些障碍或困难? (同步即可,不延伸)
  2. 三个动作
    1). 有延期:新任务便签重新覆盖。
    2). 有Bug:新任务便签红色字体重新覆盖。(Bug具体还是需要JIRA,Bugzilla等工具)
    3). 有进度:任务变迁,右移,任务完成贴在“结束时间”上。
  3. 任务便签的几点小细节
    1). 任务标签故事内容
    2). 任务归属人
    3). 任务开始时间
    4). 任务耗时天数(不要大于两天)

看板的意义

  1. 将流程可视化,将问题可视化。
  2. 促进团队成员对开发流程,过程和风险达成共同的理解。
  3. 促进问题的复盘。

看板站会的模式选择

  1. 两种模式:(承认不同团队,不同团队成员的个体性格差异)
    • 矩阵式:适用于团队成员之间技能、心理强度较为均匀的理想情况,团队成员自主发起同步信息。
    • 集中式:由一名心理风格较为平和的成员负责日常沟通、统一维护看板,即适当缓冲敏感型成员的过度信息输出,另外主动轮询其它被动型成员。

一般看板隐藏的问题

  1. 被动在看板前开站会。
  2. 站会沟通的表面认同,会后否定意见较大。
上一篇 下一篇

猜你喜欢

热点阅读