如何进行软件技术管理？

目录

• 引言
• 组织文化体系
• 软件工程管理
  • Scrum
  • RUP
  • Scrum+RUP

这个问题其实来源于一次面试，在聊完一堆的技术架构以后，面试官抛出一个问题：“你是怎么进行研发管理的工做的？”当时个人回答是：“主要是应用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

这里给出两张图来介绍

1. Scrum的总览，各个角色在工做流中的做用，以及何处产生产物。
   

2. 单纯的迭代过程
   
   评价：Scrum的特色是简单。它设定了不多的角色、流程、产物，目的是达到快速生产快速交付的目标。对于中间产物的形态、规格也没有提到。乍一看你们都能理解，可是在实践过程中，中间的详细过程如何计划、协做、控制就显得模糊，若是你不作任何要求或者规范甚至会失控。

RUP

相比RUP（Rational Unified Process），相信更多人听过的应该是CMMI（Capability Maturity Model Integration，即能力成熟度模型集成），CMMI分为5级：

1. 初始级
   软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于我的努力。管理是反应式的。
2. 可管理级
   创建了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先相似应用项目取得的成功经验。
3. 已定义级
   已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。全部项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
4. 量化管理级
   分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个做出结论的客观依据，管理可以在定量的范围内预测性能。
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的业务建模围绕的核心就是功能模型（用例图），需求分析设计主要的产出动态模型（时序图、活动图、状态图）和对象模型（类图、对象图）。
咱们实际工做中把迭代边界的角色与产出作了以下定义：

1. Development team 中的产品经过用例（UseCase）与PO确认/分析需求。
2. 核心：Development team 中的产品经过用例（UseCase）最终产生产品原型（AxureRP），原型须要包含PRD的规则说明部分。这样实际最终交付就是产品原型（AxureRP文件，有审核），交付的目标对象是Product owner，Development team中的开发。
3. Development team 中的UI最终交付Sketch Measure标注的设计文件。
4. Development team 中的研发根据需求描述作出粗略的研发内容（接口数量与规模，业务逻辑变动点，数据结构变动等），拆分任务，粗估工时。
5. Development team 中的测试根据需求描述编写测试用例（咱们使用的是Jira的Zephyr）。

研发

研发的工做内容主要是在开发和测试中进行，研发的角色和产出定义以下：

1. Development team 中的开发人员进行分析与设计，经过产品和UI提供的交付物产生流程图/时序图/状态图等用于描述业务逻辑，类图用于描述实体结构变动和接口方法命名及参数。
2. Development team 中的开发人员使用***Flow工做流进行代码分支管理，按照代码规约和SonarQube的提示进行代码调整，编写单元测试。
3. Jenkins进行持续集成，Development team 中的开发或者开发管理使用Fisheye/Crucible进行代码审核。
4. Development team 中的测试根据测试用例进行测试执行与循环。

测试与发布

为何是把测试和发布放在一块儿，而不是和研发放在一块儿呢？实际上研发阶段部分完成的内容就已经会提交到测试环境进行测试了，可是咱们迭代的环境分为研发-测试-预发布-正式四个，逐个推动，而其中的主要推动力量就是测试，也就是说功能只有测试经过的前提下才能够推动至下一环境。

1. Development team 中的测试在Bug修复后使用Jenkins发布到下一个待验证环境。
2. Development team 中的测试使用Jira中的数据生成测试报告。

总结

在上面的流程中，没有提到的例如Daily scrum， Sprint review等也是咱们须要注意的执行内容。因此咱们作到在Scrum的框架内，使用RUP来进行具体的行动指导从而产出对于研发有实际意义的中间产物。但这个方案也不是彻底固定的，即便在CMMI和RUP中，实际上都有强调可裁剪，须要根据实际的项目和团队的状况（知识积累、工期状况等等）来决定须要实施哪些步骤和内容，最好是有一个可以深刻了解的教练式的领导来带领。咱们要达到的目标就是文章头部管理的定义：计划、组织、领导、协做、控制。全部的人事物都是可管理的，全部的目标也都是可实现的。