工程文化播客：敏捷开发中的业务分析与产品管理

这里是工程文化的播客，来源于 infoq.com 网友和 QCon 会议的与会者。

在这节播客中，InfoQ 文化与方法主编 Shane Hastie 与 Kent McDonald、Steve Adolph 和 Ryland Leyton 对话，讨论在敏捷产品开发的业务分析和产品管理情况。他们一起参加了一场周末研讨会。这场研讨会由敏捷联盟和国际商业分析研究所合办，旨在为知识的业务分析产生修订版本的敏捷扩展。

关键点

• 分析技能对成功的产品开发是必要的
• 我们不质疑和挑战项目的基本理论和战略调整，而这些都会由于错误的项目或在一个项目中构建错误的功能而导致大量的浪费
• 你可以得到的最好的投资回报是停止浪费你的钱
• 很难定义价值，但确认价值却非常重要；价值的定义在不同的情况下将是不同的
• 敏捷方法提供学习和快速的反馈，这使我们能够优化价值，并确保产品开发的战略调整
• 用例是会话占位符，并不是要完成的指令

0m 49s：介绍与会者。

2m 14s：解决误解，该误解认为敏捷开发不需要分析。一些组织匆忙地采用了敏捷，急急忙忙地撤掉了分析师这个角色，却完全不明白这到底意味着什么。

3m 27s：对于在敏捷开发中业务分析师可以起的作用，有时候人们会感到困惑。

4m 01s：有几种不同的模式可以整合所有分析、产品所有权和产品管理相关的所需技能集。

4m 37s：在敏捷环境下分析仍然是必要的，而且技能集对于成功的产品开发是非常必要的。

4m 53s：分析是确定实际的需求是什么，是质疑以确保需求是真实的–我们该要费心试图彻底解决它吗？

5m 00s：是否应该解决这个问题，通常是一个很难回答的难题，而这个难题却很少被问及，导致了许多浪费。

5m 20s：社会能力和协作能力在敏捷开发中变得越来越重要。分析的基本技能仍然是成功的关键。

5m 39s：需要成为跨界者，将不同的视角和观点结合在一起。

5m57s：需要从命令执行者变为跨界者。敏捷开发中的分析有重要的社会功能。

6m 15s：分析技能会起许多不同的作用。但在敏捷开发中做的分析远不是指令性的，而且一直如此。

6m 44s：你需要有一个非常全面的工具包，并且具备将所需工具与正在进行的工作内容联系起来的能力。

7m 13s：组织需要怎样做才能从分析技巧中获得最大的效益。

8m 22s：价值管理是一种被需要的新技能集–避免浪费，只做有价值的事情，并与组织战略保持一致。

9m 40s：能够把正在做的事情削减到最关键的部分，并且减少浪费的工作量，也是组织在采用敏捷开发时获得利益的途径。

10m 17s：需要用分析技能去不断完善积压的产品并且帮助产品经理知道什么时候交付足够的功能、能够停止某项工作、转移到下一项有价值的工作上。

10m 35s：做最有价值的事情。如果实际上项目没有价值，不要害怕去结束这个项目。你能得到的最好的投资回报就是停止浪费你的钱。

11m 05s：敏捷开发成功所需的三项技能：

• 你的专业技能（UX，开发，测试，设计…）
• 敏捷技术的使用技巧（如何参与敏捷开发团队）
• 协作能力

11m 40s：一些产品经理有好的产品的能力和良好的分析能力，然而还有许多人并不具备这样的能力，他们需要有这样能力的人的支持帮助。

12m 13s：价值是什么？我们如何确定积压的产品的价值，我们如何知道在什么时候停止？

12m 38s：价值是复杂的，它有很多种形式，它取决于正在进行的工作背景。有时它真的是，“当我看到它，我就会知道它”。对于任何功能：

• 它为我们带来了什么收入？
• 它为我们开启了什么样的机遇？
• 它为我们减少了什么风险？
• 它能使我们为社会做出什么贡献？
• 它如何有助于我们实现组织的战略和目标？

13m 52s：审视价值的一种方法就是“我们认定某些需求对于实现战略目标是重要的，我们满足这些需求了吗？”

14m 09s：早期主动进行重要谈话，就是要问清楚在这种背景下什么是价值，因为在每种不同的背景下，价值的内涵也不同。

14m 58s：有一种识别一个工作项的价值方法就是从四个角度排列优先级：

• 对这个产品的业务有什么价值？
• 这个产品的顾客有什么价值
• 开发的估计是什么（尺寸 / 成本 / 分值）？
• 如果我们生产这种产品，组织的成本是多少？

用这个来帮助开发优化功能。

16m 44s：有时你必须对积压的产品进行处理，排优先级，但这可能存在问题，因为不同的股东他们的观点会互相冲突。

16m 58s：想方设法使“对我的价值”越发显现，以便暴露幕后的动机（“我想要这个功能是因为它会帮我拿到回报”）

17m 38s：我们如何帮助组织以这种思维方式作为工作方式？

17m 53s：探索在组织背景下的价值，然后用它来帮助做出决定，并坚持到底。

18m 35s：有从项目到基于产品交付的推动力。如果有些工作是无法停止的，因为该产品已经有了自己的生命，这样的产品侧重点是有风险的。有时候最好的办法就是放弃对一个产品的工作，因为它对组织已经不再有用，或维持它的成本超过可能的回报。

19m 35s：敏捷方法给我们提供反馈机制和展示真正价值，或暴露其中功能的欠缺和适应快速反馈的不足的工具，以便引导开发获得更好的成果。

20m 35s：当我们围绕一个功能迭代时，我们要花真金白银，明白这一点是很重要的，因此，我们要找到使学习和反馈尽可能低成本的方法。

21m 00s：有降低反馈成本的方法，如纸上原型和低技术含量工具。

21m 30s：采用敏捷之后建模似乎已经过时。建模是一种廉价且快速的方法，用于缩小解决方案选项，并减少反馈周期的长度。

22m 05s：使用原型和建模有助于克服对需求分析的“当我看到它，我就知道它”的反应。

23m 30s：接下来会发生什么？–产品管理和分析的未来是怎么样的？

24m 02s：建立正确的东西并用 DevOps 支持它们，以确保以正确的方式建立它们并得到需要的反馈。

24m 44s：许多已经采用敏捷的组织从一开始就错过了强大的工程实践，实际上它是想法的核心部分。从极限编程的实践到现在已经有十五年，但往往被忽视或忽略。

25m 01s：我们开始看到更多解决上游活动的对话–积压的产品来自哪里，同时 DevOps 让我们可以看到下游活动，我们能够看到价值交付端到端的视图。

26m 55s：看着任何功能或积压物品，捍卫“你怎么知道”的想法，提出难以回答的问题，这个问题就是我们怎样保证确实有价值？确定价值的度量是什么？我们所做的一切都必须可以追溯到预期的结果，并且有指标告诉我们是否越来越接近结果。

28m 01s：作为未做列表的一部分，我们能够也应该拥有价值和意图，但是很少机构有这样必要的执纪水平并使其常态化。

28m 50s：许多团队已经忘记，在未做列表的项是对话的占位符，而不是必须不假思索执行的指令，当然仍有一些团队和组织正确使用了它。

30m 40s：衡量敏捷成熟与否的标准是一种和整个团队沟通的能力，沟通待定项在什么地方符合整体产品愿景，为什么有这样的项目，它的目的是什么，然后让团队在真正协作的环境中接受挑战，探讨和建议实现结果的方法。

31m 30s：梦寐以求的目标是能够跳出业务分析师的职位，确定一套关于分析的共同的好做法，以便所有的团队成员都可以使用，而且是经常使用，以确保我们专注于提供正确的产品。

32m 05s：最忙碌的研发人员处理积压物品，他们参与围绕价值、成本的谈话，非常有可能想出更好的主意，提出按需交付而不是只是满足需求的好方法。

33m 44s：让人们知道他们既有权利也有义务去都挑战和质疑要求–敏捷的关键点是关于个体和交互，我们需要开放对话，留出时间并且在一个安全的环境里征求团队成员的意见。

34m 30s：定期留出时间去进行谈话，和整个团队探讨，是否有比那些目前正在探索更好的实现目标的方式。

35m 05s：研发团队成员都是专注做好工作的专业人士，他们熟悉产品的运作和有能将事情做得更好的创意–我们需要创造一种氛围，在这种氛围里他们可以质疑、探讨和提议并且用他们希望的方式去处理积压物品–谈话占位符。

36m 00s：在主动的情况下，确保对什么是对价值有共同的理解。

36m 30s：接受每个团队都是不同的–你与不同的团队沟通的方式将会不同，这些和团队的成熟度、实践和团队工作环境都有关系。

37m 10s：成为团队的沟通枢纽–将人们聚集在一起，并促进对话，而不是试图详细定义要求。

38m 55s：帮助确保当他们进行沟通的时候，处理好积压成品并且项目是清楚的，要成为推动整个团队工作的积极推动者。

提到的公司和组织

• 敏捷联盟
• 学会–国际商业研究院分析（ IIBA – International Institute for Business Analysis）
• PMI–项目管理协会（ PMI – Project Management Institute）

资源

• Kent 的书：超越要求：敏捷思维的分析（ Beyond Requirements: Analysis with an Agile Mindset ）
• 支持和交付：加快业务敏捷性
• Steve 的书：有效用例的模式（ Patterns for Effective Use Cases ）
• Ryland 的书：敏捷业务分析师：从瀑布式到敏捷（ The Agile Business Analyst: Moving from Waterfall to Agile ）
• 敏捷宣言

关于我们的播客的更多信息

你可以通过我们的 RSS 关注播客上的更新，可以通过 SoundCloud 和 iTunes 得到。通过这个网页，你也可以访问我们记录下的笔记。他们都有可点击的链接，会直接链接到你需要的音频部分。

阅读英文原文： Engineering Culture Podcast: Business Analysis &Product Management in Agile