DevOps是旨在加快产品发布周期、减少浪费、并伴随每次迭代构建逐渐增强最终用户体验的SDLC方法。除了支持DevOps的工具和流程外，常用的SDLC方法还专注于文化、人员及其思维方式。

在DevOps企业中，跨越开发、质量保证和运营部门的小型多学科自治团队展开协作，共同承担责任。参与开发项目的所有团队和整个企业均奉行DevOps文化。这些工作团队需要通过协作、自动化以及响应所有利益相关者的反馈来关注产品质量和交付速度。这要求企业必须消除跨部门的孤岛，并允许工作团队自主运营，同时采用适当的治理措施和策略，以推动自治和自动化驱动的SDLC流程。

DevOps承诺，通过SDLC管道中多个贡献团队和个人的共同努力来构建持续改进的系统。尽管技术和流程工作流都是现成的，但是，如果不实施文化变革，各团队之间的目标可能会相互冲突，并且可能无法真正跟上DevOps的步伐。例如，开发人员可能希望响应最终用户的反馈和市场需求来快速部署新功能，而质量保证人员则希望确保每次迭代构建都是稳定的、安全的、并按预期标准执行的。在传统的SDLC模式中，出现这种僵局是因为开发人员将安全性视为QA的责任，而QA更倾向于维护系统的正常运行，而不是向市场发布创新功能。如果采用DevOps的思维方式，每当构建升级版本时，开发人员都能尽早检查功能代码，并与QA一起修复潜在的bug。为了解决与性能和故障相关的问题，DevOps团队将专注于减少平均缓解/修复时间(MTTM/MTTR)，而不是优化平均故障间隔时间(MTBF)。前一种策略允许DevOps团队快速部署多个功能版本，做好准备并快速做出反应，以降低潜在故障的影响，而后一种策略仅用于减少潜在问题。但实际上，软件问题很少能被完全消除，为了实现该目标而付出额外努力将会影响产品发布速度。

DevOps文化的协作部分也不同于传统的SDLC模式。虽然DevOps也强烈建议孤立的团队和部门在必要时进行沟通，但它的目标却是通过有效的自动化来减少协作团队内部的瓶颈。DevOps旨在消除团队成员之间手动通信、审批和延迟处理需求。例如，当开发人员需要在DevOps环境中添加其他的硬件资源时，他们可将该等硬件资源部署在云环境中，而不必与运营团队进行互动或等待其批准。自动化进一步提高了DevOps成员的协作能力。自动测试和服务器配置使开发、运营和质量保证团队能够了解每次迭代构建的性能和服务器的配置方式，从而减少因手动交互而导致的人为错误和延迟几率。

在工作场所培养真正的DevOps文化需要各团队重新定义职责，采取积极措施来减少因工作场所文化而引发的问题，并通过持续开展回顾性分析来调整文化表现。

角色和职责的分配可能不是一次会议就能搞定的。要知道，工作团队往往会经历多个成长阶段，不一定能随新工作任务的分配和项目成型而向前发展。根据Tuckman的团队开发流程，工作团队在经历了形成(Forming)、风暴(Storming)和规范(Norming)阶段之后，并不一定能够进入“运行”状态。DevOps要求基于真实反馈进行持续改进，可能会导致个人偏离最初的角色和职责，从而可能需要对团队职责进行不断的细化和整合。

DevOps文化模糊了开发、运营和质量保证角色间的界线。团队成员不再遵循传统的移交和签字流程，而是在整个SDLC生命周期中协同工作，并对软件项目的成败共同承担责任。开发、运营和质量保证团队从一开始就展开协作，而不是想办法推卸责任，因此能在每次迭代构建时交付有效的软件版本。从组织的角度来看，DevOps环境还重新定义了传统的决策机制和治理策略，以促进这种协作。例如，工作团队可以使用具有自动审批工作流的版本控制系统，而不是手动审核和签字流程。这些措施使工作团队能够自主运作，同时管理风险和对失败的恐惧。因此，以前孤立的部门成员便会走出自己的舒适区，以开放的心态进行协作。开发人员、运营人员和质量保证人员逐渐使用这种变化，开始共同承担责任，而不是将彼此视为独立团队的成员，因为他们在同一个SDLC项目管道中工作。

DevOps持续改进理念的实现方式是：随着每次迭代构建而频繁进行小规模的软件改进、使用自动化工具开展仔细的测试、然后以更快的速度将产品发布给最终用户。最终用户和利益相关者的反馈允许开发人员不断调整SDLC管道以改进结果。这些改进本质上是由客户驱动的，并专注于随新版本的推出来逐渐增强最终用户体验。

总之，实施DevOps需要在个人之间相互协作的方式以及企业促进必要文化转变的方式上做出重大调整。首先要抱着正确的心态：保持透明性和相互信任；制定不冲突的目标；接受失败而不是推诿责任；遵循共同担责而不是“撇清自己”的理念。从流程和组织的角度来看，要在个人和DevOps团队成员之间实现真正的自治；促进跨职能领域的协作；减少浪费和瓶颈流程；并沿着SDLC管道不间断地推进，包括集成、测试、部署甚至筹资等。即使大多数企业都无法接受突然的文化转变，但是，从小规模起步，然后逐渐蔓延到多个DevOps团队，无疑是企业文化变更的可行方式。(BMC中国）

DevOps是旨在加快产品发布周期、减少浪费、并伴随每次迭代构建逐渐增强最终用户体验的SDLC方法。除了支持DevOps的工具和流程外，常用的SDLC方法还专注于文化、人员及其思维方式。

在DevOps企业中，跨越开发、质量保证和运营部门的小型多学科自治团队展开协作，共同承担责任。参与开发项目的所有团队和整个企业均奉行DevOps文化。这些工作团队需要通过协作、自动化以及响应所有利益相关者的反馈来关注产品质量和交付速度。这要求企业必须消除跨部门的孤岛，并允许工作团队自主运营，同时采用适当的治理措施和策略，以推动自治和自动化驱动的SDLC流程。

DevOps承诺，通过SDLC管道中多个贡献团队和个人的共同努力来构建持续改进的系统。尽管技术和流程工作流都是现成的，但是，如果不实施文化变革，各团队之间的目标可能会相互冲突，并且可能无法真正跟上DevOps的步伐。例如，开发人员可能希望响应最终用户的反馈和市场需求来快速部署新功能，而质量保证人员则希望确保每次迭代构建都是稳定的、安全的、并按预期标准执行的。在传统的SDLC模式中，出现这种僵局是因为开发人员将安全性视为QA的责任，而QA更倾向于维护系统的正常运行，而不是向市场发布创新功能。如果采用DevOps的思维方式，每当构建升级版本时，开发人员都能尽早检查功能代码，并与QA一起修复潜在的bug。为了解决与性能和故障相关的问题，DevOps团队将专注于减少平均缓解/修复时间(MTTM/MTTR)，而不是优化平均故障间隔时间(MTBF)。前一种策略允许DevOps团队快速部署多个功能版本，做好准备并快速做出反应，以降低潜在故障的影响，而后一种策略仅用于减少潜在问题。但实际上，软件问题很少能被完全消除，为了实现该目标而付出额外努力将会影响产品发布速度。

DevOps文化的协作部分也不同于传统的SDLC模式。虽然DevOps也强烈建议孤立的团队和部门在必要时进行沟通，但它的目标却是通过有效的自动化来减少协作团队内部的瓶颈。DevOps旨在消除团队成员之间手动通信、审批和延迟处理需求。例如，当开发人员需要在DevOps环境中添加其他的硬件资源时，他们可将该等硬件资源部署在云环境中，而不必与运营团队进行互动或等待其批准。自动化进一步提高了DevOps成员的协作能力。自动测试和服务器配置使开发、运营和质量保证团队能够了解每次迭代构建的性能和服务器的配置方式，从而减少因手动交互而导致的人为错误和延迟几率。

在工作场所培养真正的DevOps文化需要各团队重新定义职责，采取积极措施来减少因工作场所文化而引发的问题，并通过持续开展回顾性分析来调整文化表现。

角色和职责的分配可能不是一次会议就能搞定的。要知道，工作团队往往会经历多个成长阶段，不一定能随新工作任务的分配和项目成型而向前发展。根据Tuckman的团队开发流程，工作团队在经历了形成(Forming)、风暴(Storming)和规范(Norming)阶段之后，并不一定能够进入“运行”状态。DevOps要求基于真实反馈进行持续改进，可能会导致个人偏离最初的角色和职责，从而可能需要对团队职责进行不断的细化和整合。

DevOps文化模糊了开发、运营和质量保证角色间的界线。团队成员不再遵循传统的移交和签字流程，而是在整个SDLC生命周期中协同工作，并对软件项目的成败共同承担责任。开发、运营和质量保证团队从一开始就展开协作，而不是想办法推卸责任，因此能在每次迭代构建时交付有效的软件版本。从组织的角度来看，DevOps环境还重新定义了传统的决策机制和治理策略，以促进这种协作。例如，工作团队可以使用具有自动审批工作流的版本控制系统，而不是手动审核和签字流程。这些措施使工作团队能够自主运作，同时管理风险和对失败的恐惧。因此，以前孤立的部门成员便会走出自己的舒适区，以开放的心态进行协作。开发人员、运营人员和质量保证人员逐渐使用这种变化，开始共同承担责任，而不是将彼此视为独立团队的成员，因为他们在同一个SDLC项目管道中工作。

DevOps持续改进理念的实现方式是：随着每次迭代构建而频繁进行小规模的软件改进、使用自动化工具开展仔细的测试、然后以更快的速度将产品发布给最终用户。最终用户和利益相关者的反馈允许开发人员不断调整SDLC管道以改进结果。这些改进本质上是由客户驱动的，并专注于随新版本的推出来逐渐增强最终用户体验。

总之，实施DevOps需要在个人之间相互协作的方式以及企业促进必要文化转变的方式上做出重大调整。首先要抱着正确的心态：保持透明性和相互信任；制定不冲突的目标；接受失败而不是推诿责任；遵循共同担责而不是“撇清自己”的理念。从流程和组织的角度来看，要在个人和DevOps团队成员之间实现真正的自治；促进跨职能领域的协作；减少浪费和瓶颈流程；并沿着SDLC管道不间断地推进，包括集成、测试、部署甚至筹资等。即使大多数企业都无法接受突然的文化转变，但是，从小规模起步，然后逐渐蔓延到多个DevOps团队，无疑是企业文化变更的可行方式。(BMC中国）