软件产品&项目开发过程

软件开始开发前需要确定投入与产出的比值，也就是 ROI (Return On Investment, 投资回报率）;

1. 项目启动会

1.1 目标

​ 明确该产品开发项目的目标。

1.2 准备工作

​ 需要和用户沟通并明确用户需求。

1.3 过程及议题

​ 1. 介绍议程和来宾；

​ 2. 介绍项目目标 阶段计划、管理方法；

​ 3. 发布项目的组织结构图；

​ 4. 确认关键角色及其职责，并作出承诺；

​ 5. 参会人员针对介绍内容进行提问交流；

​ 6. 高层领导做项目动员发言，激励和鼓舞士气；

​ 7. 各个相关部门领导表态支持项目工作;

会议内容整理成《项目启动会纪要》 记录项目的启动过程、项目组成员的承诺、各级领导的明确表态等，这份资料作为项目组的第一份正式公告发布。

2. 用户需求

​ 用户需求由用户提出，对技术一般不描述，只描述产品目标。

​ 用户需求关注点是系统如何支持业务流程，背后的需求是“实现业务目标” 。

3. 产品需求

​ 产品需求是根据用户需求转化而来的技术实现，需要针对用户提出的产品目标进行细分，总结出具体的功能点，再针对每一个功能点细分为各种不同的操作流程，对每一个操作流程进行技术化定义。

​ 需求分析确定的产品需求，都是从业务需求推导出来的，都必须为业务需求服务。

​ 技术人员关注的合理技术方案，背后的需求是“工作量”“实现难度”和“系统性能”。

3.1 需求理解不一致

​ 1 ）开任何会议，一定不要上来就讲解方案，应该先讲解场景每个场景先讨论背后的需求并定义清楚，这也是软件本身的意义一一模拟业务；

​ 2）大家一起讨论，研究这个场景背后的需求是不是最佳场景，能不能删除个场景，或者是否有其他场景可以代替这个场景同时还能满足背后的需求；

​ 3）如果是需求的最佳场景，再开始讨论这个场景下的产品解决方案；

​ 4）打开事先设计好的产品原型图、产品流程图、状态图、用例图， 会发现有很多需要修改，修改之后就是大家一起生成的方案；

3.2 产品需求编写

​ 产品需求一般包括产品需求规格说明书和产品需求矩阵。

​ 产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有的功能需求，每列则对应每项功能的工作步骤以及每个步骤的工作量。

3.2.1 产品需求规格说明书

3.2.1.1 简介

​ 主要由产品功能和定位简介、常用产品和技术术语、本文参考资料等三部分组成。

3.2.1.2 产品描述

​ 包括产品介绍、产品范围，以及产品遵循的标准等。

3.2.1.3 技术约束和局限

​ 说明实现过程中需要满足的条件和所受到的技术方面的限制，并且说明原因

3.2.1.4 需求详细描述

​ 按照功能进行划分，列举每一个功能需求，说清楚每一个功能的需求描述、优先级、参与者、实现前置条件、实现后的结果、功能执行过程中的正常过程（这一点是需求描述的重点，需要说清楚当没有任何错误发生时，参与者与产品的交互过程 这一过程展示了本功能的核心价值，每一个用例必须要有正常过程）、可选过程（另外一种正常过程）、异常过程（该过程一般会结束整个用例的正常执行）、特殊需求（一些非功能需求描述） 附加说明（与其他需求的相互关系说明）。

3.2.1.5 接口描述

​ 一般包括用户接口（提供用户使用产品时的接口需求）、硬件接口（指出每一个硬件接口的逻辑特点） 软件接口（其他软件调用接口） 信接口（指定各个通信接口）等。

3.2.1.6. 质量需求

​ 一般包括性能需求（产品支持的用户数量、 运行速度资源的利用率，以及正常情况下和峰值情况下的处理能力等） 、可靠性需求（例如平均可用时间、平均故障时间及修复时间 准确性和精确度 错误或缺陷率） 用性需求（要从用户使用的合理性和方便性等角度进行描述） 可维护性需求（例如行业标准、编码标准 开放性设计架构等所有有利于可维护性或可扩展性的需求）安全性需求（保护产品的要素，防止各种非法的访问和使用） 可移植性 （产品从一种环境移植到另一种环境所要求的用户程序 接口兼容方面的约束）、可测试性需求。

3.2.1.7 用户文档

​ 包括用户指南、联机帮助手册、安装指南 配置文件等。

3.2.2 需求评审

​ 在需求评审阶段，邀请产品 开发、测试相关人员进行 求评审；

​ 产品需求评审主要针对以下几个方面进行：

​ WHY ： 为什么做这个需求？

​ WHAT ：需求的价值是什么？

​ WHEN ：需求期望什么时候上线？截止日期？

​ HOW ： 需求是否完整？正常场景是什么？异常场景是什么？技术上分别怎么应对？

例如，产品技术详细评审需求是否完整，产品功能的正常场景是什么？是否形成闭环？异常场景是什么？是否考虑周全？

需求评审后，由开发和测试负责人分别编写技术方案和测试用例。接下来进行技术方案评审，由开发负责人与其他相关系统的负责人一起讨论，技术方案中必须要有业务流程图和时序图 。业务流程图是为了梳理开发对业务的理解，确认是否和需求。 时序图是为了梳理本次需求涉及的系统交互。技术方案评审通过后， 确认工作量和交付时间并反馈给产品经理。

4. 总体设计

​ 设计阶段的目标主要是对待开发系统的架构进行分析和设计，并建立系统架构的基线，以便为之后的实施工作提供一个稳定的基础。

​ 设计阶段包括了系统架构的输出， 一个好的系统架构设计可以帮助人们梳理业务逻辑并抓住核心需求，设计稳定可扩展的业务系统，评估业务开发周期和开发成本， 有效地规避风险。

​ 总体设计分为三个阶段：

​ 第一阶段：初始设计，在对给定的数据流程图进行复审和精化的基础上， 将其转化为初始的模块结构图；

​ 第二阶段：精化设计，依据模块”高内聚低藕合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口；

​ 第三阶段：设计复审阶段，对前两个阶段得到的高层软件结构进行复审 ，必要时还可能需要对软件结构做精化工作；

4.1 总体设计说明书

​ 产品设计的技术总体介绍，主要包括软件架构及模块划分、模块描述这两部分。

4.1.1 产品描述

​ 简述产品的主要功能及应用范围 、产品的特点。

4.1.2 涉及约束

​ 从《产品需求规格说明书》 中提取一些需求约束，具体描述最主要的约束，说明产品是如何适应这些约束的。约束主要包括应当遵循的标准或规范、软件和硬件环境约束、接口和协议约束、 界面约束、质量约束（例如正确性、健壮性、性能、易用性、安全性、可扩展性、兼容性、可移植性等） ，也需要描述自己的想法 思路，以及为什么要采取这样的设计。

4.1.3 总体设计

​ 产品设计的技术总体介绍，主要包括软件架构及模块划分、模块描述这两部分。

​ 软件架构及模块划分：概述整体设计方案、技术原理和构建思路， 并阐述其主要特点。要求突出整个设计所采用的方法、软件的技术体系架构 （例C/S、B/S 等）以及开发软件所使用的技术、工具。 如果产品是由多个模块搭建而成，应说明逻辑结构的构成方式（包含网络拓扑图），以帮助说清楚系统结构。

​ 模块描述：对软件架构及模块划分进行描述性的说明，具体说明每个模块的功能和组成，为概要设计打好基础。

4.1.4 接口设计

​ 包括外部接口和内部接口。外部接口说明同外界交互的所有接口安排，包括与外部软件或硬件之间的接口、与各个支持软件之间的接口关系。内部接口描述内部各子系统或模块之间的调用准则及关系，以及一些可供其他模块使用的公共模块的接口及调用方式。

4.1.5 备选方案及方案对比

​ 首先列出备选方案，如果有多个方案，需要分节列出， 如方案一、 方案 然后对总体设计中的主选方案及每一个备选方案进行对比说明， 需给出各方案的优劣势分析，具体说明各个方案的优劣势，以及如果有选方案失败，可以采用哪种备选方案及采用该种备选方案的原因。

4.1.6 集成要点

​ 对集成要点进行描述，例如总体设计中所划分主要模块之间的集成顺序，集成时的特殊设备、特殊环境等。

5. 概要设计

​ 概要设计主要介绍的是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等。 同时，还要设计该项目应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。 概要设计的目的是描述系统每个模块的内部设计，对总体设计和详细设计承担起承上启下的作用。

​ 概要设计按照结构化设计方法进行设计 结构化设计方法的基本思路是：先按照问题域，将软件逐级细化，分解为不必再分解的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。

5.1 概要设计格式

5.1.1 简介

​ 说明编写这份概要设计说明书的目的，指出预期的读者，并对本文会出现的专业术语和术语缩写进行解释。

5.1.2 总体架构

​ 一般来说包括系统说明、运行环境说明 、基本设计概念、总体结构及模块划分、可测试性设计说明 可维护性设计说明 、可配置性设计说明等，也可以增加包含尚未解决的问题列举。这部分需要通过一览表及框图的形式说明本系统的系统元素划分 ，简单扼要地说明每个系统元素的功能，分层次地出各元素之间的控制与被控制关系。

5.1.3 模块说明

​ 详细说明各个模块的输入输出及主要处理的功能，使用数据流图、 状态图、 流程图等图形化方法对模块的框架、处理流程进行描述。

5.1.4 接口说明

​ 包括用户接口、外部接口和内部接口。

​ 用户接口：将向用户提供的界面、命令、语法结构及软件的交互信息，供用户以及上级模块调用，提供的语法结构应该尽量简单并提供默认值。

​ 外部接口：与外界所有信息传输的安排，包括本系统与各支持软件或外部设备的通信协议及接口函数等，也就是对外部引用接口或协议的调用主要考虑驱动、控制软件以及数据传输等。

​ 内部接口：内部各模块之间的接口，包括类的继承、实现 聚合关系以及各个模块之间如何进行数据交换和共享的方法描述。

5.1.5 数据结构设计

​ 包括逻辑结构设计、物理结构设计、数据结构与模块的关系。

​ 逻辑结构设计：需要给出所使用的每个数据结构的名称、标识符，它们内部每个数据项的标识、定义、长度以及彼此之间的层次或表格的相关关系。

​ 物理结构设计：需要给出每个数据结构中每个数据项的存储要求、访问方法、存取单位、存取的物理关系、设计考虑等。

​ 数据结构与模块的关系：需要说明各个应用程序与访问这些数据结构的各个模块之间的对应关系。

5.1.6 系统出错处理设计

​ 说明故障出现后可能需要采取的变通措施，例如热备技术、看门狗技术等。

5.2 总结

​ 集中于模块划分、 分配任务 定义调用关系 模块间的接口与传参在这个阶段要制订得十分细致明确，需要编写严谨的数据字典，避免后续设计产生误解。在概要设计阶段，应最大限度地提取可以重用的模块，建立合理的结构体系，节省后续环节的工作量。

​ 概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计可以并行展开。

6. 详细设计

​ 详细设计依据概要设计阶段的分解，设计每个模块内的算法、流程，为每个模块完成的功能进行具体的描述，把功能描述转变为精确的 、结构化的过程描述。详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。 一个模块对应一篇详细设计文档。

​ 详细设计由项目简介、模块说明（具体说明每一个模块内部的流程功能、逻辑、消耗以及未解决问题）、接口设计（包括内部接口和外部接 口）、数据结构设计（包括物理结构和逻辑结构）、特殊处理等几个部分构成。 详细设计常用的描述方式有：流程图、N-S图、 PAD图、 伪代码等。

7. 编写代码

7.1 编码技巧

• ​ 优先考虑核心模块的压力测试；

• ​ 确保流程可控 ；

• ​ 预留地方写注释；

• ​ 人人都能看懂的逻辑；

• ​ 选用熟悉、成熟的技术栈；

• ​ 细节没优化前，别谈架构；

• ​ 多留日志；

7.2 日志规范

​ 日志约束条件：

​ 1）单个日志文件大小限制，可以设置上限、下限，这样有利于日志总大小计算；

​ 2）日志数量限制；

​ 3）日志统一路径 命名规则；

​ 4）日志备份机制设计，可以预防丢失日志；

​ 日志格式 一般为： 时间｜函数地址｜等级｜模块｜行数｜日志详情

​ 日志详细规范：

​ 1）日志语言必须是英文，保证日志是 ASCII 编码。

​ 2）日志中不能打印安全敏感信息，如用户名、密码、序列号等。

​ 3）日志不能暴露系统业务处理逻辑。

​ 4）日志必要时需要记录上下文信息，确保不缺失定位问题需要的关键信息。

​ 5）不同模块的日志格式和风格保持一致。

​ 6）抛出异常后需要把异常详细信息记录到日志中。

​ 7）日志 定要通顺简洁，不能暴露关键函数和变量。

8. 代码审核

​ 在团队中进行代码审查（ Code Review 可以提升代码质量，分享项目 知识、明确责任，最终构建更好的软件、更好的团队。

8.1 审核内容

​ 1）前置条件：代码是否可以正常运行、 开发工具或者运行过程当中有没有严重警告。

​ 2）代码规范性：主要由注释、排版、命名规则等组成，注释又可以进一步分为类定义、函数头、函数内代码实现等相关注释说明，以及注释风格统一要求。排版主要包括文件顺序（各类变量定义、函数实现等）、代码行格式要求（代码行最多字符数量、运算符外侧空格、缩进等）、对齐（函数、变量、注释等）。命名规则主要包括对于常量、类名、变量名、函数，以及通用命名规则的遵循。

​ 3）代码逻辑：包括函数、控制结构、内存管理、类/结构体、其他高级特性、并发处理、设计模式使用、跨平台设计等。

8.2 审核关注点

8.2.1 设计

• ​ 如何让新代码与全局的架构保持一致？

• ​ 代码是否遵循SOLID原则，是否遵循团队使用的设计规范，如领域驱动开发等？

• ​ 新代码使用了什么设计模式？这样使用是否合适？

• ​ 基础代码是否使用了一些标准或设计样式，新的代码是否遵循当前的规范？代码是否正确迁移，或参照了因不规范而淘汰的旧代码？

• ​ 代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？

• ​ 新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个可被重用的模式，还是当前还可以接受？

• ​ 新代码是否被过度设计了？是否引入现在还不需要的重用设计？团队如何平衡可重用和YAGNI（You Ain't Gonna Need It）这两种观点？

SOLID原则有：

• Single Responsibility Principle：单一职责原则

• Open Closed Principle：开闭原则

• Liskov Substitution Principle：里氏替换原则

• Law of Demeter：迪米特法则

• Interface Segregation Principle：接口隔离原则

• Dependence Inversion Principle：依赖倒置原则

8.2.2 可读性和可维护性

• 字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物。
• 是否可以通过读代码理解它做了什么？
• 是否理解测试用例测了什么？
• 测试是否很好地覆盖了用例的各种情况？它们是否覆盖了正常和异常用例？是否有忽略的情况？
• 错误信息是否可被理解？
• 不清晰的代码是否被文档、注释或容易理解的测试用例所覆盖？

8.2.3 功能

• 代码是否真的达到了预期的目标？是否有自动化测试来确保代码的正确性，测试的代码是否真的可以验证代码达到了协定的需求？
• 代码看上去是否包含明显的Bug？

8.2.4 其他

• 是否需要满足相关监管需求？

• 是否需要创建公共文档或修改现存的帮助文档？

• 是否检查了面向用户的信息的正确性？

• 是否有会在生产环境中导致应用停止运行的明显错误？代码是否会错误地指向测试数据库，是否存在应在真实服务中移除的硬编码的stub代码？

• 对性能的需求是什么，是否考虑了安全问题？

9 测试

9.1 单元测试

​ 要认识单元测试，首先要明白什么是“单元（Unit）”。所谓“单元”指的是代码调用的最小单位，实际上指的是一个功能块（Function）或者方法（Method）。所以单元测试指的就是对这些代码调用单元的测试。单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试。所以，单元测试的编写和执行都是由软件工程师来做。用以检查代码是否符合编码规范，是否存在逻辑错误

9.2 集成测试

​ 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。即根据集成测试计划，一边将模块或其他模块组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定他们能否在一起共同工作。

9.3 系统测试

​ 系统测试阶段包括系统测试方案和用例编写、功能性测试、性能测试、稳定性测试。

• ​ 测试方案和用例编写

  • 测试方案和用例是对业务逻辑的一次梳理，从测试角度完整理解 次需求，看看是否有测试场景遗漏，验证业务场景的完整性 测试方案的侧重点是整个务方案层面的测试，而测试用例则是根据每一个需求所实现的对应具体测试式，理论上来说它和每一个需求是 N: 的关系，即一个需求对应多个测试用例。
  • 测试方案和用例是需要评审的，而且必经过评审 评审过程需要测试负责人和产品、开发等相关人员一起评审。测试用例评审通过后，用例会分成两块，即核心用例和一般用例。

• ​ 测试阶段分工

  • 测试阶段，开发人员的主要工作是修复 Bug 或者完成突发需求，测试人员的主要工作是执行测试用例，发现 Bug 、提交 以及验证 Bug。

• ​ 功能性测试

  • 功能性测试环节的目标是为了验证需求分析确定的功能是否齐全并被正确现，同时还要对安装、部署、适应性 安全性、界面等非功能性需求进行测试。功能性测试一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合《产品需求规格说明书 》。 功能性测试阶段又可分为三个步骤：

    1 ）模块测试：测试每个模块的程序是否有错误;

    2）组装测试：测试模块之间的接口是否正确;

    3）确认测试：测试整个软件系统是否满足用户功能和性能的要求;

• ​ 性能测试目标

  • 性能测试验证系统的稳定性和效率，检查系统是否满足规定的性能要求。性能测试通常选择 些典型的功能，检验这些功能在大量用户同时使用系统时系统是否稳定。

• ​ 性能测试模型和指标

  • ​ 测试指标一般包括在线用户数、最优并发用户数、最大并发用户数、交易平均响应时间、目标 TPS等。 对于接口调用类的应用测试指标一般包括目标 TPS 、平均响应时间等。
  • 测试模型就是被测试系统的各交易在线运行时承受的交易数量（或请求数量）的比例而不是并发用户的比例。

• ​ 稳定性测试

  • 稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7×24小时），检测系统是否能够稳定运行。
  • 主要目的验证产品在一定的负载下能否长时间地稳定运行，其主要的是验证系统能力，在能力的验证过程中找到系统不稳定的因素并进行分析解决。

10 产品发布

​ 产品发布是系统测试结束后的最后一步，通常在软件产品开发过程中不需要产品试制环节，可以直接上线，只需要系统测试员输出系统测试报告并批准产品发布（上线） 就可以了。

​ 产品发布前需要通过产品发布说明会的形式，对整个产品开发过程从立项开始回溯过程，总结整个过程中的经验教训。这一会议可以通过正式的会议形式召开，需要召集产品经理、主要开发人员、测试人员、上级领导等参与，必须准备充分，尽最大可能说清楚这个产品发布之后的效果、效益，为上线后的价值评估做准备。这一环节不可缺少，即便在互联网公司，迭代速度很快的情况下，这一环节也需要满足。

11 开发过程复盘

复盘的意义

​ 总结项目经验教训的目的在于总结问题、分析原因，避免以后犯同样的错误，而不是追究谁的责任。

如何复盘

​ 项目经理需要在产品开发过程中召开一个或者多个复盘会议，会议要对项目启动会的每一个环节进行回溯。

​ 例如：项目启动会是否准备充分，启动会现场是否有提问没有回答上来，为什么没有回答准确；产品需求是否按期完成、评审是否通过、为什么存在产品经理不满意产品需求的情况；总体设计是否提前与产品需求完成；总体设计、概要设计评审是否存在高优先级缺陷，为什么会有这样的缺陷存在，是不是设计阶段没有考虑周全；单元测试是否完成，为什么单元测试效果不好；系统测试阶段发现了哪些高优先级缺陷，冒烟测试是否通过，为什么没有通过。

​ 复盘的参与人员不用很多，只需要该产品的开发人员参与就可以了。再重申一句，复盘会不要太严肃，它不是“批斗会”，而是为了总结经验，不断优化，不再犯同样的错误。

12 其它

12.1 业务理解

​ 业务问题的本质是业务所服务对象的利益问题。根据业务对象的利益，可以整理出业务的生命周期和生命周期的拆分，再根据业务的概念和组织方式，可以分析出业务的核心生命周期。根据当前业务增长的方式，也可以反过来理解业务的生命周期拆分。通过对生命周期的分析，可以快速理解业务，并进行领域建模，为软件模拟业务做好准备。

12.2 需求变更

​ 需求发生变更后一定要认真仔细修改相关的文件，如需求文档、项目计划设计文档等，并通过书面方式通知团队成员，不能在会议上一笔带过，并且要确保团队成员都准确地知道了变更的内容以及下一步的计划 注意，再小的变更都会给项目带来影响，多次微小的变更可能引发连锁 ，所 不能因为变更影响小而疏忽怠慢。

​ 此外，公司的变更管理流程可以帮助我们有效控制变更，通过流程我们可以规范变更，并帮助我们将变更内容准确地传递给每一位团 队成员 变更管理流程不是操作上的累赘，而是帮助我们控制项目范围 、避免麻烦产生的利器。

12.3 进度管理

​ 为了有效控制进度，开发经理需要请各个小组每天召开“晨会”以检查昨天工作进展，并且布置当天工作；另外，每周召开周例会，项目组全体成员都要参加。

12.3.1 晨会

​ 晨会的检查基准是各个小组的底层计划，以检查和确认为目的，不展开讨晨会规定在 15 分钟以内，每个小组的成员站在白板前面完成 步骤如下：

​ 第一步，检查状态 成员逐个说明昨天任务的完成情况，今天计划的工作任务，以及遇到的问题 如果确认任务的完成情况不涉及执行细节，则仅需要回答：“完成”或者“未完成” 开发经理进行记录，一般任务按时完成可用打钩表示，未按时完成需要特别标记出来 检查完成后，将任务的完成情况分成“按期完成”“延迟完成”和“延迟中”，并进行汇总统计。

​ 第二步，调整计划 根据昨天任务的完成情况和个人任务的调整，小组一起对“底层计划”进行适当调整，确定当天每个人的工作任务。

​ 第三步，解决问题 首先审核昨天列出的问题的状态。然后，将今天每个提出的问题记录到自板上 除非可以当场解决的简单问题，否则不对问题展开讨论，只记录到白板的问题栏 会后由相关成员讨论问题的解决方案，或另行安排时间组织专题讨论。

12.3.4 周例会

​ 周例会检查和调整项目计划，关注的问题是：任务完成了吗？没完成的原因是什么？怎么调整？先确认了状态，再讨论该如何调整工作或计划，并一定要落实到具体的行动方案上。

姓名		部门名称		项目名称		时间		上周主要工作
编号	工作内容	周一	周二	周三	周四	周四	周六	周日	合计	结果	未完成原因
1

​ 只有提前建立工作结果的验收标准，才能确定如何才算是完成任务了。

​ 项目计划要想落地，需要细化分解到每个人的工作任务中去。 个人工作计划可以通过白板的方式管理，它可以实时反映进展情况。

​ 计划进行调整和更新是常态，因为“计划本身没有用，不断地进行计划才有用” 底层计划的管理使用简单的白板就可以发挥巨大的作用，可见软件开发中 “人”

才是最重要的，没有“人”的主观能动性，再高级的管理工具也难以发挥作用。

12.4 评审

​ IT系统在能够真正运行前，需要很多前期的分析、设计工作，这些工作决定了系统最终能否正常运行。但由于这些工作大多落在书面上，验证其正确性不够严谨，所以更多依靠一些有经验的专家通过书面审核的方式来确认工作是否达到要求，这就是我们常说的评审。评审过程中涉及的角色主要有 种，包括责任人、主审人、评审专家、记录员。

12.5 版本管理

​ 由于软件开发是一个独立的生命周期，可以与软件生命周期并行，因此自然就可以做到多个版本并行开发，以并行的方式来提高生产力 一旦同一个软件的不同版本生命周期并行地被推进，就需要把代码的生命周期单独切分出来，以确保不同版本软件工程师之间的代码在空间和时间上不会产生冲突。因为软件工程师编写代码是软件开发的核心生命周期，所以要确保他们的工作能够按照各自的时间顺序来执行编码生命周期活动。

12.6 优先级

​ 设置优先级的关键是，划去清单中那些既不紧急也不重要的事项，找到那些既紧急又重要的事项，并进行优先处理，然后再去做剩下的那些或是紧急或是重要的事项，这时候就需要你来安排合适的优先级了，优先处理既紧急又重要的事项是关键。

​ 根据时间管理的经验，安排工作的原则顺序为： 重要/紧急工作 ＞ 重要/不紧急 > 不重要/紧急 > 不重要/不紧急 ;

​ 在资源和进度都有严格限制的情况下，需要考虑集中优势资源优先完成高优先级的需求。

12.7 项目管理

​ 项目管理是 种软实力，只有逻辑能力强 对于业务和技术都非常了解的人才能既做好开发经理，也做好项目经理，其实也只有两者都管理得当，我们的开发项目才能够 正发布成功。项目管理的重要性，大致包含以下几条：

支撑公司收入

​ 无论是产品型公司，还是外包型公司，最终都在通过项目的形式落地，你可以把一个产品从咨询开始到客户付款的整个过程当成一个项目，大家明白了吧，没有项目的支撑，公司哪来的收入？ 哪来钱养活技术人员？公司的注册资金不是用来发工资的，大家的工资是通过客户付款产生的。

项目进度把控

​ 技术人员很容易犯的错误是技术优先，对项目的进展不太关注，而项目管理的目标就是要让这点不出现问题，也只有做好项目管理才能正解决进度把控问题，你不能单纯地认为只需要给开发人员添加 KPI 就行了，果真的可以，为什么会有 OKR 的出现？为什么日本的软件企业越来越不行了，要知道，他们可是 KPI 的发明人和强有力的执行者。

人员工作安排

​ 对工作进行拆分，每天的工作要能说清楚它的具体目标、要求标准等，让大家有存在感和参与感。

12.8 产品质量

​ 质量是一种管理，是一种控制，是一种预防 只有成熟的组织，成熟的团队， 才能做出高水平的产品来。

​ 质量就是你的最高水平，以及你对用户理解的最高水平 你只有发挥出自己的最高水平，并且全身心投入，从根本上解决问题，才能带来更好的用户体验，更好的质量。

12.9 测试过程

​ 通用的测试过程包括计划 、设计、实现、执行、完成几个步骤。

测试计划

​ 需要确定这次测试目标和策略，估计测试用例、测试实现的工作确定所需的人力资源和测试环境资源。这些内容都写在测试计划中，测试计划通过评审就可以执行了。

测试设计

​ 需要确定测试需求，设计测试用例，并对测试用例进行评审等。

测试实现

​ 任务包括搭建测试环境、编写测试脚本、编写驱动程序和准备测试数据。根据需要尝试测试部分程序，然后修改测试用例和驱动程序等。

测试执行

​ 根据计划将测试任务分配给测试的执行人员，测试执行人员根据测试用例输入测试数据、记录测试结果。发现问题后记录和跟踪缺陷，缺陷修改完成后进行验证。执行中还要对测试环境进行管理和监控。

测试完成

​ 主要工作完成以后需要对测试的情况进行分析 总结，确认目标是否达成，并给出测试结论或建议 。具体的工作包括评估测试活动、分析测试结果、编写测试报告，最后对测试的整体情况进行评审并形成结论。

单元、集成、系统测试比较如下：

测试类型	测试对象	测试目的	测试依据	测试方法
单元测试	模块内部的程序错误	消除局部模块的逻辑和功能上的错误和缺陷	模块详细设计	大量采用白盒测试方法
集成测试	模块之间的组装和调用关系	找出与软件设计相关的程序结构、模块调用关系、模块间接口方面的问题	软件概要设计	结合使用白盒与黑盒测试方法，较多采用黑盒方法构造测试用例
系统测试	整个软件系统	对整个系统进行一系列的有效性测试	软件需求规格说明书	黑盒测试

以上数据来源于《技术领导力》