Luke Hohmann 指出,“给力超问题”(Awesome Superproblem)代表了一类庞大、复杂而持久的问题,它们只能通过协同方式解决。协同工作的关键在于实现一些严肃的游戏,其中参与者自愿遵守游戏规则,意在创建更好且更持久的结果。
Luke Hohmann 是 Conteneo 的 CEO,他将在 2017 年精益 & 敏捷苏格兰大会上以“给力超问题”为题目做主题演讲。大会将于 10 月 4 日至 6 日期间在爱丁堡举行:
(精益 & 敏捷苏格兰大会)将广泛地覆盖部分常见主题,从整体上审视伟大软件产品的生成之道。各分会将会拓展与会者的思维,为他们引入新的理念,并为投身于精益和敏捷的新手提供帮助,使他们可以开始一个新的旅程。
InfoQ 将以问答、总结和文章的形式覆盖大会全程。
InfoQ 采访了 Hohmann,所涉及问题包括:解决“给力超问题”如此困难的原因何在、创立协同工作去解决问题的条件是什么、如何能将回顾扩展到整个企业层面等。
InfoQ:什么是“给力超问题”(Awesome Superproblem)?
Luke Hohmann:当前,我将“给力超问题”定义为具有如下特点的问题。首先,问题应是非常“给力”的。这类问题会激发人们的敬意、畏惧和认真对待之心。其次,问题也应是“超级”的,是不能被个人单枪匹马解决的,必须协同他人一起解决。
InfoQ:是什么使得解决此类问题如此困难?
Hohmann:导致了解决“给力超问题”存在挑战的因素很多。下面给出从我个人经验中所发现的。
最突出一点在你的提问中就能发现:你使用了“解决”一词。这类似于提问,是否你可以“解决”吃饭问题、睡觉问题或是洗澡问题。当然你可以解决当下的问题,但是问题还会周而复始的出现。这类问题是一种持久性问题。
持久性决定了一个问题是否会成为“给力超问题”。例如城市预算、工作的未来发展、管理共享的和稀缺的天然资源、处理气候变化问题等。虽然我们并不能一劳永逸地“解决”其中任何一个问题,但我们还是需要去处理这些问题,正如我们需要解决吃饭、睡觉和洗澡问题一样。
InfoQ:在哪些条件下,协同工作可以解决问题?
Hohmann:我认为,如果使用游戏和游戏用于作为协同的基础,那么协同工作就能最好地解决这类问题。下面我将使用 Innovation Game®的“修建产品树”(Prune the Product Tree)游戏为例。当然读者也可以使用自己最喜欢的游戏或回顾技术去验证概念。
- 我们应具有一个目标,或者说要去实现的事情。例如,在“修建产品树”游戏中,目标就是根据产品组成上的需求修剪产品或服务。
- 参与者应清楚地了解自身所掌握的资源、各自的角色以及如何使用这些资源(即参与和交互的规则,其中包括了获取和处置资源的规则)。继续回到我们的例子上,“修剪产品树”游戏的参与者被赋予了数量有限的苹果,通常每个苹果表示一个产品特性。但是,我们也可以考虑对“修剪产品树”游戏稍作变更。如果参与者能给出特别引人注意的想法,那么就可以“挣到”更多的苹果。
- 参与者明确地创建了开展工作所需的空间或“游戏场所”。有时是参与者亲自现场创建的,但是我们也看到,更多的企业已迁移到使用 Conteneo Weave 平台在线创建,这可解决分布式团队相关的挑战,并可以扩展。
- 在达成目标的过程中,具有清晰的反馈。所有“修剪产品树”游戏的参与者都可以看到结果。
- 协同结果将对参与者产生切实的影响。当“修剪产品树”游戏的参与者相信他们的反馈将会调整有问题的产品或服务时,游戏的效果最好。
- 参与者是自愿的。他们并未强制合作。
注意游戏是协同的基础。将此基础置于实践中,意味着要解决协作多维度设计空间的不同维度。下面给出其中一些常见的维度:
- 亲自还是在线:有时协同将是亲历亲为,例如单一 Scrum 团队参与发布计划。而有时协同是在线的,这时会有数十乃至数百个团队参与到这种参与式预算中。
- 团队的结构:一个团队可以是稳定的,也可以是动态的;可以是同构的,也可以是异构的;可以基于现有结构,也可以是以特设方式构建,这取决于设计者的目标。团队可以由内部利益相关者组成,也可以由客户或者合作者等其它外部利益相关者组成。
- 同步与异步操作:参与者可以实时地协同操作游戏,或是在很长的时间面上操作。
InfoQ:在实践中,自愿参与的情况如何?
Hohmann:我发现自愿参与如果是团队自身文化的组成部分,那么最容易实现。团队的行为规范是团队文化的组成部分,通常表现为工作协议。例如,尽管在“Scrum 指南”中定义了“Sprint 规划”中的 Scrum 实践,但是在实践中,我所指导的团队立刻在适当的 Sprint 过程中发现了真正的价值所在,并自愿选取了继续参与实践。只要 团队能在使工作组发现自身目标的协同框架中发现价值,那么这种自愿参与将会持续下去。
InfoQ 早期采访过 Hohmann,并做了名为“用在线游戏召开大型回顾会”的报道。在这篇报道中,Hohmann 解释了为什么在线游戏适用于大规模回顾:
Hohmann: 在线游戏的成本比较低,也能比较快地得到结果,团队可以在方便的时间做回顾,并且能够提供更好的数据分析。有些人比较内向,还有些人愿意说出自己的心声,而不是在公司里随声附和,那这种在线的形式能够更好地获得和描述这些人的想法。
InfoQ:您是如何将回顾扩展到企业层级的?
Hohmann: Conteneo 公司在可扩展回顾上处于领先的地位,所执行的回顾从十数个到超过 60 个敏捷团队。其过程十分直接:
确认企业的领导者正寻求对跨多个团队的性能加以改进。确保领导者明确项目将会给出一些相当棘手并难以解决的问题。
找出一到多个可以帮助企业识别改进机会的回顾框架。例如,Sailboat 由于其隐喻性和开放性,无疑是一个好的选择,它使团队能够识别出哪些会构成障碍,哪些会产生加速。
找出一个可促成回顾的促进者团队。只要 Scrum Master 可以管理好自身的固有偏见,他们无疑是适合的人选。
为每个团队规划一个回顾。我们的经验是,如果通过亲历亲为的回顾技术实现此,那么需要过长的时间,并且过于令人乏味。我强烈建议使用专门设计用于大规模协同的平台。
跨团队的数据应从以下维度分析:
- 类别:该障碍是否和人、过程、技术或其它因素有关?问题和分类是否表现出明显的模式?
- 范围:该障碍是否可被团队修复(在团队的控制和 / 或职责范围内),或是需要由企业去解决?为说明其中的差异,我们假定在一个企业回顾中找出了一系列重要的架构更改,诸如 Angular 由 1.6 升级到了 4。如果只有一到两个团队,那么协同更改十分容易实现。但是如果企业具有三十个、七十个乃至一百个以上的团队,那么就需要创建跨所有团的项目(即一个“企业范围”上的项目)。
在特定的更改列表上,添加代价及对影响的估计。
让团队选择它们想要解决的障碍。
开始工作!
查看英文原文: Tackling Awesome Superproblems With Collaborative Games
评论