用协同游戏解决“给力超问题
http://www.zy-yj.com 2017-11-11 12:58   来源: 未知  
  

  语音输入法,助力手游提升用户体验;语音合成,开创低头一族听小说时代;机器人语音对话,炫酷而又实用;智能客服,节省了商业运营的人力成本。

  智能音箱市场一片红海,语音作为智能交互的入口,再次被推上风口浪尖。远场语音识别与近场有什么区别?难点,解决方案又是什么?我们将与您一起探讨。

  Kafka Streams是2016年发布的Apache Kafka 0.10版本中引入的一个新Feature,提供了对存储于Kafka内的数据进行流式处理和分析的功能。与Spark、Storm等流式框架相比,Kafka Streams具备低延迟和轻量级等特点,使得它在特定业务场景(比如本文所介绍的广告消耗预测)中成为更理想的流式框架的选择。

  中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少。中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速迭代以验证商业模式,很少去关注技术架构。这时如果继续按照原有的架构及研发模式,会出现大量的问题。能不能有一套可直接落地、基于开源、成本低,可快速搭建的中间件及架构升级方案呢?作者将现抛砖引玉,与大家一起探讨这方面的问题。

  《原生云基础设施:动态可扩展基础设施与应用程序模式》是O’Reilly Media出版的有关现代基础设施构建和管理的系列指南。为了进一步了解他们提供的以及如何依照指南采取行动,InfoQ采访了该书的作者。

  Luke Hohmann指出,“给力超问题”(Awesome Superproblem)代表了一类庞大、复杂而持久的问题,它们只能通过协同方式解决。协同工作的关键在于实现一些严肃的游戏,其中参与者自愿遵守游戏规则,意在创建更好且更持久的结果。

  Luke Hohmann是Conteneo的CEO,他将在2017年精益&敏捷苏格兰大会上以“给力超问题”为题目做主题。大会将于10月4日至6日期间在举行:

  (精益&敏捷苏格兰大会)将广泛地覆盖部分常见主题,从整体上审视伟大软件产品的生成之道。各分会将会拓展的思维,为他们引入新的,并为投身于精益和敏捷的新手提供帮助,使他们可以开始一个新的旅程。

  InfoQ采访了Hohmann,所涉及问题包括:解决“给力超问题”如此困难的原因何在、创立协同工作去解决问题的条件是什么、如何能将回顾扩展到整个企业层面等。

  Luke Hohmann:当前,我将“给力超问题”定义为具有如下特点的问题。首先,问题应常“给力”的。这类问题会激发人们的、和认真对待。其次,问题也应是“超级”的,是不能被个人单枪匹马解决的,必须协同他人一起解决。

  Hohmann:导致了解决“给力超问题”存在挑战的因素很多。下面给出从我个人经验中所发现的。

  最突出一点在你的提问中就能发现:你使用了“解决”一词。这类似于提问,是否你可以“解决”吃饭问题、睡觉问题或是洗澡问题。当然你可以解决当下的问题,但是问题还会周而复始的出现。这类问题是一种持久性问题。

  持久性决定了一个问题是否会成为“给力超问题”。例如城市预算、工作的未来发展、管理共享的和稀缺的天然资源、处理气候变化问题等。虽然我们并不能一劳永逸地“解决”其中任何一个问题,但我们还是需要去处理这些问题,正如我们需要解决吃饭、睡觉和洗澡问题一样。

  Hohmann:我认为,如果使用游戏和游戏用于作为协同的基础,那么协同工作就能最好地解决这类问题。下面我将使用Innovation Game®的“修建产品树”(Prune the Product Tree)游戏为例。当然读者也可以使用自己最喜欢的游戏或回顾技术去验证概念。

  我们应具有一个目标,或者说要去实现的事情。例如,在“修建产品树”游戏中,目标就是根据产品组成上的需求修剪产品或服务。

  参与者应清楚地了解自身所掌握的资源、各自的角色以及如何使用这些资源(即参与和交互的规则,其中包括了获取和处置资源的规则)。继续回到我们的例子上,“修剪产品树”游戏的参与者被赋予了数量有限的苹果,通常每个苹果表示一个产品特性。但是,我们也可以考虑对“修剪产品树”游戏稍作变更。如果参与者能给出特别引人注意的想法,那么就可以“挣到”更多的苹果。

  参与者明确地创建了开展工作所需的空间或“游戏场所”。有时是参与者亲自现场创建的,但是我们也看到,更多的企业已迁移到使用Conteneo Weave平台在线创建,这可解决分布式团队相关的挑战,并可以扩展。

  协同结果将对参与者产生切实的影响。当“修剪产品树”游戏的参与者相信他们的反馈将会调整有问题的产品或服务时,游戏的效果最好。

  注意游戏是协同的基础。将此基础置于实践中,意味着要解决协作度设计空间的不同维度。下面给出其中一些常见的维度:

  亲自还是在线:有时协同将是亲历亲为,例如单一Scrum团队参与发布计划。而有时协同是在线的,这时会有数十乃至数百个团队参与到这种参与式预算中。

  团队的结构:一个团队可以是稳定的,也可以是动态的;可以是同构的,也可以是异构的;可以基于现有结构,也可以是以特设方式构建,这取决于设计者的目标。团队可以由内部利益相关者组成,也可以由客户或者合作者等其它外部利益相关者组成。

  Hohmann:我发现自愿参与如果是团队自身文化的组成部分,那么最容易实现。团队的行为规范是团队文化的组成部分,通常表现为工作协议。例如,尽管在“Scrum指南”中定义了“Sprint规划”中的Scrum实践,但是在实践中,我所指导的团队立刻在适当的Sprint过程中发现了真正的价值所在,并自愿选取了继续参与实践。只要 团队能在使工作组发现自身目标的协同框架中发现价值,那么这种自愿参与将会持续下去。

  InfoQ早期采访过Hohmann,并做了名为“用在线游戏召开大型回顾会”的报道。在这篇报道中,Hohmann解释了为什么在线游戏适用于大规模回顾:

  Hohmann:在线游戏的成本比较低,也能比较快地得到结果,团队可以在方便的时间做回顾,并且能够提供更好的数据分析。有些人比较内向,还有些人愿意说出自己的,而不是在公司里随声,那这种在线的形式能够更好地获得和描述这些人的想法。

  Hohmann:Conteneo公司在可扩展回顾上处于领先的地位,所执行的回顾从十数个到超过60个敏捷团队。其过程十分直接:

  确认企业的领导者正寻求对跨多个团队的性能加以改进。确保领导者明确项目将会给出一些相当棘手并难以解决的问题。

  找出一到多个可以帮助企业识别改进机会的回顾框架。例如,Sailboat由于其隐喻性和性,无疑是一个好的选择,它使团队能够识别出哪些会构成障碍,哪些会产生加速。

  找出一个可促成回顾的促进者团队。只要Scrum Master可以管理好自身的固有,他们无疑是适合的人选。

  为每个团队规划一个回顾。我们的经验是,如果通过亲历亲为的回顾技术实现此,那么需要过长的时间,并且过于令人乏味。我强烈使用专门设计用于大规模协同的平台。

  范围:该障碍是否可被团队修复(在团队的控制和/或职责范围内),或是需要由企业去解决?为说明其中的差异,我们假定在一个企业回顾中找出了一系列重要的架构更改,诸如Angular由1.6升级到了4。如果只有一到两个团队,那么协同更改十分容易实现。但是如果企业具有三十个、七十个乃至一百个以上的团队,那么就需要创建跨所有团的项目(即一个“企业范围”上的项目)。

  我们理解您使用ad blocker的初衷,但为了InfoQ能够继续以免费方式为您服务,我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单,感谢您的理解与支持。