一张图带你了解“持续交付”和“DevOps”的前世今生(2)

在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”.在这个模型中,包含如下六个维度：

• 构建管理和持续集成
• 环境与部署
• 发布管理和和符合性
• 测试
• 数据管理
• 配置管理

通过实际工作的验证,我发现,这里面缺失了一些东西.所以,增加了一些维度,并重组了一下,如下图所示：

我也没有称其为成熟度模型,而是“持续交付七巧板”.

是的,中国的传统玩具“七巧板”,这个儿时的玩具可以拼出各种各样的图形.也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形).

找正确的问题去解决

上面的诸多概念并不是你的问题或目标,而只是你的工具(手段).千万不要把手段当成你的目标来实现.很多人问：

• 怎么做持续交付?
• 怎么做持续集成?
• 怎么做敏捷?
• 怎么做DevOps?

我猜测你是想问：是否有捷径做XXX.当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种“捷径”.

• 我们做的是敏捷吗?
• 我们这么做持续交付,对吗?

我猜测你是想问：(某个人或部门)这么搞,是不是靠谱啊?

• 你这不是敏捷?
• 你这不是DevOps?
• 你这不是持续交付?
• 你这不是持续集成?

我想说：无所谓,因为我的在微信上的签名是：别提概念,只解决问题.我们还是先讨论清楚问题吧～

再炒一炒冷饭

2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思：

1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧.或者没有看到他想找的内容.

2. 标题党啊
好吧,我承认在那个很少有人提及“DevOps”的年代,我就做标题党吧.

这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要.

一、了解环境背景

当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围.

几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念).一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难. 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队.

团队间接管理者

• 项目交付不太可控：
  • 我们一直在做计划,但计划性非常差.
  • 经常有各种各样的情况发生,总会让项目改期.

团队直接管理者

• 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到.
• 这个项目中,有一部份需求必须在XXX时间点完成.

团队Lead

• 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字).
• 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作.

开发人员

• 领导说试一下,就试一下吧.

测试人员

• 工作经常被打断.
• 提测质量不高,经常浪费精力.
• 出了Bug,影响太大.
• (这里省略一千字).

二、找到正确的问题来解决(目标)

三个月内：

(１)该项目交付时间可预期.

(２)建立新的软件开发协作方式.

(３)建立必要的基础设施,以支持后续的持续发布模式.

三个月后：

(１)需求的周期时间缩短,可以短周期上线.

(２)生产环境的质量不降低.

(３)测试人力总投入降低.

在少于30人的团队(61个人也可以～哈哈～那62个人呢～～～)

1. 通常行为的改变,需要一个半月的时间；
2. 带来强烈可感知的收益需要三个月的时间.

三、承诺是必须的

上面的问题(目标)找到了,也要一并承诺.

要想让团队和你走,你必须站在前面.

四、培训及过程指导

需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认.

启蒙培训(1小时)

对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙.

重新定义工作流程

• 新的项目工作流程
• 新的迭代工作流程
• 新的需求工作流程

• 新的代码工作流程

解决新流程中的障碍

• 团队沟通和协作的方式.
• 编译环境的准备.
• 编译时间的缩短.
• 自动化测试策略的制定,比如：我们放弃了原教旨主义的单元测试.

（编辑：ASP站长网）