最近一段时间在客户处遇到了很多同样的问题，首先DevOps的落地建设是一个长链条的实践，它不同于单纯的工具引入，而是一个完整体系的落地，而作为整个闭环体系的入口，如何从需求维度就能提高效率就成为了很多企业的关注点，而作为传统企业往数字化转型阶段，很多企业还是以传统开发模式为主，那如何开展敏捷开发及后续支撑规模化敏捷，此文希望能给大家带来点思考。

先后说了十多年，为什么有敏捷

敏捷，最初作为舶来品，在漂洋过海之前，就已经被互联网背景的企业玩“花”了，最初，它体现的只是一种价值观及简单的规则，并没有对工作的切实指导以及面向具体行业业务的解决方案。

那么按照敏捷的价值观体系，我们传统企业在引入工具和流程之前，另一个需要考虑的就是我们现在的“人”是怎么样的？在工作中他们有哪些互动，这些互动的结果是怎么输出的？哪些地方是企业或行业中规定的必须遵照的标准流程？

这些清楚过后，再结合一套工具的话，才能够有效提升工作效率，所以说流程、工具都是为了支撑人员的工作，而不是单纯的引入一套流程、工具，人员围绕工具转。

有了上述的基础，我们就可以开始看实际的问题，例如我们可能经常无法按期按期交付业务侧提出的需求、无法按期交付项目中的软件，导致这些情况发生的因素有很多，而我们首要思考的是将问题统一提出，划分主次，定义时间交付节点，所有的出发点都是解决问题而不是找出问题后丢给其他人一个个解决。

所以聪明的你已经发现了，这里面很自然的就体现出一个团队的概念，所有的事情都是围绕一个团队来做，团队中可以有各种角色，但是事情是大家共同的事，不是个人的。

小结一下，“敏捷”并不是一个完整、全面的流程，而是一种方式，用于引导出新流程，改进传统流程的思考方式，它并不是在所有情况下都具备优势，而是要结合用户的实际情况来比较。

我们怎么样做才叫敏捷

1.敏捷开发模型

目前敏捷越发被传统企业所接受，在软件开发领域，很多情况下大家将敏捷作为一个优先考虑的事情，目前根据最初的敏捷方式，划分的团队基本在十人以内，此数量级的项目组沟通起来最为方便并且人员分工也较为完整，在此基础上，常规的结构方式如下：

整体交付周期包括以上四个部分：

• 第一部分需求池，所有的需求最初可以统一提到这里，需求会有优先级的概念。
  

• 第二部分软需，需求池中拆分后的技术任务，可以是多次拆分，例如需求分析、UI、研发、测试等，包括软件开发周期中的所有工作任务。
  

• 第三部分两个圈，大圈为我们常说的迭代周期，理论上建议是2-4周，小圈称为站立会，主要是每天统计整体的进度情况及困难点等。
  

• 第四部分即最终的交付产物，如软件、APP、甚至只是一个明确板块功能都可以。
  

用户角色：

• PO：产品经理或需求分析岗，主要接受各干系人提出的需求，将用户描述转化为具体的业务需求。

• 敏捷教练：一个敏捷团队的负责人，工作类似于一个整体项目的项目经理，需要理解业务需求，保证项目的整体按时交付。
  

• 团队：包括完成一个特定功能或迭代的所有成员，设计、开发、测试、运维等。
  

2.落地经验

结合蓝鲸DevOps平台——敏捷协同板块能力来看，如何支撑实现业务敏捷，首先我们可以将项目划分两种体量来看，大型项目和普通项目。

大型项目

大型项目常见可以定义为两种，第一种企业战略级项目，一个战略级项目需求往往会牵涉到多个子项目，第二种产品线复杂，一个完整的产品或业务往往由多个子业务线组成，并且他们互相之间可能存在一定的依赖关系。

蓝鲸平台中对于大型项目主要通过项目集能力进行管理，从项目集维度接收来自各个维度的业务需求，需求在项目集维度可以继续细分，如果产品组或战略本身具备多层级，项目集本身也支持与子项目集进行层级关联。这里关系的划分更多线下先对业务需求和产品层级进行讨论，完毕后落入到项目集中。

项目集的主要作用是业需侧的统一记录并对齐多项目的里程碑及发布时间，因此项目集中拆分后的最小颗粒度需求，可以直接同步到敏捷管理中的协同管理板块，作为板块的输出记录下来。

普通项目

项目维度的管理支持传统、敏捷或混合方式，本次主要讨论敏捷方式的支撑。

敏捷协同部分的输入可以有两个来源，一种是直接通过项目集同步过来，进入平台后就作为最大的一个层级（EPIC俗称故事集），另一种方式是直接通过新建的方式记录需求，作为满足用户开箱即用的需求，平台中预设了常用的工作项。

用户需求的记录按照颗粒度可以直接记录于Epic或故事中，在常用的敏捷开发流程中，故事依然属于业务维度的需求，需要由产品或需求拆分人员进一步拆分为技术需求记录于任务环节，任务进一步拆分为具体工作项中的子任务，由具体人员进行执行。

用户需求的记录按照颗粒度可以直接记录于Epic或故事中，在常用的敏捷开发流程中，故事依然属于业务维度的需求，需要由产品或需求拆分人员进一步拆分为技术需求记录于任务环节，任务进一步拆分为具体工作项中的子任务，由具体人员进行执行。

3.需求与CI、CD的联动

通过流程加平台能力的方式支撑敏捷开发中的需求管理后，在整个DevOps中又可以扮演哪些角色呢，这里可以提供一些思路参考。

首先我们有一点是可以明确的，需求及任务主要是看整体的进度，而落实到具体工作中，往期都是相对不透明的，那么我们怎样才能从业务角度看到研发流程的完整流转情况和问题呢，蓝鲸给出了两种解决方式：

第一种：需求支持与代码、流水线、测试用例做关联，这样我们可以做到通过需求查看哪个分支是匹配这一块能力的，也可以看到相应需求下流水线执行情况及测试用例准备及执行的情况。

第二种：提供需求部分的研发商店，由于蓝鲸平台天然的底层数据贯通，我们可以便捷的开发响应的插件能力，将需求侧的数据与后续想要关联的部分进行打通，形成企业特有的一种管理模式。

总结

在DevOps中如何辅助企业用好敏捷乃至规模化敏捷，绝不是纯粹依靠拿来主义。真正想要达到完整体系的落地一定是需要量体裁衣，可通过轻量的咨询服务结合企业组织现状、人员能力等方面，逐步形成特色化的敏捷模式。

而如何匹配特色化的敏捷模式，这对于工具平台开放性及扩展能力就要有很高的要求，应当即具备开箱即用的最小化板块，亦能很便捷的扩展能力。

以上要求与PaaS化思想不谋而合，通过“能力”与“服务”的解耦不仅能够满足特色化企业级平台的落地要求，更多的是支撑企业对未来使用场景无限遐想。