今天不谈DevOps的开源技术工具链，而是从敏捷开发和研发过程效能改进的角度再来回顾下DevOps研发运维一体化和研发效能改进。

在前面我专门写过一篇文章，里面有个核心观点，即：

不要期望通过DevOps各种工具链技术来解决研发效能和过程管理中存在的问题，研发效能提升有一个核心还是软件工程域和过程管理最佳实践。

敏捷和精益各在强调什么？

大家对敏捷方法论都比较熟悉，特别是当前主流的Scrum敏捷研发方法论。而敏捷方法论的核心如果用一个词就是短周期迭代。

为了短周期迭代，你必须将大块的用户需求输入进行拆解为条目化的UserStory，为了确保迭代版本可交付，你需要持续集成，可视化进度看板等。通过短周期迭代，你具备了一个关键的敏捷能力，即快速地适应变化和自我调整能力。

敏捷得快，一个是响应变化快，一个是自身的生产加工过程也快，效率高。所以你看到在软件研发过程中各种自动化工具的引入，自动化的流水线，持续集成等实际都是提升这个效率服务。

再回来看精益，精益的一个核心是减少浪费。

而软件开发过程中的浪费实际体现在几个方面。

其一是减少任何不必要的输出工件，所有的工件输出本身都要有价值，不要为了输入而输出，为了文档而文档。要提倡源代码就是文档。

其二是减少返工，所有的返工，不论是需求变更引起的，还是Bug修改等，都是COPQ坏质量成本，都是对资源的极大浪费，同时又拉长了交付周期。

其三是减少人员等待，任何一个研发项目和研发过程，如果你在整体计划和任务分解中，导致出现了大量的人员闲置和等待，那么本身就是一种巨大的浪费。

对于第三点减少人员等待或闲置本身是一个技术活，考验的是项目经理或架构师的任务分解能力，如何通过恰当的角色分工和任务分解，能够让所有的人员并行工作，并减少相互之间的依赖。

推式生产和拉式生产，流水线和看板

在谈敏捷和精益生产的时候，经常会谈到看板文化，基于用户和市场需求的拉式生产模式。看板解决了一个关键的可视化和进度跟踪问题。而拉式生产模式解决了零库存和减少浪费的问题。

回到敏捷研发和看板，也是同样的道理。

敏捷团队中的每一个人实际都应该时刻知道我有哪些todo list，我需要做的就是将我待办的任务按规范和质量要求尽快做完，并快速地朝下游传递。比如一个开发人员应该随时能够看到自己的待办清单。有哪些功能点要开发，有哪些Bug要修改等。

对每个角色都是，我只需要关注我的todo，并尽快完成。

任何一个任务在上游角色完成相关工作后，通过流水线都能够做到自动化地推送到下游活动节点。这个节点可以是自动化机器节点，也可以是需要人工进入处理的工作节点。

流水线起到的关键作用就是基于上下游的任务活动协同关键，将多个任务编排为一个完整的整体，并做到自动化或半自动化执行，同时随时可以监控其进度和状态。

那么流水线的效率体现在哪里？

流水线的效率不仅仅体现在自动化的程度，而是体现在流水线运行过程中各种闲置或等待时间的多少。比如一个开发过程流水线，到了开发阶段后开发人员始终都无事可做而处于等待状态，那么流水线效率就不可能高效。

所以再回顾下DevOps流水线。

代码Checkin-》编译-》构建-》打包部署-》环境迁移

这个并不是一个完整的开发过程流水线，因为这个流水线并没有体现需求人员，开发人员，测试人员的任务和活动。

完整的研发流水线一定是自动化+人工参与结合的一个大流水线。实现从用户需求进来，到最终完成IT应用的功能交付的完整过程。

这里面不是简单地持续集成，重点是架构，开发，测试，工程运维人员之间的高效协同，同时在协同过程中如何建设依赖。

从条目化需求到文档结构化

在Scrum敏捷方法论里面，条目化始终是一个重点强调的内容。

条目化本身就意味着更好的结构化。

敏捷方法论过程改进，最好的思路就是所有文档都要结构化和条目化掉，而不是再去输出冗长非结构化的word文档。

我们都知道在软件开发中的需求文档往往是Word形式的非结构化内容，一个需求文档往往会实现多个用户需求并分解为多个用例，由于没有结构化我们管理和变更的单元都将是以一份文档为准。而现在结构化的文档开发工具可以使文档开发工作结构化，通过结构化后可以对文档的管理颗粒度粒度从一个Word文件喜欢到一个具体的用例或用户故事，而这不仅仅是带来了版本控制和多人文档协作的方便，更重要的是文档开发过程的一个重要变更。

在软件开发中需求的端到端管理中，我们对用户需求，产品需求，软件需求都可以拆分为条目化管理，并且实现条目化需求的状态跟踪和需求追踪。通过需求追踪保证需求实现的完整性，方便跟踪需求实现状态，同时为后续的需求变更分析提供有利的影响范围识别。

需求可以条目化，测试用例也可以条目化，比较困难的就是设计内容如何进行条目化管理。架构设计的内容放到哪个层次和级别。在微软的SCRUM实践里面我们也看到了通过UserStory驱动的需求跟踪和管理。为了方便条目化我们又可以解决FDD里面的最佳实践通过领域模型分析找出具体的特征点，而特征点就是一个细粒度的可以从需求一直管理到测试的最小单位。我们的实现过程追踪，状态跟踪，版本管理和控制都可以以这个为单位进行管理。这样在我们实现的过程中，在关心某一个具体的功能点的时候很容易的就能够获取到有关该功能点从头到尾的全部信息，包括每次变更的相关信息也可以很容易获取到。

当我们向客户按阶段交付文档的时候如何处理呢？这个其实在结构化文档开发工具里面已经有了，即可以根据我们的不同配置规则，根据预定的文档生成格式，自动的抽取相应的内容来生成出我们需要的文档。可以看到在整个过程中我们不会再去专门强调文档这个概念，而是更加强调业务功能和用例，特征值和需求管理和跟踪的概念，文档仅仅是我们在各个阶段思考过程的一种记录后的整合，我们随时的思考和实现思路都应该随时的记录，而不是到后面再来补文档。

我们可以看到，现在一些SCRUM的敏捷项目管理工具已经具备了结构化的UserStory管理和跟踪的能力，而这正是结构化文档开发的一个雏形。

即不再依赖word去输出需求文档，而是应该直接在敏捷研发和过程管理工具中编写每一个userStory，对其业务场景，流程，规则，界面UI等进行详细说明。当然从一个大IT系统构建的整体性层面，我们仍然会保留少量的整体业务流程，整体架构方面的介绍。

那么如果最终需要向客户交付完整的需求文档如何办？

简单来说应该是我们选择需要交付的模块和功能点，然后通过勾选的内容自动化的生成最终的word文档。也就是最终交付的文档应该是通过配置的方式动态生成的。

从产品结构，WBS分解到任务活动

我们可以回顾下一个微服务架构下前后端分离开发模式，任何一个需求点过了，实际都可以分解为如下几个任务。

• 需求和原型开发
• 前端开发
• 后端开发和数据库设计
• 测试设计
• 测试执行

如果你是用的传统开发模式，那么可能分解为如下几个任务：

• 需求开发和文档编写
• 功能设计和数据库设计
• 编码和自测
• 测试设计
• 测试执行

什么意思呢？

对于一个条目化的需求自然会对应到相应的需求开发，设计，编码和测试等任务。对于PBS产品结构分解处理的最底层的模块或单元结合WBS模板都会产生这些WBS条目。

这就是一个简单的交叉相乘的过程。

1. 对于总体设计任务不需要根据具体的模块和单元进行分解。
2. 对于集成测试任务如何来产生的问题

解决了以上两个问题，基本上就可以自动生成相应的WBS。而且我们还可以根据过程定义和裁剪来选择哪些条目应该生成，哪些不应该生成。比如可以裁剪掉单元测试，则就不自动生成相应的单元测试任务。基于以上考虑可以参考下图的例子，左边为WBS模板，右边为一个简单的PBS分解。

其中PBS中黄色的为最底层的模块或单元，都需要和左边的WBS模板相乘得到相应的WBS条目。对于集成测试任务的生成，可以看到满足存在叶子节点，且叶子节点大于1个的都需要生成集成测试任务。因此根据该方式可以生成如下实际的WBS分解

同时在生成的过程中我们还可以建立根据生命周期模型建立WBS条目任务之间的关联和依赖关系，设置每各WBS条目的类型。模板化每个条目和任务的输出格式，责任人等内容。

在实现了这一个步骤后，我们接着可以考虑的问题就是受岗位角色分工和资源约束限制条件下的自动排程。在供应链管理中我们可以通过建立模型和目标约束来实现最优的排程，在软件项目进度计划的编制中应该同样是可以的，这种方式将通过约束理论，目标规划和计算机模型来选择可行的进度方案。而不是根据简单的根据关键路径和资源平衡来制定进度。

以上自动生成规则并不复杂，但是当前的各类Scrum敏捷项目管理工具往往并不支持这种自动化生成规则。