需要沟通改善的小故事
人物：小白(平台)，小顾(测试)，培培(部署)，老朱(管理)
时间：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现状。我们想要工作持续改善，经常会问一些问题：
- review的问题如何想办法改进？
- 若确实没有瓶颈的话，那交付出去的产品质量如何？
- 可不可以做得再好一点？
- 一个需求从提出到上线的周期是多长？
- 有没有可能再缩短一些？
看板的形式
大家看1分钟，看能不能发现看板的问题。
- 能否一眼看出：项目各环节(开发，测试，部署)的流水进度？
- 能否一眼看出：持续交付的瓶颈点在那儿？
- 能否一眼看出：哪个环节Bug比较多？Bug的个数多少？
- 能否一眼看出：影响项目进度的成员及影响时间？
我们想要看板给DevOps团队解决以上问题?反映DevOps的问题，给我们持续改善的原数据
如何一眼看穿我们的问题，看板的改造
- 取消Do，Doing，Done，将问题直接暴露在当前环节，一个需求交付是一条价值流。
- 研发阶段：设计，沟通，需求确认，都可以放到研发阶段，以单独的便签纸体现。
- 测试阶段：体现出测试左移和右移，尽量缩短交付周期，延长线上环节（延伸到投产环节）。
- 部署阶段：明确交付周期，体现交付次数，每次交付一个任务标签。
- 重叠度：便签重叠越多说明延期越严重。在研发阶段重叠可能出现技术问题；测试阶段重叠可能bug较多；部署重叠可能自动化程度不够或研发未从运维角度考虑上线难度。
- 完成标示：每个环节完成，整齐贴在“结束时间”上。当一个需求交付完成，所有的阶段会整齐排成一行。
看板辅助每天站会沟通
有了看板，集中站在看板前同步信息，为减少站着疲劳和防止话题延伸太深，每个人简单同步三个问题和三个动作。
- 三个问题
1). 我昨天完成了什么任务？
2). 我今天打算做什么任务？
3). 我遇到了哪些障碍或困难？ （同步即可，不延伸） - 三个动作
1). 有延期：新任务便签重新覆盖。
2). 有Bug：新任务便签红色字体重新覆盖。（Bug具体还是需要JIRA，Bugzilla等工具）
3). 有进度：任务变迁，右移，任务完成贴在“结束时间”上。 - 任务便签的几点小细节
1). 任务标签故事内容
2). 任务归属人
3). 任务开始时间
4). 任务耗时天数（不要大于两天）
看板的意义
- 将流程可视化，将问题可视化。
- 促进团队成员对开发流程，过程和风险达成共同的理解。
- 促进问题的复盘。
看板站会的模式选择
- 两种模式：（承认不同团队，不同团队成员的个体性格差异）
- 矩阵式：适用于团队成员之间技能、心理强度较为均匀的理想情况，团队成员自主发起同步信息。
- 集中式：由一名心理风格较为平和的成员负责日常沟通、统一维护看板，即适当缓冲敏感型成员的过度信息输出，另外主动轮询其它被动型成员。
一般看板隐藏的问题
- 被动在看板前开站会。
- 站会沟通的表面认同，会后否定意见较大。
