2015年11月3日星期二08:35

在用户故事中关注故事

撰写者

用户故事几乎已经成为敏捷上下文中无处不在的需求工件。用户故事中有很多有关它们,它们的格式,如何编写,相关的验收测试等的文章。

galennov2

至于验收测试,我们已经超越了编写测试的范围,而将其表达为在Cucumber和Robot Framework等工具中作为“可执行测试”。

所有这些演变都很棒,对用户故事协作方面的关注也是如此。

但是我开始在教练旅行中发现一些麻烦。我认为我们可能会过多地关注作为敏捷需求工件的用户故事。相反,我们应该退后一步,将用户故事视为一种更简单的通信设备。

这仅仅是一个故事,而不仅仅是一个书面故事,而是一个面对面讲述的故事。

想像

实际上,在撰写本文时,我设想的是一个典型的讲故事场景,其中一群侦察员在深夜里围在篝火旁。侦察长正在向他们讲述一个故事。通常这是一个恐怖的故事,旨在娱乐,但也会引起听众的焦虑。

随着故事的继续,童子军向前倾。他们的脉搏增加,并且他们开始听到周围树林中的噪音,这会抬高手臂上的头发。它们成为故事的一部分。对他们来说这是真实的,他们可以想象这些单词。实际上,在短时间内,故事变成了现实。

我相信这就是Kent Beck最初创建用户故事时的意图。这不是必需条件,而是团队与客户之间的互动对话。

目的是让客户或利益相关者与他们的团队坐下来,以讲故事的方式分享他们的愿景。它旨在进行协作,共享想法,并提出问题。随着讨论的进行,团队将非常熟悉客户试图改善的挑战或问题。

他们没有告诉团队交付什么,而是简单地分享了自己的观点。并且团队将以同情和理解的方式来回应如何实施可帮助其客户的事情。实际上,他们也开始考虑可能会缩小理解范围的实验。

如果这是最初的意图,让我们开始研究敏捷团队中可能讲故事的某些方面。

把客户放在第一位

我们越能预见客户及其背景,团队将能够更好地实施解决方案,以解决他们的挑战,并最终使他们感到惊喜和高兴。

讲述有关客户的故事。他们的动机是什么?他们的环境是什么?他们的经验水平是多少?他们是谁-特别是?重要的是,他们正设法解决其请求中的哪些问题?

相关文章: 撰写出色用户故事的50种方法

找出让他们兴奋的东西,而不让他们兴奋。不仅要探索他们的迫切需求,还要尝试了解他们未来的挑战以及一年或一年以上的挑战。

galen3nov2

卡诺模型 讨论客户需求的三个基本类别:

  • 欢欣鼓舞者 –产品或应用程序中的WOW因子。
  • 基本需求或必须具备的 –这些是产​​品的“赌注”。
  • 性能或线性 –越多越好。

这三种类型的客户需求与客户对他们的反应的满意程度以及团队的执行和质量交付动态相对应。

比谈论客户更好,邀请他们加入您的团队。沟通越直接越好。而且,使用诸如Kano之类的模型来探索其对功能,优先级,影响和需求的反应可能很强大。不仅在决定建造什么以及何时建造它,而且围绕Kano的对话更加强大。

这是我对卡诺的参考- http://www.agilebuddha.com/agile/faster-time-to-market-or-lower-cost-of-development-is-a-delighter-anymore/

背景故事

您的客户要求软件功能的原因经常有很多。其中一些是由业务需求驱动的。其他系统则具有更多的上下文关系,例如,一个较旧的系统已经过时,以致无法再满足其需求。或者他们需要功能,但需要升级,更易于维护的“程序包”。

通常情况下没有讲故事,您需要从客户,利益相关者或客户中“取悦”。

您还需要进行第一个反应,这通常是–我需要它,因为我需要它。您需要耐心“深入”他们的思维过程和动机。

一种有效的方法是观察。要求客户向您展示他们今天的工作,这可能使您深入了解他们为何要求新的东西。例如,如果他们向您显示他们当前的过程缓慢或笨拙,那么速度和简单性将是至关重要的。

探索此问题的另一种方法是通过演示。向他们展示简单的纸张和代码原型,这些原型和代码原型的构建成本很小,从而可以得到他们的反应和反馈。无论我们如何做,我们都有责任探究客户要求背后的驱动因素。

现在,我想稍作调整,并探讨我们讲故事的一些关键策略。

讲故事的策略

很好的介绍

通常,仅了解您的客户就非常有用。他们叫什么名字?他们在公司中的职位或角色是什么?还有一点是他们的经验水平?在开始说之前–您如何设计此功能或特性,停下来了解它们。

这包括自我介绍和分享激励你的东西。来到一个可以互相了解的地方,改善彼此之间的关系。花一些时间在一起,最重要的是,观察,提出开放性问题并深入聆听。

动机

我已经看到演员们为自己的角色或舞台上的场景做准备,而经常出现的话题是“他们的动力”。女演员探讨了导致当前情况或背景的角色,事件和经验。

女演员经常尝试将情况与他们的经历和历史联系起来,以便他们可以更好地为观众理解和表达这一时刻。

另一种描述方式是请求背后的原因。在他的《为什么开始》一书中,作者 西蒙·西内克(Simon Sinek) 探索有效的领导者如何从目标背后的原因开始。换句话说,探索他们想要达到的目标。我认为有效的产品负责人会做同样的事情,而不是简单地要求功能。他们首先从请求背后的原因开始。

可视化

我是科幻小说和奇幻小说(特别是奇幻小说)的狂热读者。使优秀作者与优秀作者脱颖而出的一件事是,他们具有建立一个可视化世界的能力。通常,他们正在发展一个充满文化,种族,地域,家庭,历史,人物以及善与恶二分法的整个世界。

在我阅读时,我经常可以形象地看到世界,既是作者已经建立的事物,也开始将我的想象力添加到环境和环境中。

用户故事需要调用相同的内容。他们需要鼓励读者或听众利用他们的想象力。根据已分享的内容提出问题。或者,更好地提出建议,以建议用户如何展开或期待某些事物。

白板在此方面特别有用。当团队在白板上讲故事时,一些不同的人开始绘制和可视化选项时,我喜欢它。

填补空白

好故事往往不仅仅会带给您情节。相反,情节是一波三折地展开的。实际上,在最后一个页面中,您很难知道一个坏蛋是谁。在大部分故事中,您都试图“把事情弄清楚”。

正是这种谜或阴谋使故事吸引了读者(或听众)。

我认为,用户故事会出现漏洞或“故意模糊”的原因之一是鼓励听众用他们的经验和直觉填补空白。这是激发整个团队创造力的有力方法。

激动

一个好的故事应该吸引听众的注意。它应该引起他们的注意,并最终产生一些活力和兴奋。

而且您不必一次就产生那种兴奋。我认为故事在本质上通常是迭代的。您开始讲出来,时间用完了。因此,您可以让听众“继续前行”或考虑一下故事。让他们开始制作自己的故事,这最终是讲故事的人的目标。

同情

我认为同理心使自己“陷入困境”。这不仅仅是角色扮演或思考练习。这是一种深入而坚定的努力,旨在树立客户的心态。

访谈和观察通常可以在这里提供帮助。我记得当我在iContact时,我们工程团队中的所有人每个月都会花费2-3个小时与我们的客户支持人员一起坐下来听客户的电话。在众多好处中,这极大地增加了我们对客户和支持人员的同情心。

并且它也改善了我们的产品质量。

成功

关于验收测试或验收标准的一件很酷的事情是,它们有助于定义用户故事的完成方式和成功方式。这是一个非常有用的概念。

通常,在讲故事时,我们不仅要分享我们想要的东西,更重要的是,我们想要或不需要的东西。这种清晰的边界可以帮助团队专注于解决方案,而不会陷入镀金的陷阱。

下一步

当然,每个故事都应该采取行动并采取后续行动。或者我应该说这激发了行动。应该对下一步的工作有内在的意识,并且有动力去实施它。

实际上,当我们讲故事时,我们还应该包括所听到的导致我们实现或解决方案的背景故事。这只是故事的一章的结尾。

包起来

作为写作工作的一部分,我经常讲故事或分享故事。它的一个关键方面是它们必须真实且相关。

但是我有种感觉,这是向读者传达信息的最佳方法之一-使我的课程变得真实,并使之在读者的“真实世界”中引起共鸣。

我并不是说我是最好的讲故事的人。我当然不是。但是讲故事的行为是我发现的最丰富的交流方式之一。

希望我启发您以不同的方式看您的用户故事,并增加讲故事的尝试。

保持敏捷,我的朋友们,

鲍勃

PS:写完这篇文章后,我发现了Brian Hoadley在LinkedIn上的一篇简短文章,他在其中进行了探索- 了解叙事在我作品中的重要性。虽然与UX相关,但我认为它很好地补充了本文

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站