项目经理是否有必要学习UML？

一、项目经理是否有必要学习UML？

答案是肯定的，但是没有必要全学。
UML，表面上是一种以图来展示的语言，但其本质是一种看待事物的思想和角度。通过UML，我们能够拥有一个抓手，快速去挖掘到事物背后的属性、特征和行为，可以借用它在我们和工程师之间搭建一座沟通的桥梁，更好地向工程师表达和阐述我们的思想。

二、如何学习UML？

UML总共有十多种图，包含类图、活动图、状态机图、顺序图、用例图、部署图、构建图、包图、时序图、交互概览图、组合结构图。作为项目经理，只需要掌握类图、活动图、状态机图、顺序图和用例图即可。这5种图能够帮助我们更好地进行问题解构和需求分析。
一般我们会把UML图分为结构型图和行为型图2种。

结构型图描述的是事物及事物之间的结构，这个结构在某段时间内应该是稳定的、静态的；
行为图则描述的是事物的行为，是动态的。
在这5种图中，类图是其中唯一的一种静态结构型图，其余4种都是行为型图。

类图 class diagram

类图可谓作是其他图的基础。因为每个系统都涉及到了大量的人、事、物，这些抽象出来的人事物或者概念就是我们所说的类。而任何UML图都需要建立在有概念和类的基础上才能展开结构和行为的描述。类图是一种帮助我们快速提炼出业务概念并识别出其属性和关系的工具。
类图包括类属性和关系。常见的类与类之间的关系有：包含、继承、依赖，其中包含又分为聚合和组合。

• 聚合关系：其中A只能属于B一个类，那么我们称A和B是聚合（强包含）关系。例如A员工只能属于某一个部门。
• 组合关系：当A既可以属于B，也可以属于C，二者不是强包含关系，则他们为组合（弱包含）关系。例如A员工既在B部门工作，又兼任C部门的部分工作。
• 继承关系指A继承了B的属性，但同时也有自己特有的特点。例如，老师和学生都是「人」，但是老师和学生各自有各自的特性，那么他们就和「人」之间是一种继承关系。
• 依赖关系指A需要B协助才能完成某事，但并不是必须和赖以生存的关系。就像我们开会依赖于使用投影仪一样，但没有投影仪我们也照样完成会议，只是可能没那么方便。

活动图

活动图和我们常见的流程图很像，就是按照时间顺序将活动的逻辑整理出来。注意：在日常的工作中，基本没有工程师会太过于纠结你的绘图语法正确与否，只要能够向读者清晰表达和传递意思即。

状态机图

活动图是将流程分解为一个个的活动，通过活动的先后顺序来展示流程；而状态机图则是围绕一个事物的状态为中心来讲述流程。

顺序图

顺序图，有时候也会被混称为时序图。在前述的活动图中，虽然流程较为清晰，但我们很难清晰地定义角色的具体职责边界和通信交互，而顺序图则帮助我们补充到了这一点。顺序图能够帮助我们逐层拨开一个复杂业务的内部运作。

用例图

用例图是以操作者的角度出发，去看这个产品能够带给他哪些价值、支持他去操作和查看哪些东西。用例图能够帮助业务方、项目经理和工程师以最直观的角度认识到产品能给客户带来什么价值，产品在帮助客户做什么事。用例图关注的是系统的外在表现、系统与人的交互、系统与其他系统的交互。用例图没有太多的技术用语和实现细节，在需求初期对团队和客户都是一种非常好的沟通工具。

如何选择哪种图来表达？

建议按照「类图-用例图-状态机图/顺序图/活动图」这样的顺序去使用。

1. 在需求前期，我们可以先使用类图来识别类、类的属性和关系。
2. 接下来，通过用例图去和客户、工程师沟通产品的价值和能做的事，以一个粗粒度的角度框定产品范围，看当前的范围是否能够满足客户需求，帮助我们确立能够开发出有价值有意义的产品。同时借助用例图，项目经理也能够向研发积极传递当前所做产品的价值，避免工程师因功能价值理解不足而产生开发受阻的问题。
3. 最后，就是要在状态机图、顺序图、活动图中去做抉择来描述具体流程了。这3种图各自有各自的优缺点，下面给出一些选择上的参考建议：

顺序图：强调角色之间的交互，信息传递很明确，强调按时间顺序分别发生了什么事情，但不太适合表达复杂的特殊流程（循环分支、条件分支、可选分支）
活动图：强调每个角色做了什么事情，这些事情的先后关系 适合表达各种特殊流程，如分支、并发等。
状态机图： 事情围绕某事开展，该事有不同的状态，状态会因为发生了一些事情而变化。
从上述三个点中，我们能够看出这3种流程分析图之间的区别，在使用时加以选择即可；同时也不要限制自己只能选择一种，完成可以同时使用多种图来从多个角度分析问题。

四、如何把控画图的粒度？

画图相对是一个主观性比较高的行为，我们应该如何掌控画图的粒度呢？
核心就是：明确该图背后想表达的内容和重点，以目标为导向，看看自己的图能否表达出对方想要理解到的内容。

1. 先用宏观的绘制一版粗粒度的图出来。
2. 随后再进行粒度的逐层细化。
3. 画完后多与读者（工程师等）交流，收取对方从阅读角度提出改善建议。
4. 根据建议，进行适度优化迭代。