写点什么

可持续的速度——怎么理解?如何实现?

  • 2011-10-10
  • 本文字数:2151 字

    阅读完需:约 7 分钟

“以可持续的速度工作”,这是《敏捷宣言》的原则之一,也常常是难以实现的一条。 Agile Leader 新闻组最近开始讨论可持续速度的相关话题。

什么才是真正“可持续的速度”,如何始终如一地达成可持续的速度,这是讨论围之展开的两个中心。

Bob Sarni 引用敏捷原则,开启了这次讨论:“敏捷过程提倡可持续的开发。出资方、开发人员和用户应该能够保持恒久稳定的进展速度。”

他进一步说明:

在我与众多组织和团队的工作经验中,可持续的速度看来是这些团队和组织共同面临的问题。要维持可持续的速度,需要很多因素——产品的路线图和承诺、愿景、速度 / 流 / 节奏、工作与生活的平衡、可见性、企业文化、个人问题、信任、多任务,等等。 团队层面要做到可持续的速度难度更高,因为团队中每个人都有自己的可持续速度,并且影响团队的整体速度。

Manoj Vadakkan 认为:无法以可持续速度工作,其问题在于,组织在实施敏捷实践时,没有深入理解背后的价值观和原则。

我看到的实施 Scrum 主要的问题在于:它被当做迭代过程实施,没有以原则和价值观做基础。不知道大家是否同意:可持续速度的问题,是我们的流程没有以速度为基础造成的诸多问题之一。 我担心的是:总体来说,关于这一点我们强调的还不够——不以敏捷的价值观和原则为基础,这个(Scrum)不会有成效。

其他人也同意:如果不以敏捷价值观为起点,敏捷和 Scrum 的转换将不可持续,团队和个人会面临精疲力竭的风险。 Scott Duncan 讲述了自己与大型组织工作的经验:

  1. 就我所知,他们现在希望人们可以“持续”的,称为“职业周”,比如 50 个小时,或是每天多加班 2 个小时,而且不会有加班费或任何补偿。
  2. 基于小时数的估算方法,假定人们每周高效工作至少 40 个小时(即使期望人们每周只工作 40 个小时),每个特性和需求都会以小时数估算,然后团队中的人员数目乘以 40,再乘以按周计算的开发时间段,再把得到的结果用需求和特性的小时数填满,这样团队和项目所有的小时数就被充满了。
  3. 相信真正的职业人士会“一切可能把工作完成”,因此并不真正关心可持续的理念。
  4. 着手工作时,假定所有的时间都已经被占用,因此任何没有事先规划的事件(比如变更、设计“发现”等)都会假定使用加班来吸收掉。

Manoj Vadakkan 引用了自己在 Scrum 联盟网站上的一篇文章,他在其中的总结是:

当然,客户不关心你的雇员是否每天长时间工作,可你是否跟他们讨论过产出代码的质量?试着告诉他们不利一面,他们也许会开始关心。长期看来,客户如果想在下个版本中改变代码,他们才是付账的人。你是否认为可持续速度值得拥有?也许我们应该跟客户商量商量。也许他们会同意质量很重要,也许不然。有一点可以确定:我们不能替他们拿主意。

Karen Greaves 基于自己的经验,提供了具体建议:

我现在在自己组织内的工作方式是: 1. 断开工作小时数和工作效率或是交付价值之间的联系。作为管理人员,永远不要度量工作小时数。也就是说,不要用工时表,不要有固定的工作小时数,甚至不要暗示员工“必须”每天工作 8 小时。更应该做的,是设定人们应该交付的成果的期望值。
2. 把关注点放在完成工作上,而不是保持忙碌。如果你今天工作不在状态,不如回家。如果你今天小宇宙爆发,而且工作不断取得进展,那就继续下去。引用一下 Kent Beck 那句话:“如果你不想工作,那么你在办公室里度过的每一个小时,都等于是加班。”
3. 永远不要让人们周末加班。
4. 提供一个有吸引力的目标,这可以激励人们达成它,而不是编造一个无法实现的截止日期。
5. 不要把工作安排得太紧。留出人们估计无法如常工作的时间。我们有特快专递日、实验室日,还有正常的周五学习时间。

目前来看,这些做法在我的团队内效果还不错,虽然业务人员很难接受,但是我对它们的坚持还是有所收获。当我一年多前接受我现在的工作时,团队会定期在周末和深夜加班。去年,我们可以做到在每个发布日期当天的下午 6 点之前发布版本,而且从未在周末加过班。质量改进了,大家的工作满意度提升了,人员流失率也降低了。工作效率虽然有所波动,但与其直接相关的,是版本发布的目标和规划。

在 Agile Leader 讨论组外,还有一些人就可持续速度的话题发表了自己的看法。

Bob Hartman(“ Agilebob ”)有一篇文章《刚接触敏捷吗?从以可持续的速度工作开始吧》。他在其中指出,如果无法做到以可持续的速度工作会有什么后果:

  1. 缺陷会增加。疲劳的团队会产生更多缺陷。
  2. 工作产出会降低。疲劳的团队在更多时间内完成的工作更少!
  3. 士气会大幅降低。这会导致雇员们在项目的最低潮期时离职。
  4. 互相责备的游戏会更普遍。(你之前没说 X,所以不是我们的错;我当时就说了来着;当时没那么做;当时就那么做了……)
  5. 团队开始抛弃优秀实践,转而选择“看起来”更快的时间。抱歉,比起只是写代码,然后抛给墙那边的 QA 去测试来说,测试驱动开发(TDD)确实更快!

他为敏捷团队的主管们提出强烈建议:

项目经理和 Scrum Master 需要观察团队的精神和身体健康程度。要维持可持续的速度,主管必须要能感受到团队的状态。把上句话再读一遍,再问问你自己:做项目经理时,如果发现团队不健康,就让他们减少工作时间,上次这么做是什么时候?

在您的团队中,“可持续的速度”意味着什么?您是如何确保可以维持下去的?

查看英文原文: InfoQ: Sustainable Pace – What’s it mean and how to achieve it?

2011-10-10 01:132051
用户头像

发布了 479 篇内容, 共 157.4 次阅读, 收获喜欢 49 次。

关注

评论

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

少林寺方丈释永信造访 Meta 总部;OpenAI 正在摧毁创业公司?丨 RTE 开发者日报 Vol.80

声网

致敬记者节,合合信息扫描全能王助力新闻工作者构建“随身资料库”

合合技术团队

人工智能 合合信息 扫描全能王 记者节 新闻工作者

立冬礼物已送达,小艺陪你开启“暖冬”模式

最新动态

DDD技术方案落地实践

EquatorCoco

技术 DDD 教程 教程分享

杭州悦数出席 2023 云栖大会计算巢专场,分享云上最佳实践

最新动态

AI对抗中的AI:技术展望与应用研究

EquatorCoco

人工智能 AI

HarmonyOS应用开发

不在线第一只蜗牛

华为 架构 系统 HarmonyOS

软件开发全套资料整理下载(投标支撑,立项,研发,测试,实施维护,安全监测,服务巡检,结项,验收支撑)

代码人,代码魂

浅议特权账号防护措施

尚思卓越

网络安全 数据安全 特权账号管理

Macos视频下载工具:Downie 4 支持M1

彩云

视频下载 downie 4

第三方数据测评对比五大品牌HTTP代理!哪家代理最纯净稳定

Geek_bf375d

AutoCAD 2024 中文版 附 完整图文安装激活教程 支持M1

彩云

mac软件下载 AutoCAD 2024

软件测试/测试开发丨接口自动化学习笔记——请求方法构造

测试人

软件测试 接口测试

重庆上百位老师和学生,正在使用这个国产操作系统

OpenCloudOS

Linux 操作系统

冬天的第一份惊喜,是小艺给的!

最新动态

SAE 2.0,让容器化应用开发更简单

Serverless Devs

云计算 负载均衡 Serverless

提速30%!HarmonyOS NEXT自动化测试开发效率提升

新消费日报

Linux中比cp好用10倍的rsync,你会用了吗

高端章鱼哥

Linux rsync

前端常用的开发工具有哪些?

互联网工科生

前端框架 前端开发工具 JNPF

全方位监控基础设施,坚实守护您的业务稳定!

观测云

监控 基础设施 网络

COSCon'23|Sermant亮相2023第八届中国开源年会,共赢数智时代

华为云开源

开源项目 微服务治理 sermant

实例详解构建数仓中的行列转换

华为云开发者联盟

数据库 后端 华为云 华为云GaussDB 华为云开发者联盟

大模型时代,程序员的工作还是“写程序”?

SoFlu软件机器人

程序员 软件开发 AIGC java 技术提升

加密货币交易软件开发:树立行业新标准

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

数据赋能业务,神州数码HR数字画像荣获2023HRoot人力资源管理卓越实践奖

科技热闻

软件测试/测试开发丨接口自动化学习笔记——响应体断言

测试人

软件测试 接口测试

程序员这个职业未来会消失吗?

高端章鱼哥

编程 程序员 AI编程

可持续的速度——怎么理解?如何实现?_研发效能_Shane Hastie_InfoQ精选文章