如何进行软件技术管理？

单纯的迭代过程

评价：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中，实际上都有强调可裁剪，需要根据实际的项目和团队的情况（知识积累、工期情况等等）来决定需要实施哪些步骤和内容，最好是有一个能够深入了解的教练式的领导来带领。我们要达到的目标就是文章头部管理的定义：计划、组织、领导、协作、控制。所有的人事物都是可管理的，所有的目标也都是可实现的。

来源：陈晨_软件五千言