思维导图在软件组中的重用

大家好，欢迎来到IT知识分享网。

关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

产品所有者、开发人员和测试人员找到了一种有效的方法来避免遗漏用例和识别边缘案例。

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

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

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

使用的开发方法

存在不同的开发方法，如瀑布、敏捷、精益、极限编程、原型设计、快速应用程序开发等。不同的方法也有不同的风格，同时也可能存在混合组合。我们不会关注哪种方法、风格或组合更好，但为了避免混淆，我们必须澄清本文采用类似敏捷的全团队方法。开发团队包含（至少）开发人员和测试人员，团队的工作分为任务。每个任务都包含要发布的功能。对于每个任务，都会分配一名产品负责人，专注于为客户做出业务决策。

软件组中不同角色的思维导图

产品拥有者

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

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

尺寸

要分析和解释包含大量功能的大型特征，将需要更多的电路板空间。当许多大特征放在同一个思维导图中时，事情可能会变得难以理解。当思维导图包含大量信息时，很容易遗漏细节，人们通常会对使用它感到气馁。然而，当思维导图的范围是描述在整个任务期间交付的功能时，如果涉及大量功能，则需要谨慎决定要抽象什么。

范围

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

开发

开发人员需要清楚和完整地了解应该实施的内容。他们决定如何编写实现代码和测试。根据产品负责人的思维导图，他们可以创建自己的思维导图。应描述哪些信息（思维导图的范围）由开发人员决定。它是否用于阐明代码的相互依赖性？它是用来解释事物如何运作的吗？它是否用来描述什么已经过单元测试，什么没有？是否用于要求产品所有者进行澄清？它是否用于描述代码中需要测试人员注意的特定区域？

实体关系思维导图

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

状态转换思维导图

识别触发状态转换的事件是分析软件系统的另一种方法。例如，登录事件可能触发了从注销状态到授权状态然后是登录状态的转换。状态可以由 UI 直接控制，并且易于识别，如登录/注销。它们也可能是微妙的，由时间的流逝触发（例如，我们软件系统中的计时器已过期）并且不受 UI 控制，例如授权。描绘状态及其转换的思维导图有助于实施和调试。它们还可以帮助识别边缘情况并重现零星的错误。

测试

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

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

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

生态系统思维导图

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

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

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

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

总结

思维导图是可重复使用的、可定制的，并且可以根据我们的需要进行混合和匹配。它们可以成为交换信息和增强团队之间发布功能的信心的有效工具。毕竟，这一切都是为了与让客户满意这一共同目标保持一致。