业务建模概述
“业务建模”中的业务指的是组织级别的知识，而不是领域知识。因此，“业务建模”这个名字可能起得不好，更贴切的名字应该叫“组织建模”，但出于对过去叫法的尊重，我们继续沿用“业务建模”这个名字。
为什么要业务建模
对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。软件系统和人脑系统都是组织中的一个零件。开发团队经常发现需求“容易变化”。根源之一是需求的来路不正，没有把系统当作一个零件放在组织中来看，而是靠拍脑袋得出需求，导致得到的系统需求是错的。系统投入使用后，发现和组织的其他零件格格不入，自然要改。“需求变化剧烈”是一个假象，真正的需求可能没有变，只不过一开始得到的需求是假的。如果能正确运用业务建模技能，“需求变化”就会最大程度的收敛。
什么是业务建模
业务建模以某组织为研究对象，在组织之外和组织交互的其他组织（人群或机构）就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行者。
组织内的人称为业务工人，例如某商业银行里面的营业员。业务实体是组织中的非人智能系统，例如银行的ATM、点钞机、营业系统。业务工人是可以被替换的人脑零件，它可能会被其他业务工人替换，但更有可能被业务实体替换。
业务执行者和业务工人的区别是：
- 业务执行者在组织外面，业务工人在组织里面；
- 业务执行者是组织不可替换的服务对象，业务工人是组织可以替换的零件。
在业务建模中，我们从内外两个视角来研究组织：
- 从外部看，组织是一些价值的集合，我们可以用业务用例图来表示；
- 从内部看，组织是一些系统的集合，我们可以用业务序列图来表示。
业务建模的主要工作是完成业务用例图和业务序列图，其中业务用例图描述业务执行者希望通过和所研究组织交互获得的价值，而业务序列图描述业务用例如何实现，是业务建模中最繁重的工作。
如何做业务建模
如何画业务用例图
业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。在识别业务执行者时，不需要画业务工人和业务实体。
业务用例图中业务执行者可以用小人表示，业务用例用椭圆表示，组织边界用方框表示。看到这里，有些熟悉系统用例图的同学可能有点蒙圈了，感觉这两个图很难区分。显然，它们都是用例图，从形状上看的确很想，但业务用例图的研究对象是组织，而系统用例图的研究对象是软件系统，我们可以通过边界框中的名字是组织名还是软件系统名来区分是业务用例图还是系统用例图。
如何画业务序列图
得到待改进组织的业务用例图后，就要考虑业务用例如何实现了，这就是业务流程。我们用业务序列图来描述业务流程，将业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。业务对象包括业务工人和业务实体，在业务序列图中被平等看待。
业务序列图的难点是理解消息的含义，即消息代表责任分配而不是数据流动。A 指向 B 的消息，代表“ A 请求 B 做某事”，或者“ A 调用 B 做某事的服务”，做某事是 B 的一个责任。在业务序列图中，消息表示为从一个业务对象的生命线指向另一个业务对象的生命线的箭头。注意，消息名称中不用带“请求”二字，因为消息箭头已经有请求的意思了。
消息类型主要包括简单消息、同步消息、返回消息、异步消息和自反消息，说明如下：
- 简单消息：可以泛指对象之间的发送的任何消息，而不必关心是同步还是异步的；
- 同步消息：对象发送消息后，需要接收消息的对象响应完毕并返回消息时才会进行其余的工作；
- 返回消息：与同步消息对应，是接收同步消息的对象对发送对象的回应；
- 异步消息：对象发送消息后，不需要等待接收对象的返回消息可以继续执行其余的工作；
- 自反消息：又名自关联消息，也是简单消息的一种，不过是对象向自己发送消息，而不是其它的对象。
业务序列图还可以通过alt、loop等结构化控制片断来描述业务流程，强迫建模人员用这种方式思考。在业务序列图中，数据流仅仅作为消息的输入输出参数存在。如果不了解这一点，就容易把消息的方向当成数据流动的方向，不但消息名称没写对，还会出现成对的消息。
业务建模初体验
需求来源
代码打靶是一项高效的代码能力提升活动，可以带动打靶人员Code Review能力和编码能力的腾飞。打靶人员使用Web进行打靶，通过度量看板获得快速反馈，既可以明显感知近期的进步，又可以轻松拿到针对弱项的学习资料，从而进入了高效的正反馈循环。
代码打靶铁三角包括规范、内容和工具，说明如下：
- 规范：实例化为缺陷分类体系，是铁三角的基础，不依赖于其他两者，让代码打靶标准化；
- 内容：实例化为靶子和靶场建设，依赖于规范，规范越好内容的质量越高，让代码打靶高质量；
- 工具：实例化为打靶服务，依赖于内容，内容越好工具的用户越多。
业务用例图初体验
业务用例图需要考虑业务执行者、组织和业务用例：
- 业务执行者：在所研究组织之外和该组织交互的人群或其他组织就是业务执行者；
- 组织：一个组织可能是一个公司、一个政府单位、一个部门、一个小组、一个家庭、一群人（非正式组织）等；
- 业务用例：指业务执行者希望通过和所研究组织交互获得的价值。
对于代码打靶实践，业务执行者、组织和业务用例分别是：
- 业务执行者：主要是开发人员（DEV），还可以是团队主管（SM）、业务分析师（BA）或架构师，我们统称为打靶人员；
- 组织：由一个非正式组织推进，是一个虚拟项目，我们称之为打靶项目；
- 业务用例：打靶人员与打靶项目交互的目的包括打靶（类比答卷）和查看结果（类比考试成绩）。
根据概述中所说的画法，我们得到代码打靶实践的业务用例图：
业务序列图初体验
有了代码打靶的业务用例图后，就需要考虑业务用例如何实现了，这是业务建模中最繁重的工作。
最初打靶项目中的业务对象都是业务工人，即人工打靶。我们看看这时的业务序列图是什么样的：
说明如下：
- 规范专家制定各语言的靶场规范（指向自己的箭头表示自反消息），每条规范包括缺陷大类、缺陷小类和缺陷细项，制定过程包括评审；
- 规范专家请求靶场管理员发布规范（圆圈实线箭头表示异步消息），消息内容“发布规范”是靶场管理员的职责，而规范专家是请求的发起方，同时消息已经有请求的含义，所以消息内容中不用再重复“请求”两字；
- 靶场管理员请求靶子专家根据规范建设靶子（实线箭头表示同步消息），包括选择靶子（题目）和制定靶标（答案）两个重要步骤，并收到靶子专家建设成功的返回消息（虚线箭头表示返回消息）；
- 靶场管理员在本地建设靶场；
- 打靶人员请求靶场管理员发送靶场，并通过邮件收到该靶场；
- 打靶人员在本地完成打靶，并请求靶场管理员阅卷；
- 靶场管理员收到打靶人员提交的答卷后，先进行保密处理，然后请求靶子专家阅卷，并通过邮件收到打靶结果；
- 靶子专家进行阅卷时，及时发现靶标中的问题，并对靶标进行更新；
- 打靶人员回顾打靶结果中的弱项，并根据弱项进行针对性的提升；
- 靶场管理员组织复盘，输出代码打靶总结报告；
- 规范专家根据总结报告，演进规范，并在规范新版本中发布。
人工打靶了一段时间后，大家发现：
- 虽然代码打靶实践很好，但成本太高，项目投不起，需要找到一条路径，大大降低规模化推广的成本；
- 研发能力的数字化，需要结合项目实战，用一个工具来统一呈现。
基于上面两个原因，我们决定利用业余时间开发一款工具来辅助打靶，使代码打靶实践成本持续降低，以便过几个月后在组织中可以规模化推广起来。
这款工具我们称之为打靶服务（CodeShooting），在公司内仅部署一份，让打靶更美好！所有开发人员都可以通过人事账号登录，采用Web丝滑的进行打靶，并根据打靶结果有针对性的实施改进。有了工具的加持，打靶场景业务序列图发生了变化：多了业务实体打靶服务，虽然业务工人的数量没有发生变化，但他们的很多职责转移到了业务实体上，如下所示：
说明如下：
- 第一个变化：靶场管理员发布规范，之前是人工交互，而现在需通过上传规范发布到打靶服务上（注意，没有圆圈的箭头消息是同步消息，下面有一条虚线表示的返回消息与之对应）；
- 第二个变化：靶子专家建设靶子，之前包括选择靶子和制作靶标两个步骤，而现在将比较复杂的制作靶标在线化了，所以要先将选择的靶子上传，然后以打靶的方式来制作靶标；
- 第三个变化：靶场管理员建设靶场，之前是人工建设，而现在是通过打靶服务新建；
- 第四个变化：打靶人员打靶，之前是通过excel打靶，而现在是通过Web打靶；
- 第五个变化：靶子专家阅卷，之前是人工阅卷，而现在是通过打靶服务自动化阅卷；
- 第六个变化：打靶人员查看打靶结果，之前是通过邮件查看打靶结果，而现在是通过打靶服务查看打靶结果；
- 第七个变化：靶子专家更新靶标，之前是通过excel更新，而现在是通过Web更新，并且会触发重新阅卷，然后打靶人员可以重新查看结果；
- 第八个变化：靶场管理员输出总结，之前是本地人工汇总数据并生成图表，而现在是从打靶服务的度量看板上按需获取。
随着技术的发展，组织中的业务工人可能会被业务实体或其他业务工人替换，或者业务工人的部分责任转移到了业务实体或其他业务工人身上，责任转移的思想对识别待引入系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了：我们先画好现状的业务序列图，然后寻找改进点改进业务序列图。
业务建模再体验
业务用例代表组织的本质价值，很难变化，而业务用例的实现（业务流程）却容易变化。你可能会产生一个疑问：既然业务用例很难变化，那么代码打靶实践只有这一个业务用例图吗？
需求来源
随着代码打靶实践的规模化推进，打靶人员及所在的组织获得了较大的收益，可以从产品交付和能力提升两个维度来体现。
从产品交付维度来看：
- 2022下半年故障泄露总数相比上半年数量呈下降趋势；
- 2022下半年编码故障占比相比上半年占比呈下降趋势；
- 针对2022上半年TOP N问题专项打靶，下半年没有再出现。
从能力提升维度来看：
- 通过弱项收集，提高了能力提升的精准性（相比考试竞赛）；
- 通过打靶活动，提高了能力提升的有效性（相比培训宣贯）；
- 通过度量复盘（如命中率），提高了能力提升的可视化（相比传统复盘）。
我们发现，有一些团队已将靶子建设内嵌到研发流程，如下图所示：
可见，收集靶子的时机，至少包括：
- 代码走查时；
- 故障复盘时；
- 静态检查问题常犯时。
还有一些团队更进一步，自研了浏览器插件及配套的度量脚本，将靶场规范应用到了日常代码评审实践。这使得打靶不仅能用于能力提升，还能用于日常工作，并且使用方式是完全一致的。
这种浏览器插件的方式虽然提升了代码评审的效能，但是也存在一些明显的问题：
- 靶场规范升级比较麻烦；
- 打靶体验远不及打靶服务；
- 度量数据采集和展示需要人工参与。
于是，很多人想到了，作为读者的你肯定也想到了：打靶服务对接Gerrit，支持日常评审及度量指标。
业务用例图再体验
对于日常评审实践，业务执行者、组织和业务用例分别是：
- 业务执行者：主要是评审人员和被评审人员；
- 组织：还是打靶项目；
- 业务用例：评审人员与打靶项目交互的目的是评审，而被评审人员与打靶项目交互的目的是查看评审结果，同时可以对评审结果进行逐条确认（采纳或拒绝评审意见）。
根据概述中所说的画法，我们得到日常评审实践的业务用例图：
业务序列图再体验
有了日常评审的业务用例图后，就需要考虑业务用例如何实现了，又到了体验业务序列图的时刻了。
打靶项目中涉及的业务对象包括规范专家、靶场管理员、Gerrit和打靶服务，其中Gerrit和打靶服务是业务实体。因为待评审的代码就是靶子，并且该靶子没有靶标，所以就不需要靶子建设了，相应的业务对象中也就没有靶子专家了。我们看看这时的业务序列图是什么样的：
说明如下：
- 规范专家请求靶场管理员发布规范；
- 靶场管理员在打靶服务上传规范；
- 评审人员以打靶的方式完成了评审，打靶服务将评审结果持久化到了Gerrit，在本地数据库仅记录了评审相关的度量数据；
- 被评审人员从打靶服务上查看评审结果，而打靶服务又同步请求Gerrit来获取评审结果；
- 被评审人员找评审人员沟通评审结果，主要是针对打算拒绝的评审意见；
- 靶场管理员组织复盘，输出日常评审总结报告；
- 规范专家根据总结报告，演进规范，并在规范新版本中发布。
小结
本文针对代码打靶实践中的两个典型需求来源进行了业务建模的实战，传递了业务建模的核心技能，给出了探索需求的思路，希望对读者有一定的启发。
没有把系统当作一个零件放在组织中看，而仅从系统视角来探索需求是不全面的。靠拍脑袋得出的系统需求很有可能是错误的，因此我们需要增加组织视角来探索需求，并且先考虑组织视角再考虑系统视角。如果能正确运用业务建模技能，“需求变化”就会最大程度的收敛。
参考资料
- 潘加宇：《软件方法（上）：业务建模和需求（第2版）》
