“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

扩展不需要蓝图和敏捷扩展循环

  • 2015-12-16
  • 本文字数:2914 字

    阅读完需:约 10 分钟

GOTO Berlin 2015 会议上,Stefan Roock 讨论了敏捷扩展不需要蓝图。InfoQ 有幸对其进行了采访,主要关于向 Scrum 中添加 XP 实践,为什么将敏捷框架作为组织设计的蓝图是不成熟的优化,和当扩展敏捷时,为什么文化和原则比实践更加重要。Roock 还解释了敏捷扩展循环(agile scaling cycle),并提供了如何使用的案例,讨论了这种方法对敏捷扩展的优点和缺陷。Roock 还用案例解释了如何使用敏捷扩展循环,讨论了这种方法对敏捷扩展的优点和缺点。

InfoQ:您讨论了在 mobile.de**** 中同时使用 Scrum**** 和 XP。添加 XP**** 实践的优势是什么?

Roock:一开始,mobile.de 能够每月发布一次。这在 Scrum 之前完全满足他们的工作方法。随着拥有超过 10 个并行 Scrum 团队之后,每月发布一次成了一个瓶颈。我们通过组织合并时隙(merge slot)设法解决这个问题——预定义每个团队将贡献合并候选版本的时间。

每个团队都尝试将尽可能多的特性放入每月发布一次的版本里,因此会为了下一次合并时隙产生冲突。当然合并过程中会发生不可预见的问题,因此合并会超过合并时隙。在这种情况下我们会为了该做什么争论不休。

  • 我们是否应该从发布中移除制造问题的团队,这样接下来的合并时隙计划可以保持不变。
  • 我们是否应该允许团队扩展合并时隙,如果这么做:我们是否应该推迟发布直到每个团队成功合并,或者我们是否应该从发布中移除晚于合并时隙的团队。

有一个专门负责这些事情的发布经理。

引入 Scrum 后不久,我们将重点放在持续集成和自动化测试方面(单元测试和 UI 测试)。这带来了更高的质量和更少的开支。团队更少使用分支,合并工作急剧下降。合并噩梦消失了,发布经理这一角色也过时了。

与此同时,mobile.de 开始使用 TDD、ATDD 和结对编程。

今天,如果需要,mobile.de 可以每天发布好几次。mobile.de 开发人员也在 ebay dev blog 记录了一些他们的经验。

InfoQ:您说将敏捷框架作为组织设计的蓝图是不成熟的优化。您能解释一下吗?

Roock:在我看来,局部和全局的蓝图 / 框架是不一样的。Scrum 是一种蓝图,也能够起作用。它帮助人们跨出第一步,给人们理解敏捷是什么和意味着什么提供指导方针。

当人们接受了敏捷的思维方式,他们就会找到适合他们自己的扩展方法。它会从实践中出现迭代——团队会检查 & 接受通往结构的方法。

扩展蓝图会对这种结构进行预先定义。但是为了什么呢?成熟的敏捷团队不需要它,并且会因此受到不必要的限制。而敏捷初学者团队也不应该扩展敏捷。在跑之间他们必须学会走路。

InfoQ:您有人们在不理解原则的情况下开始实践的案例吗?

Roock:在我开办的某次产品负责人培训中,曾经有个参与者说他有好几年的敏捷经验。当我们讨论产品 Backlog 时,他询问工具支持。以前他们使用 EXCEL,但是因为行数超出范围,他们又不得不舍弃它。原来,这家公司的实践非常的不敏捷,但是自己在局部贴上了 Scrum 标签。参与者觉得在公司学到了 Scrum,并且认为他真的有 Scrum 方面的经验。

另一件非常常见的事情是 Sprint 评审。我的培训学员中 80% 都将 Sprint 评审作为鉴定会(approval meeting)在使用:我们是否完成了我们计划的内容?只有非常少的一部分公司将 Sprint 评审用于讨论 Sprint 的投资回报率(ROI),并收集反馈用于改善产品。

而每次我被邀请去评估某个 Scrum 实施时,每日 Scrum 站立会议几乎每次都成了无聊的状态会议,而不是目标明确的充满精力的团队构建和计划活动。

InfoQ:您能否解释一下为什么你觉得在扩展敏捷时,文化和原则比实践更重要?

Roock:所有的敏捷方法都是非常的轻量化。只有少数的规则、角色、会议等等。这给适应目前的情况和改进留下了非常大的空间。同时也给错误留下了非常大的空间。

如果没有采用敏捷文化和原则,人们在敏捷实践时就会发生错误。他们会依据现有的参照标准解释实践。产品 Backlog 就会被看成是另一种形式的需求规格说明文档。Sprint 评审就会被当成鉴定会。每日 Scrum 站立会议就会变成状态报告。Scrum Master 就会扮演产品经理的角色,而产品负责人就成了某种官僚,负责向利益相关者索取需求。

敏捷原则有助于发现这些错误。

“欢迎改变需求,即使是在开发的后期。”这句话告诉我们一个固定的“产品 Backlog”肯定不能与敏捷思维同步。

“最好的架构、需求和设计来源于自组织团队。”这句话告诉我们如果仅仅向利益相关者询问他们的需求,开发肯定会发生错误。

在扩展方面,对于如何应用敏捷宣言有些方面并不明显。因此,一些教练包括我建立了扩展原则(详见 http://scaledprinciples.org )。这些扩展原则并不是新的发明,仅仅是有关扩展的现有原则的集合。

InfoQ:您能解释一下敏捷扩展循环的步骤吗?您为什么建议以这种顺序执行这些步骤?

Roock:敏捷扩展循环是一种简单的三步循环模型。在第一步中,我们减少团队之间的依赖。自主团队非常擅长敏捷。然后团队必须怀有敬意地对剩下的依赖关系进行协调。在这个工作中,组织的功能障碍会暴露出来,而团队的 Scrum Master 也没有能力移除每一个功能障碍(有些可能需要公司整顿)。Scrum Master 将为目前情况找出一个应急措施,而潜在的功能障碍将会在第三阶段得到解决:开发组织。

这个模型是我与 Peter Beck 在一次敏捷扩展培训中提出的。我们要求学员在便利贴上写下他们知道的扩展实践。当观察完学员写的内容后,我们意识到我们面临着一个巨大的工作量,我们需要一个结构来系统化实践。我们发现了三个集群:减少依赖、协调团队、开发组织。这些集群似乎非常有用,之后我们开始在演讲中使用,一段时间后,“敏捷扩展循环”这个称号就出现了。

与所有其它的模型一样,敏捷扩展循环也是错误的。但是有时它是有用的。敏捷扩展循环非常有利于集群扩展实践并且它有助于重点关注两个要点:

  1. 自主团队很重要。
  2. 检查 & 调整从而提高组织是必然的。

敏捷扩展循环错在次序。实际上,这三个步骤是并行完成的。你不会在步骤 2 中忙上几个月(协调团队),然后停止工作,带着一大堆的组织功能障碍问题进入步骤 3。

InfoQ:您能举例说明组织如何使用敏捷扩展循环?

Roock:我们通常被要求与不同团队一起“修复”敏捷实施。客户提的最多的问题是计划和协调团队。因此,他们在寻找更强大的计划和协调实践。

这些情况下,通常开始执行敏捷扩展循环步骤 1:减少依赖之后。当建立跨职能团队后,几乎所有情况下的这种问题都消失了。

第二个方面跟敏捷扩展循环的步骤 3 相关。企业必须认识到不仅仅团队层面需要持续改进过程。我们试图通过培训使大家建立这种认识。

InfoQ:敏捷扩展循环的优点和缺点?

Roock:优点之一是一开始你不需要拥有最佳结构。我非常喜欢 LeSS,但是一开始就完整安装 LeSS 对企业而言可能比较困难。敏捷扩展循环告诉我们努力减少依赖,然后与剩下的依赖一起合作。有问题的依赖就会暴露出来,那时就可以解决他们。

缺点之一是人们可能误解敏捷扩展循环是一个顺序过程,会推迟移除组织的功能障碍。另一个缺点是减少依赖和协调团队需要经验来选择合适的实践。当然,人们可能倾向于尽可能多地使用扩展实践——仅仅是为了确保成功。因此我创建了“Stefans 敏捷扩展成熟度模型”:你不再需要大量的协调实践。少即使多。

查看英文原文: Scaling Without Blueprints and the Agile Scaling Cycle

2015-12-16 18:00905
用户头像

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

关注

评论

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

centos系统应用日志文件被删,空间无法释放怎么办?

百度搜索:蓝易云

云计算 Linux 运维 服务器 云服务器

NAT穿透详解

百度搜索:蓝易云

云计算 Linux IP NAT 云服务器

每日一题:LeetCode-98. 验证二叉搜索树

半亩房顶

面试 算法 LeetCode 二叉树 DFS

2023 ACDU 中国行 · 西安站 | 数据库技术发展及实践

KaiwuDB

KaiwuDB ACDU 中国行

通过容器化应用实现前端微服务

Geek_2305a8

什么是shell?

小魏写代码

Amazon CodeWhisperer 审查:最新的 AI 代码伴侣

亚马逊云科技 (Amazon Web Services)

人工智能 机器学习 云上探索实验室 Amazon CodeWhisperer

国泰航空开发基于 MongoDB 和 Device Sync 的机上移动应用

Geek_2d6073

KaiwuDB 获评信通院 2023 大数据“星河”标杆案例

KaiwuDB

KaiwuDB “星河”标杆案例

低代码开发,到底存在多少误解?

秃头小帅oi

敏捷开发 低代码 开发工具 JNPF

Studio One 6 for mac(音乐制作工具) v6.2.0永久激活版

mac

Studio One 音乐制作软件 苹果mac Windows软件

TDengine 签约大唐水电院,助力水电时序数据高效写入存储查询

TDengine

tdengine 时序数据库

语音数据集:AI语音技术的基石

来自四九城儿

大模型元年压轴盛会定档12月28日,第十届WAVE SUMMIT即将启航

herosunly

软件测试/人工智能丨Spark开发分布式造数,构建大规模测试数据

测试人

人工智能 软件测试

大模型元年压轴盛会定档12月28日,第十届WAVE SUMMIT即将启航

爱编程的喵喵

小小的日志,大大的坑 | 京东云技术团队

京东科技开发者

性能优化 性能 日志

容器中域名解析流程以及不同dnsPolicy对域名解析影响

华为云开发者联盟

容器 云原生 华为云 华为云开发者联盟

测试用例设计方法六脉神剑——第三剑:倚天屠龙,正交试验冲锋 | 京东物流技术团队

京东科技开发者

测试 测试用例 正交试验

1688订单详情对接及实现方案

Noah

PAM案例——某大型医院

尚思卓越

数据库 运维 安全

语音数据集:推动AI语音技术的核心力量

来自四九城儿

持续测试性能的方法

敏捷开发

DevOps 性能测试 自动化测试 CD 持续测试

神经网络是如何工作的? | 京东云技术团队

京东科技开发者

人工智能 神经网络 AI

PWA 离线方案研究报告 | 京东云技术团队

京东科技开发者

前端 Web PWA

ChatGPT也宕机了?如何预防DDOS攻击的发生

Finovy Cloud

黑客 网络安全 机房 DDoS 黑客攻击

2024年程序员必须掌握的10款开发工具

伤感汤姆布利柏

敏捷开发 低代码 开发工具 测试工具 前端开发工具

华为云CodeArts Artifact:保障制品质量与安全的最佳选择

华为云PaaS服务小智

云计算 软件开发 华为云

程序员的护城河是什么 ?

KubeData

个体成长

互联网一线大厂最新高质量Java面试八股文整理(附答案)

架构师之道

程序员 java面试

【等保】安徽省等保测评机构名单看这里!

行云管家

等保 等级保护 等保测评 安徽

扩展不需要蓝图和敏捷扩展循环_方法论_Ben Linders_InfoQ精选文章