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

加入小点:与敏捷开发团队合作

Written by

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

我没有看到这么多的是BA如何在敏捷开发团队中使用不同的角色。我之前的博客进入了在瀑布框架中工作的BA的变化,触摸这个主题,所以我想深入了解我们如何使用的工具和技术,以及如何与权利一起工作人们确保这些技术的输出是有效的。它基于英国计算机社会(BCS)在商业分析课程中的基础,为那些认证的人员标题。

调查情况 - 揭示问题和问题

正如我们所知,这个阶段是关于了解问题是什么。该技术主要用于发现阶段,并且对利益相关者参与非常沉重。但是,您使用的技能与用户研究人员的技能密切相关。面试技巧可能听起来非常简单和简单,但对于那些尝试过的人来说,这并不容易。了解开放和封闭的问题并从其他“噪声”中挑选出重要信息是困难的。在对利益相关者进行面试时,很容易:

  • 失去面试的重点(跑道偏离)
  • 没有充分利用你对受访者的时间,并最终得到跟进对话
  • 没有得到你以后的所有信息(再次,导致跟进对话)

与良好的用户研究员一起使用,他们将向您展示如何创建有效的讨论指南,使您不仅可以最大限度地提高您的面试人员的时间,而且还捕获您需要的所有相关信息去。利益攸关方是忙碌的人,可能不想与许多次联系。

如果您有主题专家(中小企业)作为发现阶段的敏捷团队的一部分,那么您将花费很多时间与他们一起了解“原样”流程。不要只是为了信息使用它们,让他们参与阐明问题,无论是丰富的图片,思想地图还是情感地图。让他们感受到团队的一部分将建立您可能需要在产品开发中呼叫的关系。

考虑视角 - 利益相关者识别和分析

首先确定您的产品/服务的利益相关者将涉及当时的大部分开发团队。通常,这将是产品所有者/经理,交付管理器(Scrum Master),用户研究员和中小企业。

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

分析需求 - 识别改进

在发现阶段完成后,您已经开始了Alpha,现在是时候(为我)进入产品开发的令人兴奋的部分......识别出问题的潜在解决方案。

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

您现在与用户研究人员合作,以引出用户需求,从事中小企业和利益相关者理解“原样”流程,确定了潜在的痛点,并列出了您关注和管理的利益相关者(理想情况下战略)。虽然这一切都进行了,但互动设计师/ UX将有(或者应该有)一直在研究原型以满足其中一些用户需求(并非所有这些,毕竟是敏捷的)。那么BA在这里适合哪里?嗯,首先,你参与通过与利益相关者(包括用户)的访谈引发这些用户需求,您希望确保UX正在设计的内容满足这些需求(而不仅仅是他们认为是“好主意”的需求。要公平,UX很少,如果大自禁出来)。一些BA书籍会说BA会创造原型,但是,在这些软件开发的日子里,许多组织现在专注于UX,互动设计师或变体(这里小心。我在推荐时与有非常愤怒的人合作当他是一个互动设计师时,他是一个UX !!有一个 区别 顺便一提)


广告

现在已经开发了一个原型,你(以及你的问题)将它带到用户测试并获得反馈。再次,这是一个你将从好的学习中学到的技能。试图阻止自己向用户展示如何使用原型很难......我们本质上有用,但需要约束自己,看看用户的表现。

当您将测试结果中的测试结果反馈到团队的其余部分(必须)时,您将询问开发人员和QA如果要实施特定解决方案,则可能会有(如果有的话)。在这个阶段,您可以开始聘请QA以了解他们如何希望在用户故事中阐述的情况(例如,他们对BDD感到满意)。这很好地流入下一阶段。

评估选项 - 高级用户故事

对于很多人,这个和下一阶段(定义要求)是BA进入自己的地方,因为它是关于用户故事的。值得注意的是,如果你还没有开始了解球队的其余作用,它会使最后的2个阶段变得更加困难。请记住,您正在建立与您的团队的关系和理解,并且您越早这样做是越好的......。我稍后会来为什么。

由于原型已经过测试,其中一些设计假设将转向验证用户需求,即,用户喜欢被设计的东西,并“很高兴”以进入“事物”。伟大的,我们终于可以开始写用户故事!在这里,我不会将该主题覆盖,因为这里有足够的信息来涵盖如何编写良好的用户故事。我将覆盖的是,您必须涉及团队中的每个人创造和阐述这些故事......从开始到结束。不要将用户故事视为纯粹的'BA角色'。它可能是编写它们,但它们实际上是整个团队的用户故事。没有什么比花费时间和精力更令人沮丧地创造了你认为的完美用户故事,只为前端开发人员说明了设计已经改变的3个Amigos,或者已经被删除/改变了API,从而导致必须改变功能。

使整个团队意识到故事,而不仅仅是开发人员和QA,是一种管理风险的方式,确保未知数保持最低。你永远不会停止所有未知数,但是当团队中的每个人都知道这个故事的情况时,你可以削减这些权利。毕竟,BA不能预期想到一切!

定义要求 - 用户故事

我简要介绍了用户故事的发展,但这是你如何把它带到一个下一级,成为开发团队的Linchpin。我在所有敏捷团队中使用的最重要的工具之一是用户故事地图。 Jeff Paton在主题上写了一本很棒的书(我相信你们所有人都已阅读)但是,我的主要问题是实现它。我会覆盖如何在后面的博客中克服这一点,但现在,用户故事地图不仅仅是用于显示用户故事的工具。它是让整个团队所涉及的车辆,让产品保持在轨道上实现其目标。如我们所知,用户故事地图不仅显示了从左到右(用户旅程)的故事流程,而且还显示出顶部到底部(发布)。它给出了团队工作的简短(ISH)的视图,但如果您在设计师的假设纸板和产品视觉中添加,它提供了从设计到开发的流程。它也是在展示和讲述的伟大工具。它真的让利益相关者订婚。不仅仅是一套无聊的幻灯片。

我加入了许多团队,他们没有拥有一个用户故事地图(他们通常刚刚得到一个Sprint板),我发现整个团队断开了连接。设计人员正在研究一些不属于产品路线图的东西(如果有的话)或者他们正在进行用户研究,开发人员在下一个冲刺中建造,没有时间进行BA来执行故事的分析。简而言之,每个人都有不同的对产品的视野,导致不同的优先事项和行动。灾难的配方。

作为敏捷世界的业务分析师,我们不仅要关注与利益相关者的建立关系,而且需要与将开发产品的团队建立关系。这不仅是BA的重要作用,我会争辩这对团队的成功至关重要。

尼克斯托

作为一家商业分析师,即将到达近5年的近5年来,我来实现BA的作用仍然误解了商业,我想提供其他业务分析师的见解,洞察BA如何为使用敏捷框架的组织带来价值提供产品和服务。

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

我真的相信一个好的商业分析师是一个高性能的敏捷团队和一个不是的差异。我与几个敏捷团队的经验说出使用不同的项目交付(甚至框架混合动力量),我将分享审判和磨难作为在这些团队中工作的BA,并且当您将所有点加入所有圆点时提供创造性,创新和价值的产品到最终用户。

©ba time.com 2021

MacGregor Logo White Web