我的软件研发套路

春节回来之后，调整到一个新的团队工作。

团队，是已有的；所用的技术栈，不熟悉；所做的业务领域，也涉猎甚少。挑战比较大。

管理层对团队的产出不满。我的首要任务，是提升团队的效能。

目前团队的软件研发管理没有套路，比较随性，出现的很多问题都是软件研发中常见的。

在这种情况下，我选择先把自己当成一个教练，梳理过去的经验教训，根据团队当前的情况，进行选择和裁剪，在个别项目中陪着团队用起来，形成适合这个业务、这个团队的干法。在这个过程中，必然会带来一些改变：习惯，规范，人，人和人之间的关系。公司有惯性，团队有惯性，要进行改变，不能下猛药，要慢慢调理，从小处入手，从接受意愿强的部分开始做起来，产生效果，再逐步推广。

同时，一边当教练，一边当学生，学习新的技术栈，学习新的业务领域，让自己尽早能下场成为队员。

在这个情况下，要求自己把软件研发的套路，提炼出来，成文，以便于团队内的沟通。

领域：应用系统的软件研发

主要内容，可以用下面这些关键词来概述：

业务分析：对象关系图，状态图，活动图，用例图，外加报表需求。
分析和设计过程：静态模型 => 动态模型；建模结果 => 存储结构、内存数据结构；前后端对接的restful API列表。
项目scope：用例图 => 功能特性（叠加非功能特性）=> 任务拆分 =>工作量评估（前端、后端、测试）。
项目过程：项目启动，项目计划，检查点，敏捷，复盘。

一、业务分析

做应用系统，是为了解决业务问题。

要解决业务问题，首先得理解业务，理解一个业务有哪些参与者(Actor），他们分别有哪些诉求、哪些问题。

所以，首先要从业务的理解和分析入手，进行业务建模。

这几年业界提得比较多的DDD，也是业务建模的一种方法。识别业务对象，划分子域，设计聚合关系，也是其重要组成部分。

我习惯从三张图入手：

对象关系图
状态图
活动图

这里的对象关系图，接近于UML中的类图，目的是识别业务对象，以及它们之间的关系。状态图和活动图也基本上是UML中的定义。

对我来说，这三张图承担了Ubiquitous Language的作用，作为业务方、产品、开发、测试等项目成员之间用来沟通业务和方案的通用语言。

识别业务对象，是最基础也是最核心的。

对象关系图，可以帮助我们识别和梳理业务对象及其关系。一般需要多张图，才能把一个系统的业务对象及其关系都描述出来。对象之间的关系比较复杂时，还需要从不同的维度，分别用不同的图来描述对象之间的关系。

关系的描述，简单粗暴地，区分1对1、1对多、多对多就可以了。去年我发现飞书上画UML图的工具不错，可以用聚合、组成、扩展这些标准化的关系，效果更好。

样例1：1:n 关系

样例2：用聚合、扩展等标准化的描述

系统的使用者，一般也会在对象关系图中进行分析。

对象关系图，属于静态模型。

动态模型，则用状态图和活动图来描述，两者可相互印证。时序图，用的比较少，一般只在调用关系比较复杂的情况下，或者跟第三方有比较多的调用关系时才画，一般在设计或编码阶段使用。

状态图：首先要识别对象是否存在状态。如果有状态，有哪些状态；是否存在多个维度的状态；对象之间的状态，是否存在关联性；

活动图，一般按泳道图的方式来画。如果业务比较简单，也可以简化。

业务建模一般就用这三类图。

在撰写这三类图的过程中，自然会形成名词表，以及各种枚举值等主数据。

除了业务建模，还需要梳理系统的需求边界，设计系统功能，所以还需要用例图，从业务目的出发，分解出功能点、特性。

每个功能点中，除了业务逻辑，可重点说明对关联对象的限制、影响。

报表需求，也是在这个阶段需要收集的重要信息。从报表中可以反推和验证业务对象及其关系。报表的统计需求，能帮我们发现一些维度、主数据，发现一些容易被忽略的东西。另外，报表对数据存储结构设计的影响也比较大，需要尽早收集。有的产品负责人会忽视这一点，认为报表需求可以在系统跑起来之后再做。在过往的工作中，多次遇到在做报表的时候，发现数据缺失，或者数据的颗粒度不满足需求，导致产生很大工作量。为了满足报表需求，调整数据结构，增加数据冗余这类工作更是常见。

在慧点科技的时候，到客户那里调研需求，除了到各业务部门访谈，索要组织架构、索要各种表单和报表，就是标准动作。拿着这些东西，结合访谈内容，结合每个业务流程进行梳理。二十年过去了，这招依然管用。

业务分析，是平时我最关注的，也是在实际工作中花时间最多的。

二、概要设计

设计文档，一般只做到概要设计。除非有特别复杂的业务逻辑，单独画流程图，做详细设计。

文档，缺少越好。

自己不看的文档，不要写；可写可不写的，不要写。

文档管理最难的在于更新维护，保持其up-to-date。写得越多，维护工作量越大。没时间维护，文档的有效性就变差，慢慢得就没人看，没人看就更不会有动力去维护，恶性循环。

概要设计，我主要关注两部分：

数据库存储结构
API清单，目前一般是Restful API清单，用于前后端对接，或者服务之间调用。Restful API清单，只需要写到 method 和 url 就可以，不用详细描述参数和返回值。

除了这两类之外，还会就某些专题要求提供设计文档，例如部署拓扑的设计、特定模块的代码结构设计。

对于设计，我的观点：

设计要解决的是结构性的问题。数据结构、代码结构、接口定义，都涉及结构，所以都要关注。不影响结构的细节，在设计阶段知其大概就可以。
设计要回答为什么。为什么选择这个方案，为什么不选择另一个方案。我经常发现“为什么不”是一个好问题。在设计过程中，要找到影响设计的关键点，每个关键点，至少提供两个选项，并说明为什么选择A而非B，这样才能把设计决策说清楚。

文档的具体形式，不一而定。

可以用思维导图，可以用Excel表格，可以用ppt，也可以手写手绘拍照存档。数据结构的描述，可以单独写文档，也可以直接引用代码。

三、项目管理

工作中经常要面对一个问题：这个事情什么时候能做好？

很多时候，挺难给出一个简单的答案。

把过程拆解开来看。

首先是确认目标

业务方经常只是给出一个笼统的描绘，需要先搞清楚其真正的诉求，搞清楚目标。

目标的描述，要从业务角度来进行。结合场景，描述要在系统中让用户能完成哪些事情，并把这些事情排出优先级。实际操作起来会复杂一些，不只是比较实现A和实现B哪个更重要，很多时候的比较是类似A这件事的体验从60分升到80分，跟B这件事从系统不支持到能支持（60分）的优先级。需要进行拆解，拆成比较小的条目，以便于比较，即WBS（Work Breakdown Structure）。

画用例图把用户诉求细化为具体的功能点、特性点，有助于找到用户的关注点，有助于安排优先级。除了功能特性，非功能特性，业务规模、性能、可用性、安全性，这些也需要了解，加到工作任务里面。

需要注意的是，拆解之后，我们不能忘记真正的目标，是为了实现业务目的，不要让自己迷失在繁多的功能点里面，忘记了本谋。

其次是工作量评估

从在巴克莱开始使用Scrum之后，我觉得Story Point这个方法挺好。根据业务对象的属性多少和复杂度等因素，综合评估，根据基准任务来进行规模的评估。例如，把一个不超过10个属性的简单对象的CRUD功能，设为基准，对应2个SP，其他任务就根据和它的对比来估算。一个任务的工作量估算值只能从1，2，3，5，8，13，21，∞中进行选择。

前端、后端、测试，各自评估自己的。

评估的工作量，包括设计、编码、自测、集成测试和问题修复，包括过程中所需的沟通、文档编写，从接受任务开始，到完成交付目标为止，需要完成的所有工作。团队里每个人都要对每项任务提供评估。

如果不同的人，提供的估算值相差很大，例如 3 vs 8，就需要沟通，这种情况，常见的原因有两个：1. 对任务的目标和边界理解不一致；2. 实现方案有重大分歧。

尽早发现问题，尽早沟通解决。

第三，才是排期

如果积累了数据，每个人每周能完成多少个Story Point，排期就比较容易。

项目的时间和人员经常是固定的，这时就需要根据每个任务的客户价值和工作量，综合评估优先级，选择项目范围。