全球先进公司建成全球首座8英寸氮化镓代工厂
06-06
业务分析处于开发流程的上游。提高业务分析的质量可以减少后续开发、测试和集成过程中的重复确认和遗漏场景。
使用可视化的业务分析工具箱可以极大地避免文本版本的业务需求描述带来的不完整和误解等问题。在本次《可视化业务分析》课程中，CODING特邀敏捷顾问、“业务分析工具箱”创始人王红亮先生将带领大家掌握可视化业务分析的基本工具和方法，提高业务分析的质量和效率。
今天我给大家介绍一下可视化商业分析。说到业务分析，指的是基于文本的业务描述文档SRS，即软件需求说明书。
线下培训时，我会让学员做一个小互动，直观地感受详细业务分析的重要性：首先让学员分组，每组选出一名代表观看屏幕上显示的图形，记录下什么内容他们看到了。写下来并口头传达给小组成员，小组成员将其复制在A4纸上。
因为它涉及到许多精确的元素位置，所以无法用语言正确地再现。例如，一名团队成员描述：“这个焦点称为圆心，正方形的边长是圆半径的一半。
”团队成员在复制尺寸时会产生较大偏差。可以想象，当我们口头或者书面表达非常复杂的需求时，我们的开发团队和测试团队就会出现理解上的偏差，进而导致重现错误。
如果让团队成员将图形拍照并交给团队进行复制，复制错误的可能性就会大大降低。同理，我们在表达业务需求时，信息带宽越宽，能够表达的信息越完整，传递的信息就越准确，团队成员理解得越透彻，做出的产品就越精准。
。 例如，从ATM机取款的形式称为IPO（Input Process Output），即输入参数、处理过程和输出参数。
若账户扣款失败，则需将扣除的账户余额提前退回账户。但如果仅在该条件下进行描述，而未标注其他条件，则可能会被省略，难以识别。
当我们发现需要添加相关信息时，我们会对格式进行调整。 如果我们使用下面的格式来编写SRS，如果我们想要准确地表达给开发团队，我们将不得不在文档上花费大量的精力。
由于都是文本，如果在复制过程中被覆盖，信息就会丢失。因此，使用纯文本来描述业务需求会带来问题：一是难以阅读；二是难以阅读。
第二，会出现一些错误，而且不容易发现；最后，修改会导致格式调整，导致不必要的新错误。我们可以用另一种方式表达相同的业务需求——泳道流程图。
图中的矩形和菱形分别代表处理和条件，加上用户、ATM和账户三个通道，让每个处理者都能清楚地了解谁负责；当发生变化时，可以清楚地显示变化发生在哪里。以可视化的方式表达业务需求，可以更好的呈现所有信息。
语言表达增加了误解的可能性，更何况语气无法用言语表达，所以当开发人员和测试人员产生误解时，就会争论谁是正确的。当BA无法判断时，就向上游询问BA。
如果BA无法判断，他们会继续向上询问。为了避免浪费时间，BA向开发和测试团队传达需求时，应该沟通清楚，确保满足需求。
正确性和可读性。如果BA一开始对需求的描述是错误的，通过书面表达与客户确认，而客户没有发现错误，那么开发和测试就白费了；如果在测试过程中发现遗漏场景或条件，将会导致产品质量下降和项目延误。
如果能够及早发现遗漏，就能及早消除这些隐患，避免问题的重复和拖延。你也可能会遇到多个BA，根据他们自己的理解来处理他们负责的部分。
需求导致最终结果不一致、无法开发，可以通过相互评审工具来避免。 当业务需求分析师遇到需求分析，简单写完之后让开发人员自己开发想法时，可能会和原来的需求不一致。
如果事后发现问题并返工，就会过度消耗开发时间。为了避免这种情况的发生，一开始就必须将需求进行一定程度的细化，以便开发者能够根据明确的需求做出正确的版本。
需求缺乏优先级会导致用户发现产品的各种问题。这种情况可以通过迭代的方式来解决。
每次迭代都会交付一次，并根据值的优先级进行排序。用户可以在更短的周期内给出反馈，开发可以更顺利。
可以做出更正确的产品；如果需求总是变化，当变化发生时，BA会机械地将变化从上游传递给开发人员，这会导致BA没有责任，开发人员承担责任的情况。他们之间可能会发生冲突，这可能会损害士气。
事实上，需求的变化是在VUCA时代。谁能够更好地应对变化，谁就会更有竞争力，这对于整个团队来说是一件非常好的事情。
例如，在决策矩阵中，我遇到了一群商业专家，他们正在研究什么叫失败。我问判断设备是否有故障涉及多少因素？专家表示，一共有四个因素，因此每个因素都有两个选项，列在表格中，总共有16种组合。
这个问题得到解决，整个项目就能快速推进。使用正确的工具，软件开发团队可以做出巨大的改进，甚至可以缩短交付周期并提高整体代码质量。
在整个软件开发过程中，BA的角色称为业务分析师。他的职责是搭建领域专家和技术专家之间的桥梁，将领域专家提出的领域需求转化为技术需求，以便技术专家能够实施正确的流程。
BA拿出需求文件，双方理解一致。这才是一个优秀的BA应该做的。
以Scrum环境为例，Scrum中团队并不细化，所以BA也是团队的一部分。 PO与团队中的最终用户进行沟通，将收集到的初始业务需求分解为用户故事，对价值进行排序并制定产品计划、产品策略等。
然后BA应将用户故事作为初始的基础收到数据。单元的需求被转化为开发团队能够理解和正确实施的需求过程。
因此，BA是两者之间沟通的桥梁。需求处于开发过程的最上游，因此提高需求分析的质量将对下游产生杠杆效应。
所以，BA不应该做低价值的事情，而是需要更好的体现团队的价值。需求的变化是正常的。
如果你能提前想到应对变化的措施，你就真正懂得如何提高灵活性。变更不仅仅体现在代码上，还需要响应需求层面的变更，才能真正推进整个软件项目。
当需求文档写好后，需要由开发团队和测试团队阅读。在Scrum中，Scrum Master、PO、UI、最终用户和利益相关者都需要阅读它。
然而，每个人所处的位置不同，想要看到的信息也不同。如果将文档以合适的形式组织起来，让每个角色都能快速理解并保证高质量，那么整个软件开发过程就能得到很大的改善。
比如虚拟巴士租赁项目：国内一家旅行社想要租一辆国外巴士来安排旅客行程。接到订单后，将安排乘客上车。
行程结束后，司机会结算相应费用。用下面的流程图画出公交车租赁的主要业务逻辑，可以发现有些情况下并没有说明判断标准。
当遇到业务需求时，可能会有各种条件来决定这些步骤是否可以推进。当所有这些条件都列出来时，整个流程图就会变得更大并且没有层次感，导致阅读和维护变得困难。
改变是非常困难的。如果你想实现这张图无论在什么条件下都不会改变，那么你需要用解耦的方式来创建一个固定的、可变化的文档。
从下图中可以看到决策矩阵的组成。首先是条件。
每个条件的选项均以 Excel 格式列出。所有四种组合均以这种方式列出。
动作都是调度，所以最后的结论就很明确了。这样您就可以确保 % 条件覆盖率。
如果有遗漏的话，那是因为使用的工具无法达到％覆盖率，例如纯文本描述。如果是一个较大的表，有数百甚至数千行，可能会出现人为遗漏，因此需要使用更科学的工具进行自我验证。
下图中的表格由前面的条件、中间的操作、最后的期望组成。这种形式的 Give When Then 是一个测试用例。
当测试人员拿到表单后，可以直接将其作为测试用例。这个决策矩阵不仅可以提供％覆盖率，还可以指导程序员开发正确的代码以达到良好的效果。
通过具体的操作来实现状态的切换。例如，状态4无法切换到状态1。
这样就可以将上一过程对应的所有状态都整理出来，进行下一步的分析。举两个例子：一是贷款审批，内部其实有三步，第一步是验证用户的真实身份，第二步是验证用户的信用状况，第三步是验证用户的信用状况是否一致。
银行卡和用户信息。内部处理数据时有子状态，但外部显示“贷款审批”，所以分为内部状态和外部状态。
另一个称为主状态和子状态。例如出国手续的步骤可以分为机票-酒店-签证。
每个子进程都有自己的状态，三者是并行的。当所有状态完成后，整个过程就完成了。
结尾。如图，当前状态下是否可以进行左边的操作，如果可以，则勾选。
这就是所谓的决策矩阵。如果列出一个M×N的矩阵，那么这个矩阵必须覆盖所有的场景，列出所有的状态操作。
事实上，在绘制流程图时，只提供了绘制勾号的操作，并没有表达空白单元格所代表的信息。因此，可以利用决策矩阵来了解列出的异常信息。
用好工具可以更好地呈现业务需求，让开发者有更深入的理解。例如，在项目大纲中，需求中每个未确认的点都是渔网中的一个洞。
只有把网撑起来，你才能看到还有多少洞没有填满。用数学或者客观规律找出这些潜在点，然后一一确认。
达到提高质量、提高效率的目的。如果遵循这些原则，就可以开发出新的工具，并更好地适应不同的业务场景。
一图胜千言，以上案例都是关于如何用可视化的方式展示相应的业务需求，比如图表、图片、图表、表格、流程图等。业务需求分析必须完整，必须保证以下几个方面： 正确性：需求表达必须正确；准确性：业务需求必须准确表达。
如果表达不够清楚，可能会产生误解。如果用数学来表达，就会消除公式的误解，所以用精确的方式来表达需求，而不是使用太多的自然语言；一致性：尽量保持写作格式、用词习惯、表达方式等的一致。
用同一个工具表达可以让成员理解更顺畅，让团队协助更顺畅；灵活性：需求的变化是必然会发生的，因此文档编写应对得越灵活，变化能力就越强。还要记住分层表达，用不同的层来分隔主流程和条件判断可以让文档更加灵活。
当需求变更时，尽可能缩小影响范围，让开发团队能够更快、更准确、更好地交付所有需求变更信息；解耦：包括依赖注入，主要业务和依赖基于接口和验证，接口用原型表示，用Excel进行验证，主逻辑和次逻辑分离。通过解耦，可以大大提高文档应对变更的能力，让团队以更高的效率和更好的质量提高可重用性；多功能性：多样化需求的读者需要考虑每个读者的立场和他们想要获取的信息，因此提供让读者轻松获取他们想要了解的信息的要求，提高读者的理解并加快效率；节省时间：BA在工作中节省的时间都会变成开发时间。
在文档写作中，应尽可能减少调整格式的工作。尽早交付并反复迭代。
在保证质量的情况下完成交付，可以促进更快的发展。完成比完美更重要；投入时间：把时间花在有意义的事情上，比如提高需求表达的质量和可读性，减少开发和测试的时间投入，包括减少遗漏或错误导致重复沟通和确认问题；未雨绸缪：可以提前准备的内容有很多，如果你能提前准备好相应的问题，当你遇到这种场景时，你可以立即检查分析是否全面，是否有遗漏。
同时，内容的复用率也可以大大提高；最后，应该记住墨菲定律。 : 不分析的东西一定有问题。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-06
06-18
06-18
06-17
06-18
06-18
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用