写点什么

敏捷转型中的看板

  • 2013-12-03
  • 本文字数:2130 字

    阅读完需:约 7 分钟

Scrumban 最初是一种从 Scrum 向精益看板转换的机制,现在它已经支持双方向的转换,并可以应用到项目和精简 BAU(常规商业运营) 工作流。能够实施 Scrum 和精益方法的相互转换自然是很好的。但当你的客户不具备实践这些方法的条件时,你如何去帮助他们实现一个灵活的敏捷模型呢?当一个客户当下没有使用 Scrum、精益看板或者其它任何一种敏捷方法时,他们如何才能从 Scrumban 这类方法中获益呢?万一 Scrumban 方法关联的项目或 BAU 工作流出状况了呢?你如何去帮助一个“十分努力才勉强运行”的客户提升呢?

敏捷咨询顾问 Ian Mitchell认为,成功实现敏捷转换的第一步是实现透明度,利用好看板。

我认为使用一个看板(Kanban board)就可以达到这个效果。在这个看板上,我们用卡片来代表不同工作。团队选择的是 Scrum 方法还是要其它方法并不重要。重要的是这个项目中有这么一块板子,并且这个板子是可见的。我认为最初阶段的目标就是展示现状…谁都在做什么。在这个阶段我不会试图去推动进程。我追求的只是在板子上进行信息的首次呈现。

通常,最初人们会认为自己有很多工作要做。现在我将通过标注人们真正做的工作来纠正这一观点。我们暂且将这些工作都放在“正在进行”状态栏中,并查出是不是有阻碍它们的事情。我将把内部阻碍与外部阻碍分离开——即团队自身就可以解决的阻碍、必须依靠外界力量来解决的阻碍。我也标注出开发者认为自己很快就可以完成的工作——贴在待办栏的第一个。除此之外,我对过程不做其它假设。客户可以采用“瀑布模式”(waterfall scheme),也可以不采用。

对于一个典型的看板,相比于大部分人认为开发者应该做的,Ian 对开发者实际做的和开发者期待自己做的更感兴趣。

  1. 有些展示的工作和实际任务完全无关。因此,如果这些工作在消耗某些团队成员的时间的话,我希望这些工作是可见的。
  2. 在这个阶段,我们对于看板上出现的卡片数量并没有限制。
  3. 状态(看板上每一列的标题)分别是“待办的工作”、“正在进行中”、“在测试中”(或“在审查中”)以及“完成”。此外还会有一个“有障碍的”,尽管这一栏的卡片可能会被贴的乱七八糟。
  4. 团队的定义可能是模糊的,没有明确的说明哪些人是团队成员哪些人不是。
  5. 卡上的文字是抽象的…可能只是两三个字,但在从事这项工作的人能很好地理解这些卡片。
  6. 卡片不一定与合适的、符合验收标准的用户故事相关联。
  7. 各卡片所示工作的工作内容可能有明显的重叠。
  8. 某张卡片上的工作可能远比其它卡片上的工作复杂、耗时。但看板并没有标注这种差异性。
  9. 对完成的定义可能不符合真正完成的要求(如“所有代码都已验收”),或者定义可能是重复的(如“完成测试”)。

很明显,这个阶段没有什么最佳实践。Ian 认为,在看板上不会有在制品(Work In Progress)限制,也不会有对速度以及其它指标的鼓励、督促或记录。这是一种有争议的方法,甚至有些人称之为“歪门邪道”。很多敏捷指导,包括许多知识渊博的精益教练都提倡在敏捷转换中首先要嵌入一个好的流程。如果非要使用看板的话,看板排在第二。

Ian 举了实例:例如,Jim Coplien 将最近看板的流行看作是 Taichi Ohno 推动的一场对精益系统的侵吞运动。Coplien 认为开发者首先要有一个优化整体流动性的精益流程。他指出:“我们看到有些团队采用这种滥用的看板方法,将看板作为一种工具或方法,而不是作为一种‘世界观’,也不事先构建单件流水作业所需的基础和规律。”Coplien 还表示,当最优的实践嵌入以后,我们甚至可能没有必要再使用看板了。他提到了结对编程,并认为这种方法是实现单件流水作业的催化剂,也会降低对透明性的需求。“好的结对编程是相当无组织的,”他说,“因为反馈流程是在本地进行的,于是一下子间开发者就不需要文字化的看板了。”我考虑了这个观点背后的理论依据。不过,我认为看板具有重要价值是因为它可以作为提供透明度的工具,而不是因为它是所谓的系统“世界观”的一部分。我认为这是为实现成功的敏捷方法所迈出的探索性的一步。你总要从某个地方起步…并且按我的经验,实现敏捷方法的关键是清楚的认识你现在所处的状态。

当然我也看到了一些例外。例如,Jeff Sutherland 带着他的 Scrum 转换“休克疗法”投身到“过程改进第一”的大阵营中,我也清楚这之后的基本原理。我认为这种方法类似于学习外语时的“全浸入”方法。在我看来这是一项伟大的方法…. 如果你侥幸能够成功的话。毫无疑问,“休克疗法”可以带来很棒的结果,而且其它方法可能需要很长时间才能达到这么好的结果。问题是很多客户——我甚至可以说绝大部分客户——在采用“休克方法”方法时并不具备很大的吸收能力。这并不是因为缺乏勇气。一个组织很少进行整个组织的转换。实际上,你仅可以帮助整个企业中很小的一部分。你可以帮助那些依赖于非敏捷部门并且深受限制的人们,那些持敌对态度的人们,或者那些在与其它部门交涉进程缓慢的人们。看板上贴出的第一组卡片所描述的工作中,有百分之九十以上都将会因为这些依赖性而停滞。认识到这一点,并意识到需要寻求解决办法已经是客户所能达到的极限了。所以我认为首要的是展示什么在发生。这也是最初引入看板的原因。我希望可以做到透明度第一,这样我就可以展示什么在进行。当然当我们想要更好地实现敏捷方法时,我们要改进流程,但这是第二位的事情。

2013-12-03 06:102511
用户头像

发布了 501 篇内容, 共 265.1 次阅读, 收获喜欢 61 次。

关注

评论

发布
暂无评论
发现更多内容

大型互联网应用技术方案

石刻掌纹

架构师训练营第4周作业

时来运转

架构5班3-4组优秀作业

tracy

《机器学习理论导引》阅读攻略

华章IT

学习 周志华

一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述。

Carlos

计算机操作系统基础(六)---作业管理之进程调度

书旅

Java php 多线程 操作系统 进程

万字长文,让 Java 程序员入门小众语言 Ruby

Phoenix

Java ruby 个人成长 编程语言

架构师训练营第 4 周 总结

时来运转

架构师训练营第四章作业

饶军

“信息茧房”里的人

架构精进之路

程序员 自我思考

第四周作业

技术小生

极客大学架构师训练营

架构师训练营第四章作业

叮叮董董

架构 技术方案 解决手段 互联网架构

week04 学习总结 互联网面临挑战和架构模式

Z冰红茶

爱恨交织的红黑树

ytao

数据结构 算法

分布式柔性事务之事务消息详解

古月木易

分布式柔性事务‘’

使用 Prometheus-Operator 监控 Calico

米开朗基杨

Prometheus calico

为什么美国程序员工作比中国程序员工作轻松、加班少?

程序员生活志

程序员 加班

漫画通信:惊呆了,手机登录还可以这么玩!

阿里云Edge Plus

云通信 通信 通信云

以应用为中心:开放应用模型(OAM)初探

郭旭东

Kubernetes OAM

第四周总结

石刻掌纹

设计模式

Jeff

项目域名配置流程

打鱼小王子

深入浅出Shiro系列

程序员的时光

分布式柔性事务之事务消息详解

奈学教育

分布式事务

围绕 Office 365 的那些 CLI

手艺人杨柳

Office 365

Prometheus 存储层的演进

伴鱼技术团队

性能优化 系统架构 Prometheus 存储 时序数据库

架构师训练营第四章总结

叮叮董董

总结 架构师 训练营

第四周直播总结笔记

Carlos

一路“开挂”,完美诠释“年少有为”——90 后首席科学家王乃岩

二叉树视频

写作平台 二叉树 年少有为

拿着锤子的人,哪里都是钉子

Neco.W

思维方式 思考力

HTTP 的15个常见知识点复习

Geek_z9ygea

Java 大前端 Web HTTP

敏捷转型中的看板_研发效能_崔康_InfoQ精选文章