【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

为什么敏捷没有起作用

Observations from an Agile Coach Deep in the Trenches

  • 2015-10-15
  • 本文字数:3654 字

    阅读完需:约 12 分钟

作为一名敏捷教练,我经常被问到的一个问题是:“我们实施了敏捷,但是为什么它没有起作用?”

问这个问题的人,是真正被困扰的人。我遇到过许多团队,在对团队进行结构重组、职责重新划分、流程重新定义的过程中经历了许多的麻烦,但是令他们感到沮丧的是,经历这些之后他们的生产力和士气甚至都不如从前。

每个组织都有它自己独特的功能障碍类型。作为一名教练,我要让自己深入团队,密切观察和理解他们是如何工作的。但是,尽管每个团队都有自己的独特性,还是会经常出现相同的问题模式。几乎在每个案例里,团队决定采用敏捷是因为他们遇到了现实生活中的问题,比如低的生产力和低的生产质量,他们希望敏捷能够奇迹般地让他们起死回生。他们没有意识到的是,敏捷仅仅是管理软件的一种系统方法。敏捷可以支撑一些远大的目标,比如“通过满足客户不断变化的需求使客户满意”。看到这些目标后,管理者通常都会很兴奋,并且迫不及待地跳上敏捷这部列车。敏捷的问题是在实施过程中它带来了很多麻烦:每日站立会议,规划会议,和回顾会议。咋看之下,一群人围着一个白板徘徊的景象,可能会让一些天真的管理者认为它起作用了;但是他们没有意识到在缺乏重要的管理和技术支持的环境下,敏捷将无法生存,甚至更糟,团队会背地里开始讨厌这种麻烦,希望事情能够回归到从前的模式。

管理问题

今年我一起工作过的一个团队就陷入了上面描述的那种麻烦里。它是一个大型团队,被分成了 7 个 scrum 团队。你可以想象每天早晨办公室是多么的嘈杂,几乎同一时间召开的 scrum 会议,之后是 scrum of scrum 会议。管理部门很高兴;毕竟他们已经为聘请敏捷教练实施敏捷支付好了价钱。

事情开始转变的很快。我连续参加了团队的 scrum 会议数周,并且特别注意到其中有一个团队,他们已经被同一个技术问题持续阻塞了好几天。团队不能继续向前开展工作,所以他们开始着手其它的事情,但是这导致了大量未完成的代码,不能测试和演示。

在敏捷里,scrum master 理应为团队扫除障碍。然而当被问到时,这个团队的是 scrum master 也非常的沮丧。他说,整个团队里只有一小部分人理解相关的技术细节,但是他们又不在他的 scrum 团队里。他们被他的经理安排去开发实现另外一种功能了。

下面是软件团队遇到的一些典型问题:

  1. 每个敏捷倡导者都可以从积压的工作中捡起任何任务,但是在现实中,只有几个人理解一些晦涩的技术。很难激励其他人学习并熟知这些技术,尤其是那些跟不上时代发展的人。即使你成功激励了他们,当面对大量积压的工作的时候,也很难抗拒处理其它事务,使积压起来的工作看上去很少的冲动。
  2. 敏捷 scrum master 理应移走团队面前的大山,让他们无阻碍地前行。在现实中,scrum master 经常缺乏这样做的权利。这种权利通常存在于管理者手中,正如大家所知,权利很容易上瘾,并且很难放弃。在实践中,如果管理者有抵触情绪,我也不会催促组织改变管理的角色。如果某个管理者能够胜任敏捷 scrum master,可以安排管理者承担 scrum master 的一些职责:常常管理者在获取资源和处理矛盾方面更有经验,尤其是与其它同行者之间的矛盾。

但是这个团队遇到了更大的麻烦。团队经理另外开始开发实现一种单独和私有的功能——但是没有一个 scurm 团队被分配去实现那方面的功能,因此我就不能建立它的进度表。经过进一步的探索,我发现 RnD 团队和产品经理团队之间互相不信任;产品经理团队“命令”RnD 团队去开发一种功能,但是 RnD 团队却保留了部分资源,开发实现另外一种他们认为更突出的功能。

我与 RnD 管理团队坐下聊了聊,在白板上画了一张因果关系图:

(点击图片放大)

因果关系图是一种很强大的工具。尽管管理者一直在抱怨敏捷对他们团队没有起作用,但是因果关系图清楚地显示了更深层次的根本原因。因果关系图也有循环,这表明如果根本原因得不到解决,恶性循环将会继续。

技术问题

虽然这支团队拥有管理层的全力支持,但是仍然并不是所有的事情都运行的很顺畅。特别是,持续集成总是失败。团队在办公室前面装配了一台大屏幕用来显示集成状态,这样当每个人进入或者离开的时候可以看到它。这个屏幕平均每天有1-2 小时时间是绿色的。当然,这在很大程度上推迟了团队的进度。有一个规则,除非屏幕是绿色的,否则不能签入代码,但是因为它经常失败,所以有人偷偷潜入(sneaked in)代码。

我们喜欢认为软件开发跟传统的制造业有很大的不同,因为软件开发更“聪明”,而在传统制造环境下工作的工人只需要不费心思地拧上螺母(想到了_ 摩登时代_ 的查理·卓别林)。在现实中,软件开发也有一个装配线,所不同的是,这种软件装配线引入了大量用来提高软件质量的迭代。但是,就像工厂流水线一样,如果某一步速度变慢,事情就会堆积起来,整个流水线速度就会减慢。

对于这个团队,装配线在功能级别看起来是这样的:

(点击图片放大)

这个装配线有很多的反馈回路。反馈回路越短越好,因为校正错误的成本更低。从“演示”到需求”和“开发代码& 本地测试”步的反馈回路太长;理想的反馈回路应该从“开发代码& 本地测试”步开始。然而,因为总会遗漏bug,所以我们依赖自动化和QA 测试提供反馈。但是,在这个团队里,构建- 部署- 自动化测试过程存在严重的麻烦,并且有些人无视规则,随意签入代码甚至堵塞装配线,这一事实进一步加剧了过程的复杂性。

我向团队明确了装配线的概念,他们很快就想出了解决方案,理顺了装配线,比如加强代码审查和强制执行无签入规则。然而,在自动化测试问题上,意见产生了分歧。有些人认为目前的自动化测试是完全不可维护的:代码的合约商早已毫无踪影,并且修复测试代码的bug 时间要超过修复通过测试代码发现的bug 的时间。其他人认为,即使自动化测试是坏的,但是有总比没有好,并且重新编写自动化测试代码对QA 来讲成本太高。

我要求团队进行快速计算,以确定自动化测试的优势:

通过自动化测试发现bug/ 所有回归bug

结果是有些自动化测试还是相当不错的,尤其是一些单元和组件测试,但是UI 端到端的自动化测试结果却惨不忍睹。结论很明确:没有必要为如此少的利益花费如此多的工作量。

同时我还指出,开发和维护自动化测试不仅仅是QA 的职责。UI 端到端的测试代码完全依赖生产代码。在面向服务体系结构中,服务拥有定义明确,常常是多方协商后的API,如果一个服务想要变更它的API,他将要(应该)通知与其相关的服务,这样他们可以做出相应的变更。UI 测试代码完全受生产代码的支配:因此如果如此多的比如ID 或者UI 元素的名称在生产代码中发生变更,那么UI 测试就有可能会失败。

为了实现自动化测试的健壮和灵活,自动化框架必须经过精心设计。雇佣临时合约商是无法保证这一点的,而让QA 工程师编写又需要依赖QA 的专业技能和类型,可能也不好。对于这个团队,很明显大部分QA 工程师都是功能性测试人员,并不具备架构一个框架所需要的高级的架构技能。

因此我们决定让Dev tech 负责人开发自动化框架,让Dev 和QA 一起开发和维护UI 自动化测试。该协议还包括Dev 不能随意更改ID 和UI 元素名称的规则。

你可能认为所有的这些都发生在一个轻松愉快的会议上;事实上,让这些成为现实得到了大量的管理支持,并且前后花费了近三个月才完成了自动化框架,实现了其快速、稳定、易于编写测试代码的功能——这就是我们解决现实生活中的问题的方法。

敏捷是一种管理软件的系统方法

我们需要回到原点,找出敏捷的精髓。在2001 年,17 名软件大师提出了敏捷宣言,但是敏捷宣言并没有规定怎么做:

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

他们还提出了12 条原则,其中的一些规定了做什么(比如业务人员和开发人员面对面的交谈传递信息),但是,大部分还是跟价值观念有关。如果我们仔细分析这12 条原则,我们可以看到它实际上构成了一座金字塔。

在最顶端的是“通过满足客户不断变化的需求使客户满意。”我们通过“经常地交付可工作的软件”实现这一目标。但是为了交付可工作的软件,需要重要的技术和管理支持。确保变化的需求不会破坏系统和延缓开发进程是最重要的一个技术问题:如何设计一个灵活的系统和如何构建可以确保变化不会破坏系统的自动化测试。为了在团队里培养高级专业技能,团队需要积极从错误中学习并进化自我。

(顺便提一下,我选择对原则10 中的简单进行解释的原意跟Jobs 一样,都是为了强调易用性的重要意义:“简单可以比复杂更难:你必须非常努力地让你的想法足够清晰,使之变得简单”)

向敏捷过渡并不是一场容易的旅程。如果它不起作用,就仔细的看一看,想一想。它可能暴露了你团队中的一些根本性问题。你可以转向白板,找出是什么减缓了你团队前进的脚步,使用精益工具比如因果关系图和五个为什么发现根本原因,解决它们,之后你将会收获敏捷的全部好处。

关于作者

Chen Ping在中国的上海生活,2005 年获得计算机科学硕士学位。从那时起,一直就职于 Lucent 和 Morgan Stanley。目前她在 HP 担任开发经理。工作之余,他喜欢研究中医。这是她的博客

查看英文原文: Why Agile Didn’t Work

2015-10-15 18:583033
用户头像

发布了 92 篇内容, 共 22.6 次阅读, 收获喜欢 4 次。

关注

评论

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

一个小巧、快速、轻量级的 .NET NoSQL 嵌入式数据库

不在线第一只蜗牛

数据库 nosql .net

数据交付变革:研发到产运自助化的转型之路

百度Geek说

大数据 数据分析 BI 分析工具 企业号 1 月 PK 榜 数据仓模

软件测试/测试开发/全日制/测试管理丨前端框架Vue

测试人

软件测试

中国电信天翼云位列云数据库领导者象限!

天翼云开发者社区

数据库 云计算 大数据

软件测试/测试开发/全日制 |利用ChatGPT自动生成自动化测试脚本

测吧(北京)科技有限公司

测试

软件测试/测试开发/全日制/测试管理丨后端接口文档管理Swagger

测试人

软件测试

TikTok云手机:突破传统社媒营销方式的黑科技

Ogcloud

TikTok 云手机 海外云手机

企业成功部署SD-WAN的七个关键要点

Ogcloud

网络 SD-WAN 企业网络

软件测试/测试开发/全日制/测试管理丨RESTX框架

测试人

软件测试

荣登榜首,天翼云位列专属云容器服务市场第一!

天翼云开发者社区

云计算 容器服务

玩转TypeScript--openInula中的TypeScript实践(第一篇)

openInula

typescript 前端 Web 开发 前端框架

聚道云软件连接器助力某品牌管理有限公司实现有赞对接三联

聚道云软件连接器

案例分享

面试官:单例Bean一定不安全吗?实际工作中如何处理此问题?

王磊

Java 面试

软件测试/测试开发/全日制 |Python全栈开发:实践容器化部署与微服务架构

测吧(北京)科技有限公司

测试

软件测试/测试开发/全日制/测试管理丨ORM中间件 SQLAlchemy

测试人

软件测试

左耳听风 - 做正确的事,等着被“开除”「读书打卡 day 04」

Java 工程师蔡姬

读书笔记 程序员 读书 职业发展 左耳朵耗子

揭秘关键指标稳定币供应比率(SSR):它如何影响你的投资?

Footprint Analytics

区块链 加密货币 稳定币

阿里云实时计算企业级状态存储引擎 Gemini 技术解读

Apache Flink

谷歌SEO秘籍:On-Page seo开启网站突破之门

九凌网络

创建service后,kubernetes会发生什么

华为云开发者联盟

Kubernetes 云原生 后端 华为云 华为云开发者联盟

腾讯云 Elasticsearch 新篇章 - 存算分离+读写分离+查询/IO并行化, 助力日志/搜索领域降本增效

腾讯云大数据

ES

怎么看待存在争议的低代码?

高端章鱼哥

软件开发 低代码 JNPF

飞管飞控系统仿真应用探究与浅析

DevOps和数字孪生

飞管飞控

跨境电商卖家都在用的海外云手机

Ogcloud

云手机 海外云手机 跨境电商云手机

5分钟搞定vue3函数式弹窗

不在线第一只蜗牛

Java Vue 函数式

聚道云软件连接器助力企业实现有赞商城与金蝶云星空系统无缝对接

聚道云软件连接器

案例分享

国内有哪些比较好用的低代码开发平台?

互联网工科生

软件开发 低代码开发平台 JNPF

基于“小数据”的机器学习

快乐非自愿限量之名

人工智能 机器学习 AI 人工智能技术

软件测试/测试开发/全日制 | Python全栈开发实战:搭建高可用的分布式系统

测吧(北京)科技有限公司

测试

年度回顾 | 2023年,云起无垠的开拓与创新

云起无垠

尊嘟假嘟?三行代码提升接口性能600倍

EquatorCoco

MySQL 接口

为什么敏捷没有起作用_文化 & 方法_Chen Ping_InfoQ精选文章