[  /pic/001l8XD7zy7ySSN414oc4][/url]

今天谈下DevOps能力成熟度模型里面的敏捷开发管理，如果做过CMMI或敏捷项目管理的可以看到实际上在当前DevOps成熟度模型中的敏捷开发管理还是相当粗的，而且是将软件工程域内容和过程管理内容融合在了一起，同时也可以看到其核心还是基于scrum敏捷项目管理方法论而展开，只是在这个过程中更加强调了业务场景驱动和价值交付的重要性。

DevOps持续集成和交付本身就是为了更加敏捷响应需求，快速短周期的迭代交付，因此和敏捷方法论配合是自然的事情。同时我们也可以看到要实现敏捷，需求必须细粒度化，同时需求本身需要体现业务价值，而要做到这点核心就是基于业务场景分析出来的用户故事和用户故事地图。

在上篇文章我们也重点谈了用户故事地图的作用，也进一步解释清楚了对原来backlog清单跟踪的改进。

而对于敏捷开发或敏捷项目管理，如果要用一句话来总结的话就是，基于业务场景和用户故事驱动的短周期迭代和项目团队高效协同，以实现快速的业务价值交付。而这个目标下我们经常谈到的可视化看板，站立会议，燃尽图等也仅仅是实现上述目标的工具。

也正是这个原因我们看到，要进入到敏捷开发过程管理，形成基于业务场景形成具备优先级划分的细粒度用户故事至关重要，这将直接是我们后面迭代计划安排，测试用例编写，交付交付的基础。

下面我们还是根据成熟度模型里面对敏捷开发管理拆分的三个子过程域分别来谈下。

1.价值交付（需求工件，需求活动）

价值交付管理包括了需求工件和需求活动两个部分内容，体现需求管理过程中的分析，测试，验收三个阶段。价值交付管理主要体现在各个环节中实现敏捷方法探寻用户问题和述求，业务价值，并定义有效产品功能的能力，适应需求变化的能力，快速验证反馈的能力。

需求工件：对需求和用例的管理，可以看到包括了需求内容，测试用例，测试用例验证，测试用例管理，覆盖了前面谈到的需求->测试-》验收完整线条，而里面核心又是用户故事。

需求活动：包括了需求分析和需求验收，而需求分析是将产品需求具体化，形成代办事项列表的过程，或者说需求分析重点就是要形成用户故事清单，而且估算故事点，评估优先级为后面形成迭代计划做准备。形成迭代计划后才可能对应到后面的验收是多次验收，多次交付。

对应需求工件和用户故事的形成，思考了下，更加值得参考的做法应该是

1. 基于业务场景分析梳理业务流程，识别关键业务活动，并识别一级用户故事

2. 基于识别完成的一级用户故事来进行原型设计和开发

3. 基于原型设计再进一步的分解一级用户故事，形成最小化用户故事和优先级(完整用户故事地图）

这种方法和步骤可以更好的将业务场景和流程和我们实际的业务功能实现结合在一起，将具体实现的业务功能匹配到核心业务价值实现上。这才是我们谈到的价值交付而不是单个功能点交付。同时上面这种方法我们还看到进一步将需求分析过程和我们后续的产品规划和迭代版本计划过程紧密的结合在了一起，由于用户故事具备优先级，在进行优先级分析过程中结合到迭代版本计划安排，在故事点估算过程中分析具体的工作量，这些都为后续的版本计划安排和任务下达奠定了基础。

而对于需求的管理，里面谈到的比较粗，对于需求的追踪，需求的变更管理，需求的发布计划，需求的验证等都应该属于需求管理的范畴。只是在敏捷开发过程中的需求管理，更加强调围绕用户故事形成一条线的端到端管理，并实现价值交付的目标。

2.敏捷过程管理（价值流，仪式活动）

敏捷过程管理是产品经理，研发团队以及与产品相关的干系人围绕业务价值交付进行的软件研发过程，包括价值流和仪式活动两个部分，要求上述人员建立以尽早和持续的交付价值的软件为目标，通过高效的沟通方式，高效的可视化工作流，有效的度量和快速反馈机制，实现软件研发业务价值最大化。

价值流：将软件产品转化为业务价值的能力，包括按照用户地图按需交付可用的软件，同时包括了交付质量管理，交付度量，和持续的价值流跟踪。也就是说这里面入口是用户故事地图，然后是可视化的交付全流程的跟踪和反馈，其次是在整个过程中还需要围绕价值交付建立有效的度量和评估机制。

仪式活动：通过建立价值流动的管控机制，可视化的管理价值流程，控制流动节奏，不断提升价值交付效率。包括各类计划会议，评审会议等。这个可以进一步参考敏捷过程管理中的一些最佳实践。

简单来说敏捷过程管理核心是可视化，管控机制，度量机制，高效的协同和反馈机制建立。所有的这些机制建立都又是围绕价值交付服务。

3.敏捷组织模式（敏捷角色，团队结构）

敏捷组织模式是指团队在研发过程中的角色定义，角色能力以及之间的协作，团队结构的工作方式，团队间的协作模式等方面的要求，主要从敏捷角色和团队结构两个方面进行定义。

敏捷角色：指产品经理，敏捷教练和团队之间的职责分工，能力提升和协助方式，角色都能够以价值交付为目标，持续的提升交付效率。我们来看下敏捷教练定义：

参考：[  /pmd/793824.html]pmd/793824.html[/url]

敏捷教练在深刻的理解敏捷的价值观的基础上，同时需要具备丰富的敏捷技术实践经验，以及拥有基于团队的实际情况采用合适的敏捷实践的能力。这里面实际包括了需求分析和拆分，用户故事地图，需求影响分析，故事点故事，需求优先级评估，迭代计划安排等一系列的敏捷实践。

产品经理是对产品的ROI负责，负责梳理产品需求，规划产品功能列表，确定优先级，参与规划活动，并验证最终的交付成功。对于scrum里面强调的product owner更加强调面向市场和客户，只是参与而不是具体去执行敏捷开发过程中的具体事务类活动。

敏捷教练重点是引导团队进行敏捷转型，驱动敏捷实践的运转。可以全职，也可以兼职。

团队结构：团队结构在研发过程中以最小化的功能团队，以共同的价值观，通过可视化的方式，紧密合作，实现业务价值的快速交付。团队足够小，其各个团队相互独立，能够独自完成交付。


对于团队架构，实际上在devops过程实践里面本身是对团队结构有要求的，而这个在传统的敏捷方法论里面是不涉及的。比如我们经常谈到如果拆分为两个独立的微服务模块，那么两个模块涉及到的前端开发，设计，数据库人员完全是分离的，能够实现独立管理和协同。

[  /pic/001l8XD7zy7ySSN414oc4][/url]

今天谈下DevOps能力成熟度模型里面的敏捷开发管理，如果做过CMMI或敏捷项目管理的可以看到实际上在当前DevOps成熟度模型中的敏捷开发管理还是相当粗的，而且是将软件工程域内容和过程管理内容融合在了一起，同时也可以看到其核心还是基于scrum敏捷项目管理方法论而展开，只是在这个过程中更加强调了业务场景驱动和价值交付的重要性。

DevOps持续集成和交付本身就是为了更加敏捷响应需求，快速短周期的迭代交付，因此和敏捷方法论配合是自然的事情。同时我们也可以看到要实现敏捷，需求必须细粒度化，同时需求本身需要体现业务价值，而要做到这点核心就是基于业务场景分析出来的用户故事和用户故事地图。

在上篇文章我们也重点谈了用户故事地图的作用，也进一步解释清楚了对原来backlog清单跟踪的改进。

而对于敏捷开发或敏捷项目管理，如果要用一句话来总结的话就是，基于业务场景和用户故事驱动的短周期迭代和项目团队高效协同，以实现快速的业务价值交付。而这个目标下我们经常谈到的可视化看板，站立会议，燃尽图等也仅仅是实现上述目标的工具。

也正是这个原因我们看到，要进入到敏捷开发过程管理，形成基于业务场景形成具备优先级划分的细粒度用户故事至关重要，这将直接是我们后面迭代计划安排，测试用例编写，交付交付的基础。

下面我们还是根据成熟度模型里面对敏捷开发管理拆分的三个子过程域分别来谈下。

1.价值交付（需求工件，需求活动）

价值交付管理包括了需求工件和需求活动两个部分内容，体现需求管理过程中的分析，测试，验收三个阶段。价值交付管理主要体现在各个环节中实现敏捷方法探寻用户问题和述求，业务价值，并定义有效产品功能的能力，适应需求变化的能力，快速验证反馈的能力。

需求工件：对需求和用例的管理，可以看到包括了需求内容，测试用例，测试用例验证，测试用例管理，覆盖了前面谈到的需求->测试-》验收完整线条，而里面核心又是用户故事。

需求活动：包括了需求分析和需求验收，而需求分析是将产品需求具体化，形成代办事项列表的过程，或者说需求分析重点就是要形成用户故事清单，而且估算故事点，评估优先级为后面形成迭代计划做准备。形成迭代计划后才可能对应到后面的验收是多次验收，多次交付。

对应需求工件和用户故事的形成，思考了下，更加值得参考的做法应该是

1. 基于业务场景分析梳理业务流程，识别关键业务活动，并识别一级用户故事

2. 基于识别完成的一级用户故事来进行原型设计和开发

3. 基于原型设计再进一步的分解一级用户故事，形成最小化用户故事和优先级(完整用户故事地图）

这种方法和步骤可以更好的将业务场景和流程和我们实际的业务功能实现结合在一起，将具体实现的业务功能匹配到核心业务价值实现上。这才是我们谈到的价值交付而不是单个功能点交付。同时上面这种方法我们还看到进一步将需求分析过程和我们后续的产品规划和迭代版本计划过程紧密的结合在了一起，由于用户故事具备优先级，在进行优先级分析过程中结合到迭代版本计划安排，在故事点估算过程中分析具体的工作量，这些都为后续的版本计划安排和任务下达奠定了基础。

而对于需求的管理，里面谈到的比较粗，对于需求的追踪，需求的变更管理，需求的发布计划，需求的验证等都应该属于需求管理的范畴。只是在敏捷开发过程中的需求管理，更加强调围绕用户故事形成一条线的端到端管理，并实现价值交付的目标。

2.敏捷过程管理（价值流，仪式活动）

敏捷过程管理是产品经理，研发团队以及与产品相关的干系人围绕业务价值交付进行的软件研发过程，包括价值流和仪式活动两个部分，要求上述人员建立以尽早和持续的交付价值的软件为目标，通过高效的沟通方式，高效的可视化工作流，有效的度量和快速反馈机制，实现软件研发业务价值最大化。

价值流：将软件产品转化为业务价值的能力，包括按照用户地图按需交付可用的软件，同时包括了交付质量管理，交付度量，和持续的价值流跟踪。也就是说这里面入口是用户故事地图，然后是可视化的交付全流程的跟踪和反馈，其次是在整个过程中还需要围绕价值交付建立有效的度量和评估机制。

仪式活动：通过建立价值流动的管控机制，可视化的管理价值流程，控制流动节奏，不断提升价值交付效率。包括各类计划会议，评审会议等。这个可以进一步参考敏捷过程管理中的一些最佳实践。

简单来说敏捷过程管理核心是可视化，管控机制，度量机制，高效的协同和反馈机制建立。所有的这些机制建立都又是围绕价值交付服务。

3.敏捷组织模式（敏捷角色，团队结构）

敏捷组织模式是指团队在研发过程中的角色定义，角色能力以及之间的协作，团队结构的工作方式，团队间的协作模式等方面的要求，主要从敏捷角色和团队结构两个方面进行定义。

敏捷角色：指产品经理，敏捷教练和团队之间的职责分工，能力提升和协助方式，角色都能够以价值交付为目标，持续的提升交付效率。我们来看下敏捷教练定义：

参考：[  /pmd/793824.html]pmd/793824.html[/url]

敏捷教练在深刻的理解敏捷的价值观的基础上，同时需要具备丰富的敏捷技术实践经验，以及拥有基于团队的实际情况采用合适的敏捷实践的能力。这里面实际包括了需求分析和拆分，用户故事地图，需求影响分析，故事点故事，需求优先级评估，迭代计划安排等一系列的敏捷实践。

产品经理是对产品的ROI负责，负责梳理产品需求，规划产品功能列表，确定优先级，参与规划活动，并验证最终的交付成功。对于scrum里面强调的product owner更加强调面向市场和客户，只是参与而不是具体去执行敏捷开发过程中的具体事务类活动。

敏捷教练重点是引导团队进行敏捷转型，驱动敏捷实践的运转。可以全职，也可以兼职。

团队结构：团队结构在研发过程中以最小化的功能团队，以共同的价值观，通过可视化的方式，紧密合作，实现业务价值的快速交付。团队足够小，其各个团队相互独立，能够独自完成交付。


对于团队架构，实际上在devops过程实践里面本身是对团队结构有要求的，而这个在传统的敏捷方法论里面是不涉及的。比如我们经常谈到如果拆分为两个独立的微服务模块，那么两个模块涉及到的前端开发，设计，数据库人员完全是分离的，能够实现独立管理和协同。