DevOps平台规划随笔

2018/8/23

今天围绕着项目管理，和几个参与规划的同学主要讨论了2个业务对象
1 什么是一个项目？
形成的一个一致意见是说和年度规划中申报的项目保持一致。例如，占了年度工作量超过60%业务系统改造可以理解为是一个项目，而且是跨部门的项目。新系统建设类的项目，也可以是单独一个项目。
2 迭代sprint的概念？
这部分讨论比较激烈，在我不断的引导下，终于大家意识到了在目前这种模式下，可能把sprint迭代这个时间盒固定名称，固定节奏可能是一种比较好的方式，参考SAFe，解决了目前当不同团队、不同部门、项目组之间讨论各自的迭代时，可能名字，起止时间都不相同的问题。一致性消除了上述沟通上的转换，可以降低沟通成本。更好的是，产品、开发、测试、运维在安排各自任务时，可以使用同一个时间盒。组织层面上的管理和沟通可能就更容易了。

2018/8/25 关于迭代和交付节奏

统一迭代节奏的事情基本达成共识了。

微信图片_20180825140533.jpg

交付模式

按照这个模式，结合我们目前的月度版本发布模式，梳理了一下我们的交付节奏，如下图:

微信图片_20180825140520.jpg

1. 按照需求、开发、测试、部署每项工作各2周的节奏完成一批次需求的交付
2. 为了能够赶上每月发布一次的交付节奏，每个迭代中其实运转着两批次的交付物。如第10/11周这个迭代中，M10正在测试，而M11则开始了需求设计的工作。而12/13周这个迭代中，M10/M11则完成了部署和开发的工作。

对比下敏捷的理想状态(见下图中的"这是一个跨职能迭代，称模式3"），其实这是一次交付中的瀑布（见下图中的"这是一个迭代间的瀑布，称模式1")

微信图片_20180825140545.jpg

（参考 《SAFe4.0精粹》）

基于现状的思考：

1）要不要从“模式1”->"模式3" ？
要，也不要。 要，说的是这是这个组织效能改进的目标。
不要，是说现在不要，或者18/19年不要。
2）那现在要什么呢？
运维团队最近提出，由于版本质量时常出问题，要不要考虑不是1个月上线一次，而是2个月上线一次，即取消M10/M11并行部分，完全串行工作。
测试同学说，现在我们要2周测试，但是开发经常不能按时交付可测试的版本，由于系统间依赖，也没有时间做系统集成测试，这样就容易把缺陷遗漏运维团队。而且更没有时间做自动化了。
开发同学说，需求都不确定，我开发时间也被挤占了。早开始开发又由于需求变化容易重做。

2018/8/26 与业界大牛梳理问题

找了2位业界大牛（网易/京东），请教了一下推进思路。

案例背景：

1）合同
目前服务母公司的部分按照年度服务合同收取总费用，与一般甲乙方按照项目或者工作量单价收费方式不同，基本属于一个全包的状态。
2）目标
对技术子公司的最低目标是，不要成为业务创新和发展中拖后腿的，因为技术系统准备未就绪，导致某些业务延期开展。 所以目前的目标是提高业务交付的速率。
3）发布模式：
我们把系统开发任务划分为 常规业务系统改造和 大型专项进行管理。常规业务系统改造从去年末开始，从以前的每个季度发布上线一次到现在每月上线一次。

现状

1）发布管理
跨部门的发布管理上，目前就约定了每月上线的几个时间点，如上线时间、版本发布/评审时间，测试完成时间等等。也就是只管结束，不管开始。
2）需求：
每次发布接收哪些需求，由各个开发部门自行决定。发布时间为1个月，中间的所谓子迭代的时间，各部门也各不相同。需求/任务的管理方式和系统使用方式，也各不相同。
3）组织架构
开发（若干个部门）/测试1/运维/1/安全1 属于职能型划分。
4）devops系统：
目前由测试和运维牵头促进开发测试一体化，建设devops平台。平台已经有部分成功，主要是从代码提交到（跨部门)版本合并以及部署上线。目前准备从头开始梳理价值流，从项目管理/需求管理开始，目标是形成一个大家可以统一的流程和方法，可以落地到系统中。

问题:

目前的发现
1）大家都在号称玩敏捷， 但是玩法都不一样，且各玩各的
2）开发/测试都在喊时间来不及，运维说版本质量不好
3）业务部门需求经常变化
4）多条交付流水线并行(常规版本， hotfix , 大型专项），高优先级需求加塞以后，可能影响常规版本交付
5）度量数据的收集，现在靠手工完成，收集人员要求爷爷告奶奶让大家来填写 ，正确性也较差。

关于工具：

JIRA是最主要的，包括了版本申请，需求，任务，缺陷等等。测试我们在用excel管理进度。特点是只管创建，很少去更新状态，另外刚才刚才说过的问题，部门间玩法不统一。
譬如某些部门是整个部门所有开发任务都在一个Jira项目，而有的部门是一个产品一个Jira项目。
所以想把各家套路统一。不然同一个系统 在各JIRA 项目中的名称可能都不相同，更别说版本号了。

在考虑1）统一迭代节奏（包括所有交付流水线的） 2）统一需求管理/任务管理方法 3）在团队日常任务的看板之外，建设一次交付的进度看板(类似我上的横道图)，系统的看板(用户故事地图)

大牛点评：

1)前面梳理得挺好啊，第一步可以试一试
2）数据收集要靠工具，不能人工填写，否则肯定会，受到抵制。
3）尽量避免瀑布迭代，走模式三是正确的道路。
4）通过safe，把多个团队对齐是非常必要的。
5）（模式三现在的组织能力还达不到的情况下），先做4)，再提升自动化水平。
6）分析下整个价值流，看看哪些地方是非必要的环节，削减一下，可以加快些速度。

总结：

各方目前的诉求不是更快，而是在（月度发布)这个节奏下把质量搞上去，让生活质量更好。

参考小岗村，交足国家的(2周完成各自的迭代内工作)，剩下的都归自己(提效成果用于改善生活)。

2018/8/27 开发部门负责人的反馈

上班之后，通过邮件把迭代图和相关人员进行了沟通。有开发负责人回复说，他们的开发进度要快于图中的节奏，可以提前交付版本给测试人员进行测试。我回复说，这个方案只是底线，如果开发能提前，测试人员也会提前跟进进行测试，提高效率。

2018/8/28 规划启动会

今天，开发、测试、运维各部门的负责人和devops平台规划小组的成员一起召开了项目启动会，准备利用三周的时间，完成devops平台规划，在前期调研的基础上，通过问题和现状梳理、形成规划任务以及后续的工作路线图。

2018/9/20 宣讲会

今天就部门研发的devops平台在公司内部进行了宣讲。目前主要完成了代码提交到版本发布这段的系统建设和项目落地，公司大约一半的系统已经在这个平台上抛了。