Erin McManus和Ryan McKergow在1st Conference（专为对敏捷不了解的人准备的的一场会议）上发表了is there a future for business analysis?（商业分析有未来吗？）的演讲，他们探讨了当机构采取敏捷时商业分析的作用。InfoQ就商业分析的需要性，敏捷是如何影响商业分析师的角色和当采用敏捷举措时发生在商业分析的变化等对他们进行了采访，以及他们有哪些具体商业分析的做法可以推荐给敏捷团队。

\\

InfoQ：你认为当机构采用敏捷时，依然需要商业分析吗？

\\

\

McKergow：是的。我认为商业分析对敏捷的软件发展来说依然很重要。商业分析意味着批判性地思考和质疑我们所提供的价值，我们在试图解决什么问题？我们为什么把开发软件当做解决方案？

\\

它还包括理解机构的复杂性，如政府的监管变化、企业政策、行业标准、商务流程，一直进行的明细表。仅仅因为我们采用了和传统方法不同的敏捷工作方法，也不能意味着我们会忘记这些问题和考虑的领域。

\

\\

\

McManus：当然，我觉得 Ryan和我所说的是我们考虑软件的方式随着时间的推移而进化，所以软件开发团队里的角色也需要进化。我们真的需要考虑这些角色在未来可以做什么，尤其是采用敏捷后。 所以我确实认为在机构采用敏捷后还是需要商业分析。

\

\\

InfoQ：敏捷举措是如何影响商业分析师这一角色的？

\\

\

McKergow：就像软件开发中的其他每个角色，敏捷挑战了这一角色带来的作用，并且质疑：“我们还需要专门这样的一个角色吗？”这就是为什么敏捷鼓励跨职能团队。我们团队里拥有用于开发软件的所有技能，但我们不需要团队里一个专门的人，纯粹的专家（其他什么都不是）。所以它质疑了我们需要一个纯粹的商业分析师吗？需要一个纯粹的测试人员吗？这是两个例子。还有更多。

\

\\

InfoQ：你能就你所看到的当采用敏捷时发生在商业分析的变化，举些例子吗？

\\

\

McManus：敏捷增加了团队内部的协作，商业分析因为敏捷而发生改变的一个例子是拥有了创造一种共享语言的工具。我们在Behaviour Driven Development (BDD)的采用中看到了这点。商业分析师用Given, When, Then的BDD格式编写他们的验收标准。要写出这样的方案需要运用复杂的功能，同时和非技术人员用他们能理解的语言清晰地交流。\\
我们也看到了完成分析的时间和数量上有所改变。不仅仅有一种精益的“及时”生产方法来分析。只有在需要时做到所需要的。这就确保了在分析过程中没有浪费。

\

\\

\

McKergow：依我来看，我认为已经有传统商业分析师向T型分析师转变。你可能有专业化的分析，但你应该扩展在敏捷方面的技能。

\

\\

\

McManus：我同意！在开发过程中有更多的合作。我看到商业分析师扮演着测试人员的角色，所以他们可以确定开发团队将特性所需要的全部要求考虑在内，或者作为商业代表，像一名代理产品所有者签署特性一样。在敏捷团队里有更多的余地去承担不同的责任。不再是“这不是我的工作”，我们应该质疑，如果你能做，那为什么不做呢？我们不应该需要针对不需要专门知识的工作而配备专门人员。

\

\\

\

McKergow：我最近一直很多次扮演测试人员的角色。主要做手工的探索性测试，但是考虑系统间的数据流是一份很有趣的学习体验。这包括确保如果你在系统中更新数据，它会在相应的系统中更新！它也很好地刷新了我的SQL技能。我发现查询数据库的能力对分析有很有用处。尤其是定量分析有多少用户在使用特定的功能。

\

\\

\

McManus：这使得我了解了一些其他的T型技能。优秀的商业分析师现在更加地了解顾客以及他们的软件之旅。他们不仅对为什么企业想要这件既成产品感兴趣，更对这件产品设法解决的问题以及顾客会怎样使用它感兴趣。\\
商业分析师也处在一个影响团队动力的奇妙位置。他们和产品负责人紧密合作，与开发团队紧密合作，推动决策共识的达成，这是确保整个团队感受到拥有产品的很好方式。这对建立一个整个团队可以一起努力的共同目标也很有帮助。\\
所以你可以看到，商业分析师可以采取很多不同的方法来成为T型分析师，从而为他们的团队提供更多的价值。

\

\\

InfoQ：如果一个敏捷团队想自己做分析而不是由商业分析师来完成的话，该怎么办呢？

\\

\

McKergow：如果一个团队想自己做分析，那真是极好的。那就应该没有任何事阻碍他们。有一些商业分析师做的真的很有意思的事，他们可以试试。但是他们需要记住商业分析师的缺席不是避免做更多详细分析工作的借口。比如研究一项监管或政策。了解一些复杂的业务流程也是一个例子。还是要有人来承担这些责任。

\

\\

\

McManus：我在一个没有专门商业分析师的夫妇创新团队中工作过。这之间一点也没有觉得不自然，而且在文档类型方案中有非常多的协作。开发人员会亲自采访顾客然后研究解决方案。在那种快速追踪——建立、测量、学习——创新的环境中，正好不需要一个专门的商业分析师。

\

\\

InfoQ：你有什么具体的商业分析方法推荐给敏捷团队吗？

\\

\

McKergow：有很多技术可供团队里的人使用。以下是我最喜欢的一些：

\\

• 3 Amigos from ATDD——不是商业分析师包括产品所有者。就你打算发展的东西和你的开发人员、测试人员和产品所有者沟通一下。甚至是深入细节，关于每个故事的验收标准的细节。这有关于增强三者不同身份间的合作。你可以参考InfoQ对3 Amigos创始人的采访：George Dinwiddie on the three amigos 。\\
• Story kickoffs——和前面的3 Amigos相似，但尤其是当开始发展一个Story时，让每个人一起讨论它传达的是什么，想想怎么在技术上实施它，以及所有需要注意的事情。我在我们的公司网站上写到了这一技巧：How to introduce Story Kickoffs to your team.（怎样将Story Kickoffs介绍给你的团队。）\\
• Design studio（设计工作室）——这是我最近一直在用的一项使得团队合作共同设计产品的技术。团队可以从字面上理解问题的框架，然后在不同的设计中交流不同的想法，最后汇聚成一个成型的设计。Jason Furnell对这一过程有全面的认识：Facilitating Collaborative Design Workshops（促进协同设计工作室）。\

如果你处于这种情况，为什么不试试这些技术呢？你也可以扩展你的技能，为你的团队带来更多的价值。

\

\\

查看英文原文：Role of Business Analysis in Agile

\\

感谢张龙对本文的审校。

\

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群（已满），InfoQ读者交流群（#2））。