这个问题其实来源于一次面试，在聊完一堆的技术架构之后，面试官抛出一个问题：“你是怎么进行研发管理的工作的？”当时我的回答是：“主要是应用Scrum来进行管理。”后续的情况不细说，但是我觉得我这句话来概括之前近10年的管理经历，实在是太弱了。后面我就思考该如何真正回答好这个问题，我也去读了厦大的MEM，下面就是我觉得可以很好回应的一个答案。
引言
广义上的管理，指的是一定组织中的管理者实施的行为 ，目的是达到共同目标。管理有五个核心要素：计划、组织、领导、协作、控制。组织中常见的资源有人力、财力、物力、信息等，所以我们的管理专业知识体系应当覆盖人力资源管理、金融财务管理、市场营销管理、信息系统等。管理是一门人与人之间的实践科学，所以我们还应当了解组织行为学和心理学，才能够很好的对单个人或者一个群体进行沟通联系。
但是我们一般是在一个完整的企业组织内部的一个中心或者部门，研发相关的组织应当如何管理呢。上面提到的知识体系实际上仍然需要，我们还是要对组织内的各种资源进行掌控，只是责任重心不同，或者有其他部门协助管理。针对研发相关还需要实施的管理行为，我认为分为两部分。一部分是研发组织文化体系建设、另外一部分是软件工程管理。把研发组织文化体系建设放在前面，是因为我觉得团队的习惯和目标的高度，决定了产出的上限（或者说团队的管理者决定了整个团队的上限）。假如整体团队建设的高度不足，即使工程管理控制的再精妙合理，也不会有超出预期的结果。
组织文化体系
组织文化体系建设的核心，就是要以各种辅助手段，统一整体团队习惯和目标，达到团队效率最大化。我将其分为两部分，研发环境建设与研发制度建设。
研发环境建设：
- 研发标准工具集
- IDE
- 系统分析/建模工具
- 编译/反编译/构建工具
- SCM工具
- 运行环境
- 常用工具（数据库相关/远程访问）
- 过程管理
- Jira（迭代控制，Tempo工时）
- 知识库
- Confluence
- Nexus
- 质量管理
- 编码规范（阿里规约（IDE集成））
- Fisheye/Crucible
- SonarQube
- 持续集成/交付（CI/CD）
- Jenkins
- Docker/Kubernetes
研发制度建设：
- 目标制度（KPI，OKR）
- 培训制度（ 迭代/工作总结， 分享/定期培训， 新人入职培训）
- 职级/考核/晋升
这里期望使用各种工具和制度，能够建立起一套完整、可靠、高效，并且能够量化输出的辅助环境，最终引导形成“严谨、高效、可靠、进步”的研发团队文化。
软件工程管理
大学时学习的课程就是Software Engineering，工作中更常提的概念是ALM（Application Lifecycle Management），使用的是(Computer Aided Software Engineering）CASE tools。
最早时我们学习的是瀑布、迭代，那时候的生命周期基本划分为需求、分析、设计（概要、详细）、编码、测试（单元、集成、系统）、交付。当时的互联网没有那么发达，项目往往是针对大型企业的定制管理系统，或者自己产品的定制系统（比如人月神话中的Brooks所主导的IBM360系统），在如今的互联网时代，需求变化和响应要求已经越来越快，完整和重度的模式使用起来也就越来越困难。但是也不能直接全盘否定，大型的ALM管理方法一般都会明确的划分阶段、阶段性里程碑与产物，这些往往在敏捷的思想中是缺失的部分。所以我们最终整合出的ALM的管理方法就是以敏捷为核心思想，有选择的使用大型过程管理方法作为实践行为的理论指导。这句话看起来有点的拗口，我们展开来讲一下。
我们的ALM方法实际上就是传统与敏捷的方法整合，敏捷选择的是Scrum，传统（重量）的选择的是RUP。先介绍一下这两个方法的核心概念。
Scrum
Scrum的定义是一套敏捷框架用于知识工作的管理，实际上目前很多领域都尝试在应用并且仅仅限制于软件开发。Scrum是为3-9人的小组设计，用于在一个较短的时间段内分解并且最终完成目标的方法。当中包含几个核心概念：
- 角色（Roles）：Product owner，Development team，Scrum master
- 工作流（Workflow）： Sprint， Sprint planning， Daily scrum， Sprint review，Sprint retrospective等
- 产物（Artifacts）：Product backlog，Sprint backlog， Product increment
这里给出两张图来介绍
-
Scrum的总览，各个角色在工作流中的作用，以及何处产生产物。
-
单纯的迭代过程
评价：Scrum的特点是简单。它设定了很少的角色、流程、产物，目的是达到快速生产快速交付的目标。对于中间产物的形态、规格也没有提到。乍一看大家都能理解，但是在实践过程当中，中间的详细过程如何计划、协作、控制就显得模糊，如果你不做任何要求或者规范甚至会失控。
RUP
相比RUP（Rational Unified Process），相信更多人听过的应该是CMMI（Capability Maturity Model Integration，即能力成熟度模型集成），CMMI分为5级：
- 初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 - 可管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 - 已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 - 量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。 - 优化管理级
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
从层级的命名可以看出这是一个从无管控到有管控最终到精细化管控的过程。相信经历过CMMI评级的朋友能够体会其中的复杂度。你会需要一个委员会、若干的角色来主持整个生命周期，过程中无数的文档（word和excel）让我印象极度深刻（也极度反感）。
相对于CMMI，RUP更会让我们产生好感。RUP的创作公司是Rational（IBM于2002年12月收购了Rational），UML就是由Rational公司的Grady Booch, Ivar Jacobson 和James Rumbaugh在1994–1995年设计的，Rational Rose也是UML建模最好用的软件了。这样Rational公司不单单是ALM方法论，还配合UML和建模工具，可执行性会更强（但仍然是重型方法）。
RUP的核心概念包括：
- 角色：分析师（Analysts），开发者（Developers），管理人员（Managers），产品&支持（Production & Support），测试（Testers），其他（General Roles）
- 四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）
- 九个核心工作流：
- 六个核心过程工作流（Core Process Workflows）：业务建模（Business Modeling），需求（Requirement），分析和设计（Analysis & Design），实现（Implementation），测试（Test），部署（Deployment）
- 三个核心支持工作流（Core Supporting Workflows）：配置和变更管理（Configuration & Change Management），项目管理（Project Management），环境（Environment）
- 六个最佳实践：迭代式开发（Develop iteratively），管理需求（Manage requirements），组件化复用（Use components），可视化建模（Model visually），验证软件质量（Verify quality），控制软件变更（Control changes）
RUP的阶段和核心工作流：
举例，初始阶段的工作分解（WBS）
举例：配置与变更管理工作流的工作流（Workflow）与工作分解（WBS）
评价：RUP提供了针对每个阶段和核心工作流的详细指导：who（角色）when（在什么阶段/节点）how（如何做，给定任务和目标）what（目标需要的结果产物），在图片中也能看到单个节点中若干个任务目标的先后顺序，前置步骤，模型信息，任务类型，可计划性等等。基本就是一个完整的指令集，如果有一个对于RUP深入理解的团队来主导，能够指挥几百上千人为了某一个项目目标共同努力。但是问题在哪里？？问题就是太复杂，如果这是一支军队，RUP的战术是很难被士兵甚至军官所理解的，所有的行动都必须由指挥团队发出，军队只能被动的接收从而反应，无法主动的采取行动，可以想象整个反应过程会有多长。互联网时代没有这么多时间给到企业，不冲锋就长眠。
Scrum+RUP
Scrum的松散和RUP的复杂应当如何融合来散发更闪耀的光芒呢？我的理解就是使用Scrum来控制节奏，使用RUP来指导行动。
项目组的角色分为Product owner（需求方），Development team（产品研发测试），Scrum master（迭代管理者）
迭代过程整合了Scrum与RUP的核心概念：
根据上图，实际上主要分为三个部分：迭代边界确认，研发，测试与发布。
迭代边界
迭代边界确认最终产生的是backlog，实际上就是一个任务清单（Epic/Story），但是如何交付或者说结果呈现是什么呢？我们在很多Scrum的书籍中都看到看板，无论是电子还是实体，一个小纸条在不同区间内移动，显然很多复杂需求如此管理是不够的。我们从RUP的建模-需求-分析阶段的要求中来寻找答案。
RUP的业务建模围绕的核心就是功能模型（用例图），需求分析设计主要的产出动态模型（时序图、活动图、状态图）和对象模型（类图、对象图）。
我们实际工作中把迭代边界的角色与产出做了如下定义：
- Development team 中的产品通过用例（UseCase）与PO确认/分析需求。
- 核心：Development team 中的产品通过用例（UseCase）最终产生产品原型（AxureRP），原型需要包含PRD的规则说明部分。这样实际最终交付就是产品原型（AxureRP文件，有审核），交付的目标对象是Product owner，Development team中的开发。
- Development team 中的UI最终交付Sketch Measure标注的设计文件。
- Development team 中的研发根据需求描述做出粗略的研发内容（接口数量与规模，业务逻辑变更点，数据结构变更等），拆分任务，粗估工时。
- Development team 中的测试根据需求描述编写测试用例（我们使用的是Jira的Zephyr）。
研发
研发的工作内容主要是在开发和测试中进行，研发的角色和产出定义如下：
- Development team 中的开发人员进行分析与设计，通过产品和UI提供的交付物产生流程图/时序图/状态图等用于描述业务逻辑，类图用于描述实体结构变更和接口方法命名及参数。
- Development team 中的开发人员使用***Flow工作流进行代码分支管理，按照代码规约和SonarQube的提示进行代码调整，编写单元测试。
- Jenkins进行持续集成，Development team 中的开发或者开发管理使用Fisheye/Crucible进行代码审核。
- Development team 中的测试根据测试用例进行测试执行与循环。
测试与发布
为什么是把测试和发布放在一起，而不是和研发放在一起呢？实际上研发阶段部分完成的内容就已经会提交到测试环境进行测试了，但是我们迭代的环境分为研发-测试-预发布-正式四个，逐个推进，而其中的主要推进力量就是测试，也就是说功能只有测试通过的前提下才可以推进至下一环境。
- Development team 中的测试在Bug修复后使用Jenkins发布到下一个待验证环境。
- Development team 中的测试使用Jira中的数据生成测试报告。
总结
在上面的流程中，没有提到的例如Daily scrum， Sprint review等也是我们需要注意的执行内容。所以我们做到在Scrum的框架内，使用RUP来进行具体的行动指导从而产出对于研发有实际意义的中间产物。但这个方案也不是完全固定的，即使在CMMI和RUP中，实际上都有强调可裁剪，需要根据实际的项目和团队的情况（知识积累、工期情况等等）来决定需要实施哪些步骤和内容，最好是有一个能够深入了解的教练式的领导来带领。我们要达到的目标就是文章头部管理的定义：计划、组织、领导、协作、控制。所有的人事物都是可管理的，所有的目标也都是可实现的。