我们的最终目标是打造“ALL IN IDE”的研发体验，业务研发团队应该对于整个流程无感知，需要知道的细节越少越好 。
1. 前言
自下而上地进行DevOps推进，除了一步一个坎的糟糕体验外，最大的一个难点就是共识的形成。
组织结构上缺乏行政力量的支持、团队里人员能力和意识的缺失、自身多职责兼任等诸多原因，造成实际推进过程中，DevOps进度属于你推一步，它往前走一步；你稍微没留神，又退回来半步。在这种反反复复的拉锯中，不少人因此心灰意冷。
本文秉承"晓之以理，不如诱之以利"的思想准则，给研发团队画一张"饼"，以寄希望于在未来的推进之路上，少一些阻碍，多一些支持。
2. 角色分工
在DevOps推进这一条改良路线上，我们推荐使用”外科手术队伍“的团队协作模式。
《人月神话》里建议了一种组织方式，叫“外科手术式的队伍”。就像一台外科手术一样，有一个主刀大夫，软件项目也应该有一个首席程序员，其他人都是给他提供支持的。这样，就既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
| 角色 | 人数 | 职责 |
|---|---|---|
| 主导推动者 | 1-2人 | a) 设计整个流程。 b) 搭建最基础的实现 —— 实现整个流程的起步运行。 c) 初期需要落在实际的业务研发小组，将流程真正推动起来，并在小组内物色并培养起接手人员。 d) 实践中不断积累，优化，维护迭代整个流程。 e) 培训、宣讲、推广整套流程。 |
| 核心骨干 | 主观意愿优先 | a) 掌握整个devops流程的实现，能够解决90%以上的扩展需求。 b) 向上反馈实际推进devops过程收集到的问题，以及对应的解决方案。 c) 向下回答业务研发团队对于devops流程的疑问。 d) 根据业务团队的自定义需求，提供相应解决方案。 e) 宣传、推广整套流程。 |
| 小组长(业务研发团队) | a) 知晓devops流程中的相关扩展点和实现方式。能够借助这些扩展点来实现自己项目的自定义需求。 b) 向上反应devops流程中的问题。 |
|
| 组员(业务研发团队) | a) 知晓规定的devops操作流程中的基本人工操作，并熟练使用。例如：GIT提交日志中所支持的关键字。制品下载地址链接地址，目录结构。 b) 其它各类终端用户所需要知晓的信息。 |
3. 最终目标
我们的最终目标是打造“ALL IN ONE”（一个IDE下解决所有问题）的研发体验，业务研发团队应该对于整个流程无感知，需要知道的细节越少越好 ，他们就不该知道：
- 制品是由什么工具编译打包出来的？
- 整个流程是由什么工具推动的？
- …？
业务研发团队(尤其是一线业务研发人员)需要做的事情：
- 理解需求，将需要转换为代码，
- 根据流程或测试人员的反馈修复代码。
- 按照要求的格式提交代码。
- 没了。