打开网易新闻 查看精彩图片

" Type="normal"SectionTitle="产品所有者、开发人员和测试人员找到了一种有效的方法来避免遗漏用例和识别边缘案例。" Type="normal"@@思维导图用于探索、澄清、解释或计划。它们是收集和描述信息的有效方式。这可能是我们想要学习的信息或我们想要分享的知识。我们可能希望专注于某些点，例如抽象一个数字或细节。或者，我们可能想提前计划我们的工作或详细解释事情是如何运作的。头脑风暴和寻找不同想法之间的联系、解决问题和创造新想法，思维导图是我们职业或个人生活中的有用工具。它们远远超出了软件开发，它们可以用于任何需要批判性思维和决策的人类活动。

思维导图可以是组织我们思想的任何东西——图画、图表、表格、关键字、图片、图表、维基页面等等。它可以用笔和纸、记号笔和白板来完成，也可以使用 Coggle、MindMeister、Ayoa、MindNote、XMind 等思维导图工具来完成。

与我合作过的许多软件组一直在重复使用思维导图来发布功能。产品所有者、开发人员和测试人员找到了一种有效的方法来避免遗漏用例和识别边缘案例。这有助于需求的澄清和消歧、可测试性和完整性。思维导图的重用导致了富有成效的讨论、有根据的决策以及团队之间的信息交换。

" Type="normal"SectionTitle="使用的开发方法" Type="normal"-->软件组中不同角色的思维导图

产品拥有者

产品拥有者

产品负责人 帮助客户定义功能和非功能需求。毕竟，这个角色试图通过满足所有要求来充分利用每个任务中的开发团队。这意味着所有团队成员都在追求一个共同的目标，确定优先级，以便他们致力于最高价值的功能。还做出了导致每个任务的良好投资回报的决定。每个功能交付的价值是多少？对于任何给定的特征集，哪个特征更重要？应该首先开发哪个功能，然后再开发哪个功能，依此类推。客户要求什么？

产品所有者的思维导图可以针对每个功能，也可以涉及多个功能或整个任务。这取决于特征大小和思维导图的范围。

" Type="normal"SectionTitle="尺寸" Type="normal"-->

范围

范围

描绘不同功能之间业务级别相互依赖关系的思维导图可能只包括相互依赖的功能。专注于一个特征及其子特征的思维导图可能会抽象出所有其他特征。专注于所交付功能的安全方面的思维导图可能只会描述安全用例中涉及的功能。就产品所有者而言，这是需要澄清的上下文。" Type="normal"SectionTitle="开发" Type="normal"-->
实体关系思维导图

实体关系思维导图

实体及其关系是分析软件系统的基本方法。实体可以特定于我们工作的领域，例如会计系统的发票、库存系统中的项目、网络管理系统中的节点或社交网络中的朋友。在思维导图中探索实体及其关系有助于开发和产品团队就应开发的内容达成一致。它还帮助测试人员识别边缘情况，并与开发人员就性能瓶颈进行头脑风暴。" Type="normal"SectionTitle="状态转换思维导图" Type="normal"-->
测试

测试

该角色试图确保在向客户发布功能之前发现并修复错误。发布后，测试人员会尝试验证功能的演变是否遵循特定的质量标准。测试人员根据需求创建和执行（UI 或 API）测试。来自产品所有者和开发人员的思维导图可能非常有益。产品所有者将包含需要发布的功能。这对于黑盒测试中的测试用例设计非常有用。

一些开发团队创建思维导图来描述在单元级别测试的内容。这向测试人员表明了哪些已被测试，哪些未被测试。测试人员可以扩充开发思维导图以了解需要测试的内容。这里有灰盒测试信息。

在某些情况下，开发人员会共享思维导图，描绘 UI 中需要测试人员注意的区域。这是灰盒测试信息的另一个主要来源。基于开发人员的这种反馈，测试人员可以集中精力进行测试。

" Type="normal"SectionTitle="生态系统思维导图" Type="normal"@@生态系统包括我们的软件所处的环境、我们软件的所有接口以及所有外部依赖项。整个生态系统的思维导图可以为调查与我们系统中不受软件控制的部分相关的连接、依赖关系和风险提供清晰的画面。

一个团队使用生态系统思维导图来描绘他们的软件如何连接到外部世界。重点是接口、用户和与集成系统的连接。

另一个团队使用基于部署的生态系统思维导图。它侧重于构成其系统的组件（例如数据库、配置文件和可执行文件）在生产部署中的位置。

生态系统思维导图帮助测试人员设计他们自己的正面和负面测试思维导图。他们还帮助产品所有者更全面地了解他们的软件，并考虑在需求中可能遗漏的用例。开发人员发现在他们的代码中需要特别注意的边缘情况。

" Type="normal"SectionTitle="总结" Type="normal"-->