标签：没有 精益 互联网公司 地址 迭代 工作方法 自己 share awd
作者/分享人：乔梁，20年IT老兵，腾讯公司高级管理顾问，敏捷和精益开发专家，持续交付领域先行者。曾就职于百度，国内多个知名互联网公司的企业教练。 历年QCon技术大会的讲师和专题出品人。
这是一个新概念风起云勇的时代。 就让我们从云端抓它几个名词下来，一起玩耍吧！！！ “敏捷软件开发”，“增长黑客”，“持续集成”，“DevOps”，“精益创业”，“持续交付”，“大数据”... ...
OK，就这四个啦：
“敏捷软件开发”，“持续集成”，“DevOps”，“持续交付”。
先让我们在Wikipedia上验明正身。
敏捷软件开发
Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.
持续集成
Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.
持续交付
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.
DevOps
DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.
从来就没有一种方法，叫做“敏捷软件开发方法”。因为，IT行业中的“敏捷（Agile）”一词，从2001年它的诞生之日起，就是个软件开发方法集合，当时这个集合中的方法，都遵从敏捷宣言和相同的工作原则（十二原则），它的缔造者是十七位软件工程师（请查敏捷，雪鸟会议）。目前，在这面大旗下，又增加了很多种方法，当然也有很多方法走出了人们的视线。
在国内比较活跃的几种方法：极限编程XP（2009年以前），Scrum及其进化品（2006年至今），精益软件开发方法（2009年至今），看板方法（2012年至今）。当然，现在好象也不再特意强调“敏捷宣言”和“十二原则”了，只在培训课堂上还能听到。
早在1999年KentBack的《解析极限编程》一书中，对“持续集成”这一概念就有提及，它是极限编程XP方法中的十二最佳实践之一。在2004年，Martin Fowler发表的一篇博文上，给“持续集成”下了一个定义，并一直沿用至今。即：“持续集成是一个软件开发实践， 是指团队成员频繁地集成他们的工作成果，通常每天每个人至少集成一次， 这样在团队内每天都会有多次代码集成，每次集成都有通过自动化的构建（包括测试）尽可能快地发现集成问题。” 这个概念已被软件研发团队广泛接受，但是其中提到做法，并未能全部落实，太困难了。 这是正常的，来自极限编程方法的实践，都是有挑战的，否则就不叫“极限”二字了。
在2008年的一次敏捷大会上，运维相关人员就“敏捷基础设施（Agile Infrastructure）”展开讨论，并在2009年以后逐步发展成为一场大规模“运动”，它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作，同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展，也让DevOps多了一些发力点。
Jez Humble和David Farley在2010年《持续交付》一书中正式提出这个概念，它在书中被定义为：一系列的原则与实践的集合；通过这个集合，团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为，持续交付有三个支柱，它们分别是持续集成、自动化测试和部署流水线（Deployment Pipeline）。
根据以上的信息，我认为它们在空间和时间维度的关系是这样的：
上面这个图是从实践或环境的角度来看它们之间的关系。那么，如果我们换一个角度呢？
我的微信签名是“别提概念，只解决问题！”。所以我更愿意从解决问题的角度看这些概念。一谈到问题，就有一个经典的话浮现在我脑海里：“所有的问题，都是人的问题”。所以，这个角度看到的才是本质。那么，它们的关系是什么呢？
持续集成，有助于打破开发人员和测试人员之间的“墙”。
敏捷开发，有助于打破研发团队（开发+测试）与业务（产品）人员之间的“墙”。
DevOps，有助于打破开发团队与运维团队之间的“墙”。
持续交付，则是希望从端到端的角度，考虑如何解决问题。
在我多年的持续交付践行及咨询工作中，总结的经验是：如果希望在最短的时间和成本内，取得最大的收获，那么在一开始，与“人”相比，技术实践并不需要太在意，即：最好还是先从“人”的角度看问题。真正去解决问题时，上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具，而且其中的每一个工具（概念）都包含了很多个小工具（原则和实践）。而且，在解决问题时，你也不必整套选择这些工具。
从参与者的问题陈述中找问题。比如：
老板：
“项目经常延期” “做东西太慢”
产品：
“老板的想法总变”
“事情太多，忙成狗”
“开发说这个实现不了”
开发：
“需求总变”
“UI方案给的太晚”
“活儿太多”
测试：
“需求变了没提前通知”
“测试时间总被压缩，还要背锅”
“重复测试太多遍”
运维：
“每天这么多版本上线，活干不完，出事儿第一个背锅。”
每句话的背后都有很多含义。开挖吧～～
提问题的人是问题的创造者，也是接盘侠～
在《持续交付》一书的第十五章，提到一个“持续交付成熟度评估模型”。在这个模型中，包含如下六个维度：
构建管理和持续集成
环境与部署
发布管理和和符合性
测试
数据管理
配置管理
通过实际工作的验证，我发现，这里面缺失了一些东西。所以，增加了一些维度，并重组了一下，如下图所示：
我也没有称其为成熟度模型，而是“持续交付七巧板”。
是的，中国的传统玩具“七巧板”，这个儿时的玩具可以拼出各种各样的图形。也就是说，每个团队、企业都有不同的环境上下文（人也是环境的一部分），解决方案也不必一样，关键是你想解决什么（想拼成什么图形）。
上面的诸多概念并不是你的问题或目标，而只是你的工具（手段）。千万不要把手段当成你的目标来实现。很多人问：
怎么做持续交付？
怎么做持续集成？
怎么做敏捷？
怎么做DevOps？
我猜测你是想问：是否有捷径做XXX。当然有，多种途径里，一定有相对来说的捷径，但不一定是你期望的那种“捷径”。
我们做的是敏捷吗？
我们这么做持续交付，对吗？
我猜测你是想问：（某个人或部门）这么搞，是不是靠谱啊？
你这不是敏捷？
你这不是DevOps？
你这不是持续交付？
你这不是持续集成？
我想说：无所谓，因为我的在微信上的签名是：别提概念，只解决问题。我们还是先讨论清楚问题吧～
2011年，我在InfoQ上发表了一篇案例文章《DevOps，不是一个传说！》，其中有两个评论比较有意思：
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化？
正如我们上面第二张图所示，这个项目的前期工作，的确主要是在敏捷开发的范畴，但文中还是提到一小部分Ops方面的东西，可能评论者没有注意到吧。或者没有看到他想找的内容。2. 标题党啊
好吧，我承认在那个很少有人提及“DevOps”的年代，我就做标题党吧。
这个案例就混合了上面所有的概念，但在项目里，谁还在意概念呢，达成结果最重要。
当任何人想要对组织进行改变时（无论改变的大小，你叫它改进、转型或者变革都可以），一定先要了解组织的历史，感受组织的文化，因为组织的历史决定了问题的来源，定义了问题的范围。
几年前的百度，工程管理相对固化，敏捷还在“小步快跑，越变越美”的倡导期（从瀑布到迭代，强调项目管理中的迭代概念）。一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发（Single Branch mode）”，但由于原有的基因特别强大，进展艰难。 而这个项目是在最有百度特质的大搜索团队，试验田是一个10人左右的工程架构团队。
团队间接管理者
项目交付不太可控：
我们一直在做计划，但计划性非常差。
经常有各种各样的情况发生，总会让项目改期。
团队直接管理者
我非常希望能够快速交付，但我们对这类架构变动类的项目不知道怎么能做到。
这个项目中，有一部份需求必须在XXX时间点完成。
团队Lead
估算不准确、临时插入事情多、项目计划很难做（这里省略一千字）。
我不知道怎么改进，因为我周围的团队也是这样，而且一直这样工作。
开发人员
领导说试一下，就试一下吧。
测试人员
工作经常被打断。
提测质量不高，经常浪费精力。
出了Bug，影响太大。
（这里省略一千字）。
三个月内：
（１）该项目交付时间可预期。
（２）建立新的软件开发协作方式。
（３）建立必要的基础设施，以支持后续的持续发布模式。
三个月后：
（１）需求的周期时间缩短，可以短周期上线。
（２）生产环境的质量不降低。
（３）测试人力总投入降低。
在少于30人的团队（61个人也可以～哈哈～那62个人呢～～～）
通常行为的改变，需要一个半月的时间；
带来强烈可感知的收益需要三个月的时间。
上面的问题（目标）找到了，也要一并承诺。
要想让团队和你走，你必须站在前面。
需要解决团队提出的任何疑问，如果当时不知道如何解决，也要承认。
启蒙培训（1小时）
对于这种能够直接认识团队每个人的小团队，一开始就别花费太长时间讲大道理，以解决具体问题的方式来启蒙。
重新定义工作流程
新的项目工作流程
新的迭代工作流程
新的需求工作流程
新的代码工作流程
解决新流程中的障碍
团队沟通和协作的方式。
编译环境的准备。
编译时间的缩短。
自动化测试策略的制定，比如：我们放弃了原教旨主义的单元测试。
自动化测试运行的环境的准备。
自动化测试编写时机与自动化的利用。
自动化测试用例代码管理。
我和运维人员的对话（真实的场景再现）
我：我们团队想每两周就部署一次服务
运维：不行
我：为啥？
运维：线上需要稳定
我：每两周部署一次，就不稳定了吗？
运维：原来的质量太差，每次上线总是出问题
我：现在质量很好
运维：怎么可能？
我：我们改变了工作方法，质量优先，你可以参加我们的站会。你有什么要求，我们都可以满足
运维：那也不行
我：为啥
运维：我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次，每次前前后后要折腾两天。现在每两周上线一次，我还哪里有时间去干其它业务线的活啊？
怎么解决？
改变部署方式，让他的工作生活美好起来吧～～～～～
部署流水线的建立，要求一键部署
运维人员负责编写部署脚本，并做版本管理。
开发人员在开发自测时使用同样的脚本。
测试人员在测试环境上使用同样的脚本。
运维人员在生产环境上也使用同样的脚本。
如果想了解更多，我的“持续交付”微信公众号上对这个案例进行连载分析。感兴趣就来我的Chat交流吧。
强烈建议大家仔细研读《持续交付》，尽管这是一个大部头著作，而没有代码，少量插图，也没有什么工具使用说明。
我正在写一本关于持续交付案例解读相关的书，希望能帮助大家。书中很多内容是我在实际工作里如何运用书中的理论和原则，做出我认为适当的选择（比如上例中的不做单元测试），帮助团队解决实际问题。
原文地址：《持续交付和DevOps的前世今生》
标签：没有 精益 互联网公司 地址 迭代 工作方法 自己 share awd
原文地址：http://www.cnblogs.com/SanMaoSpace/p/6842417.html
