常见 IT 项目管理模式总结

软件从立项到交付，总会经历规划、设计、开发、测试、部署、维护，我们称之为 SDLC (Software Deployment Lifecycle)。随着项目复杂度不断提升，各种围绕 SDLC 管理的方法论不断发展，以下总结主流的几类模式：

瀑布式开发 (Waterfall Model)

瀑布式开发是软件开发的传统模式，严格遵守 SDLC 的流程，强调完整的规划、分析、设计、测试等管理与控制。强调文档的重要性。

优点：由于每个阶段都要求保证严格的管理和完整性，能够保证交付的品质，适用于大型项目。

缺点：线性的开发模型，正如瀑布无法逆转，客户只有等到整个项目完成才能看到成果，整个项目的开发周期一般以年计算，项目延期也是家常便饭，增加了开发风险，并且无法应对客户变化的需求。强调严格按照设计文档来开发，需要投入较多精力来维护各个阶段文档。

迭代式开发 (Iteration Model)

迭代式开发与瀑布式开发相反，每次只设计、实现产品的一部分，逐步完成整体项目，每次设计实现都是一次迭代。

优点是降低了开发风险，能够适应需求的不确定性。

缺点是在设计上需要投入更多时间，确定每次迭代的内容，不适用于小项目。

螺旋式开发

螺旋式开发强调风险评估，适用于大型复杂、高风险的项目。在每个迭代确定方案之后，都会进行方案的风险评估，保证项目整体不偏离目标。适合于大规模软件项目

敏捷开发 (Agile Model)

敏捷宣言：

敏捷宣言强调的敏捷软件开发的四个核心价值是：
个体和互动 高于流程和工具
工作的软件 高于详尽的文档
客户合作 高于合同谈判
响应变化 高于遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。

敏捷开发是一种应对频繁变化需求的开发模式，强调开发团队成员及产品之间紧密协同合作、面对面沟通、频繁交付新版本。强调目标导向，对开发人员有更高的要求，希望每个成员能够更加主动拥抱挑战。

敏捷开发常用的开发模式包含 Scrum 框架，XP（极限编程），Crystal（水晶编程）等。

• Scrum 实施方案：

  Scrum开发流程中的三个项目角色

  • 产品负责人(PO)：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
  • 流程管理员（SM）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
  • 开发团队(ST)：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须有很强的自我管理能力，同时具有一定的表达能力。

  Sprint：是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为 Sprint。(在Scrum中，Sprint 说的是类似橄榄球比赛中的冲刺：大家团结一致，为了完成该Sprint的目标疯狂向前冲)

  1. 首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ，这是由 PO（Product Owner） 负责的
  2. ST（Scrum Team） 会根据 PB 列表，进行工作量的预估和安排
  3. 有了 PB 列表，我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期 是1~4 个星期，然后把这个 Story 进行细化，形成一个Sprint Backlog
  4. Sprint Backlog 是由 ST 去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）
  5. 在 Scrum Team 完成计划会议上选出的 Sprint Backlog 过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，最重要的是提出问题，这样有利于暴露并今早规避风险，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint 燃尽图）
  6. 做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员。
  7. 当一个 Story 完成，也就是 Sprint Backlog 被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）
  8. 最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮 Sprint 的产品需求中。

敏捷开发和迭代式开发的联系和区别：

敏捷开发是一个总体概念，而迭代式开发只是几乎所有敏捷开发所采用的一个基础模型。敏捷开发每个周期称为 Sprint，迭代开发每个周期称为 Iteration。迭代开发主要是定义了开发的过程，而敏捷开发包含多种软件开发项目管理方法，强调沟通协作和对需求变化的快速响应。

优点：将大的项目拆分为 1-4 weeks 为一个周期的子项目，每个子项目都有完整的从设计到发布的完整流程，在子项目完成时，再与需求方 review，确定符合预期后，再继续开发下一个子项目。反之则进行改造。经过若干次这样的迭代，形成最终完整的产品或功能，这样可以降低整体风险，并能够快速应对需求变化。

缺点：由于强调沟通，比较忽略文档的重要性。如果项目人员流动性比较高，会给维护带来较大难度。

DevOps

DevOps = Development & Operations 核心包括开发、测试、运维之间的紧密沟通合作，强调利用自动化快速构建、测试、发布软件，开发多去思考运维层面、运维也站在开发的角度多思考。以期打破开发和运维人员之间的壁垒。

DevOps 流程源于敏捷开发，它延续并拓展了以更快的方式、更优的质量构建和交付软件的思想。

运维需要做的上线工作，主要就是将代码部署到对应的机器里面，微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。

那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西

运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DEVOPS开发模式诞生了，开发即是运维。

什么是DevOps？ – 小龙飞的回答 – 知乎

****DevOps 重视工具，包括；****

1. 版本控制
2. 持续集成（CI）
3. 持续交付（CD）
4. 监控
5. 自动化测试
6. 报警
7. ….

另外 DevOps 也经常与 SRE 一起讨论，他们有什么联系和区别呢？

DevOps是一种思想、文化；而 SRE 是指 Google提出的 Site Reliability Engineer (网站可靠性工程师)，是一个具体岗位。SRE 可以认为是 DevOps 的一个具体实践（Is-SRE-Googles-version-of-DevOps）。

SRE 的目标不是 Operation，而是 Engineering，是一个是“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位，这也是和传统运维最大的区别，即自动化替代人工。SRE 需要很强的开发能力，需要关注业务稳定性、高可靠性等。