我们一直都在探讨DevOps，关于“Dev”和“Ops”仿佛总有貌合神离的情况出现，DevOps最重要的目的就是鼓励开发部门和运维部门通力合作。在真正的工作环境中，DevOps虽然仍存在很多争议，但它的价值确是不可估量的，所以我们必须将DevOps进行到底。本文主要探讨DevOps的一项关键性话题——价值流程图，它是实现整个DevOps的第一步，在DevOps能否被接纳的问题上起到了至关重要的作用。

“DevOps”应该从管理层认可开始

DevOps出现之后，大家也许曾经提出或者听到过一个很关键却又普遍的问题——“DevOps转型应该从哪里开始？”

工作中，并非所有人都信任DevOps，通常遇到的第一个难题是得到管理层的认可与支持，因为DevOps的核心含义可能会掀起公司的大变革。

价值流程图才是最理想的DevOps第一步

DevOps的终极目标在于产品快速迭代的同时又能保证良好的质量水平，为了了解当前哪些人员、流程、技术需要修复或改进，我们要画出整个软件交付周期的价值流程图——从接收应用或者功能的开发新要求，到将产品交付至客户或者员工。而这正是DevOps最理想的第一步，这项工作包括：

·         全部流程区都将参与其中

·         保障信息流程与开发流程（对于应用开发工作）

·         流程时长，即新应用或功能在单一流程之内的开发周期

·         生产交货时间，即应用或功能需要耗费多长时间来过渡到下一个流程并最终达至交付

·         现有应用或者功能的就绪时间

·         新型应用或者功能的现有交付时间

价值流程图有很多版本，每个人的理解也有偏差，有时候在面对客户时甚至不清楚他们是否已经拥有一套有意义的价值流程图方案。

以下示意图通过简单示例解释了新功能发布所需的价值流程图方案：

在这套流程机制中，我们可以看到：

·         信息流程——即新功能的要求如何与业务相契合并与CIO进行对接。在这种情况下，每隔一周就要进行一次需求讨论会。需要注意的是，应用智能（包括监控与分析两大要素）对反馈回路非常重要。

·         软件开发流程——此流程在IT部门内部，同样属于新功能开发的重要组成部分。需要注意的是，应用智能同样对软件开发周期内的信息反馈与交付回路至关重要。

·         交付时间表——即将应用或功能由理论要求转化为可交付内容的时间周期。在这里我们可以看到两项计算过程：1）产品交付时间=该功能在不同流程间过渡所耗费的总时长；2）流程时间=该功能在每个流程当中所耗费的独立时长。

·         在此之后，我们能够一步步计算出总体功能就绪时间和总体功能交付时间。在这个示例当中，一项全新功能需要大约三个半月才能被呈现在用户面前——这样的周期对于当前追求唯快不破的用户来说太过漫长了。

关于价值流程图的五项提示

为自己的DevOps做一张价值流程图仅仅只是第一步，好的价值流程图机制应该具备极强的针对性，能够很轻易绘制在白板之上，最重要的是能帮助工作人员解读当前流程。而前面列举的示例则能更近一步向企业决策者展示并争取到他们的认可。如何做好专属的DevOps价值流程图，以下五点你可能会用到：

   

1、价值流程图最重要的意义并不在于立即生效，它会逐步进行同时帮助同一团队内的成员理解整个流程，通过抱怨、诉求、接纳以及变更等途径直至达成共识。这对于整个DevOps团队来说极为重要，因为日常工作当中我们会发现，往往就是不沟通不诉求才会导致效率下降。

2、不要在决策制定者未了解的情况下着手构建价值流程图，这样的话将无法确保流程的准确性。只有决策制定者才能真正了解到整个DevOps的实际情况，能保证最后的流程能够顺利进行，这可能会很麻烦但却非常值得。

3、对于DevOps价值流程图的讨论一般需要较长的时间，根据大家实际采取的流程情况来定，要确保不同职责的人能够在这一环节中畅所欲言，避免把同一项内容拆分开，因为Dev和Ops在实际工作中还是有很大区别的。

4、DevOps价值流程图的规划需要一个主持人，他将扮演极为重要的角色。要统一来自不同部门的意见，调节大家的情绪波动，让不同参与者在讨论过程中始终保持正确的交流状态。

5、最后是价值流程图的发布，需要组织一次研讨会或电话会议，以更正式的方式进行价值流程图方案的发布，因为这是DevOps的第一步，同时也是最重要的一步，它是实现各类有价值目标的必要基础，是以后所有工作的起点和指导。

接下来该如何使用价值流程图？

说到这里，我们仅仅勾勒出了价值流程图方案的轮廓，也许你的心中也有了属于你自己的DevOps价值流程图。需要强调的是，这里的每个流程都只是参考，我们需要结合自身实际情况，包括人员因素、内部流程与技术类别等，分辨出他们具体处于哪个阶段，该流程的持续时间甚至最终交付时间如何确定，这些都是我们需要自己去考虑的。

如果最后能够确保DevOps价值流程图真实准确，那DevOps的第一步将走得无比坚实，这不仅能解决DevOps实施过程中的矛盾，同时还回答了之前关于DevOps的核心目标——指导我们如何在加快发布速度的同时保证成果的质量水平，从此迈出DevOps的第一步！（来自听云）

我们一直都在探讨DevOps，关于“Dev”和“Ops”仿佛总有貌合神离的情况出现，DevOps最重要的目的就是鼓励开发部门和运维部门通力合作。在真正的工作环境中，DevOps虽然仍存在很多争议，但它的价值确是不可估量的，所以我们必须将DevOps进行到底。本文主要探讨DevOps的一项关键性话题——价值流程图，它是实现整个DevOps的第一步，在DevOps能否被接纳的问题上起到了至关重要的作用。

“DevOps”应该从管理层认可开始

DevOps出现之后，大家也许曾经提出或者听到过一个很关键却又普遍的问题——“DevOps转型应该从哪里开始？”

工作中，并非所有人都信任DevOps，通常遇到的第一个难题是得到管理层的认可与支持，因为DevOps的核心含义可能会掀起公司的大变革。

价值流程图才是最理想的DevOps第一步

DevOps的终极目标在于产品快速迭代的同时又能保证良好的质量水平，为了了解当前哪些人员、流程、技术需要修复或改进，我们要画出整个软件交付周期的价值流程图——从接收应用或者功能的开发新要求，到将产品交付至客户或者员工。而这正是DevOps最理想的第一步，这项工作包括：

·         全部流程区都将参与其中

·         保障信息流程与开发流程（对于应用开发工作）

·         流程时长，即新应用或功能在单一流程之内的开发周期

·         生产交货时间，即应用或功能需要耗费多长时间来过渡到下一个流程并最终达至交付

·         现有应用或者功能的就绪时间

·         新型应用或者功能的现有交付时间

价值流程图有很多版本，每个人的理解也有偏差，有时候在面对客户时甚至不清楚他们是否已经拥有一套有意义的价值流程图方案。

以下示意图通过简单示例解释了新功能发布所需的价值流程图方案：

在这套流程机制中，我们可以看到：

·         信息流程——即新功能的要求如何与业务相契合并与CIO进行对接。在这种情况下，每隔一周就要进行一次需求讨论会。需要注意的是，应用智能（包括监控与分析两大要素）对反馈回路非常重要。

·         软件开发流程——此流程在IT部门内部，同样属于新功能开发的重要组成部分。需要注意的是，应用智能同样对软件开发周期内的信息反馈与交付回路至关重要。

·         交付时间表——即将应用或功能由理论要求转化为可交付内容的时间周期。在这里我们可以看到两项计算过程：1）产品交付时间=该功能在不同流程间过渡所耗费的总时长；2）流程时间=该功能在每个流程当中所耗费的独立时长。

·         在此之后，我们能够一步步计算出总体功能就绪时间和总体功能交付时间。在这个示例当中，一项全新功能需要大约三个半月才能被呈现在用户面前——这样的周期对于当前追求唯快不破的用户来说太过漫长了。

关于价值流程图的五项提示

为自己的DevOps做一张价值流程图仅仅只是第一步，好的价值流程图机制应该具备极强的针对性，能够很轻易绘制在白板之上，最重要的是能帮助工作人员解读当前流程。而前面列举的示例则能更近一步向企业决策者展示并争取到他们的认可。如何做好专属的DevOps价值流程图，以下五点你可能会用到：

   

1、价值流程图最重要的意义并不在于立即生效，它会逐步进行同时帮助同一团队内的成员理解整个流程，通过抱怨、诉求、接纳以及变更等途径直至达成共识。这对于整个DevOps团队来说极为重要，因为日常工作当中我们会发现，往往就是不沟通不诉求才会导致效率下降。

2、不要在决策制定者未了解的情况下着手构建价值流程图，这样的话将无法确保流程的准确性。只有决策制定者才能真正了解到整个DevOps的实际情况，能保证最后的流程能够顺利进行，这可能会很麻烦但却非常值得。

3、对于DevOps价值流程图的讨论一般需要较长的时间，根据大家实际采取的流程情况来定，要确保不同职责的人能够在这一环节中畅所欲言，避免把同一项内容拆分开，因为Dev和Ops在实际工作中还是有很大区别的。

4、DevOps价值流程图的规划需要一个主持人，他将扮演极为重要的角色。要统一来自不同部门的意见，调节大家的情绪波动，让不同参与者在讨论过程中始终保持正确的交流状态。

5、最后是价值流程图的发布，需要组织一次研讨会或电话会议，以更正式的方式进行价值流程图方案的发布，因为这是DevOps的第一步，同时也是最重要的一步，它是实现各类有价值目标的必要基础，是以后所有工作的起点和指导。

接下来该如何使用价值流程图？

说到这里，我们仅仅勾勒出了价值流程图方案的轮廓，也许你的心中也有了属于你自己的DevOps价值流程图。需要强调的是，这里的每个流程都只是参考，我们需要结合自身实际情况，包括人员因素、内部流程与技术类别等，分辨出他们具体处于哪个阶段，该流程的持续时间甚至最终交付时间如何确定，这些都是我们需要自己去考虑的。

如果最后能够确保DevOps价值流程图真实准确，那DevOps的第一步将走得无比坚实，这不仅能解决DevOps实施过程中的矛盾，同时还回答了之前关于DevOps的核心目标——指导我们如何在加快发布速度的同时保证成果的质量水平，从此迈出DevOps的第一步！（来自听云）