BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

通过讲故事进行敏捷辅导的本质

| 作者 Ben Linders 关注 20 他的粉丝 ,译者 马凯 关注 0 他的粉丝 发布于 2014年12月17日. 估计阅读时间: 5 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

通过讲故事的方式,团队和其他团队以及敏捷教练分享他们的经验。Patrick Steyaert和Wim Bollen说,敏捷教练可以通过经验分享过程的引导来提升和帮助团队实现自组织。他们展示了一种基于原型构建的技术,用来从团队的故事中挖掘知识,团队可以利用这些知识规划并展开自己的敏捷之旅。

2014年布鲁塞尔敏捷之旅大会上,Patrick和Wim组织了一个关于敏捷辅导本质的研讨会——没有教练的敏捷辅导。他们两人以及与会者所讲的故事被提炼成原型团队,代表一种典型的敏捷实现。

对于想采用敏捷的企业,有许多现成的框架和解决方案可用,每一种都有其适用的领域。选择和推行它们可能是有困难的,当采用敏捷框架所需要的变革强加给团队时,他们有可能会抵制。在关于探索一种综合方法来管理多样化敏捷团队的白皮书里,Patrick描述了为什么多样化在敏捷实施中很重要。

一方面CIO追求基于一种模型或方法的标准化,但同时他们也不能忽视“多样化定律”,即不同的敏捷方法是有必要的,而同时支持所有这些方法又会使标准化变得困难。团队各有不同:不同类型的工作,不同的人,不同水平的敏捷经验,不同的价值观,不同的目标,不同的做法和不同的工作标准等等,以上只是几个关于团队之间差别的例子。毕竟,敏捷动物园是多样化需求的结果。一个单点解决方案在某种情况下奏效,但在另一种情况下却未必(……)。在整个企业中发起规模化敏捷转型计划很复杂:不仅仅因为没有所谓的“一刀切”的方法(即并非所有的变化都是一样的),而更重要的原因是,当在自己的团队中实施敏捷时,人们不想丢弃已经积累的经验,这不足为奇。

教练或顾问会用一些敏捷评估方法来评估团队。当团队被这样衡量的时候,其行为可能会改变,但Patrick说,问题是他们是否会真正地变得更加敏捷。正如Patrick 和Wim的描述,“成为敏捷”需要一种不同于“做敏捷”的观念:

做敏捷

  • 教练是专家——教练最清楚该如何工作
  • 一刀切——所有团队都需要遵守标准实践
  • 知识传递——一对多地传递做事方式

成为敏捷

  • 教练是一个引导者——团队成员最清楚该如何开展自己的工作
  • 支持多样化——团队有不同的需求,但是对于什么是成为敏捷有着共同的愿景
  • 知识共享——多对多地分享哪些实践是可行的而哪些是不可行的

知识分享有不同的方法。例如,回顾帮助团队通过反思学到什么地方做得好以及什么地方需要改进。教练可以通过“展示与讲述”的方式帮助团队学到实践和经验。叙事方法是利用故事案例深入了解团队如何开展组织内学习。

Patrick和Wim在布鲁塞尔敏捷之旅大会上组织了一个研讨会,通过讲述一些趣闻轶事来练习讲故事。Wim讲述了他如何帮助一个银行软件产品供应商进行敏捷转型的故事,拉开了研讨会的序幕。他们把参与者分成多个小组,并要求他们在即时贴上用关键字记录故事中有特色的东西。只要能保持内容言简意赅,他们想写多少张即时贴就写多少。参与者是不允许提问的,他们必须听并真正地从故事中获取内容。

Patrick也讲了一个故事,而最后,其中一个参与者也分享了他在一个故事中的经验,所有的参与者则持续地在即时贴上写关键字来记录故事中有特色的东西。Patrick说,在分享的时候,最好提供两个有几分相似的故事,而另外一个故事则完全不同。两个类似的故事为某种方法提供了深度和细节,而不同的故事则拓宽了解决方案,并通过一些不同的经验激发了创意。

Patrick要求参与者把写有关键字的即时贴按主题分类聚集起来。其中的部分主题是关于“过程”、“团队技能”、“交付”、“反馈”、“体系和愿景”以及“计划”等。当所有的即时贴都有了主题名,Patrick就要求小组删除即时贴里的关键字,而只留下主题名字,然后让团队看看哪些主题出现在了不同的小组中。

Patrick要求参与者为每个主题给出四个从非常正面的到非常负面的解释。当给出解释后,主题的名称就可以移除了。

我们现在就有了正面和负面的解释。参与者被要求把这些解释汇集成一个项目或团队的原型,并给每个原型取一个生动的名字。举个例子,一个团队把一些正面的解释归纳成了“梦之队”,而负面的解释就归纳成了“来自地狱的队伍”。

Patrick和Wim说,主题可以帮助我们抓住什么是重要的,而原型让我们可以深入了解主题相关的不同方法。这种多样化有助于团队决定他们采取什么方法来实施敏捷满足自己的需要。这样,团队们就可以规划并踏上自己的敏捷之旅。

查看英文原文:Intrinsic Agile Coaching with Storytelling


感谢谢丽对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

传统企业敏捷转型难 by 黎 邓根

我们是轨道交通信号行业,这个行业的软件开发需要遵循EN50128等标准,对文档质量追溯等要求非常高,在项目组内尝试敏捷往往举步维艰,也许这个行业不适合过不需要敏捷?

Re: 传统企业敏捷转型难 by 滕 云

其实不管是什么类型的企业,实施敏捷都有难度。正如文章中所提到,不同公司和团队都存在差异性,随意实施敏捷在任何一个团队都不是一帆风顺的。而且实施敏捷过程团队也遵循学习曲线的规律,开始的时候工作效率会有有所降低,等到团队学会了整体效率才会提升,最后超过直线。很多团队看到效率降低就不干了,还有些团队断断续续经历了几次尝试才成功。对于你说的那个文档其实只是实施敏捷过程中的一个疑问。敏捷框架中并没有对最终形成的文档要求,知识做任务的时候会将任务拆分细,降低复杂度和风险,是项目得以顺利的进行。用户故事和你说的东西是两码事,他们不冲突。建议你在深入的了解敏捷思想。之前遇到过几个行业的求职者,聊过之后发现他们并没有真正理解团队当初为什么会用敏捷。如果有添加可以邀请敏捷团队或者thoughtworks公司中的团队加入你们的团队中,帮助你们顺利的实施。

Re: 传统企业敏捷转型难 by 黎 邓根

非常感谢您的指导,我现在对敏捷的大致认识和我们项目的实践如下,希望您能不吝赐教:
敏捷目的:在变化的需求下,快速且高质量的交付可发布版本。
敏捷关键点:高效沟通,小步迭代,自动化测试。
敏捷价值观:沟通,简单,反馈,勇气,谦逊。
我们的特点:需求不会有快速的变化,人员结构也相对稳定,不要求短周期的快速发布,但也不是长周期,对安全性和可靠性要求非常高!
我们的要求:可预期可控的交出高质量的阶段性产品。
我们的做法:在SIL2要求的V模型下进行迭代开发,每个迭代的每个小功能都通过启动会和小会,以白板画图建模的方式进行简单有效的沟通,通过逐步建立自动化测试和沟通快速的得到反馈,验证设计和实现的正确性。每天通过站立会议和白板进行简单沟通,工作协调和进度跟踪。通过doors建立追溯。简化了详细设计文档的内容,关注设计思路而不关注实现细节。简化了质量流程。

Re: 传统企业敏捷转型难 by 黎 邓根

非常感谢您的指导,我现在对敏捷的大致认识和我们项目的实践如下,希望您能不吝赐教:
敏捷目的:在变化的需求下,快速且高质量的交付可发布版本。
敏捷关键点:高效沟通,小步迭代,自动化测试。
敏捷价值观:沟通,简单,反馈,勇气,谦逊。
我们的特点:需求不会有快速的变化,人员结构也相对稳定,不要求短周期的快速发布,但也不是长周期,对安全性和可靠性要求非常高!
我们的要求:可预期可控的交出高质量的阶段性产品。
我们的做法:在SIL2要求的V模型下进行迭代开发,每个迭代的每个小功能都通过启动会和小会,以白板画图建模的方式进行简单有效的沟通,通过逐步建立自动化测试和沟通快速的得到反馈,验证设计和实现的正确性。每天通过站立会议和白板进行简单沟通,工作协调和进度跟踪。通过doors建立追溯。简化了详细设计文档的内容,关注设计思路而不关注实现细节。简化了质量流程。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT