软件开发流程与项目管理

软件开发的流程

什么是软件

与计算机系统操作有关的计算机程序，可能有的文件，文档及数据

软件开发的流程

瀑布模型 -> 敏捷模型 (XP,SCRUM) -> DevOps

瀑布模型

• 软件开发的各项活动严格按照线性方式进行

• 当前活动接受上一项活动的工作结果

• 当前活动的工作结果需要进行验证

需求分析 -> 设计 -> 编码 -> 实现 -> 软件测试 -> 完成 -> 维护

优点

• 开发的各个阶段比较清晰

• 强调早期计划及需求调查

• 适合需求稳定的产品开发

缺点

• 由于开发模型是线性的，增加了开发的风险

• 早期的错误可能要等到开发后期的阶段才能发现

xp - 极限编程

XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：

• 在更短的周期内，更早地提供具体、持续的反馈信息。

• 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。

• 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。

• 依赖于口头交流、测试和源程序进行沟通。

• 倡导持续的演化式设计。

• 依赖于开发团队内部的紧密协作。

• 尽可能达到程序员短期利益和项目长期利益的平衡。

-> 编程方法(结对编程，测试驱动开发，重构，简单设计)

        -> 小组实践(编码标准，代码集体所有，持续集成，隐喻，稳定高速的步伐)

                -> 交付和管理(计划游戏，小规模发布，现场客户，完整的团队)

什么是Scrum

1. Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。

2. 在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。

3. 在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。

4. Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。

5. 挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。

6. 在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

7. Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

8. Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。

敏捷模型总结

• 增量迭代

• 小步快跑

DevOps (机翻读音->戴夫奥普斯)

开发，运维，测试

DevOps 生命周期

• 持续开发

• 持续测试

• 持续集成

• 持续部署

• 持续监控

DevOps 对发布的影响

• 减少变更范围

• 加强发布协调

• 自动化

什么是“持续集成”？

持续集成(Continuous integration, 缩写为CI) 是一种软件开发实践，即团队开发成员集成集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能发生多次集成，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

什么是“持续交付”？

1. 持续交付(Continuous delivery, 缩写为CD) 是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定，持续的保持在随时可以发布的状况，它的目标在于让软件的构建，测试与发布变得更加快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

2. 持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。

3. 持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

4. 持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。

CD 与 DevOps的关系

1. DevOps的范围更广，是软件交付过程所涉及的多个团队之间的合作，并且将软件交付的过程自动化；

2. 持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更加，更频繁地执行执行过程；

3. DevOps可以是持续交付下的一个产物，持续交付的成果直接汇入DevOps模型；

项目管理

项目流程	项开发的各阶段	过程管理思想
项目立项
产品定义
软件开发	需求分析阶段， 概要设计阶段， 详细设阶段计， 系统编码阶段， 单元测试阶段， 集成测试阶段， 系统测试阶段	项目管理过程， 评审过程， 软件监督与审核过程， 软件需求管理过程， 变更控制过规程， 文档控制规程， 文档开发与管理规范
软件测试	需求分析阶段， 概要设计阶段， 详细设阶段计， 系统编码阶段， 单元测试阶段， 集成测试阶段， 系统测试阶段	项目管理过程， 评审过程， 软件监督与审核过程， 软件需求管理过程， 变更控制过规程， 文档控制规程， 文档开发与管理规范
内部验收
用户验收
系统维护

设计阶段

项目经理	产品	研发	测试
工作内容： 1，监控项目进度； 2，组织安排本阶段的评审； 3，任务分解，责任到人； 4，细化项目计划 产出： 1，项目计划（具体到各个功能）	工作内容： 1，系统功能设计； 产出： 1，系统说明书	工作内容： 1，系统功能技术设计； 2，数据库设计； 产出： 1，概要设计文档； 2，详细设计文档；	工作内容： 1，组织测试计划评审； 产出： 1，测试计划

开发阶段

项目经理	产品	研发	测试
工作内容： 1，监控项目进度； 2，调整人员安排； 3，跟踪解决技术难点； 产出： 1，项目计划（更新进度）； 2，项目报告进度；	工作内容： 1，需求细节沟通	工作内容： 1，具体功能开发； 2，组织codereview； 3，单元测试 产出： 1，功能测试； 2，单元测试代码	工作内容： 1，编写测试用例； 2，组织测试用例评审； 产出： 1，测试用例

集成测试阶段

项目经理	产品	研发	测试
工作内容： 1，监控项目进度； 2，跟踪解决技术难题； 产出： 1，项目报告进度	工作内容： 1，需求细节沟通； 2，bug修改方案	工作内容： 1，集成测试； 2，修改bug； 产出： 1，集成测试报告； 2，部署测试环境；	工作内容： 1，支持研发进行集成测试； 2，准备测试数据； 3，准备自动化测试用例

系统测试阶段

项目经理	产品	研发	测试
工作内容： 1，分配Bug； 2，跟踪解决技术难题； 产出： 1，项目报告进度；	工作内容： 1，需求细节沟通； 2，Bug修改方案；	工作内容： 1，支持测试； 2，修改Bug；	工作内容： 1，测试环境搭建； 2，补充测试数据； 3，功能测试； 4，自动化测试； 产出： 1，系统测试报告（执行报告）； 2，缺陷报告；

软件项目管理的方法

• 制定项目计划

• 执行计划并监控跟踪管理

• 项目风险应对与问题解决

• 项目收尾

测试仔与产品沟通

• 需求评审会议

• 在分析需求阶段

• 在测试用例编写阶段

• 在测试过程中

测试仔与开发沟通

• 在分析需求阶段

• 在测试用例编写阶段

• 在测试过程中

• 在线上监控发现bug中

上下游测试配合

• 测试计划沟通

• 环境对接

• 熟悉业务

项目示例

1，计划：创建项目

2，项目管理工具

1，需求文档

2，设计文档

3，测试用例

4，bug管理

3，对应关系

1，开发 -> 单元测试 -> 集成测试 -> 持续集成 -> 冒烟测试 -> 系统测试 -> 验收测试 -> 发布 -> 持续监控

2，开发 -> 客户端，服务端

3，需求文档 -> 开发

4，开发 -> 设计文档

5，测试用例 -> 冒烟测试，系统测试

6，bug管理 -> 冒烟测试，系统测试，验收测试，持续监控