之前学习《软件方法》这本书,感触很深。
虽然乍一看以为只是一本21天教你学画 UML 图的工具书,实际看下来,却是扎扎实实地在教你如何分析你的业务,找到组织的竞争优势。
至于如何画图,软件行业都是聪明人,一笔带过,点到即止。
书的语言很平实,也很易懂,但作为从业人员确实会触发你好好思考下自家的立身之本到底是什么,能不能立得稳,立得久。
可惜的是书分了上下两册,上册五年前已出版,下册却至今没有音讯,只有网络流传的一章半,颇有半张武林秘籍流落江湖之感。
回归本题,首先本书强调做一行,就要了解一行。
开发人员现如今都是面向需求编程,仔细钻研技术知识,对业务领域却不屑一顾,虽然可以方便地在各行业间闪转腾挪,却始终难以沉淀业务领域的核心价值。
此外,作为一个组织(公司或团队),要向一个领域迈进,第一步也是做行业分析,作为开发人员,如果不能正确地认识和跟进这种分析,即使架构设计经验再丰富,可能也会在新的业务领域折戟沉沙。
毕竟最好的设计,一定是最符合领域特征的设计。
此外,还有一个思想认识是开发人员很容易忽视的:需求的目的,是让系统更好卖;设计的目的,是降低开发维护成本。
为什么要做需求与设计?
因为一个组织的利润 = 需求 - 设计。
也就是系统越好卖越有价值,开发维护成本越低越有利润。
研发同学需要注意的是,不能因为善于设计,便用设计来主导需求,要清楚需求一定是用来卖的,而不是因为设计可以做、容易做而做。
人力与资源都是有限的,设计应该为更好更快地完成有价值的需求服务,而不是反过来。
如果需求和设计不分,利润就会缩水。如果从需求直接映射设计,会得到大量重复代码;而如果从设计出发来定义需求,会得到一堆假的“需求”。 《软件方法》
因此,作者将软件工作流,分成了四个步骤:
还有一点伴随着“敏捷”概念而来的误区是:并非小系统就不需要建模。
任何系统如果想要打造具有竞争力的核心域机制,都必须经历建模分析的过程。
但也并不是说所有系统都需要先全部建模完毕再开始后续过程,而是做一点建模,做一点需求,做一点分析,做一点设计,循环着来。
要注意的是,不要把这看做敏捷开发,也不要把敏捷当做借口而不去好好做每一步。
1.1 愿景
做任何事情,第一步是要想清楚为什么去做,有没有价值,给谁带来价值,如果这些都没有想清楚,那事情多半走不了多远。
而业务建模的第一步,也是先要理清楚我们的愿景是什么。
如果缺乏清晰、共享的愿景,开发人员会在错误的方向上狂奔,做得越多,浪费越多,却反而还乐在其中。 《软件方法》
考虑愿景时,我们应该问自己的问题是,东西最应该卖给谁,以及对他有什么好处。
思维不能停留在做一个“可以工作的软件”,而应是“可以卖的软件”,这两者是有很大区别的。
同时,愿景也应该与团队内所有人共享,只有大家都有清晰的愿景,才能把力往一处使。
那如何得出清晰的愿景呢?
愿景必须有具体的定义,不能是“正确而无用的废话”,大而泛的目标谁都会提,真正具有指导意义的,是具体的细节定义。
业务示例:
假设我们想打造一个 IoT 管控业务中的设备售后咨询系统,那么我们首先也需要明确我们的愿景。
如前所说,愿景需要明确人群机构,还需要有明确清晰的目标定义。那么一个 IoT 管控业务的售后系统愿景大致如下所示:
1.2 业务用例图
当我们有了愿景,就等于明确的知道了“老大”及其代表的组织对哪个现状指标不满意,而这也是我们要做的软件系统的目标。
然而知道目标不代表知道怎么达成目标,要解决组织存在的问题,就要先分析组织的现状。
分析现状实际上就是分析我们所要涉及的领域,其业务是如何流转的,然后基于现状,再去寻找其中的改进点,以达成我们的愿景目标。
这里对业务现状的分析,就是以业务用例图的形式进行。
业务的用例图,表示了从外部看,一个组织的价值。
业务用例图有几个组成部分:
业务流程内,才对应具体的业务对象:
但业务工人和业务实体不需要在业务用例图出现,他们不是组织的价值,而是成本,时刻记住,业务用例图表现的是组织对外部的价值。
所以业务用例图往往很抽象,很简单,在这一步,我们的目的是理清我们所研究的组织的价值所在。
而我们要做的,是对这种有价值的业务用例,进一步研究其业务流程,找到改进点,而这就是我们软件系统的着手点。
业务示例:
对于我们的 IoT 管控售后系统来说,业务用例就是我们设备的用户来咨询运营问题,并由运营人员解答问题,这个就是售后部门的价值所在,如图所示:
1.3 业务序列图
在找到业务用例后,我们需要进一步研究用例的业务流程,这需要借助业务序列图的帮助。业务序列图描绘的是该业务用例的流程现状。
要如实地画出现状的序列图,只有描绘现状,才能找到改善的途径。
而不能是描绘想象中的或打算做的样子(这会导致改进点可能根本不合适或者已经被实现了);
也不能是组织给出的所谓规范(那是理想情况,实际流程可能与规范大不相同,毕竟人都会钻空子或者节省力气,如何保障流程按规范进行,也是一种改进点);
更不能因为是创新产品就认为没有现状(大部分创新都是基于某个既有流程做的改进,很少有凭空创造需求并成功的)。
业务序列图主要由业务对象和消息构成,长得很像研发人员熟悉的时序图。
序列图上的业务对象的最小颗粒是人和非人系统;消息是指业务对象 A 请求业务对象B做某事,或A调用B做某事的服务,做某事是 B 的责任。
在画业务序列图时,要注意以下几个反模式(不好的做法):
业务示例:
这里我们尝试绘制一下 IoT 管控的售后服务现状的业务序列图,经过了解,业务的现状是,使用设备的用户会直接咨询运营人员,提出他们使用过程中的疑问,而运营人员则需要对疑问一一作出解答:
画好业务序列图后,我们就要看看这个图中,存在什么改进点,可以被我们的软件系统所解决,也就是有没有可以让我们发挥价值的地方。改进模式一般分以下几类:
业务示例:
在 IoT 管控的售后服务现状序列图中,我们可以发现,售后服务的现状全部都由人力组成,其问题和解答的流动是由人来传递的。
那么改进点就很好找了,我们尝试“把物流变成信息流”,以达到我们的愿景,即:在不影响用户售后咨询体验的前提下,减少客服人员处理售后问题的工作量。
我们在这个业务流程中,引入客服系统。
一方面沉淀常见问题,供用户快速获取答案。另一方面让客服来回答一些比较常规的问题,解决用户的进一步人工咨询的需求,把我们的运营人员从重复的咨询解答劳动中释放出来。
此外,我们也搭建一个售后系统,作为连接用户与客服的桥梁,实际上这个售后系统包括微信小程序、后台模块等,但作为研究过程来说,他就是一个整体的售后系统。那么改进后的业务序列图便如下所示:
如果发现一个业务流程已经很完善了,很难找到常规的改进点了,怎么办呢 ?这里有一些建议:
当我们列清楚了领域业务的现状,也想清楚了应该怎么改进来体现我们的价值的时候,就可以开始研究我们的系统了。
实际上,就是我们要开发一个系统,需要列出有哪些需求点。
我们系统要实现哪些流程?这些流程有什么约束条件和步骤?怎么找到涉众真正的需求?这些都是我们在进行系统设计前要明确的,有的才能放矢。
2.1 需求启发
如何找到改进点,上文已经有建议,这里更加深入介绍一下,当要具体考虑需求细节前,我们需要尽可能地多从涉众处了解到他们的真实需求,前文也说过,要找到真正的涉众和“老大”,去得到需求的启发。在和涉众沟通时,应该尽量以其能够快速理解的方式,而不是画一个 UML 图去沟通。UML 图适合在软件开发团队内部作为专业的交流手段,和涉众交流时,则应该视其习惯转换成合适的形式来获取需求,他们熟悉网页界面,就拿原型沟通,他们熟悉文件材料,就拿文件讨论。
做需求启发时,有几个手段和注意事项:
通过需求启发,希望能够打造出尽可能有价值的系统来。
2.2 系统用例图
确定需求后,就可以画系统用例图。
我们之前曾经画过业务用例图,业务用例的重点是理出组织对外部的什么人群提供了什么价值。
而系统用例图就更细化一点,对外部的什么个体,提供了业务流程中的什么价值。
首先还是要明确“系统”这两个字。
什么是系统?系统封装了自身的数据和行为,能独立对外提供服务的东西。
注意,是能够独立对外提供服务,不是某个页面,也不是某个功能模块,更不是某个数据表。
系统的边界是责任的边界,而不是物理边界(如同一个系统可能包括不同服务器、移动终端等,但他们都是一个系统)。
系统用例图依然有系统执行者。
这里的系统执行者与业务用例图中的业务执行者也有所不同。
系统用例图中的系统执行者,是在所研究系统外,与该系统发生功能性交互的人(不是组织)或其他系统。
系统的执行者必须和系统有直接交互,不能是间接交互。
比如售票员是售票系统的执行者,但购票人不是。除非售票系统必须经过购票人的确认,那购票人就成了辅助执行者,但如果仅仅是展示信息给购票人看,那依然不是执行者(因为不需要等待购票人交互就可以完成用例)。
这里提到了执行者的类别,有两种:
系统与系统执行者的交互必须是功能性的交互。
什么叫功能性交互呢,比如点击鼠标就不算功能性交互,鼠标也理所当然不应该是系统的执行者。
再来看用例,对系统用例图中的用例,也有以下几点要求:
业务示例:
在 IoT 管控的售后服务系统改进后的序列图中,我们已经把我们的系统进行了标红。
那么所有从外部指向 IoT 售后系统的消息,都可映射为我们系统的用例,这样系统用例图就比较简单:
2.3 用例规约
系统用例,描述了系统对外提供的一个个服务与价值,实际上是系统要达成的一个功能目标。
但要落实到需求方面,还远远不足,需要更加细化。
就好比我们日常接触到的需求单,只是一个标题明确做什么东西,是不够的,需要细化各种条件、约束、步骤、分支等等,用例规约就是在细化这些内容。
在画好用例图后,就可以进一步细化用例规约。
用例规约可以是文档的形式,但也可以直接画在 UML 图中,主要还是讲清楚细节。
一般来说,细节需要明确的会有下面这些内容:
有了以上这些信息,基本就能对需求有一个完整的描述和印象了。
《软件方法》这本书,聊完“需求”部分后,上半部就结束了,分析与设计属于下半部的内容,但始终没有面世,只有一章半的手稿流传于世,还是希望能尽快看到新的内容。
业务建模与需求的部分,已经明确了为什么要做、我们要做什么,也就是 WHY 和 WHAT,那接下来就是 HOW——分析该怎么做。
目前下半部的内容只讲了一章半“分析”部分的内容,且该部分内容比较直接,重点是讲解如何画分析类图的,因此这里仅摘录读书笔记,以供读者快速了解。
市场上需要花样繁多的各种系统,这是竞争和分工导致的必然结果。很多系统之间可能在关键的点上有微妙差别,但许多内在机制是类似的。如果能高效复用这些机制,软件组织就能以较低成本变出各种系统来满足市场。 《软件方法》
我们做软件设计时,也经常讲到复用,不过这里要区分两种复用形式:
我们画分析类图的时候要拆分核心域与非核心域,避免过于复杂,互相干扰。这里的类,可以理解为需求中涉及或接触到的系统对象。
分析类有三种:
执行者先把消息发给边界类对象,边界类对象能履行的就履行,无法履行的责任,再发给控制类对象。
控制类对象就像总裁办,不做具体工作,只是将责任分解后分配给实体类对象。
实体类按照它们之间的耦合程度聚集成若干聚合(也有可能一个类单独形成聚合)。
控制类对象发送消息时,先发给聚合的整体对象(也称聚合根),再由聚合根分配给聚合内的其他对象。
最后,由边界类对象反馈信息,完成一个交互回合。
对于类的分析,和关系型数据库的表结构分析是类似的,得到的类和表也基本是一一对应的。
这里,建议按照领域模型来区分类,这样得到的类,是最符合领域的特性的,也一定是最契合业务发展的(业务本身就是在其领域的基础上做流程变化)。
识别分析类与类属性的要点(设计源于需求,高于需求):
确定好类后,还需要明确类与类之间的关系,关系分三种:
有一种“彩色建模”思想,将类分为四种:
这种建模的套路是:从“时段时刻”开始,找出后面的“角色”和“事物”;在“描述”的关系上找到“事物”。
这里给出书中一个成形的分析类图以作示例:
综上所述,《软件方法》这本书,只出了半部。
作为研发人员,起初最不想看的就是这上半部,最想看的是下部(分析与设计)。
但看完后,认为最有价值的却也恰恰是这上半部。
在我看来,上半部的收获已经很大,因为上半部的内容,是告诉你,如果你要做一款软件,你该如何对你所想插手的领域做业务建模,如何找到自己系统的价值,让自己的产品更好卖。
文章的开头说过,组织的利润 = 需求 - 设计。
真正带来利润的,最重要的,还是需求,把功夫下到这里,走对了方向,才能有所成就。
而分析与设计,更多地是如何完善自己的系统,如何做到快速响应细节的变化。
实际上讲解软件设计方法的书市面上也有大把,我们作为研发人员,在思考设计之外,也许更应该多想想,手头所做的事情到底有没有价值,我们的涉众,到底是真实的用户还是老板。
做真正有价值的事,真正投入去了解自己的业务,去理解接触的行业,其实就已经在另一个层面上,向更好的设计迈进了一大步。
如何画图只是实现思路具现化的一种手段,真正重要的是思考的过程。
面对一个新的领域、新的业务,或者新的场景,首先思考一下,你想要解决什么问题?想要带来什么好处?此乃愿景。
然后,面对领域/业务,想清楚他现在到底为涉众提供了什么样的核心服务,即业务用例。
接着,梳理好业务的现状,准确地理出目前的流程,得到业务序列图,至于怎么调研,方法很多,实践出真知。
再想一想,要达到你的愿景,可以对现有的流程进行什么改进?这所谓的改进,到底有没有给涉众带来价值?
如果业务场景还没有接入信息化,或者接入程度低,或许可以很明显地带来价值,但如果已经有其他的竞争者介入,你如何带来更大的价值呢?
这就是你要做的系统,而系统中涉及到的执行交互点,就是系统用例。
接下来就是我们最熟悉的东西了,想好需求,明确需求规约,细化出要实现的一切。
对于设计方面,也推荐一种相似的设计方法,叫做领域驱动设计(Domain Deiven Design,DDD)。
这种设计思想,就是通过边界划分,将复杂业务领域简单化,帮助我们设计出清晰的领域和应用边界,保证业务模型与代码模型的一致性。
这实际上就契合了《软件方法》中所说的,重要的是核心域的复用能力,以及对类的分析。
关于 DDD 的分析文章与书籍也有很多,这里就不多介绍,有兴趣者可自行检索。
我们都很熟悉从需求细节到设计的部分,却往往遗漏或不去思考最开始也是最重要的东西——业务建模,或者是觉得自有领导去想,或者是认为这不是自己的专业方向,但谁想卖一辈子的糖水呢~
祝心有所梦者,皆能得其所愿。