写点什么

更好地实施敏捷

  • 2014-04-08
  • 本文字数:3363 字

    阅读完需:约 11 分钟

众所周知,敏捷运动并没有产生那种完全可行的革命性结果。如果现行的方案可行的话,那么最起码现在,成千上万的组织早就已经达到一种自立、持续、独立的敏捷状态。

很显然,事实并非如此。

故事里总是充满了各种典型的失败模式。一开始好像还进行得不错的组织,最终还是再次沦为了瀑布流的实践方式。组织聘请教练并花费数百万美元就是为了在其所衡量的标准下仅仅得到 25% 到 30% 的改善!

大规模软件开发是一项非常艰巨的任务。敏捷的思维方式、相关原则、模式和实践都能起到极大的辅助作用。问题是如何实现这一目标。很明显的是,极少人(如果有人的话)知道如何连续地提供长效且持续的大规模敏捷实施的方案。到底该怎么做?谁又知道怎么做呢?作为一个咨询和指导社区,我们没有向客户和更广阔的世界兑现敏捷的承诺。这糟透了。

通常,敏捷实践都是通过授权的方式实现的。规定的实践并不关心人们的需求、人们的想法以及人们的感受。死板的规定会减少人们的参与度,并且导致那些睿智又极富创造力的员工开始“退出”并且不再参与。

通常,我们使用以下模式来实现敏捷方法,并且常常是在一个小型团队进行了小型试验测试以后:

  • 当权者说我们正在“迈向敏捷”。
  • 当权者说我们会使用一些特殊的实践,如 Scrum、看板或者其他的敏捷实践、方法或框架。坏消息是这不是可以讨价还价的。
  • 当权者基于他或者她所从事过的规定实践为经验选择了一个教练。通常,都是熟悉 Scrum 技能的教练。这名教练被强加给下属,就像那些规定的敏捷实践一样。
    • 由于经历了可控性、包容度和归属感都较低的经验,员工都自发的不再参与了。他们已经意识到这个新游戏是十分模糊的,并且明确规定是必须要参加的。敏捷实施不是一个令人享受的游戏,因为这个游戏本身并没有被明确的定义,并且还没有机会选择退出。

在典型的敏捷实施方案里参与的方式并不是通过邀请而更像是一种授权或者规定。这里有一个针对那些失败的敏捷实施方案的秘方。回想一下那个关于开放式敏捷实施的设想,授权会降低用户参与度,但是邀请和可选择的参与却可以增加参与度。再回想一下另一个关于技术的设想,用户参与是可以快速而持久的进行敏捷实施的基本要素。

那些软件程序的开发者通常都有以下特性,特别是跟普通人比起来:

  • 高智商
  • 性格内向的倾向
  • 包含以下心理的自我形象
    • 我是被雇来解决问题的
    • 我很聪明并且富有创造性
    • 我是因为有技术专长才被雇来的

授权式的敏捷实施一般都倾向于遭到那些聪明的工作问题解决者的排斥。其中一个原因是,这些人真的很喜欢解决问题,包括那些“流程问题”,比如“在我们公司该如何实现敏捷。”现在,既然他们大部分人都是比较内向的,如果我们不询问他们的想法,那么真正可怕的事情就会发生了:他们也不会告诉我们。

通常,那些负责该工作并且解决问题的人都会有一些有用的观点或想法。但是不向他们求助相反还颁布一个规定的授权,我们将错失得到帮助的机会,并且还会制造出相当大的潜在怨恨隐患。这是一个双重的负面结果。我们渴望得到那个最好的想法,我们也渴望得到一个参与的机会。

更好地实施敏捷

开放式敏捷实施™ 是一种基于邀请而不是授权的技术。关于开放式敏捷实施的一个设想是授权会降低用户参与度,但是邀请和可选择性的参与却可以增加参与度。另一个关于开放式敏捷实施的设想是,用户参与是可以快速而持久的进行敏捷实施的基本要素,并且开放的思维倾向于邀请大家都参与进来,从而增加用户参与度。

关于开放式敏捷实施的一个关键设想是,用户参与是基本要素,并且通过邀请可以提高参与度。

相比于颁布一个授权式的特定敏捷实践,开放式敏捷实施使用了以下基于邀请的模式:

  • 朝着敏捷的方向解释商业案例。根据诸如竞争、价格压力、产品过时等方面解释业务所面临的挑战。
  • 表明企业是朝着敏捷的方向前进的。并解释清楚敏捷的方向是明确的。
  • 邀请每个人参与到编写敏捷故事的进程中。由于领导的方式并不能解决所有问题而且还在苦苦寻找那个最有想法的人,所以沟通就必须使敏捷朝着更加真实、可信、快速和持久的方向前进。
  • 需要明确说明的是,任何被当做敏捷实践进行尝试过的事情,都可以看做是试验性的、可选的、将会被检验的、并非一成不变的。例如,如果非营利组织准备尝试使用 Scrum 框架,那么它将会是一次试验,并且事后是要受到检查的。如果现成的实践很像 Scrum,但是不能被调整和定制的很好,那么它将会被丢弃,而我们就会尝试一些其他可行的方法。我们可能会使用敏捷宣言作为向导来“创造出我们自己的”实践。

这么做了以后,那些员工就可以参与进来,并且获得一种强烈的控制感和归属感。

大部分的敏捷实施问题都可以追溯到社会学动态方面,而不是实践方面。实际上,我们会调整实践活动来适应现实社会。比如说,故事点通常就是授权式敏捷实施中第一个玩“猫腻”的实践。并不是使用故事点这个实践本身是问题——而是现实社会自己导演了这场闹剧。

开放式敏捷实施的一个设想是敏捷的引入对于大多数参与者来说都是一个很大的触动,会导致他们不再参与,甚至抵触为敏捷实施所做的努力。对于管理者和系统架构师们来说,由敏捷所引起的担忧是非常严重的。授权式的敏捷实践会轻松地放大这些由于退出甚至怨恨而引发的忧虑。

在敏捷实施的过程中通常处理压力和忧虑的方式是指望文化人类学…关于如何做的更好。事实证明,在各个地方的各种文化里都会使用过渡仪式来处理转型过程中的产生压力。向敏捷转型绝对算得上是一个巨大的转变。

开放式敏捷实施利用文化人类学的知识,创造了一个过渡仪式,该仪式始于一个开放式会议。整个过渡仪式本身就是一场游戏。邀请代替了授权来参与游戏。在过渡仪式的中间,试验的结果就是不断学习。人们都在玩敏捷这个游戏。最终组织收获并集成了那些宝贵的学习经历:再来一次,还是以开放的方式。

开放式敏捷实施的术语

下面这些是开放式敏捷实施中所使用的术语和词汇,也许你可以需要花点时间来仔细查看这些定义:

阈限:由于转型所制造的一个紧张状态。敏捷实施制造了阈限。

过渡仪式:一种处理文化变更压力的仪式。过渡仪式有助于处理在状态切换的过程中所产生的阈限问题。

共同体:社区的灵魂。开放式敏捷实施营造了这种包容感和归属感。

司仪:过渡仪式中的基本角色。这个人在过渡仪式中身居仪式主持的位置,扮演了裁判或者“游戏规则”维护者的角色。

学习阶段:在开放式敏捷实施中,拥有明确的开始、进行和结束阶段的组织性学习单元。学习阶段一般在开放式会议之间的时间段进行。

开放式会议:一种拥有特定结构,包含特定元素的会议形式。定期的的开放式会议是开放式敏捷实施里的基本和核心元素。

开放式会议议程:开放式会议中的事件文档。议程包括了各个事件在文字、图表和图片方面的总结。

开放式会议主办者:一个在组织里拥有足够授权并且能够召开至少一次一天的开放式会议的人。

开放式会议促进者:在开放式会议的形式里,由主办者所授权并负责协助会议召开的人。开放式会议促进者帮助营造一个开放的氛围,并且在开放式会议的过程中“保持这个氛围”的开放性。

教练或“敏捷教练”:由组织所雇佣并主要负责辅助实现敏捷方法和实践的人。

开放式会议的开端:在开放式敏捷实施里,开放式会议开始或打开了学习的篇章。

开放式会议的结尾:在开放式敏捷实施里,也是开放式会议结束或终止了学习的篇章。

升级:在游戏社区里,这个术语用来描述游戏里等级或者状态的改变。“升级”意味着前进或提升到一个新的能力等级。

通过这些术语,我们现在就可以检验开放式敏捷实施的方法中所使用的那些概念和工具了,当然这是在下一篇文章里。

关于作者

Daniel Mezick是一名管理顾问,作家和社区组织者。他还是敏捷波士顿实践社区的创始人。并且是开放式敏捷实施的设计师,这是一种创建快速而持久的企业敏捷性的技术。Daniel 是《文化游戏》的作者,该书描述了有助于团队更加聪明的十六种群体行为范式。他将自己在五年的时间里指导25 个组织的119 个敏捷团队的经验都写进了这本书。Daniel 的客户名单包括Zappo Insights、CIGNA、SEIMENS Healthcare、哈佛大学以及众多小型企业。欲了解更多并联系Daniel 请访问 www.DanielMezick.com

查看英文原文 Better Agile Adoptions


感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-04-08 06:001407
用户头像

发布了 31 篇内容, 共 83802 次阅读, 收获喜欢 1 次。

关注

评论

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

Django 中如何优雅的记录日志

AlwaysBeta

Python django Web 后端

redis数据结构介绍三-第三部分 整数集合

Nick

redis 源码 数据结构 源码分析 算法

Java并发编程系列——Fork-Join

孙苏勇

Java Java并发 并发编程 线程

初入响应式编程(下)

CD826

spring 微服务 响应式编程 reactor

从翻译到本地化:我在Airbnb做本地化经理的经历

葛仲君

产品 翻译 Airbnb 本地化 全球化

西江月·记游(一)

轩辕御龙

最通俗易懂的H264基本原理

音视频专家-李超

音视频 WebRTC ffmpeg H264

Flink Weekly | 每周社区动态更新

Apache Flink

大数据 flink 流计算 实时计算

Netty系列之源码解析(一)

猿灯塔

Netty

C++数组可以为变量吗

泰伦卢

c++ 互联网 编程语言

Make Tmux Great Again

ccx

tmux

忆秦娥·记游(三)

轩辕御龙

开发机直连Docker中的redis容器小案例

麦洛

redis Docker

音视频已强势崛起,我们该如何快速入门音视频技术?

音视频专家-李超

音视频 WebRTC ffmpeg 在线教育

广告与数据算法系列1.1.1: 什么是广告

黄崇远@数据虫巢

互联网 算法 广告

菩萨蛮·记游(二)

轩辕御龙

记游(四)

轩辕御龙

MySQL死锁与Spring事务

Dean

MySQL

redis数据结构介绍二-第二部分 跳表

Nick

redis 源码 数据结构 源码分析 算法

没有永恒的技术,只有适合的技术

MavenTalker

技术 个人成长 职业规划

要不要重新认识一下递归与迭代?

西了意

编程

格局不行,有机会也抓不住

池建强

创业 格局 MacTalk

B站、Quora、InfoQ,哪个的阅读/播放量会先到10W+?

赵新龙

写作平台 B站 Quora

回"疫"录(6):致敬最美逆行者

小天同学

疫情 回忆录 现实纪录 纪实 创新突破

多人实时互动之各WebRTC流媒体服务器比较

音视频专家-李超

音视频 WebRTC 在线教育 mediasoup janus

Istio 1.5:对开发人员有什么帮助?

麦洛

云原生 istio servicemesh

废掉一个人最好的办法是让他忙到没有时间思考

熊斌

程序员 职场 思考

Ledge:这可能是距今最好的『DevOps + 研发效能』知识平台

Phodal

DevOps 敏捷开发 软件开发 研发效能

如何学习区块链技术

比特币 区块链 以太坊

工作时间都去哪儿了?

伯薇

效率 时间管理 个人提升 团队

程序员陪娃漫画系列——排队问题

孙苏勇

程序员 生活 陪伴 漫画

更好地实施敏捷_文化 & 方法_Dan Mezick_InfoQ精选文章