文档首页 > > 理论实践> 持续开发与集成>

持续集成,降低集成的痛苦

持续集成,降低集成的痛苦

分享
更新时间:2020/12/24 GMT+08:00

Agile作为美国最大的通信公司之一,采用的是目标管理(MBO)体系。目标管理 (MBO)的概念是管理专家彼得·德鲁克(Peter Drucker)1954年在其名著《管理实践》中最先提出的,其后他又提出“目标管理和自我控制"”的主张。德鲁克认为,并不是有了工作才有目标,而是相反,有了目标才能确定每个人的工作。所以“企业的使命和任务,必须转化为目标”。如果一个领域没有目标,这个领域的工作必然被忽视。 因此,管理者应该通过目标对员工进行管理,当组织最高层管理者确定了组织目标后, 必须对其进行有效分解,转变成各个部门及每个人的分目标,管理者根据分目标的完成情况对下级进行考核、评价和奖惩。 目标管理提出时,时值第二次世界大战后西方经济由复苏转向迅速发展的时期,企业急需采用新的方法调动员工积极性以提高竞争能力,目标管理的出现可谓应运而生,遂被美国企业界广泛应用,并很快为日本、西欧国家的企业所仿效,在世界管理界大行其道。

目标管理

目标管理指导思想上是以Y理论为基础的,即认为在目标明确的条件下,人们能够对自己负责。它与传统管理方式相比有鲜明的特点,可概括如下:

  1. 重视人的因素

    目标管理是一种参与的、民主的、自我控制的管理制度,也是一种把个人需求与组织目标结合起来的管理制度。在这一制度下,上级与下级的关系是平等、尊重、依赖、支持的,下级在承诺目标和被授权之后是自觉、自主和自治的。

  2. 建立目标锁链与目标体系

    目标管理通过专门设计的过程,将组织的整体目标逐级分解,转换为各单位、各员工的分目标。从组织目标、经营单位目标,再到部门目标,最后到个人目标。在目标分解过程中,权、责、利三者已经明确,而且相互对称。这些目标方向一致,环环相扣,相互配合,形成协调统一的目标体系。只有每个个人完成了自己的目标,整个企业的总目标才有完成的希望。

  3. 重视成果

    目标管理以制定目标为起点,以目标完成情况的考核为终结。工作成果是评定目标完成程度的标准,也是人事考核和奖评的依据,成为评价管理工作绩效的唯一标志。至于完成目标的具体过程、途径和方法,上级并不过多干预。所以,在目标管理制度下,监督的成分很少,而控制目标实现的能力却很强。

MBO/OKR的O(Objective,目标)

MBO(Management By Objective,目标管理)跟Scrum在思想上是相通的。 在英特尔和谷歌等公司,已经把MBO延伸成了OKR(Objectives and Key Results,目标和关键成果)。MBO更多的是从上往下,而OKR则是提倡员工自我驱动,属于由下向上,符合组织扁平化、阿米巴化的趋势。无论哪个方法的O(目标),如果想要很好的落地,都要遵循如下的三个原则,而谷歌在这方面的尝试值得借鉴。

  1. 可量化的O

    O应该是可量化的,要符合SMART原则,比如不能说“使Gmail达到成功”而是“在9月上线Gmail并在11月有100万用户”。在谷歌,最多5个O,每个O最多4个KR(关键成果)。

  2. 有挑战的O

    O应该是有野心的,有一些挑战的,有些让你不舒服的(按照谷歌的说法,完成挑战性目标的65%要比100%完成普通目标要好)。正常完成时,以0~1.0分值计分,分数0.6~0.7是比较合适(这被称为sweet spot,最有效击球点);如果分数低于0.4,你就该思考,这个项目究竟是否需要继续进行下去。要注意,0.4以下并不意味着失败,而是明确什么东西不重要及发现问题的方式。这与KPI要求“跳一跳够得着”类似。

  3. 透明化的O

    O及Key Results(关键成果)需要公开、透明、可视化的管理,每个人都可以了解到其他人的目标,当你能够看到同级、上级或者老板的目标时,你才可以校检你的方向是不是跑偏。

    在Agile公司,目标管理有固定的一套程序或过程,它要求组织中的上级和下级一起协商,根据组织的使命确定一定时期内组织的总目标,由此决定上、下级的责任和分目标,并把这些目标作为组织经营、评估和奖励每个单位和个人贡献的标准。为了更好地检查目标完成情况,上级和下级要定期会晤,讨论进展和问题。在Agile公司, 这种定期会晤称为One to One Meeting(1对1会议),是经理跟员工一对一地进行。

MBO/OKR与Scrum的区别

MBO/OKR关注的是组织与个人目标和价值的管理,Scrum关注的是价值驱动的交付,关注的是目标实现。OKR和Scrum结合能够更好地保证目标实现。如果把KR转换为Scrum的Backlog,正好可以分阶段、分迭代实现。当然,MBO/OKR不是KPI,不是用来做绩效考核的,重点是能够让团队关注目标、关注重要的事情, 而不只是围着考核相关的数字、公式转。通过OKR的透明化管理,把公司的目标、每个人的目标公开化、可视化呈现出来,相互监督,共同努力实现目标。在这样的高度透明的环境下,谁的表现如何自然很清楚,这样为团队的相互评审提供了良好的基础。这样的做法和Scrum的透明性是完全一致的。

正在实施Scrum的团队目标之一就是“如何做到测试的敏捷化”。

  • Objective(目标):如何做到测试的敏捷化。
  • KRs:做全新的版本,需要的回归测试时间从3天降到1 天。
  • KRs:每次构建打包的时间,从3小时降到1小时。
  • KRs:自动化测试的比率,从50%提升到70%。
  • KRs:保证当前迭代内的功能,完成100%的测试。

持续集成和每日构建有什么关系?二者是不是一个东西?

持续集成强调的是集成频率。和每日构建相比,持续集成显得更加频繁,目前业界的极致实践是每一次提交代码就集成一次。持续集成强调及时反馈。每日构建的目的是每天可以得到一个可供使用的发布版本,而持续集成强调的是集成失败之后向开发人员提供快速的反馈,当然成功构建的结果也就是得到可用的版本。每日构建并没有强调开发人员提交源码的频率,而持续集成鼓励并支持开发人员频繁提交对源码的修改并得到尽快的反馈。

持续集成有一个与直觉相悖的基本要点,那就是“经常性的集成比偶尔集成要好”。对于持续集成来说,集成越频繁,效果越好,如果集成不是经常进行的,比如少于每天一次,那么再集成就是一件痛苦的事情,也就是我们过去及现在一直遇到的问题。

持续集成的反模式(anti-pattern)

反模式这个词,表示在特定环境中不应该采用的做法。反模式最终可能产生严重影响。

第一个是代码提交不够频繁,导致集成延迟。也就是说,如果代码长期滞留在开发人员自己手中,没有及时提交,如果其他人对系统的其他部分做出修改,而修改可能会相互影响的话,集成就会延迟;延迟越长,消除其影响就越困难。把任务划分得越小,越容易完成,开发人员才能越容易地经常性提交。

第二个反模式是经常性构建失败,使团队无法进行其他任务。在将代码提交到存储库之前,先在存储库中更新代码,再运行私有构建(Private Build),保证构建成功后,才能提交。万一构建失败,就要指定专门开发人员并以最高优先级尽快修复。

第三个反模式是构建反馈太少或太迟,使开发人员不能及时采取纠正措施。

第四个反模式是垃圾构建反馈太多,使得开发人员忽视反馈消息。只有构建失败时,才把邮件发给引起失败的人,这样大家才会重视。

第五个反模式是用于进行构建的机器性能太低,导致构建时间太长,严重影响频繁地执行集成。

最后一个反模式是膨胀的构建,导致反馈延迟。譬如,把太多的任务添加到提交构建过程中,比如运行各种代码自动检查、统计工具或运行性能测试,从而导致反馈被延迟。

持续集成的要点

  1. 持续集成最大的优点之一是可以避免传统模式在集成阶段的除虫会议。持续集成强调项目的开发人员频繁地将他们对源码的修改提交到一个单一的源码库,并验证这些改变是否给项目带来了破坏,持续集成包括以下几大特点。
    • 访问单一源码库。将所有的源代码保存在单一的地点(源码控制系统),让所有人都能从这里获取最新的源代码(及以前的版本)。
    • 支持自动化创建脚本。创建过程完全自动化,任何人只需要输入一条命令即可完成系统的创建。
    • 测试完全自动化。要求开发人员提供自测试的代码,让任何人都可以通过一条命令就运行一套完整的系统测试。
    • 提倡开发人员频繁地提交修改过的代码,一天至少一次。
  2. 项目Bug的增加和时间并不是线性增长的关系,而是和时间的平方成正比。两次集成间隔的时间越长,Bug增加的数量越多,解决Bug付出的工作量也越大;你越觉得付出的工作量大,越想推迟集成,企图最后一次性解决问题,结果Bug更多,导致下一次集成的工作量更大;你越感觉到集成的痛苦,就越将集成的时间推后,最后形成恶性循环。
  3. 有效限制持续集成(Continuous Integration)反模式如下建议:
    • 频繁提交代码,可以防止集成变得复杂。
    • 在提交源代码之前运行私有构建,可以避免许多失败的构建。
    • 使用各种反馈机制避免开发人员忽视构建状态信息。
    • 有针对性地向相关人员发送反馈,这是将构建问题通知团队成员的好方法。
    • 购买更强大的构建机器,优化构建过程,从而加快向团队成员提供反馈的速度。
    • 避免构建膨胀。

痛苦的事情反复做

开发中最痛苦的事情是什么?集成、测试、部署和发布。极限编程以及持续交付的理念,就是提前并频繁做让你觉得痛苦的事情。

从某种程度上讲,持续集成是反人类天性的。由于集成很痛苦,人们便会本能地抗拒和拖延。如同锻炼身体一样,过程会很痛苦,但对身体健康是有益的。持续集成也是一样,开始的过程会痛苦,坚持下来,对研发的健康度有极大帮助。

敏捷开发强调节奏,Sprint的迭代以几周为单位,每日站立会议是以天为单位,而持续集成则是以小时和分钟为单位的,它是敏捷开发以及DevOps的心跳。

持续集成

“如果集成测试重要,那么我们将在一天中多次集成并测试”,这是极限编程中的建议。集成的目的是测试,测试的目的是反馈,反馈的目的是给开发者信心。

如前所述,推迟集成,会造成恶性循环;而持续集成实践,可以有效抑制缺陷蔓延。缺陷发现越晚,成本越是会几何倍数增长;我们都知道切换的成本,让开发人员从一个任务中抽离,切换思维去回忆几周甚至数月前修改的代码引入的缺陷,是极其低效的。

马丁·福勒(Martin Fowler)在他的博客上描述了对持续集成的建议:

  • 只维护一个源码仓库
  • 自动化build
  • 让你的build自行测试
  • 每人每天都要向mainline提交代码
  • 每次提交都应在集成计算机上重新构建mainline
  • 保持快速build
  • 在类生产环境中进行测试
  • 让每个人都能轻易获得最新的可执行文件
  • 每个人都能看到进度
  • 自动化部署

而Jez Humble在其所著的《持续交付》一书中,推荐了在使用持续集成时必不可少的实践:

  • 构建失败之后不要提交新代码
  • 提交前在本地,或持续集成服务器,运行所有测试
  • 提交测试通过后再继续工作
  • 回家之前,构建必须处于成功状态
  • 时刻准备着回滚到前一个版本
  • 在回滚之前要规定一个修复时间
  • 不要将失败的测试注释掉
  • 为自己导致的问题负责
  • 测试驱动的开发

Scrum与MBO/OKR

将Scrum和MBO/OKR进行关联的做法,非常有意思。将团队和个人的目标,与Scrum的目标与产出有机结合,并通过Scrum过程监控,可视化进行有效追踪, 随时反馈并调整。如果OKR中的Objective是Epic(史诗),那么KRs就是Feature(特性), 进一步可以拆分成一个迭代可以完成的Story(故事)以及Task(任务)进行实现。

需求有业务类的,有技术类的,目标也是一样,同一个Sprint迭代中,应该设置一定比例的技术类需求,持续对技术债务进行清理。

爱德华·戴明认为绩效考核、绩效排名以及年度考核是管理上七大顽疾之一。考评应该偏重团队而不是个人,就像球队一样,团队应该为了统一的目标而努力。频度上应该以季度甚至更短,个人和团队的目标及绩效应该设置阶段检查点,并随时根据结果进行沟通,而不是到年度绩效出来以后,再告诉员工绩效结果。绩效考评的目的是为了员工的成长和改进,而不仅仅是监督与批评,更不是开除员工的借口;考评即要面向结果,也要面向过程,避免为短期结果而牺牲长期利益而走捷径的方式。

OKR最早起源于英特尔,因约翰·杜尔在谷歌的建议推广而闻名天下。OKR的实施,应该是自上而下来制定,并同时保持自下而上的沟通;自上而下,公司的目标逐层拆解到个人目标;自下而上,个人目标要不断地与公司目标对齐,更容易调动员工的个人积极性。好的目标Object,应该是使劲跳能够到,要有一定的挑战性,100%都能完成的只能表明目标平庸。OKR不是KPI,不要与绩效进行挂钩。

  

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

  

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!非常感谢您的反馈,我们会继续努力做到更好!
反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

智能客服提问云社区提问