How to manage software technology?

In fact, this question comes from the first interview, after talking after a bunch of technical architecture, the interviewer throws a question: "? How do you manage the R & D work," was my answer is: "The key is to apply Scrum management. "subsequent case does not elaborate, but I think before my words to sum up nearly 10 years of management experience, is too weak. I think back on how to really answer this question, I have read the Xiamen University's MEM, the following is what I think the answer can be a very good response.

introduction

Management in a broad sense, refers to the behavior of certain organizations in the implementation of the managers, with the aim to achieve common goals. There are five core elements of management: planning, organizing, leadership, collaboration and control. Common organization of human resources, financial and material resources, information, etc., so our knowledge management system should cover human resources management, finance and financial management, marketing management, information systems. Scientific management is the practice among a people, we should also understand organizational behavior and psychology, it can be very good for a single person or a group of communication links.
But we generally are in a complete internal organization of a center or department, research and development related to how organizations should manage it. Knowledge mentioned above is actually still needed, we still have various resources within the organization to control, but different responsibility center of gravity, or assist in the management of other departments. For research and development related to management actions also need to be implemented, I think that is divided into two parts. R & D is part of the construction of organizational culture system, the other part is the software engineering management. Research and development organization to build cultural system on the front, because I think highly habits and goals of the team, determines the upper limit of output (or team manager determines the upper limit of the entire team). If the height is less than the overall team building, project management and then even subtle reasonable control, there will not be more than expected results.

Tissue culture system

The core organization building cultural system, is to take a variety of aids, unified whole team practices and objectives, to maximize team efficiency. I will be divided into two parts, construction and environmental development in R & D system.

R & D Environment :

• R & D standard toolset
  • HERE
  • Systems analysis / modeling tools
  • Compiler / decompiler / build tools
  • SCM tools
  • Operating Environment
  • Common tools (database-related / remote access)
• 过程管理
  • 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 of developers use *** Flow workflow management branch code, the code adjusted in accordance with the statute and SonarQube prompt code, and write unit tests.
3. Jenkins continuous integration, Development team in the development and management of development or use Fisheye / Crucible code review.
4. Development team performing the test the test cycle in accordance with the test cases.

Testing and release

Why is the test, and publish together, rather than R & D and put it together? In fact partially completed research and development stage of the content has been submitted to the test environment for testing, but we iteration of the environment into research and development - testing - a pre-release - an official four, one by one forward, and one of the main propulsion force is to test, also That feature is available only under the premise of tested before they can advance to the next environment.

1. Development team in the test used after Jenkins Bug fixes to the next release pending verification environment.
2. Development team data of tests used in Jira generate test reports.

to sum up

In the above process, such as Daily scrum, Sprint review and so we also need to pay attention to the implementation of the content is not mentioned. So we do within the framework of Scrum, RUP to use concrete actions to guide yielding meaningful for the development of intermediate products. But this program is not completely fixed, even in the CMMI and RUP, in fact, we have stressed that can be cut , need to be decided according to the actual project and team (the accumulation of knowledge, case duration, etc.) and what steps need to be implemented content It is better to have a coaching style of leadership to gain insight to the leadership. Define the target article is the head of management we want to achieve: planning, organizing, leadership, collaboration and control. All of them things are manageable, all goals are achievable.