AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

为什么敏捷没有起作用

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:583178
用户头像

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

关注

评论

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

ElasticSearch写入流程详解

IT巅峰技术

elasticsearch

软件设计模式:适配器模式

正向成长

设计模式 适配器模式

在线JSON压缩工具

入门小站

工具

东方园林应邀参加人民网《人民会客厅——两会时刻》栏目访谈

科技大数据

Tapdata Cloud 2.1.2 来啦:大波细节已就绪!字段类型可批量修改、支持微信扫码登录、新增支持 Vika 为目标

tapdata

《数据密集型型系统设计》LSM-Tree VS BTree

懒时小窝

哈希 B-tree 列式存储 LSM-Tree

2022第12周-程序接盘侠

李印

离职交接

持续精进,性能突破,openGauss 3.0社区版正式发布

Geek_32c4d0

GaussDB(for openGauss) 社区版

AI 加持实时互动|ZegoAvatar ⾯部表情随动技术解析

ZEGO即构

计算机视觉 即构科技 Avatar

netty系列之:netty中的核心MessageToByte编码器

程序那些事

Java Netty 程序那些事 4月月更

Redis(二)分布式锁与Redis集群搭建

神农写代码

前端食堂技术周刊第 31 期:Vue 3、Vitest 中文文档上线、Pinia 正式成为 Vue 官方默认推荐的状态管理库、Vite v2.9.0

童欧巴

JavaScript 前端 Web web前端 前端工程师

Redis集群架构剖析(4):槽位迁移,重新分配

非晓为骁

redis 分布式架构 redis cluster

计算机网络: IP地址,子网掩码,网段表示法,默认网关,DNS服务器详解

喀拉峻

网络安全 IP

Rust中值销毁前的清理动作

Shine

rust

大数据洞察画像自动化实践

网易云信

大数据

Postman中文版客户端

Liam

Jmeter Postman API swagger Mock

沙龙:如何使信息系统更加稳定

博睿数据

北京市支援合作办公室党组书记、主任丁勇一行到正镶白旗调研京蒙协作工作

科技大数据

完美结合,10款提升编程能力的游戏项目!

Jackpop

信通院牵头数列科技参与主编的《信息系统稳定性保障能力建设指南》正式发布

TakinTalks稳定性社区

Whats On Tap | Tapdata Cloud 如何助力大型家居连锁商城推进数字化经营?

tapdata

新闻速递 I MobTech首席数据官杨冠军受CSDN之邀,探索企业数字化转型最佳路径

MobTech袤博科技

数字化转型 企业 数智未来

一文浅谈:我们为什么需要云原生

穿过生命散发芬芳

4月月更

中国信通院联合OpenMLDB邀您参加《开源数据库发展研究报告》调研问卷

第四范式开发者社区

数据库 大数据 开源

模块二:作业微信朋友圈的高性能复杂度

本人法海

「架构实战营」

Linux之lastb命令

入门小站

在线正则表达式可视化测试工具

入门小站

工具

Flutter 简单实用的 fluro 路由管理插件简介

岛上码农

flutter 大前端 ios开发 安卓开发 跨平台开发

吹爆Python,解决了10个痛苦已久的难题

Jackpop

津厦两地托育行业发展线上视频交流会成功召开

InfoQ 天津

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