敏捷 2015:Ron Quartel 的 Scrum + 极限编程 (XP) 的好处

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

会议吸引了形形色色的人群进入 Ron Quartel 的 Agile 2015 演讲 房间;他们想听听 Ron 的回答,了解如何处理软件工艺活动和敏捷活动中的分歧如此之大,以至于甚至分裂了会议世界。没过多久,罗恩就开始了。

罗恩通过引用专家关于卓越技术重要性的观点来奠定基础。例如,Scrum 的共同创始人 Jeff Sutherland 博士说,很少有 Scrum 实施 达到真正的超高效状态(正常团队绩效的 500% 到 1,000%),而那些达到它的实施了极限编程的变体.

极限编程 (XP) 涉及硬技术实践,包括测试驱动开发、重构、结对编程和持续集成。这些做法改变了完成工作的方式,并且可能需要数月的时间来学习和发展专业知识。另一方面,Scrum 改变了工作的组织和管理方式;组织可以在几天内采用 Scrum。

根据 Quartel 的说法,结果是组织选择了快速简便的方法,而不是艰难而有纪律的方法。 Ron 继续展示了 VersionOne 的敏捷状态调查 Scrum 联盟的 Scrum 状态报告的调查结果, 它们都显示了 50% 到 90% 之间的压倒性采用 Scrum,只有不到百分之一的组织在进行实际的极限编程。

然后罗恩扔下了炸弹。

现实:公司不关心提高质量

指出经过多年的讲道质量并看到它被置若罔闻,罗恩转而谈论速度和增加的速度。用他的话来说,“突然间,同一家公司都被洗耳恭听了。” Ron 建议,这可以解释为什么 DevOps 和持续交付 是业界的热门术语:它们承诺更快、更频繁地交付软件。

这是个问题,因为像极限编程这样的实践需要前期投资。当您添加结对编程时,技术实践看起来会使开发速度减慢 50%。学习测试驱动开发和建立持续集成意味着团队的进度将低于 50%。此外,我们已经知道无形和无形的质量卖不出去。

就投资而言——用数字和电子表格——可能会有所帮助,但速度下降 50% 的心理障碍对管理层来说太大了,无法承受。 Ron 建议你需要一些东西来让人们感受到痛苦,而他正好有一个练习:Scrum Gauntlet of Debt。

练习

Ron 挑选了七名志愿者,开始担任两个角色:开发人员和测试人员。开发人员的数量比测试人员多五比二。一面墙上的便签纸代表待办事项。开发人员将即时贴 从开发转移到测试, 测试人员将它们从测试转移到完成,所有这一切都在短短的时间内完成,大约两分钟。罗恩扮演经理的角色,劝告参与者完成更多的工作,因为毕竟管理需要的是速度。

回合结束后,罗恩拖了几把椅子挡在路上,代表必须解决的技术债务。在简短地警告安全之后,罗恩开始了下一轮,恳求各队走得更快。房间里的温度上升了,人们开始感到压力,是的,性能上升了。

一阵子。

随着时间的推移,罗恩增加了更多的椅子,性能下降了。

然后罗恩改变了规则,模拟了技术实践。因为程序员在投资,他们不得不停止跑步,以可持续的速度行走,并且每两分钟冲刺就拿走一把椅子。随着时间的推移,性能恢复了。

在新风格下进行了一两轮之后,罗恩打破了练习,并在电子表格上展示了两种风格随着时间的推移对表现的影响。第一种“硬驾驶”风格有立竿见影的效果:压力下的人确实表现出色,但长期影响是随着团队承担债务而速度缓慢下降。与此同时,拥有以可持续的速度消除债务(技术实践)的工具的团队在很长一段时间内行动得 更快

罗恩透露的数学可能很简单,但它很有意义。随着时间的推移,管理人员通过技术实践获得速度和更快乐的团队。与此同时,他们进行了一项练习,让他们看到并感受到作为一个不断推动速度的团队是什么感觉——感觉并不好。

可以尝试的东西

如果您正在与一个不愿学习现代技术实践的团队或不愿花时间进行投资的管理团队作斗争,请仔细阅读此练习。详细规则可在 Scrum Plus Extreme Programming (XP) for Hyper Productivity 的 幻灯片 21-23 中找到。与几个朋友一起运行它以解决问题,然后在部门员工会议上提出它。像 Ron 一样,解释吸引语言学习者的方法,然后提供图表以帮助视觉和练习到达边做边学的人。

练习后,试着想出一个小实验,与一个团队或一个项目一起运行。决定要投资的东西和时间框,让人们有足够的时间学习新东西——也许一个月——知道它一开始会导致放缓。一个月结束后,见面并提出下一件事。

并准备好进行第二次练习——人们会开始期待它。

在最后三分之一的演讲中,Ron 回到了没有卓越技术的 scrum 的后果。

关于债务的更多信息

在我们看到压力的力量之后,我们能够讨论它在组织中的样子。人们走捷径:他们剪切和粘贴代码并创建做太多事情的大量对象。当需要修改代码时,一个地方的小改动可能会导致意想不到的行为。 探索性测试 和设置需要更长的时间并且是必要的,因为这里的改变可能会破坏那里的东西。

简而言之,质量受到影响。

罗恩提醒我们他之前提到的:没有人关心质量。成本是看不见的。然而,就像团队成员试图绕着椅子跑一样,技术债务会导致进展停滞不前。他的重要教训是:不注重质量的“结果驱动力”“起作用”,直到它不起作用,突然间,取得进展变得困难且代价高昂。

在另一个例子中,Ron 从儿童玩具 Etch-a-Sketch 中画画。在 Etch-a-Sketch 上画东西很简单——问题在于扩展对象。由于没有“擦除”按钮,作者不得不要么留下有错误的图画,用黑色填充它们,要么重新开始。作为替代方案,Ron 建议团队学习开发代码作为工艺,并指出了一组旨在使代码随着时间的推移具有延展性和可快速发布的技术。

Ron 继续从技术实践开始为团队提供一些指导:

  • 在冲刺中建立松弛状态。将速度降低 20% 并开始
  • 学习 James Shore 的 《敏捷的艺术》 等书籍
  • 找一个 XP 教练,因为这可以在六个月内压缩到高功能的旅程。

采取下一步

阅读概念是一回事;体验它是另一回事。因此,请在 演示文稿的幻灯片 中查看 Ron 的 Scrum Gauntlet of Debt 的完整规则,可在线免费获得。与您的团队一起进行练习,然后聚在一起讨论下一步该做什么。罗恩建议聘请一名技术教练,以减少达到超高效率的时间。没有预算的团队可以考虑读书俱乐部; Andrew Stallman 的 Learning Agile 是一本涵盖 Scrum、看板和极限编程的现代著作。如果您正在寻找如何在团队中采用这些想法,您可能想研究 Ron 的扩展方法, 快速敏捷 ,它涉及开放空间的使用、技术人员报名工作以及非常紧迫的时间限制。

今天我们带你了解了这个理论并讲述了这个故事。下一步由您决定。