Lec5-看板

1. 看板方法定义

  1. 看板方法,由David Anderson创立,它脱胎于大野耐一所创立的丰田生产方式(TPS),以及埃利亚胡·高德拉特(EliGol-dratt)的约束理论(TOC),并结合统计质量控制(SQC)、排队论(QT)、工业工程(IE)、软件成熟度模型(CMMI)等多个领域的知识,在软件开发社区中获得了极高的关注度,并迅速传播开来。

2. 看板例子

2.1. 看板例子1

  1. 虚构故事
  2. 背景:团队是一个很小的开发团队,他们为一个大的保险公司服务,负责新发布的手机银行应用。这个团队负责在手机银行这个应用中开发新特性,同时还要支持和维护已经发布的版本

2.2. 开发出现问题

  1. 我们经常延迟交付
  2. 估算常常不准
  3. 整个团队忙得不可开交
  4. 优先级不清楚
  5. 需求来自四面八方
  6. 互相不清楚谁在干什么

2.3. 白板

  1. 把项目原来在Jira中的工作内容贴在白板上。
  2. 每个工作项一个记事贴。
  3. 我们一般称电子工具为‘信息冰箱’。

2.4. 白板:可视化工作

  1. 你无法对自己没有看到的进行改进。
  2. 让隐藏的工作无所遁形
  3. 为每个工作项建立一个即时贴即可轻易做到
  4. 帮你理凊
  5. 谁在干什么
  6. 你正在处理的工作
  7. 进行中的工作数量
  8. 工作可视化之后,信息将散播给看到的每个人

2.5. 工作流映射

DevOps-5-看板_架构

2.6. 工作项

  1. 卡片上有什么内容?
  2. 从卡片上你可以
  1. 看到工作项的进展状态
  2. 能够决定下一步如何处理
  1. 常见的属性为
  1. 工作项描述
  2. 电子系统中的唯一标识
  3. 完成期限
  4. 谁在处理这个工作项
  5. 工作类型(比如bug或者常规工作)

2.7. Work in Progress(WIP)

  1. 在制品 (WIP) 是同时进行中的工作数量,减少在制品使其快速流过整个工作流,即前置时间缩短。
  2. 我们不再关注是否每个工人的工作都是最有效率的;
  3. 在最后一轮中,前置时间是最短的,但每个工人的工作时间都延长了,从个人来看工作效率下降了,但整个团队的效率最高。

2.7.1. 限制在制品

  1. 致力于减少同时处理的工作项
  2. 批量规模越小,前置时间越短
  3. 流动效率提升的同时资源效率会有所降低
  1. (类似传递硬币的游戏或模拟方法是教人抽象概念的很有力的方式)
  1. 立即实施:停止立项并开始完成
  2. 限制在制品将使改进机会浮出水面
  1. 着手改进后会获得更快的流动
  1. 不要企图找到一个唯一正确的数字作为团队的在制品限制规模.
  2. 在制品限制不是仅为了设立规则,而是为了触发讨论

2.7.2. 紧急工作

  1. 快速通道
  2. 处理特殊情况的常用方式,如紧急工作
  3. 通常在白板上刻划为单独通道
  4. 快速通道的相关规则如下:
  1. 任何时候最多只能有一个工作项在快速通道内
  2. 每周最多有一个紧急工作
  3. 快速通道内的工作项无需计入在制品限制

2.7.3. 度量

DevOps-5-看板_DevOps_02

  1. 有利于团队改进
  2. 团队自己选择度量指标,但不要将度量指标用于绩效考核
  3. 两个常用的度量指标为:
  1. 前置时间是整个工作流的时间
  2. 吞吐量是一定时间段内完成的工作项数量

2.8. 看板例子2

DevOps-5-看板_架构_03

DevOps-5-看板_架构_04

DevOps-5-看板_看板_05

DevOps-5-看板_容器_06

DevOps-5-看板_Scrum_07

2.8.1. 看板不是?

  1. 看板并不是一种软件开发生命周期的方法学,也不是一种项目管理的方法。
  2. 实施看板时,需要当前已经有一些在运行的过程,这样便可应用看板来逐步改变当前运行的过程。

2.8.2. 看板与Scrum

  1. 看板更加适应支撑维护团队
  2. Scrum更加适应全新开发团队
  3. (不绝对)

2.8.3. Scrum和看板都是过程工具

  1. Scrum和看板都是适应性很强的,但相对而言,Scrum更规范一些。Scrum多了些约束,少了些选择。
  2. RUP的规范性相当强──它有30多种角色,20多种活动,70多种工件;
  3. XP(极限编程)比Scrum又规范一些。它囊括了Scrum的大部分内容,还多了很多相当具体的工程实践,例如测试驱动开发和结对编程。
  4. Scrum的规范性比XP弱,因为它没有规定任何具体的工程实践。但它又比看板规范,因为它规定了迭代和跨功能团队之类的东西。
  5. Scrum和RUP的主要区别在于,RUP给你的东西太多了,你得自己把不需要的东西去掉;而Scrum给你的东西太少了,你得自己把需要的东西加进来。
  6. 看板几乎对任何做法都是开放的。它仅有的约束就是将流程可视化和限制在制品。它离做什么都行只有几步之遥,但仍有令人惊异的力量。

2.8.4. 别把自己绑在一种工具上

  1. 把工具搭配着用,用在合适的地方。
  2. 无法想象几乎不用XP的Scrum团队还能成功。很多看板团队也在做每日立会(Scrum实践)。有些Scrum团队也把backlog条目写成用例(RUP实践),还会限制队列大小(看板实践)。只要有用就行。
  3. 不过我们还是要关注每样工具有哪些约束的。假如你在用Scrum,又决定不用固定时长的迭代(或是其他任一款Scrum的要素,3355),就不要说你在用Scrum了。Scrum本身已经足够浓缩了,如果你去掉一些东西,然后还叫它Scrum,那这个词就失去了意义,只会带来困扰。

2.8.5. 经验主义

  1. Scrum和看板都是经验主义的产物,你用的时候需要先进行试验,然后根据自己的环境作调整。
  2. 它最核心的一点就是反馈环。改变=>检查结果=>从中学习=>继续改变。一般而言,反馈环越短越好,这样可以快速调整过程。

DevOps-5-看板_看板_08

  1. 平均生产周期。每次有任务到达"Done"这一列(不管它叫什么吧,反正是最右边那一列)的时候就更新数据。
  2. 瓶颈。典型症状就是X列里面堆满了卡片,但是X+1列里空空如也。找找板上哪里有"气泡"吧。

2.8.6. 寻找WIP的例子

DevOps-5-看板_DevOps_09

DevOps-5-看板_DevOps_10

  1. WIP上限提醒我们要采取行动,改善瓶颈;而不是把没完成的工作堆啊堆啊堆啊堆个没完。
  2. 但要是WIP当初设成4的话,我们早就能有所反应了,这样平均生产周期还能表现得好点。所以这是要平衡的。我们度量平均生产周期,不断优化WIP上限,以此优化总生产周期。

2.8.7. 相似性

  1. 都是既精益又敏捷、都是拉动式计划、都限制了WIP。Scrum的WIP按单位时间限制;看板的WIP按流程状态限制。
  2. 都以透明的方式驱动过程改进。
  3. 都关注于尽早交付、频繁交付可发布的软件。
  4. 根基都是自组织型团队。
  5. 都需要把工作拆分
  6. 发布计划都是根据经验数据(生产率/生产周期)不断优化的。

2.8.8. 差异

DevOps-5-看板_Scrum_11

DevOps-5-看板_看板_12