我有机会与业务分析师进行大量的对话,而谈论话题通常会涉及到敏捷。
通常出现的问题是“Scrum中没有提到业务分析师角色。这是否意味着业务分析师没有一席之地吗? ”
简洁的答案是不对。
Scrum提到了三个角色–团队,产品负责人和ScrumMaster。头衔(我通常会描述为业务分析师)和这三个角色之间是有区别的。无论你的头衔如何,你都可以担任一个或多个职位,具体取决于你的组织,技能和过去的经验。
是的,我意识到越来越多的组织发布ScrumMaster和产品负责人的招聘广告来模糊这些界限。这不会改变以下事实:拥有业务分析师的背景并不会阻止您担任产品负责人,团队成员或ScrumMaster。实际上,我已经看到了所有这三种情况的案例。
产品负责人
我喜欢将产品所有权描述为主要做三件事情:
· 让每个人都专注于成果而不是产出
· 建立并保持共识
· 做决定
在许多情况下,业务分析师会充当产品负责人的角色,并做这三件事。为了实现这一点,业务分析师需要能够做出决定。
如果您是一位优秀的业务分析师,那么您已经在做前两件事情。通过帮助您的团队找到问题,而不是仅仅提供解决方案,您可以使每个人都专注于成果而不是输出。项目章程是实现这一目标的一种方法。
您可以通过运用分析技能来建立和维护共识,包括创建产品待办事项列表,优化待办事项列表以及与团队合作以使待办事项更加清晰。
在某些情况下,您可能无法自行做出决定。通常,当您与几个不拥有您的产品但有相当发言权的相关人员打交道时,就会发生这种情况。在这种情况下,您可能仍然是产品负责人,但是上面的第三件事情可以更好地描述为“确保做出决定”。如果您的工作做的好,您的团队将不会因决策延迟而受到干扰;他们可能只是不知道这些决策是如何决定的。
团队的一员
如果您是业务分析师但没有担任产品负责人,这并不意味着您在敏捷环境中没有一席之地。在一个相当普遍的模型中,产品负责人和业务分析师都在同一团队中工作。这种模型通常发生在产品负责人做出决定,而业务分析师建立并维系大家的共识。当有多个团队工作在复杂的产品上时,此模型也很普遍。
从事多年开发人员后,因为您想跟利益相关者和用户进行更多的交流, 您可能会成为业务分析师。一旦您的组织开始用敏捷的方式工作,团队中的任何人都可以与团队外的人进行交流,您可能会发现进行开发工作并与利益相关者和用户紧密合作,可以两全其美。
ScrumMaster
我还看到过业务分析师会扮演教练或ScrumMaster角色。如果您具有较强的引导技巧,并且乐于帮助团队解决他们的动态问题,那么这可能是您的最佳选择。如果您的产品负责人不具备与团队建立共识的丰富经验,那么您会发现这可能是一条不错的路。
技能比头衔更重要
归根结底,根据某人的现有头衔或职位将某人安排到敏捷团队中的特定角色并没有多大意义。您确实需要考虑他们的技能和过去的经验,并让他们在组建团队时能充分发挥这些技能。
应该已经很清楚了,当您的组织采用敏捷时,您应该做什么。但这可能并不那么明显,您可能需要掌握一些新技能或对工作方式持不同看法。或者您可能会意识到,您并不喜欢组织的方向,现在正是寻找不同机会的好时机。这实际上取决于您的技能以及您的最佳工作方式。这是一件个人的事情,而不是根据头衔来定。
这有两个重要含义。
如果您的组织因为职称而得到除掉整个团队的建议,那么被除掉的人就是提出建议的人。看他们的技能,看他们的适应能力。看他们学习的意愿。不要因为他们是业务分析师(或经理,或项目经理,或…)而让他们离开。
意识到并非每个人都希望以敏捷的方式工作。我遇到了业务分析人员,他们在产生极尽繁杂的需求规范或UML模型方面投入了很多。他们也许能够适应迭代和增量的工作方式或者不能。给他们一个机会,如果不成功,帮助他们找到可以成功的地方。
敏捷方法将重点放在工作人员及其交互方式上。当您给人们机会去做他们有激情,有能力和有精力去做的事情时,您就是在实现这一价值。具有业务分析师背景的人员可以给您的团队和组织贡献很多价值。他们只需要有机会证明这一点。
By Kent McDonald
ShineScrum捷行 翻译&编辑
原文链接:https://www.agilealliance.org/agile-qa-what-do-business-analysts-do-on-an-agile-team/?
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/295302.html