2018年6月14日,星期四09:39

点点滴滴:与敏捷开发团队合作

撰写者

我已经阅读了许多有关业务分析工具和技术的文章和书籍,以及何时在项目生命周期中使用它们。

我还没有看到太多的事情,BA是如何在敏捷开发团队中扮演不同角色的。我以前的博客谈到了将在瀑布框架中工作的文学士转变为敏捷的话题,因此,在这里我想深入研究一下您如何使用众所周知的工具和技术,以及如何正确地工作。人们确保这些技术的输出是有效的。该证书基于英国计算机协会(BCS)基金会商业分析课程的标题,适用于拥有该证书的人员。

调查情况–发现问题

众所周知,这个阶段是要了解问题所在。该技术主要用于发现阶段,并且在利益相关者参与方面非常繁重。但是,您使用的技能与用户研究人员的技能紧密相关。面试技巧听起来很简单明了,但是对于那些尝试过的人来说,这并不容易。理解公开和封闭的问题并从另一个“噪音”中挑选出重要信息非常困难。在采访利益相关者时,很容易:

  • 失去面试重点(偏离正轨)
  • 没有充分利用与被访者的时间,而最终无法跟进对话
  • 无法获得您想要的所有信息(再次导致跟进对话)

他们与优秀的用户研究人员一起工作,将向您展示如何创建有效的讨论指南,该指南不仅可以使您与被访者相处的时间最大化,而且可以将您需要的所有相关信息捕获到一个走。利益相关者很忙,可能不希望被联系很多次。

如果您在发现阶段的敏捷团队中拥有主题专家(SME),那么您将花费很多时间与他们一起了解“按原样”流程。不过,不要只是将它们用作信息,而要让他们参与阐明问题,无论是丰富的图片,思维导图还是情感图。让他们觉得自己是团队的一部分,这将建立关系,您可能需要在产品开发的后期阶段与他们建立联系。

考虑观点–利益相关者的识别和分析

首先要确定您的产品/服务的利益相关者,那时大多数开发团队都会参与其中。通常,这将是产品所有者/经理,交付经理(Scrum管理员),用户研究员和中小型企业。

利益相关者的识别和分析(例如兴趣/影响矩阵)会议应与整个团队一起进行,但广管局应与产品负责人密切合作,以了解那些需要管理的高利益/高影响力类别的利益相关者。虽然您可能没有直接参与他们的参与,但您可能需要了解他们的观点,因为他们很可能会看到您的一些成果(例如,问题识别,成本/收益分析)

分析需求-确定改进

在发现阶段完成之后,您就可以继续进行Alpha了,现在是时候(对我来说)参与产品开发的令人兴奋的部分……确定潜在的问题解决方案。

对我来说,这是产品开发的一部分,BA真正开始将他们在Discovery中所做的工作付诸实践,并与产品团队中几乎所有其他角色建立这种关系。让我们从原型解决方案开始。

现在,您已经与用户研究人员合作来确定用户需求,让中小型企业和利益相关者参与其中,以了解“按原样”流程,确定潜在的痛点,并列出您要关注和管理的利益相关者列表(理想情况下是通过沟通)战略)。在进行所有这些操作的同时,交互设计器/ UX将(或应该)一直在开发原型,以满足某些用户需求(并不是所有需求,毕竟是敏捷的)。那么,学士学位在哪里适合呢?好吧,首先,当您通过与利益相关者(包括用户)的访谈来激发用户需求时,您要确保UX所设计的内容能够满足这些需求(而不仅仅是他们认为是“好主意”的东西)公平地说,UX很少(如果有的话,很少这样做)。一些文学学士学位的书会说文学学士学位将创建原型,但是,在软件开发的今天,许多组织现在都专门从事UX,交互设计器或变体的工作(请注意这里。我曾与一位非常生气的人合作,当我提到当他是一个交互设计师时,给了他一个UX! 区别 顺便说说)


广告

现在已经开发出原型,您(以及UR)将其带给用户进行测试并获得反馈。同样,您将从优秀的UR中学习这项技能。试图阻止自己向用户展示如何使用原型非常困难……我们本来是有帮助的,但需要约束自己并观察用户的工作。

当您将测试的结果反馈给团队的其他成员(必须)时,您将询问开发人员和质量检查人员(如果有)要实施特定的解决方案,可能会有哪些限制(如果有)。在此阶段,您可以开始与质量检查人员联系,以了解他们如何希望用户故事中阐明的方案(例如,他们对BDD满意吗)。这很好地进行到下一阶段。

评估选项–高级用户案例

对于很多人来说,BA是本阶段和下一个阶段(定义需求)的地方,因为BA与用户故事有关。在这里需要指出的是,如果您还没有开始理解团队中的其他角色,那么最后两个阶段会变得更加困难。请记住,您正在与团队建立关系并相互理解,并且越早进行越好……对于每个人。我稍后再说为什么。

在对原型进行测试后,一些设计假设将转变为经过验证的用户需求,即用户喜欢所设计的内容,并且很乐意将其开发成“事物”。太好了,我们终于可以开始编写用户故事了!我不会在这里讨论该主题,因为那里有足够的信息来介绍如何编写良好的用户故事。在这里我要介绍的是,您必须让团队中的每个人都参与到这些故事的创建和阐述中。从开始到结束。不要将用户故事纯粹视为“ BA角色”。可能是编写它们,但它们实际上是整个团队的用户故事。没有什么比花时间和精力来创建您认为完美的用户故事更令人沮丧的了,而这仅仅是让前端开发人员在3个好友中说出设计已更改,或者API已被删除/更改导致功能必须更改。

让整个团队(不仅是开发人员和质量检查人员)了解故事是一种管理风险并确保将未知因素降至最低的方法。您将永远不会停止所有未知的事物,但是当团队中的每个人都知道故事的真相时,您可以将这些未知事物减少。毕竟,广管局不能指望一切!

定义需求–用户案例

我已经简要介绍了用户故事的开发,但是这里是您如何将其提升到一个新的水平,并成为开发团队的关键。我在所有敏捷团队中使用的最重要的工具之一就是用户故事图。杰夫·帕顿(Jeff Paton)撰写了一本很棒的书(我相信大家都读过),但是我的主要问题是将其付诸实践。我将在以后的博客中介绍如何克服这个问题,但就目前而言,用户故事地图不仅是显示用户故事的工具。这是使整个团队参与进来的产品的跟踪工具,以实现其目标。众所周知,用户故事地图不仅显示从左到右(用户旅程)的故事流,而且从上到下(发布)。它提供了团队工作的简短视图,但是如果您添加了设计师的假设委员会和产品愿景,它就会提供从设计到开发的整个流程。这也是在表演和讲述中使用的绝佳工具。它确实使利益相关者参与。不仅仅是一组无聊的幻灯片。

我加入了许多团队,这些团队还没有适当的用户故事图(他们通常只有一个冲刺板),但我发现整个团队都没有联系。设计师正在进行的工作不是产品路线图的一部分(如果有的话),或者他们正在进行用户研究,开发人员将在下一个冲刺中进行开发,而BA则没有时间进行故事分析。简而言之,每个人对产品的愿景都有不同的看法,从而导致不同的优先事项和行动。灾难的秘诀。

作为敏捷世界中的业务分析师,我们不仅需要集中精力与利益相关者建立关系,而且还要与将要开发产品的团队建立关系。这不仅是广管局的重要角色,而且我认为这对团队的成功至关重要。

尼克·斯托尔斯

作为将近5年的业务分析师,我逐渐意识到BA在业务中的作用仍然被人们误解了,我想向其他业务分析师提供BA如何为使用敏捷框架来实现价值的组织带来价值的见解。提供他们的产品和服务。

我想激发当前和未来的业务分析师 他们是项目团队提供基于用户的产品和服务并为人们带来创造力,创新和价值的基石。 

我坚信,出色的业务分析师是高绩效敏捷团队与非高绩效团队之间的区别。我从几个敏捷团队的经验谈起,他们使用了不同的项目交付变体(甚至是框架的混合),我将分享作为这些团队中的BA所经历的考验和磨难,以及当您作为BA参与所有工作时所经历的喜悦向最终用户提供具有创造力,创新性和价值的产品。

©BA Times.com 2020

麦格雷戈徽标白色网站