CODING 敏捷实战系列课第三讲：可视化业务分析

业务分析处在开发过程的上游，提升业务分析的质量，能够减小后续开发、测试和集成过程当中的反复确认，场景遗漏。采用可视化的业务分析工具箱能够大幅度避免文字版的业务需求描述所带来的不够完整，有误解等问题。CODING 特邀敏捷顾问、“业务分析工具箱”创始人 王洪亮老师将在本次 《可视化业务分析》 课程中，带领你们掌握可视化业务分析的基本工具和方法，以提升业务分析的质量和效率。

今天我为你们介绍可视化业务分析。提到业务分析，是指以文字为主的业务描述文档 SRS，即软件需求规格说明书。在线下培训时，我会让学员作个小互动来直观感觉详细的业务分析的重要性：首先让学员分组，每组选一位表明来观看展现在屏幕上的图形，把看到的内容记下来并以口头表达的方式传达给组员，组员在 A4 纸上来复现。

由于涉及到不少精确的元素位置，以口头的方式并不能正确复现。好比组员描述：“这个焦点叫圆心，正方形的边长是圆形半径的一半。”组员在复现尺寸时则会产生较大的误差。可想而知，当咱们用口头或者文字的形式，去表达很复杂的需求时，咱们的开发团队、测试团队会在理解上产生误差，从而在复现上产生错误。若是让组员把图形拍照以后交给团队去复现，则复现错误的可能性会大大下降。一样道理，咱们在表达业务需求时，可以表达的信息带宽越宽、表达的信息越充分，咱们传递的信息就越准确，组员理解越透彻，产品作出来就越精准。

举个例子，从 ATM 机上取钱的形式叫 IPO（Input Process Output），分别是输入参数、处理过程和输出参数。帐户若是扣减失败，须要提早把扣减的帐户余额退回帐户，但若是只在这个条件下进行了描述，其余条件下没有标注，就有可能产生遗漏且难以被识别。而当咱们发现了须要补充相关的信息时，就会引发格式上的调整。

若是咱们采用以下格式来书写 SRS ，想要准确的表达给开发团队就要在文档上花不少功夫。因为全是文字，若是复制时产生了覆盖就会形成信息的丢失，所以采用纯文本方式描述业务需求会产生问题：一是难以阅读；第二是会产生一些错误而且不容易被发现；最后是修改时会产生格式调整，引发没必要要的新错误。

一样的业务需求，咱们能够换一种表达方式——泳道形流程图。图上矩形、菱形分别表示处理和条件，加上用户、ATM 和帐户三个泳道，让每一个处理者能清晰了解是谁在负责；当发生变动时，就能明显呈现出哪里发生了变动。采用可视化的方式表达业务需求，能够更好地呈现全部信息。

语言表达会增长误解的可能性，更况且语气没法在文字中表达，因此当开发人员和测试人员产生理解误差，他们就会争论到底谁是正确的。当无法判断时，就到上游来询问 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 的形式列出，用这种方式列出全部的四种组合，动做全是派车，那么最后的结论就很清晰。用这种方式能够确保条件覆盖率达到 100%。若是有遗漏那是由于所采用的工具无法达到 100% 覆盖率，好比纯文字描述。若是是一个更庞大的表格，达到上百甚至上千行时，也可能产生人为的遗漏，所以须要采用更科学的工具进行自我校验。

下图表格的构成形式，前面是条件、中间是操做、后面是预期，这种 Give When Then 的形式就是测试用例，测试人员拿到表格，能够直接做为测试用例使用。这个断定矩阵不只能提供 100% 的覆盖率，还可以引导程序员开发出正确的代码，达到一个好的效果。

状态之间是经过具体的操做进行切换的，例如状态 4 没法切换到状态 1，用这种方式把前面流程相应的状态所有梳理出来，就能够进行下一步的分析。举两个例子：一是贷款审批，实际上内部有三个步骤，第一步核实用户的真实身份，第二步核实用户的征信情况，第三步核实银行卡与用户信息的一致性。内部在处理数据时有子状态，可是对外都显示“贷款审批”，因此会分为内部状态和外部状态。另外一种叫主状态和子状态，好比说出国手续的步骤能够分为机票——酒店——签证，每个子过程都有本身的状态，而且三者是并行，所有状态完成以后整个过程才算完结。

如图所示，在当前状态下可否进行左边的操做，若是能就打勾，这就是所谓的决策矩阵。若是列出一个 M×N 的矩阵，那么该矩阵必定是覆盖全部的场景，列出了全部的状态操做。实际上在画流程图时只提供画对勾的操做，不会表达出空白格所表明的信息，因此决策矩阵能够用来了解列出的异常信息。

善用工具能够更好地呈现业务需求，让开发人员的理解更深入。例如纲举目张：在需求中每个未确认点就是渔网的一个孔，把网子撑起来才可以看到有多少孔没有填充，利用数学或者客观规律来找到这些潜在的点，而后逐个确认，才可以达到提高质量、提升效率的目的。若是遵循这些原则，能够发展出新的工具，也可以更好适应不一样的业务场景。

一图胜千言，以上的全部案例都在讲如何用可视化的方式去展现相应的业务需求，例如图示、图片、图表、表格、流程图等等。业务需求分析必定要完整，要保证如下几个方面：

1. 正确性：必定要让需求获得正确的表达；
2. 精确性：在表达业务需求时必定要精确，表达不够清晰就会产生误解，若是用数学表达式误解就会消除，因此要用精确的方式来表达需求，而不是过多地采用天然语言；
3. 一致性：尽可能保持书写格式、措辞习惯、表达方式等的一致，用同一种工具表达可让成员理解起来更顺畅，让团队协助更顺利；
4. 柔软性：需求变动必定会发生，因此文档书写越具备柔软性的响应，变动能力就越强。还要记住分层表达，采用不一样的层将主流程和条件判断分开，可让文档具备更高的柔软性。在需求发生变动时尽量减小所影响的范围，能够更快、更准确、更好的让开发团队传递全部的需求变动信息；
5. 解耦合：包括依赖注入，主业务和依赖是基于界面和校验的，界面用原型表示，校验用 Excel，主要逻辑和次要逻辑进行分离。经过解耦合的方式，能够很大程度上提升文档响应变化能力，更好地让团队以更高的效率、更好的质量来提升复用性；
6. 多面性：需求读者是多种多样的，要考虑每种读者所站的立场和他们所但愿获取的信息，因此提供的需求要让读者可以轻松得到想要知道的信息，提升读者的理解程度加快效率；
7. 节约时间：BA 在工做上节约的时间都会变成开发的时间，在文档书写上尽量让调整格式的工做减小，尽早交付反复迭代，在保证质量的状况下完成而且交付，能够更快的推进开发前进，完成比完美更重要；
8. 投入时间：把时间花在有意义的事情上，好比质量、需求表达可读性的提高，减小开发和测试时间投入，包括减小遗漏或错误形成反复沟通确认的问题；
9. 未雨绸缪：有不少内容能够提早准备，若是能预先准备好相应问题，在遇到该场景时，能够立刻检查是否分析全面，是否还有遗漏，同时内容复用率也能够获得很好的提高；
10. 最后是墨菲定律，要记住：凡是你不分析的地方必定有问题。

点击观看完整录播视频