第3章 形神兼具——实现敏捷的核心价值

第3章  形神兼具——实现敏捷的核心价值

你读完第2章后会觉得Scrum描述了一个并不复杂的开发模式,但许多企业在导入Scrum时忽略了一个重要事实:这些实践是有关联性的。也就是说,随意选择部分实践而忽略其他关联活动不会将Scrum的价值潜力真正发挥出来。

近几年来,中国实施敏捷的IT企业越来越多,我也有机会和很多“敏捷”团队有所接触,得到了一个也许有些人不以为然的结论:大部分所谓敏捷团队及企业都没有真正理解敏捷的真谛,他们在做法上有一个共同点,即只引入一些相对比较容易的实践,对一些他们认为较难实施的Scrum实践则采取了视而不见的态度。另外一个大的问题是,敏捷只在团队层面实施,而整个公司的文化、理念和敏捷格格不入,“敏捷”团队无法得到组织层面的支持,使得一些重要的敏捷原则无法落地。

形似神不似只能让敏捷团队获得有限的提升,很难把团队打造成一个高效率的团队。Jeff Sutherland对Scrum的实施现状有下列的结论:

支离破碎实施Scrum的实践现状让人不可思议!哪怕是这样,大部分宣称和旧的过程比,还是看到了提高。我们还要做很多工作让大家回归到基本Scrum要求上面来。

他同时观察到,支离破碎的Scrum带来的效率提升在35%左右,而完整的Scrum有可能带来300%~400%的提升,可惜这样做的组织太少。

在Scrum的架构下,如何实施工程活动是所有团队面临的一个问题。Scrum中超短的迭代及部署上线周期给开发团队带来了极大的挑战,按部就班的传统开发方法不可能满足质量及进度的要求。增量开发下的架构设计、代码优化如何做变得格外重要,团队必须将代码库不断扩张带来的技术风险降到最低。我们需要引入能将技术变更、代码库增加的成本降下来的工程实践。极限编程是一个很好的选择,它能有效地支持Scrum的执行,让团队真正实现敏捷价值。在3.4节,我会探讨极限编程的价值观、原则及实践,并讨论如何将其和Scrum自然结合。在第6章,我会深入探讨一些能够有效支持Scrum架构的优秀工程实践,包括极限编程的一些有价值的实践。

3.1 形似神不似的Scrum实施

形似神不似的Scrum有一个特点,那就是把在本组织难以实施的敏捷Scrum实践忽略不计,仅实施自己喜欢做、容易做的内容。如大部分国内企业在实施Scrum时,往往不做团队的自我管理实践,也不强求明确定义迭代完成(Done)标准。

另一个常见的问题是,在通过Scrum实施敏捷时,不考虑敏捷宣言及敏捷12原则。支离破碎的Scrum往往意味着放弃一些敏捷原则。知其然不知其所以然,没有理解敏捷带来的价值,为做敏捷而做敏捷,不可能达到形神兼具的境界。

3.1.1 Scrum不能保证解决问题,但能保证暴露问题

当一个组织在“我特殊所以不适用”的借口下绕开一个Scrum实践时,很有可能这个实践触到了该组织的痛处:这个实践所指正是问题所在。变革需要勇气,正视自己的问题需要勇气,放弃习惯需要勇气。可惜勇气是很多组织缺乏的东西。

当管理者习惯地对一个Scrum团队说:“放下手中的工作,这边有更重要的任务需要你们去做。”这就是说Scrum过程经理没有办法保护团队在迭代中不受外界干扰,一条Scrum实践被放弃了。借口是“我们特殊,因为我们会常常碰到更紧急的任务需要团队处理”。

当一个管理者在无形中要求Scrum团队放弃这个实践时,他同时把危害团队效率的一个问题埋在了地毯下。同时做多件事,虽然貌似让团队成员一直在忙,但并不意味高效率。业界共识是同时做多件事是效率的杀手,从一个任务转到另一个任务需要转换成本,让专注变得困难。在放弃这个Scrum实践的同时,组织也失去了纠正这个问题的机会。

当一个团队以没必要为借口,拒绝对需求特性进行细化分解时,很有可能团队放弃了解决需求蔓延,用小的代价实现需求价值的机会。因为对需求分层细化,会给团队实现一个大特性更多选择机会,当你将一个大需求细分成5个小故事时,需求优先级才会起到作用。你可以判断一下核心的故事是什么,哪些故事是锦上添花的,哪些故事是其他故事不同的表现形式(也就是不需要的),哪些故事可以在以后确定了必要性后再实现。

当你以“团队成员会避开有难度的任务”为借口,放弃让成员自己认领任务的做法,而仍由项目负责人来分配任务时,你放弃了挖掘团队潜力的机会,放弃了营造一个能让团队成员有自豪感的工作环境的机会。一个人习惯了被动地接受任务,主动就是一个陌生词。当一个程序员3天完成了分配给他5天的工作,有多少程序员会主动去要求追加两天的工作?

当你以各种借口避开敏捷(Scrum)实践时,你同时放弃了解决组织内真正问题的机会。一个不易实现的实践往往是一个对组织价值大的实践,支离破碎的Scrum只能带来有限的改进也就不那么奇怪了。Scrum不能保证解决问题,但能保证暴露问题,而勇敢地面对问题,是解决问题必须跨出去的第一步。

3.1.2 没有本地化的适配,敏捷过程很难落地生根

当你尝试本书介绍的实践时,一定不要忘了和你组织的实际情况紧密结合。Scrum是一个来自美国的方法,它必然体现一些美国文化。在建立你的团队Scrum过程时,必须考虑本地特点,你的过程你做主,不要怕犯错误,因为不断完善过程是Scrum的要求。

用敏捷方法引入Scrum,已经被验证是一个有效的做法。我虽然建议敏捷组织尽可能全面实施敏捷实践,但这不是说你应该一下子将所有Scrum和极限编程的实践都同时引入。“增量实施、先易后难”是一个有用的八字箴言。引入Scrum的过程也是一个自己了解自己的过程,知己知彼,百战不殆,了解敏捷、了解Scrum、了解极限编程,同时了解自己,是成功实施敏捷的秘诀。

本地化意味着深入理解你的团队、你的客户、你的产品需求、你的技术平台、你的组织文化、你的工具、你的工作环境等重要因素。

举个简单的例子:在哪里开你的每日站立会议?如果只有一个敏捷团队,这可能不是问题。相信你总能找到一个会议室。但当整个组织都在实施敏捷,这就是个头疼的问题了。你需要因地制宜了,例如,重新布置办公空间,为每个Scrum团队建立自己的敏捷岛。

在你的组织架构下,谁来做Scrum的过程经理?谁来做产品经理?在你的产品环境下,如何设计产品需求列表?如何描述用户故事?这些都是你需要根据自己的情况来确定的。

3.1.3 不要因为错误的原因引入Scrum,要明确引入敏捷的目的

不少正在实施敏捷的组织管理者无法明确回答一个简单的问题:“你希望通过引入敏捷解决什么问题?”也就是为什么引入敏捷。

这些聪明人无法明确回答这个问题的原因也很简单:他们没有真正理解敏捷,没有真正理解Scrum。不理解的后果是,他们可能会因为错误的原因引入敏捷。下面是我听到的一些引入敏捷的原因。

  • 华为在用敏捷,所以我也要用。

  • 敏捷可以解决CMMI的问题,团队不需要再浪费时间写文档了。

  • 因为敏捷是目前最好的开发方法,引入敏捷就会解决效率问题。

在我做CMMI过程改进咨询、培训、评估时,听过许多公司老总谈他们对CMMI的认识和引入CMMI的原因。我的感受是道听途说、一知半解很害人。我不希望同样的问题在敏捷落地中国的过程中再现。

一个组织在引入敏捷以前,应该做3件事。

(1)搞清楚敏捷是什么、Scrum是什么、极限编程是什么,一定不要忽略其局限性。

(2)对自己的开发过程的瓶颈做个诊断:3~5个主要问题是什么?对这些问题做必要的根因分析,明确哪些问题可以通过引入敏捷解决、如何度量解决的效果。

(3)制订一个初步敏捷引入规划,列出范围、目的、步骤、策略、风险、时间表等。

俗话说:好的开始是成功的一半。知道为什么引入敏捷,明确要解决的问题是一个好的开始。

3.2 使用Scrum的艺术

念好Scrum这本好经是一门艺术,它的难处在于我们需要放弃很多习惯的理念及做事方式,这些做事方法、理念已经深入人心,特别是你的领导的思维方式也被框在其中。在这一章节里,我重点讨论Scrum方法中没有直接描述,但是能决定Scrum成败的要点。

3.2.1 Scrum中的自我管理及实现方式

几乎所有软件开发面临的挑战都和人有关系:如何控制人的情绪,如何调动人的主动性,如何保障人于人之间的有效沟通。所有敏捷方法无一例外,把人及他们之间的沟通放在了比过程更重要的地位。Scrum实践最希望达到的目标是支持在一个团队中建立健康的工作关系:诚实、信任、开放、相互尊重、通力合作实现每一轮迭代目标。

我在国内一些企业看到的做法往往达到相反的效果,如测试人员完全依赖缺陷跟踪(Bug-tracking)系统和开发人员进行沟通,这种沟通模式往往会形成一个推诿责任的文化,损害了开发和测试之间的工作关系。为什么不能让他们一起紧密配合工作,确保用户不会发现任何缺陷呢?软件开发团队的跨职能小组之间不应该是PK的关系,应该是荣辱与共、同在一条船上的关系:产品缺陷给使用的用户带来了不便是整个团队的耻辱,发布前发现的每一个缺陷都是值得整个团队庆祝的事。

自我管理是敏捷在开发过程中提倡的人的管理方式。由于文化的原因,让中国的软件团队自己管理自己,确实不是一件容易的事。不考虑管理者的因素,工程人员一开始也很不习惯这种工作环境。从小到大,在中国教育体系下成长起来的软件工程师已经习惯了被动地接受:在家里家长告诉你应该怎么做;在学校老师告诉你应该怎么做;从你上班的第一天起,你的上司告诉你应该怎么做。在产品开发过程中,他们习惯了每周由经理告诉他们做什么,然后埋头去做,很少相互间沟通。如果能提前完成任务,就放慢节奏;如果不能按时完成,到时就找个借口,下周继续做。这样一个被动的团队,是很难将团队的潜力最大限度地发挥出来,也很难让开发人员有成就感,更没有动力去主动寻找更好的实现方法,真正形成一个紧密的团队。

实现自我管理要有两个大的调整:管理者管理方法的调整和工程人员工作方式的调整。这两个调整会是每一个实施敏捷企业都面临的问题。

用人不疑,让团队放手做好自己的事,是管理者常常挂在嘴边的话。但是没有几个领导能够真正做到这一点,一个原因是他们找不到一个让他们放心的放手管理的方法。Scrum给出让团队自我管理的架构,给软件研发团队指出了一个全新的工作方式。

首先,Scrum明确定义了产品开发中的“猪”和“鸡”,极其智慧地区分了产品开发的业务和技术的职责。在这个架构下,只有“猪”直接承担研发过程的责任,所以“猪”也是研发过程的决策者。Scrum的策略是让业务人员专注业务的问题,让技术人员专注技术实现的问题,项目的管理是由业务决策驱动,而业务决策必须是在技术方案的成本和风险基础上做出的。

Scrum的产品经理被赋予产品业务决策权,而团队则被赋予了相关技术决策全权,Scrum很好地平衡了业务和技术的关系,不给产品经理或团队过大的权力,不让一个强势的产品经理或技术高手完全控制整个过程。让产品经理控制产品需求列表,而让团队控制迭代需求列表,则是保证这种平衡的机制保证。从某种意义上来讲,Scrum的过程经理的主要责任之一也是维护好二者之间的平衡。

业务和技术职责的平衡是Scrum实现自我管理的基础,在这个大框架下,团队可以专注做好自己的事,同时必须不断完善其工程实践,完善使用的开发管理工具在短时间内能够交付可部署的软件。Scrum要求团队每次迭代的最后一个活动是回顾改进,从错误中学习,不断提升能力。正是有了这些保障,管理者可以放心放手让团队做好自己的事。

实现团队的自我管理,意味着每一个成员都清楚自己的责任及权利,团队会根据自己的能力确定每轮迭代完成的故事范围,每天让每个成员主动认领任务(在回答站立会议的第二个问题时),有问题及时沟通,充分利用团队内的资源寻找帮助,同时随时准备帮助其他成员,团队只有一个共识:想办法努力实现团队承诺的迭代目标。

何时认领任务是很有讲究的,我看到国内大部分Scrum团队在迭代规划会上就将任务分配完了,在我问为什么这样做时,最多的回答是怕没人认领比较难的任务,这又是一个绕过实施敏捷实践的例子。这种做法带来的最大问题是有些人认领的任务是他完不成的,而有些人认领的任务可以提前完成,等迭代快结束才发现某些任务无法按时完成时,很有可能团队已经没有时间实现迭代目标了。这样做的另一后果是,我们很难逐步把团队带成一个主动、互助、高效的团队。

Scrum鼓励当天的任务当天认领,这样有几方面的好处:避免了忙闲不一的情况;通过前面已完成的任务,成员会对后面的任务,各自的长处、短处更加清楚,这样任务和成员能力的匹配会更好。如果碰到了技术难点,可以集思广益、攻关解决。

虽然Scrum没有传统意义上的项目经理,但团队会自然形成一些技术领头人,以他们为核心,鼓励主动承担任务,不怕失败,及时从失败中学习,不断调整,正是Scrum的核心实践。Scrum通过自我管理机制的完善及相关实践的结合来解决复杂的问题。

让团队从被动到主动,不可能一步到位。管理者必须给团队创造一个安全的环境,让他们放手发挥自己的能动性,出了问题不要责难,而是要鼓励。中国的Scrum过程经理在这方面面临的挑战更大,他需要指导团队逐步学会使用自己的权力,去担当,去学习,逐步形成一个真正的团队。产品经理和团队也要学会互相尊重对方的权力,在同一目标下,双方协调实现Scrum的价值,实现产品的价值。

3.2.2 管理者从监控型到服务型的转变

在Scrum模式下,管理者要从计划驱动思维方式转换为敏捷思维,其中一个重要的变化是不要把初始计划太当回事,要能够容忍计划的调整变化。从传统计划驱动到敏捷的另一个大转换是敏捷的管理者度量监控的是需求(如产品功能完成情况,产品是否可以发布),而不是任务。管理者关注的不是实现这些需求的任务执行情况,而是这些需求的实现情况。

管理者如果要了解某次迭代的情况,他可以列席团队的每日站立会议,但注意他只能听而不能干预团队。如果想了解整个项目的状况,管理者可以在项目的敏捷岛(更多的信息可以参见第5章)看到相关信息。迭代的评审会议、产品需求列表、燃尽图都是管理者了解项目进展的渠道。

也许Scrum团队需要为管理层提交其他的状态报告,但这些报告的制作必须有价值,同时不会占用团队很多精力。软件开发是马拉松,走的是一条艰难的路,管理者必须让团队轻装上路,不要在他们身上加任何不必要的包袱,因为背着沉重包袱是跑不快、跑不久的。管理者要尽量减少全员必须参加的、冗长的会议,不要求项目组定期收集一堆没人看的数据、提交冗长的项目状态报告,不在迭代过程中随意给团队追加新的任务。

管理者了解项目的状况不是为了监控团队,确定是否有人不尽力,而是为了帮助团队解决问题。在敏捷模式下,管理者从监控型变成了服务型,他们需要更加信任团队,能够有效地激励团队,为团队提供必要的物质和精神支持。

做好服务型的领导者要善于倾听,团队的声音让你知道团队能做多少以及成本代价、技术风险是什么,产品经理会告诉你客户要什么、什么最重要,Scrum的过程经理让你知道团队面临的困难是什么。并不是每个管理者都能成功地转型,有人统计在美国有20%的管理者在其企业推行敏捷后,由于无法适应新的管理模式而离职。

敏捷并不是不要管理,并不是反对项目管理。高效的敏捷团队会平衡好管理者和个人的关系,会平衡好自我管理和自我约束的关系,高效敏捷团队是灵活的,但不是无序的。

3.2.3 追求问题的解决而不是最佳解决方案

软件开发中的不确定因素要求Scrum团队不能是完美主义者,而应该是一群真正的软件工程师,因为工程师就是从复杂场景下找到解决办法的人。产品开发不确定性越大,越要求团队勇于实践,勇于探索,不怕犯错误,及时发现问题,及时调整。产品需求的不确定和技术的不确定意味着没有完美的解决方案,意味着团队需要在迭代中学习,不断完善。

为了实现迭代目标,团队需要在很短的时间内找出解决方案,并完成开发测试,在迭代结束时展示工作的软件。这就要求团队不要追求复杂的解决方案,而要尽量把复杂的问题简单化,简洁的解决方案是敏捷追求的目标。考虑一个简单的例子,某银行IT需要维护一个还要使用2年的软件产品,为实现某个功能我们需要判断当天是不是周末,因为如果是星期六或星期日,系统的处理方式和每周的其他5天不一样。你用什么样的算法来实现这个十分简单的判断呢?这个团队选择了万年历的算法,这个算法确实能解决问题,但它带来的设计、编程、测试的工作量相当大。既然这个产品只有2年寿命,为什么不用一个简单的实现方法呢?如把2年内的周末的日子做到一个表格里,一个简单的IF语句就能做这个判断。这个简单查询只实现了所需要的功能,而万年历则实现了许多现在不需要的功能。敏捷追求简洁,追求将复杂的事情简单化。越简单,开发成本、维护成本越低;越简单,沟通成本越低。

考虑两个今天需要做的决策选择:是用简单的方法实现功能、需要的话明天再修改,还是用复杂的、超前的方法来实现同样的功能,因为明天可能需要?敏捷的选择永远是前者,因为今天实现的额外复杂功能以后可能永远不会被使用。

不久前我为一家电信应用软件开发公司做了CMMI评估,其中一个评估项目的客户(甲方)是政府。我发现这个项目立项很早,但一直没有签合同,也就是说,公司承担着很大的商务风险。因为如果客户看到的东西不能让他们满意,那么客户就不会支付任何费用。我被告知公司有不少这种类型的项目。在评估中,我看到团队很认真地执行公司制定的过程,花了很大的精力做需求、设计、编码,做了各种技术评审、各种测试,而所有这些工作的目的就是为了能给客户(主要是几位政府官员)做些演示,得到他们认可,能够把合同签了,再立项开发出用户使用的系统。我在最后报告会上的建议让大家有些意外。我对这类项目的建议是:遵循“够了就好”(just enough)的原则,用最小的代价开发出可演示的功能,由于没有真正用户会使用开发出的软件,所以没必要做严格覆盖的测试,只要能清晰地向客户展示出系统特性即可,用最小的代价实现这类项目的目标。

我会在本章后面的章节中更多讨论敏捷实施中所需要的勇气,在这里我讲的是一个软件工程师在面对问题时应有的勇气。

  • 哪怕是在迭代后期,如果发现设计架构有问题,也应该有勇气集中精力去修复它。

  • 如果发现某段程序中存在很多问题,那么就扔掉它们,重新编写。

  • 如果发现测试忽略了一个使用场景,那么就加上这个测试,修复可能发现的缺陷。

  • 如果发现自己不能解决某一个问题,要有勇气不耻下问,寻求帮助。

由于敏捷的旅程充满不确定性,我们的方案可能有缺陷,这些勇气是敏捷团队必备的。如果你熟悉人工智能中的爬坡算法(hill-climbing)的话,那你就知道经典的局部最优(local optimum)问题。小的修改是解决不了这个问题的,要跳出这个问题的圈子,我们需要做大的改变,换一个思路,能做到这一点,这绝对需要工程师的勇气。

Scrum中的时间盒的实践在一定程度上也是鼓励团队追求简洁的解决方案,不要陷入没头没尾的所谓最佳方案的讨论。记得Nike广告里的一个口号吗?“Just do it!”在敏捷中我们再加4个字—“错了再改”。Scrum中的频繁反馈会让你很快就有纠错的机会。

3.2.4 对工程人员能力提升及自律的要求

在国内我常听到这样一种说法:敏捷是好,但我们开发人员能力不足,所以我们无法敏捷(这里的敏捷被当作动词用)。我不太赞成这个观点,因为敏捷并不是为技术精英设计的,如果你的团队在传统模式下能够开发出软件,那么他们就有能力敏捷。但我同意这样一种观点:没有自律,没有把团队能力提升作为敏捷迭代一个目标,我们无法打造一个高效敏捷团队,这也是自我管理的重要基础。

软件开发不是一件容易的事,按客户进度要求开发出高质量的软件更难。要做到这一点,开发人员必须严格使用团队制定的有效工程实践。比起传统的开发模式下的漫长周期和庞大团队,敏捷确实对人员素质、技能等方面要求更高。

Scrum团队必须是一个学习的团队,在工作中不断学习提升自己的能力是每一个团队成员的责任,用你的特长帮助你的伙伴也是你应尽的责任。只有你的团队真正开始实施Scrum后,你才能逐步真正理解它以及它的价值,在实践中学习(learning by doing)是掌握Scrum的唯一方法。当团队在一起攻克一个复杂问题,高效协作,学习调整时,你会慢慢体会到Scrum的妙处。

自律就是接受责任有担当,就是接受并遵循确定的开发架构,就是遵循团队定义的设计原则,就是遵循团队定义的编码规范,就是写出简洁的代码,就是不把质量作为一个牺牲品,就是遵循团队的行为规范,就是乐于让同伴检查自己的工作。这些不仅是贴在墙上的口号,而且是团队的日常实践。

自律也是让开发过程完全透明,每天都使自己的工作和团队其他成员的工作同步,让大家知道自己工作完成的情况:哪些已经完成,哪些还未完成,对代码做了哪些增加、哪些修改,这些增加和修改对其他代码的影响。团队成员工作之间的同步拉通不再是在项目后期才开始,而是每天需要坚持的实践,每天将新代码检入、构建、通过测试,保证每一天提交的代码都是干干净净的,一直保持到迭代结束。本章后面我会讨论极限编程实践和Scrum的结合及其对保证团队自律的作用。

3.2.5 Scrum实践的互补,完整的Scrum才最有价值

有经验的敏捷实践者会意识到Scrum是一个能自我调整的系统,它不是一个具体的方法,不是一个过程或流程,而是一个能让一般团队自我管理、完善成为一个高效团队的框架。这个框架是由一些既独立又有关联的角色、活动和实践组成的,当然它也遵循敏捷价值及原则。

拿Scrum的3个角色为例,他们在每一个Scrum会议、Scrum文档的维护、Scrum实践中都会扮演独立的角色,但是每个角色又依赖其他两个角色才能更好地发挥作用。如果产品经理不能给出合理的产品需求列表中的优先级,那么团队每轮迭代做得再好,也很难为客户提供有价值的产品。如果团队不能给出可信的需求特性的成本估计,产品经理也很难平衡做好版本计划。如果Scrum过程经理不能有效协调产品经理和团队之间的沟通,那么我们很可能看到的是业务和开发的PK而不是紧密的合作。

Scrum的各类会议是为了确保团队内部必要的沟通,让大家关注同样的事,在工作中获得成就感。这些有效的会议使得产品需求列表的优先级、用户故事的细化、严格“完成”(Done)的标准、在清除障碍中持续的过程改进有了实实在在的意义。

图3-1展示了Scrum元素间的关联关系。

0301.tif

图3-1 Scrum元素间的关联关系

敏捷(Scrum)实践有极好的互补性,每一条都有自己的缺陷,敏捷的妙处是这些缺陷会被其他实践所弥补。正是这些相辅相成的实践,让我们能够实现敏捷带来的价值。

如果没有下列Scrum、极限编程等敏捷实践的支持,很难在一个短的周期(1~4周)开发出对客户有价值、可发布(满足质量要求)的软件。

  • 有一个知道自己速率的、密切合作的跨职能团队。

  • 通过每日例会实现同步开发并确保问题的及时解决,尽可能在识别出开发障碍后的24小时之内将其清除。

  • 细化用户故事,让其颗粒度足够小,能够在一周内完成。

  • 对迭代需求列表中的每一条需求都有明确严格的“完成”(Done)定义,让整个团队在迭代开始时就了解通过准则,并能长期控制带病迭代的问题。

  • 让每日持续集成制度化,这样能够大大降低发布的工作量投入。

  • 迭代中对团队工作的零干扰,让团队专注迭代目标的实现。

如果没有下列Scrum实践的支持,很难有一个真正做到自我管理的团队。

  • 明确Scrum角色的职责,团队清楚自己应有的担当,并做出承诺。

  • 迭代评审会对开发出的软件特性的反馈,使得团队能够及时调整产品方向,降低产品变更成本。

  • 迭代回顾会议对开发过程的反馈,使得团队能够及时纠正问题及持续改进过程,降低所犯错误带来的成本。

  • 每日例会让每个成员对团队负责,努力做好自己的工作,不拖整个团队的后腿。

  • 由团队决定哪些需求任务放入迭代需求列表,由团队决定如何实现需求特性,相信他们会把工作做好,会在实践中提高能力。

如果没有下列Scrum实践的支持,很难让整个开发过程变得透明。

  • 正确使用Scrum的3个文档(产品需求列表、迭代需求列表和燃尽图)可以让“猪”和“鸡”都能得到他们需要的重要信息。

  • 设计管理好你的敏捷岛,用最简明的方式展示迭代、版本状态敏捷岛。

  • 开好所有Scrum中的会议,让透明的过程服务于必要的审查和调整。

如果没有下列Scrum实践的支持,很难获取产品的反馈并做及时、合理的调整。

  • 迭代结束时的评审会议是获取反馈的最好时机,对需求不明确的项目,这个会议可能是最重要的会议,不要仅仅走个过场。

  • 产品需求列表的细化会议,是团队和产品经理形成默契、一起加深需求理解的重要活动,也是平衡产品需求价值和成本的好机会。

  • 在整个开发过程中,团队可以随时和产品经理沟通,随时确认实现的需求特性。

如果没有下列Scrum实践的支持,很难获取对所用敏捷过程的反馈并做出及时调整。

  • 迭代结束时的回顾会是获取反馈的好时机,对问题错误做根因分析,在下次迭代中改进调整。同时对本次迭代的优秀实践进行总结,固化可复用的实践。

  • 在解决开发问题障碍的过程中,识别改进机会。让每一个严重问题都可能成为改进机会。

  • 敏捷创造了让你的工程师从“I”型变成“T”型的平台,“T”型人才可以更好发挥过程的作用。

如果没有下列敏捷Scrum、极限编程等敏捷实践的支持,很难通过“完成”(Done)的标准把好出口关。

  • Scrum对技术卓越的追求是在增量开发中把好质量关的保障。

  • Scrum和极限编程的自然结合是解决带病迭代问题的良药。

  • 敏捷和CMMI结合的探索也许可以是解决软件开发问题之匙。

如果没有下列Scrum实践的支持,很难保证可持续的开发节奏。

  • Scrum中时间盒的实践(固定的迭代周期,固定的会议时间等)创造了一个可预测的工作步调。

  • 团队速率在计划中扮演着重要角色,也是形成团队开发节奏的重要保障。

  • Scrum中固定的例会、固定的工作环境、共同遵守的工程实践,都有助于开发节奏的形成。

  • Scrum对技术债务的管理要求,能防止团队只追求速度的错误倾向,有助于节奏的把控。

如果没有下列Scrum实践支持,很难通过最小代价实现最大的需求价值。

  • 需求驱动开发,让团队和客户的沟通变得容易,双方的对话会关注需求价值及成本。

  • 在整个开发周期,产品经理随时和团队沟通,随时根据最新的信息调整产品列表中的需求优先级,让团队优先实现价值最高的需求故事。

  • 持续不断短周期的增量开发模式,通过不断演示需求特性,让利益相关人加深对产品需求的理解,识别真正能实现用户价值的功能。

  • 持续不断迭代,让团队对产品不同需求的开发成本有更清晰的估算,使得需求特性的性价比变得更清楚。

如果没有下列Scrum实践的支持,很难维护好版本计划。

  • 每次迭代后计算团队速率,让产品经理知道开发团队的能力—每次迭代能实现多少功能,这是让版本计划变得有意义的基础。

  • 根据团队能力,调整版本计划,是保证计划准确的主要手段。

  • 产品经理根据最新信息对产品需求列表进行维护,是确保在进度压力大的情况下,首先发布对用户最有价值的功能的保障。

  • 坚持远粗近细的原则,让产品经理和团队高效完成版本计划工作。

如果没有下列Scrum实践的支持,很难让团队比较准确地计划每一次迭代。

  • 赋予团队权力,让团队可以决定每次迭代完成哪些用户故事。

  • 团队速率可以让团队根据自己的能力选择每次迭代完成多少用户故事。

  • 产品需求列表的次序能够让团队选择完成优先级最高的用户故事。

  • 需求细化会议让在极短的迭代周期中完成可发布的软件功能变得可行,这也是团队做迭代计划的基础。

如果没有下列Scrum、极限编程等敏捷实践的支持,就不可能有效地控制带病迭代。

  • 敏捷对卓越技术的追求及明确的“完成”标准是控制带病迭代的关键。

  • 持续集成等有效的工程实践也是迭代质量的保证。

  • 迭代回顾会议让团队及时发现带来隐患的做法,并及时在后面的迭代中加以纠正。

  • 燃尽图能让团队及时发现隐患对团队效率的影响。

  • 团队的自律及相互负责的文化使得走技术捷径不是一件被鼓励的事。

尽可能完整地引入Scrum是让其价值最大化的保证,令人遗憾的是敏捷实践者往往忽略这一点。

3.3 极限编程是Scrum最好的伙伴

目前业界最常见的敏捷是Scrum和极限编程(eXtreme Programming,XP)(Beck ,1999)实践的结合,从1995年起,极限编程和Scrum一起不断完善,成为最重要的、主流的敏捷方法。敏捷宣言及敏捷原则很大程度上是在这两个主要敏捷方法的基础上形成的。和Scrum的主要创立者一样,极限编程的提出者Kent Beck也是敏捷宣言的签名者之一。

极限编程在工程方面的实践很好地弥补了Scrum在这方面的空缺,共同的敏捷理念(小团队、短周期、强调反馈的价值等)又让Scrum框架可以很自然地支持XP的实践。

也许有些读者对为什么叫“极限”(extreme)感兴趣,原因很简单,其取意是如果某个实践好,那就将其做到极限。

  • 如果做代码评审好,那就总做代码评审(结对编程)。

  • 如果做测试好,那就让每开发人员都做(单元测试),也让客户做(功能测试)。

  • 如果做设计好,那就让开发人员天天做(重构)。

  • 如果简单的就是好,那我们就尽可能地选择简单的方法实现系统功能。

  • 如果架构重要,那就让每个人时刻都了解完善架构(metaphor)。

  • 如果集成测试重要,那我们每天都做几次测试和集成(持续集成)。

  • 如果短的迭代好,那我们就让迭代变得极短:以秒、分钟、小时计,而不是以周、月、年(计划游戏)计。

在本章节里,我会介绍极限编程的核心价值理念、原则及实践,并探讨和Scrum的结合。

3.3.1 技术债务:Scrum的杀手

Scrum把如何实现软件的技术相关的事情留给团队自己来决定,它允许团队根据自身的项目特点或环境选择合适的技术实践。这样做也会带来一些风险:一些Scrum团队为了追求效率,会过多地选择技术捷径,只顾快速完成编码,能在迭代结束时将实现的功能演示出来变成了唯一“完成”(Done)的标准。这些团队会忽略一些必要的、经过验证的、见效周期较长的实践,而这些工程实践往往是系统级质量的保障。

片面追求技术捷径带来的恶果在前几个迭代中表现得不会十分明显,因为开发前期代码库还不是很大,新的功能还比较容易加进来。但随着迭代的累积,团队追求短期效率所借的技术债务会拖垮团队,借债长期不还会让你破产。“技术债务”可以看作是设计、开发不足的累积总和,技术债务的管理是决定敏捷成败的一个重要因素,带病迭代是敏捷的第一杀手。

如何能在短时间内开发出可发布的软件?如何能让代码库健康成长?如何降低已开发系统的变更(功能的追加、修改和删减)成本?极限编程给出了一套经过验证的实践,已成为敏捷实践中不可缺少的一部分,在很大程度上弥补了Scrum遗忘的技术角落。

在本书后面的章节中,我会从多方面讨论解决技术债务(带病迭代)的问题。

3.3.2 极限编程的4个核心价值

极限编程提出了4个核心价值,即沟通、简洁、反馈和勇气。

1.沟通

你的团队出现过下列问题吗?

  • 一个程序员忘了告知团队其他成员他改动了一个关键设计。

  • 开发人员没能问客户正确的问题。

  • 管理人员没能问开发团队正确的问题。

  • 谁报告坏消息,谁就要被处罚,结果是没人愿意报告坏消息了。

这些问题的后果想来大家都很清楚,好的沟通是不会让这些问题发生的,极限编程将沟通作为核心价值也是抓住了软件开发的一个关键问题。

2.简洁

这一点是很难做到的,因为人总喜欢容易把简单的事情复杂化,但很难把复杂的问题简单化。极限编程追求简单,宁肯今天用最简单的方法实现功能,也不自作聪明预测将来,用复杂的方法实现大而全的功能。它的选择是:如需要,将来再修改,坚决避免开发出没人使用的功能的情况。

简洁的价值是降低了变更成本,因为越简单,沟通成本越低;越简单,开发成本越低;越简单,维护成本越低。

3.反馈

我在前面多次讲了反馈的价值,极限编程将其发挥到了极致。

  • 以分钟为单位的反馈:单元测试会实时对程序员所编程序给出反馈,这样他可以及时发现错误,找出原因,避免以后出同样的问题。

  • 以天为单位的反馈:对客户提出的新的用户故事加以描述,开发团队给出自己的估算反馈,让客户了解自己需求描述的质量。每日例会的机制,团队对每个成员前一天的工作给出反馈,做到及时调整。

  • 以周为单位的反馈:迭代后的系统功能测试能够对团队一次迭代的工作提供有价值的反馈,对所发现的缺陷进行植入分析,能帮助团队避免再犯同样的错误;同样,评审和迭代内测试的失效分析,能帮助团队提高评审及测试能力。每次迭代后,产品经理可以通过团队的速率的数据,来判断是否需要调整版本计划。

  • 以月为单位的反馈:系统的部分功能上线后,用户使用带来的反馈可以让你完善后期需求,开发出对客户真正有价值的产品。在传统开发模式下,有一个常见的错误认识:系统一旦上线投入使用,你就无法做大的修改。极限编程让对上线后的系统进行修改变得容易。

4.勇气

勇气在敏捷中格外重要,当你放弃熟悉的东西,引入新的东西时,都需要勇气。敏捷的特点是摸着石头过河,当发现错了时,你必须具备进行纠正的勇气。如前面举的一些例子:在迭代后期,如果你发现架构的缺陷不足,你会怎么办?你必须敢于先放弃新功能的实现,集中精力修复架构的问题。当你发现一个程序模块存在大量问题时,你必须有勇气把它扔掉、重新编写。

有了其他3个价值的落地,极限编程中的勇气变得容易了许多,因为它们让变更成本变得可以接受。

3.3.3 极限编程的原则

从4个核心价值,Kent Beck(1999)提出了极限编程中5个基本原则及10个一般原则。4个核心价值定义了成功标准,15个原则让这些较为模糊的价值变得有血有肉,对照敏捷12原则会发现很多类似的追求。当然敏捷12原则的描述更加严谨,文字更加优美,而极限编程对原则的描述是简单而直截了当的。

我们先看一下极限编程的5个基本原则。

  • 快速反馈(rapid feedback)人在学习中,及时反馈会起到关键作用,如果我们的过程能为软件工程师的设计、开发、测试工作及时给出反馈,而不是拖到数周数月后,学习效果会有天地之别。

  • 简洁第一(assume simplicity):简洁就是简单干净,能简绝不繁是极限编程及敏捷一个重要原则,总是假设每一个问题都有一个简单的解决方案,不要为明天去设计、去开发,努力解决好今天的问题,相信自己明天有能力实现必要的复杂方案(如果需要的话)。这个原则是符合软件经济学的。

  • 微量变更(incremental change)也许你会将其翻译为“增量变更”,但我觉得微量比增量更能反映这个原则的核心理念,因为“小”是最想表达的意思。如果开发一个系统需要引入4个新技术,XP会建议你不要一下子全部引入,最好是分4次引入。微量变更体现在多个方面:设计一次变一点,计划一次变一点,团队一次变一点,Scrum和极限编程的导入也要一步一步地实施。

  • 拥抱变更(embracing change):在恰当的时间(just in time)能让团队集中精力解决手头最紧迫的问题,也能避免浪费。到需要时才决定,也会让团队有最多的信息,这时做的选择风险最小。敏捷不把变更当成负担,而把它看作是机会,整个极限编程的思路就是将变更成本降到最低。

  • 质量至上(quality work):Kent Beck认为项目开发的4个变量(需求范围、成本、进度和质量)中质量的自由度最小,具体来讲,质量只有两个可选值:卓越或超级卓越。极限编程的工程实践也充分体现了这一原则。

除了上述5个基本原则外,极限编程也提出了10条一般原则。

  • 鼓励授人与渔(Teach learning)。

  • 控制前期投入(Small initial investment)。

  • 坚信战则能胜(Play to win)。

  • 决策试验验证(Concrete experiments)。

  • 坦诚沟通文化(Open, honest communication)。

  • 做事尊重人性(Work with people’s instincts, not against them)。

  • 敢于担当责任(Accepted responsibility)。

  • 结合本地特点(Local adaptation)。

  • 团队轻装上阵(Travel light)。

  • 真实客观度量(Honest measurement)。

3.3.4 极限编程的4个核心工程活动

编码、测试、倾听、设计是极限编程提出的4个核心活动,之所以称其为核心活动是因为它们是软件开发不可缺少的活动:没有代码,我们什么都没有;没有测试,我们就不知道是否可以结束;没有倾听,我们就不知道如何编码、如何测试;而设计让我们能持续编码、持续测试和持续倾听。

  • 关于编码:编码是任何一个软件系统的最真实的表示,代码是所有工程文档中唯一不会有假的东西,而其他文档如需求、设计等都有可能和当前的系统不一致。理论上讲,编码是软件工程中唯一必须做的核心活动。

  • 关于测试:一个重要的测试秘诀是找到你能容忍的缺陷级别,例如,用户一个月抱怨一次是你可以接受的。找到这个标准后,依此建立你的测试体系,并且不断完善,直到测试过程能达到要求,然后把这个过程变成标准过程。从不同角度来看,测试分成两类:开发角度的测试和客户角度的测试。

  • 关于倾听:项目开始时程序员很可能对要开发的内容一无所知,所以他们就要去问、去听,听了以后必须有反馈,而这些反馈是让业务人员或客户知道哪些难、哪些容易,也让他们更加理解相关的业务。

  • 关于设计:设计是建立一个能将系统中的逻辑组织在一起的架构。好的设计有下列几个特征。

  • 局部变化不会导致其他部分变动;

  • 每个逻辑在系统里只在一个地方存在;

  • 每个逻辑和它所操作的数据距离很近;

  • 容许系统只在一个地方扩展。

坏的设计的特征则正好相反:

  • 一处改则处处改;

  • 逻辑在系统中被复制;

  • 设计变更成本非常高;

  • 新的功能的追加会打乱已有的功能。

团队需要有机制支持下面3件事。

  • 做好的设计。

  • 修复坏的设计。

  • 让所有用到设计的人了解当前的设计。

我在国内企业做开发过程咨询时,常常碰到的一个问题是:如何建立所谓紧急项目流程?这类项目往往有刚性的需求范围和不合理的刚性的进度要求,如果按正常开发流程,团队根本无法按时提交。这类项目成了不少实施CMMI企业的头痛之处,在本章结尾的“两个团队的故事”部分,我会讲一个如何用极限编程核心活动建立紧急项目流程的故事。

3.3.5 极限编程的12条实践

极限编程的12条实践是Kent Beck根据自己及业界的开发经验总结出来的,这些实践,特别是其中的工程实践能够有效支持Scrum的实施。这里我们先简单介绍一下Kent Beck(1999)给的12条实践的定义。

  • 计划活动(planning game):快速依据业务价值及开发成本估算确定下次发布需求范围,随着迭代的滚动,计划会不断被调整,所以没有必要花很大精力制订初始计划。

  • 小版本(small releases):只要开发出对用户有价值的功能(哪怕是很简单的功能),就尽快上线让用户使用,然后不断频繁(1~4周)升级。

  • 隐喻(metaphor):用一个简单、公用的描述系统功能的故事指导所有开发工作。

  • 简单设计(simple design):用最简单的方法实现系统,一旦发现不需要的设计,立即将其清除。

  • 测试(testing):测试驱动开发。开发人员不断编写单元测试,只有通过了这些测试,开发才会继续进行。按客户要求编写展示系统特性的测试。

  • 重构(refactoring):在不改变系统功能前提下,开发人员不断地优化代码结构:清除重复代码,改善程序的可读性,简化程序的复杂度,让代码变得更灵活。

  • 结对编程(pair programming):所有程序都是由两个程序员在一台机器上编写出来的。

  • 代码共享(collective ownership):任何人都可以随时、随地修改系统中的代码。

  • 持续集成(continuous integration):每当完成一个新的任务时,就进行集成和构建,有可能每天要做多次集成构建。

  • 不加班(40-hour week):每周工作时间不超过40小时应该是正常的规则,不能允许团队连续加班两周。关于不加班,我这里想多讲几句。目前中国IT业的现状让这个实践变得很难落地,每天晚上7~8点钟时,华为办公楼还是灯火通明。为了赶进度,几乎所有软件工程师都有过持续加班的经历,这给个人及家庭生活带来不便。看过几期《非诚勿扰》,如果男嘉宾的职业是软件工程师,基本的结果都是最后遭遇全部灭灯。这个状况估计在相当长的时间里很难被改变,但我想从管理考核角度提一条建议:不要把加班多少作为主要的考核依据,考核决定行为,将其作为主要考核指标,会对提升工作效率有负面影响。同样的工作,一个人花6小时完成,另一个人花了12小时完成(加班4小时),作为管理者你觉得谁做得更好呢?

  • 现场客户(on-site customer):有一个真正的用户自始至终参与团队的开发,随时回答团队的问题。

  • 编码标准(coding standard):所有程序员都应遵循同样的编码规范要求完成所有开发。

和Scrum一样,极限编程的实践也是相辅相成的,它们所倡导的优秀实践,看似是一个个独立活动,实际上具有高度耦合度,不能独立执行,每一条实践的不足往往会被其他实践的强项所弥补。例如,如果没有编码标准,没有结对编程,那么代码共享的后果是不可预测的。没有重构作为重要保障,小版本的后果很可能是结构的混乱。在第6章里,我会更详细探讨4个核心极限编程实践在Scrum架构下的应用:简单设计、测试驱动开发、重构和持续集成。

3.3.6 极限编程+Scrum:1+1>2

Scrum实施中一个常见的问题是:在每轮所谓的开发迭代过程中,团队摆脱不了瀑布思维,还是遵循接力开发模式,即需求分析-设计-开发-测试-交付。当迭代周期只有一两周时,这种模式会导致没有足够时间完成必要的测试工作,不可能交付出可发布的软件。这种模式也会造成资源浪费,因为在每次迭代中,每一个角色不是一直都在忙,团队很难达到高效开发。

在这里我要明确一个观点:接力式的迭代(哪怕每次周期很短)不是敏捷,不是Scrum,还是传统开发模式。

而在敏捷(Scrum)的生命周期中,在某种程度上团队遵循“同时做所有工作”的模式,也就是说,开发人员同时在做需求开发、分析、设计、编码和测试。

在敏捷(Scrum)的生命周期中,在某种程度上团队遵循“同时做所有工作”的模式,也就是说,开发人员同时在做需求开发、分析、设计、编码和测试。如果你只有传统开发的经验,特别是如果你是传统开发模式下CMMI的忠实实践者,你会觉得这种想法很危险:如何保证需求、设计、编码和测试的一致性?如何保证质量?而另一方面,许多开发人员恐怕对这种模式不陌生,他们在巨大的进度压力下都这么做过,特别是一个开发人员同时负责设计开发工作时,他恐怕不愿意为自己单独做设计了。

如果没有过程支持,没有明确团队遵循的公共实践的支持,这种模式对开发人员能力要求会非常高。在这种模式下,要做到不以牺牲质量为代价的高效开发,团队需要有一个大家都理解的开发架构,这个架构能让团队成员清楚地了解到自己负责开发的模块和其他模块之间的关系;需要一个所有开发人员必须共同遵循的编码规范,这个规范要保证代码的持续优化;需要一个能随时验证代码变更正确性的持续集成环境,确保开发隐患的及时清除。

极限编程和Scrum的基本理念是相同的,并且高度互补。例如Scrum的迭代需要极限编程的持续集成、重构等的支持,才能保障维护产品的完整性及可靠性,是解决敏捷增量开发中带病迭代的有效方法。

Scrum的架构及实践也可以很自然地支持极限编程中的管理实践的落地,例如产品经理的角色在某种程度上可以替代现场客户代表,而产品经理在Scrum中的职责及产品需求列表的使用给出了客户代表发挥作用的方式。Scrum中的需求细化会议、迭代计划会议、迭代需求列表等活动及产出物可以有效地实现极限编程的计划活动,加上迭代评审会议及“完成”(Done)的要求,能有效支持极限编程的小版本实践也是自然的结果。Scrum倡导的团队自我管理及自律的要求能保证团队的代码共享及不加班文化。

正是由于极限编程和Scrum的高度互补,目前业界大部分的敏捷实践都是二者的结合,这也是我推荐的敏捷实施模式:Scrum+极限编程能够做到1+1>2。

3.4 引入Scrum等敏捷方法是一场需要勇气的变革

引入敏捷意味着一场大的变革,其影响面经常会被低估,导致在做引入计划时考虑不周全,组织层面缺少必要的支持。当碰到大的问题时,管理者缺乏必要的勇气,往往会选择放弃部分或整个敏捷实践。

让我们首先从大的角度看看敏捷会带来哪些变化。

  • 敏捷会改变我们定义度量业务目标的方式。

  • 敏捷会改变我们的管理方式。

  • 敏捷会改变我们的开发方式。

  • 敏捷会改变我们的考核过程,考核项目团队、考核个人的方式。

  • 敏捷会改变我们将变更风险最小化的方式。

  • 敏捷会改变我们的思维方式。

丘吉尔讲过:“改进意味变革,追求完美就是不断变革。”但是变革需要勇气,任何时候让一个人放弃已经熟悉的做事方式,去尝试一个全新的方法都不是一件容易的事,那么改变一个组织的习惯则是难上加难。敏捷意味着随着大环境的变化不断调整变革,一个敏捷的企业意味着它必定勇于尝试,具备必要的勇气。

华为是一家令人敬佩的企业,通过和它十几年的接触,我认为它的成功不是偶然的。很多人羡慕的所谓华为的“狼文化”,在我看来它更是组织、团队、个人对新知识的渴望。华为是我看到的最有勇气的中国IT企业,它把变革当作学习的机会、超越竞争对手的机会、发展壮大的机会。以敏捷实施为例,华为是国内最早试点敏捷并将其纳入标准过程的企业。当年它成功导入了集成产品开发(intergrated product development,IPD)流程,但一直没有停止对其不断优化。业界新的优秀实践是华为改进的一个重要来源,敏捷的引入也不例外。一旦了解到敏捷可能带来的好处,华为毫不犹豫开始学习、试点并本地化。从2006年前后开始,华为开始了其敏捷之旅,他们请了许多敏捷领军人物来华为做过培训,经过几年的试点、尝试、总结,成功将敏捷融入其IPD流程中,并在2009年正式发布了“IPD+敏捷”新的产品开发流程。当华为开始纠正敏捷不足时,国内许多其他著名IT企业才刚刚开始了解敏捷,在小范围内做试点。

3.4.1 精益组织与敏捷团队

近年来,一些中国的IT企业也开始研究在丰田汽车公司生产方式基础上形成的精益生产模式,希望能将其应用于软件开发管理过程中。由于生产制造和软件开发的巨大差异,很少能看到成功实施案例。敏捷的逐步普及对中国IT企业实施精益方法带来了新的机会,企业层面精益思维能够有效支持项目级的Scrum实施。对精益生产管理感兴趣的读者,可以去看一些精益管理的书籍,找出其和敏捷相通的地方。

图3-2展示了精益组织和Scrum的关系,以及企业存在的目标、使命及价值是如何通过Scrum实现的。

0302.tif

图3-2 精益组织和Scrum的关系

3.4.2 管理者的勇气:做有远见的智慧型领导者

引入敏捷对组织的管理者带来的冲击不比员工小,除了在本章节前面提到的从监控型到服务型的转变外,他们还肩负着更大的责任:领导组织的开发过程及管理实践从传统到敏捷的大转型,这个转型不仅是过程的变革,更重要的是人的转型。放弃熟悉并已使用多年的过程,引入新的过程一定有风险,领导者的勇气、智慧和决心是成功的关键因素之一。

成功引入敏捷需要领导者想清楚以下5件事。

  • 为什么要做:引入敏捷的目的是什么?具体要解决什么问题?有了明确目标,你才能判定敏捷之旅是否成功。

  • 必要的技能:分析完成这件工作所需技能,识别出技能的不足。面对这些不足,组织必须建立一个所需技能的获取计划,保证敏捷在组织内的顺利推动。需要提醒的是,技能不足的分析不仅仅需要在前期执行,而是应该在整个敏捷推动中持续关注,因为很多能力的不足只有在实施中才能更清楚地表现出来。

  • 必要的动力:人的动力从哪里来?敏捷给出了清楚的答案:成就感、自我管理、清晰的目标。那么领导者如何能让执行者保持动力呢?如何和执行者的切身利益关联起来呢?华为有个说法:谁都喜欢雷锋、焦裕禄,机制上不能让他们吃亏。

  • 必要的资源:引入敏捷需要什么样的投入?领导者在规划时就需要有个考虑。注意资源往往是个约束条件,它在很大程度上决定了引入敏捷的速率。

  • 行动计划:哪些部门、团队、项目类型先试点?什么时候将敏捷在确定范围内制度化?在推动敏捷过程中,有哪些里程碑、检查点?我建议用敏捷的方式推广敏捷,但是建立维护组织级的敏捷推广计划是必不可少的,这个计划是监控的基础。

图3-3就是著名的成功变革管理的五要素及其某一要素缺失时的后果。

就敏捷变革而言,如果领导者没有充分沟通清楚变革的目的,那么不同角色的理解会发生混乱,有可能使力不往一处使。我的经验是,在全面引入敏捷之前,需要对职能部门、开发部门、所有的职能角色进行培训,让大家对新理念、影响等方面有一致的理解。

如果领导者不关注必要敏捷技能的获取,那么很可能引入的是形似神不似的敏捷。领导者的责任是提供必要的投入,保证相关人员获取实施推动敏捷所必备的技能。获取这些技能的方式很多,例如,引入松土培训,在试点、实施过程中引入敏捷教练,在内部建立沟通交流机制,让大家逐步掌握敏捷方法、实践和相关的工具。

如果领导者不把敏捷变革和利益相关人的切身利益结合在一起,那么这件事的优先级会很低,会减缓变革的步伐。如果敏捷让人人不安,会极大增加这个变革夭折的可能性。这一条是敏捷企业领导者最重要的管理工作之一。

0303.tif

图3-3 变革管理五要素

如果领导者不保证足够的投入,那么很难将敏捷带来的价值最大化。必要的投入包括办公环境的重新梳理,敏捷管理工具的引入,持续集成工具的引入,外部内部培训的投入等。由于前期的学习磨合成本,有可能一开始团队效率会有些下降,但随着时间推移,逐步会看到效果。图3-4是常见变革效果示意图,领导者需要智慧地看到整个画面,需要有勇气将敏捷变革坚持下去。

0304.tif

图3-4 有效变革效果图

如果领导者不要求建立维护一个清晰的敏捷推广计划,那么就无法监控推广过程,无法做问题影响分析,不知道还有多少事情要做,不清楚是否在按计划实施。用敏捷的计划方式来做这件事,是一个值得推荐的做法,因为敏捷之旅也一定充满了诸多不确定性,在某种程度上也需要摸着石头过河。

作为领导者,只有全面考虑了这5个环节时,才有可能领导一场有效的敏捷变革。

注意,敏捷环境下,管理者将不再会做下列工作:

  • 替团队承诺什么时候完成多少工作;

  • 说服团队这些承诺是可以做到的;

  • 给团对指出具体开发思路、方向;

  • 监控团队的进展情况,确保进度,确保没有大问题;

  • 当团队碰到问题时,介入解决方案的制定及拍板;

  • 每周听取团队进展状况报告,常常和成员做一对一的会议,发现问题并给团队提出具体指导;

  • 用胡萝卜加大棒的方式,激励团队加班加点,完成工作;

  • 给每个成员分配具体任务,并监督完成情况;

  • 为团队在正确时间,用正确的方法,做正确的事负责任。

3.4.3 工程人员的勇气:合奏与独奏

对工程人员来讲,在一个100人团队里面工作和在一个几个人的小团队里工作是完全不一样的。大的团队比小团队更容易混日子,因为人多时,经常会出现忙闲不一的情况,对个人来讲,压力会小很多。

而小团队里,每个人要做的事会更加透明,如果做得不好大家都会看到。想象一下,在每天的站立会议中,你总是不能完成自己的工作,总成为实现迭代目标的瓶颈,这个压力会是很大的。你需要极大的勇气,将压力变成动力,尽快提升自己的能力。就像滥竽充数的故事一样,独奏是要有真功夫的,独奏需要的勇气比合奏大得多。

3.4.4 过程改进人员的勇气:找到你的定位

在一家已实施CMMI或ISO 9000的企业推广敏捷时,你必须面对的一个问题是为EPG(组织过程改进委员会)重新定位。在敏捷环境下如何在组织层面推动过程改进活动?组织改进人员,组织质量保证人员的职责是什么?如何处理对自己工作定位的不确定性?这些都需要过程改进人员有面对新挑战的勇气。

敏捷更加强调的是自下而上的改进,更关注的是团队内部的改进,而不是组织层面的改进。这个敏捷的不足给过程改进人员带来了自己的机会,那就是如何在组织中借鉴共享团队中的优秀实践?如何让团队的迭代回顾会议在组织层面发挥作用?更重要的是如何在从瀑布模式到敏捷模式的转换中扮演重要的角色?

EPG必须是这场变革的组织推动者,在本书后面关于CMMI环境下的敏捷实施相关章节中,我会更加详细描述敏捷企业的过程改进活动的组织、管理。这里我列一些敏捷变革中,过程改进人员应该了解、关注、解决的问题。这些问题没有简单的解决办法,这些问题的解决需要EPG的智慧和勇气,过程改进人员需要有较高的情商,情商也许就是智慧和勇气的结合。

由于敏捷的引入会极大地改变人的做事方式,EPG必须意识到这个转变不可能是一朝一夕的事,需要给大家时间,同时需要在整个变革过程中给大家支持。人其实不反对变化,只要这些变化不需要他们自己去改变。过程改进人员需要让大家意识到敏捷带来的益处,这些益处有组织的、团队的、客户的,但千万不要忽略了其给个人带来的好处。

在整个变革过程中,EPG需要倾听大家的声音:

  • 你们希望的变化是什么?

  • 你们担心的是什么?

  • 你们有什么好的建议让敏捷的变革成功?

这个沟通不是一次性的,必须是制度化的,让组织内部的敏捷实践者随时随地可以将他们的想法转达给EPG。

在沟通的过程中,大家对敏捷的愿景也要逐步形成一个清晰的共识,同时让大家了解为了达到最终目标,哪些东西必须变,哪些是实现目标必须走的步骤,每个人的工作会有哪些变化。EPG必须给出目标是否达到的明确度量,这些度量应该和企业的商业目标有直接或间接的关系。

在敏捷的变革中,EPG也必须将自己定位成服务型组织,也必须有勇气摒弃旧的工作模式,拥抱敏捷,用敏捷模式指导敏捷的引入。

3.5 变革之路:从瀑布模式到敏捷模式的转化

根深蒂固的瀑布思维是敏捷化的最大天敌之一,在瀑布模式下很难想象在需求文档和设计文档还没有通过评审之前,开发团队就开始编码,更难想象允许在编码过程中追加或修改需求。同时瀑布模式的影响远远超出了开发团队,一个软件企业的组织架构,部门之间的沟通机制和客户及市场的沟通方式,人员招聘及员工的职业规划等都会不同程度上受瀑布模式的影响。从瀑布模式到敏捷模式的转变,不仅仅是开发过程的改变,在很大层面上更是企业文化及习惯的改变,后者的变更比前者更难。

3.5.1 瀑布模式到敏捷模式中人和组织的转化

在瀑布开发模式下,设计人员会向设计经理汇报,编程人员向开发经理汇报,测试人员向测试经理汇报,这种组织结构可以支持瀑布接力开发但对敏捷-Scrum的新模式会有负面影响。任何一个企业都不会轻易改变其组织架构,因为这些变化会冲击一些人的利益。但是将矩阵结构转换成产品线为主的跨职能结构很可能是你要做的一个转化。

在从瀑布模式到敏捷模式的转化中,近20%的员工(包括管理人员)可能会选择离职,因为不是每个人都可以接受敏捷的工作模式。

另一个主要组织变化是开发团队是其开发产品质量的责任人,而不是质量管理部。质量控制活动必须贯穿每一个迭代,质量部的人员结构及定位不可避免地会发生变化。

产品管理的职责定位会发生很大的变化,比以前要求更高。选择谁来做Scrum团队中的产品经理,将在很大程度上决定项目的成败。产品经理将会承担很多传统项目经理的责任,管理好风险,确保每个迭代都能开发出最大价值的软件功能是他要做的事情。高层管理人员会向他了解项目的状况。敏捷企业的PMO(项目管理办公室)需要重新定位或被取消。

从瀑布模式到敏捷模式会让其他一些工作消失,做这些工作的员工将被迫走上新的岗位,如项目经理很有可能变成Scrum过程经理,而一些职能经理的管理职能在敏捷环境下将不复存在,这些经理也将面临职业生涯发展的新挑战。他们也许会变成过程经理或产品经理。

敏捷的奖金机制也会发生变化,Scrum不鼓励个人英雄行为,而鼓励的是团队英雄行为。奖金的分发会更大程度上基于团队的表现,如果一个团队有优异表现,那就请奖励团队的每一个成员。一荣俱荣,一损俱损。

3.5.2 瀑布模式到敏捷模式中企业文化及习惯的转化

一个敏捷团队很难在一个没有敏捷文化的企业里成功,因为敏捷是一个端到端贯穿整个企业的行为。那么什么是敏捷文化?如何从瀑布习惯转换成敏捷文化?我认为下面是一些必要的文化变革。

  • 建立价值文化:从进度、技术驱动决策转换成价值驱动。在做任何一个决策时,决策者一定要养成这样一个习惯:同时考虑成本及收益,而不是怎么方便怎么做。这就要求决策者扩大自己的视野,学会从全局看问题,学会平衡短、中、长期利益。敏捷宣言就是价值宣言,价值决策文化必须成为每个大小管理者的思维习惯。

  • 真正建立的团队精神:从推崇个人英雄转换成推崇团队英雄,敏捷追求的核心目标之一是发挥出团队的潜力,在开发中提升团队的能力。成也团队,败也团队的文化应该渗透到每个成员的行动上。

  • “Just do it!”的精神:从追求完美的工程文化转换成关注问题的解决,从追求完满的产品转换为尽快提交为客户带来新价值的产品特性。Just do it!

  • 全员质量文化:很多瀑布模式下的企业把质量仅仅当成测试部门的事,这种文化往往造成开发和测试变成PK的关系。敏捷转型意味着质量是所有人的责任,防止带病迭代是所有工程活动必须关注的事。质量不仅仅是通过测试,质量更是一种意识,一种在开发过程中减少隐患、维护使用的意识。

  • 善始善终的文化:为了追求“效率”,不让员工有任何可能的闲置情况,很多企业会尽量启动很多项目,会让员工同时参与多个项目的工作,善始而不能善终是这种文化常见的后果。敏捷转型更会推崇善始善终的文化,启动一件事就专注地把它做好,尽量避免一个人同时做多件不相干事情的情况。

  • 分而治之的文化:瀑布模式鼓励追求大而全的产品,由此带来追求全面完美的习惯,敏捷则鼓励分而治之,尽量将一个大的复杂工作项分成多个小的、简单的工作项,一个一个地完成。从追求完美转换到追求简单是敏捷带来的另一个变化。

  • 勇于实践、创新的文化:瀑布模式带来高昂的变更成本,使得团队在开发过程中努力第一次把事情做好,不犯错误。而敏捷带来的快速反馈,让变更成本变得可以接受。鼓励团队勇于实践、勇于创新是敏捷转型中的另一变化。

3.5.3 瀑布模式到敏捷模式的转化过程

开发过程的改变是瀑布模式到敏捷模式最显著的变化,是所有人都能看到的变化。从瀑布模式到敏捷模式,开发过程不是简单的简化,而是多层次、多方面的改变。

  • 过程改进管理的变化:在敏捷模式下,“过程的执行者是过程改进的主人”,这句话变得更加实实在在了。过程改进的主要执行者是Scrum团队自己,每轮迭代最后一个活动就是对执行敏捷过程中的问题进行根因分析,找出改进实践,完善团队的Scrum过程实践。这些改进的落地是实时的,因为它们可以在紧接着的迭代中得到实施。这些新的变化大大完善了CMMI框架下的过程管理改进。

  • 过程架构的变化:引入敏捷后,组织内的项目类型会更加丰富:可能有遵循传统开发模式的项目,有遵循敏捷方式的项目,有可能也有遵循二者结合的项目。所谓过程架构在某种意义就是项目开发流程的全景视图,当然站在不同角色的角度,这个视图会不一样。过程架构于心,我们才能清楚了解不同子过程、方法、实践、过程产出物等之间的关系。

  • 方法实践的变化:敏捷的引入会改变很多管理、工程和支持活动的方法及实践。如项目估算方法会有很大的变化,技术评审方法、配置管理方法等都会有很大的变化。我们需要在组织层面形成敏捷模式下这些方法实践的新定义。注意这些变化很有可能对相关联的子过程及产出物也有影响,任何过程变更不能损害过程的一致性。

  • 工具的变化:瀑布环境下的管理方式是任务驱动,而敏捷则是需求特性驱动,这个转换会要求团队替换旧的工具,引入敏捷管理工具。其他必要的工具引入也是敏捷转型中必要的投入,如持续集成工具等。

在从瀑布模式到敏捷模式的转换过程中,需要对原有的过程体系做一个全面的梳理,识别出需要追加的新内容,需要更改的内容,以及需要淘汰的内容。规划好过程的变更,不要妄图一口吃成个胖子,一步一步完成这个转换即可。导入Scrum最好的方式就是用类似Scrum的方法,通过持续迭代,不断收集反馈,逐步完善,完成从瀑布模式到敏捷模式的成功转换。

两个团队的故事

故事1:紧急项目的故事——让过程合理合法

几年前,我帮助一家国内国有IT企业做过程优化,虽然这家企业已经通过了CMMI四级评估,但公司领导认为开发过程还是不能有效支持组织的业务目标及客户的期望。在和项目经理访谈时,我问了一个问题:“如果给你一个绝对权力,允许你更改组织过程中的任何一块内容,你会改什么?”参加访谈的项目经理异口同声地提到了所谓紧急项目管理流程的问题:所谓紧急项目,是一些进度压力大的项目,这类项目往往带有一定的政治任务,有刚性的进度要求,如果按组织定义的标准过程来管理它们的话,一般是无法按时完成的。由于组织要求所有开发项目都必须遵循四级体系的要求,这就造成了这类项目的管理困境,如果完全按过程要求做,就不能满足进度目标,所以团队往往会在执行过程中走很多捷径。这也让PPQA(Product and Process Quality Assurance,过程与产品质量保证)人员很为难,因为他们知道,如果按过程检查单做稽核,识别出许多不符合项的话,由于进度压力,项目组也很难对这些不符合项进行整改,最后大家只好睁只眼闭只眼。我把这种现象称为“合理不合法”,合理说的是项目组被逼做出必要的裁剪(不一定是合适的),不合法讲的是实际的过程是不符合组织过程要求的。

紧急项目的问题显然是一个优先级高、必须尽快解决的问题,因为它直接影响了项目质量、效率,对项目开发团队认可过程改进、CMMI有很大的负面影响。我们决定将其列为当年的一个改进专题。首先我和开发部领导、项目经理以及分管需求及生产任务的职能部门领导一起,讨论确定界定紧急项目的标准:究竟什么样的项目可以认为是紧急项目?我们定义了下列4项界定标准。

1)工期短:项目开发周期从项目组接收到开发指令至提交UAT(用户验收测试)版本的时间要求,原则上在两个自然月(含)以内。

2)刚性的外部时间要求:在确保特定的质量要求下,系统能否在规定时间内按时上线对组织的声誉、市场、战略等有较大的影响。

3)范围确定:需求范围是确定的,没有缩减的余地。

4)任务量与工期不匹配:特定资源下工作量大,若按正常流程,很难在指定工期内完成任务。

在和组织的核心管理、工程人员讨论建立紧急项目实施指南时,我问了大家两个问题。

问题1:在你们的组织中,哪些工程活动是必不可少的活动?哪些是锦上添花的活动?哪些仅仅是为了符合CMMI、ISO 9000等过程标准的?

问题2:哪些是必不可少的管理活动?哪些是必不可少的文档?哪些是必不可少的度量项?哪些归档可以在结项后完成?

针对第一个问题,大家讨论后给出了下列不可少的核心工程活动及原因。

需求澄清评审:没有需求评审和澄清,开发人员无法真正理解要开发的系统,就不知道要做什么。

总体设计:好的总体设计可以给所有开发人员一个公共架构,减少沟通及潜在返工成本。

编码:没有代码就没有软件产品。

测试:测试让开发团队了解什么时候开发可以结束。

当我告诉大家,这4个活动也是业界敏捷领军人物识别出来的核心活动时,他们都非常开心。我接着问了一个新问题:我们如何做这4件事,才能做得好、做得快?这个问题也引出了热烈讨论,但是没有达成明显的共识。他们问我业界有没有一些可借鉴的东西,我花了半天时间给大家介绍了极限编程的价值、核心理念以及相关实践。我向他们推荐了Kent Beck的极限编程的书,建议他们结合实际认真看看其中的12条实践,研究一下其中的例子,一周后我们再讨论紧急项目的工程过程。

他们当天在网上买了这本书,后来很多人告诉我,他们一口气读完了这本书,并结合紧急项目特点边读边做笔记。除了结对编程及不加班,我们全部或部分引入了其他所有的极限编程实践,在此基础上形成了紧急项目工程及管理流程。

在讨论第二个问题时,我引导大家摒弃任务驱动的管理模式,采用需求驱动的管理模式,简化管理计划、跟踪活动,简化管理文档。在此基础上,我们很快形成了紧急项目管理指南初稿。经过6个项目的试点,这个指南变成了体系的一部分。让所有人高兴的是:这6个项目的生产效率大大高于组织级效率基线,同时

这6个项目的遗留缺陷率也都低于组织级的平均基线。

在年底总结时,公司领导问我:我们为什么不将这种做法推广到其他项目呢?

 

故事2:用Scrum的方式引入Scrum

这个故事描述了一家软件企业第一年的敏捷之旅。

KS是中国南方一家知名软件公司,它在6年前第一次通过CMMI三级评估,并在3年前通过复评。KS产品开发过程一致遵循瀑布模式,两年前管理层决定在公司内部引入Scrum为主的敏捷方法。KS的CEO李总在和一些美国IT企业合作过程中,看到了敏捷带来的好处,他在美国期间参加了Scrum过程经理及Scrum产品经理的培训,研究了许多敏捷书籍,特别是Scrum创始人写的一些关于导入Scrum的书。参考一些成功转型的敏捷企业,李总决定用Scrum的方式引入Scrum。

李总做的第一件事,是在公司层面成立了敏捷转型Scrum团队,他亲自做这个团队的产品经理,直接管理推广Scrum过程中的任务项,指导团队攻克下一个价值最高的任务。一位有经验并且有成功敏捷经历的敏捷教练被李总聘请为这个团队的Scrum过程经理,指导公司的敏捷之旅。几位公司副总、开发部门及职能部门(包括人力资源、财务、市场销售、行政等部门)的经理成了团队的其他成员。

敏捷转型需求列表对应的产品是一个敏捷化的组织,其产品开发过程由瀑布模式转换成敏捷模式。列表中的需求项来自转型团队及Scrum开发团队在实施Scrum中碰到的困难障碍及重要的任务。

敏捷转型团队将迭代周期定为4周,在迭代计划会上,需求列表中优先级高的任务项被选中,团队会选择建立执行团队来清除敏捷转型中遇到的障碍,完成任务项。在每天的例会中,转型Scrum团队为执行团队提供支持、指导。正在实施Scrum的开发团队的过程经理也会在会上提出团队碰到的、需要公司领导帮助解决的问题。

在迭代评审会议上,大家会展示各部门在上个月(本轮迭代)敏捷转型带来的变化,并调整需求列表中的任务项;而在迭代回顾会上,执行团队会分享好的实践及教训。

经过一段时间的准备,李总主持召开了由转型团队成员及其他高层管理人员参加的敏捷启动会议。参考Ken Schwaber(2004)建议,会议在3小时的时间内完成了下列议题。

  • 就公司敏捷转型的目的形成清晰的文字表述,它们将成为转型所做决策的依据。

  • 过程经理(敏捷教练)给大家介绍了敏捷团队将要遵循的Scrum过程,让大家对新的过程有个基本了解,并解释了一些大家后面会经常听到的新的敏捷术语。

  • 审定敏捷实施团队成员及转型团队将要遵循的Scrum工作方法,以及如何识别敏捷推动中的问题。

  • 讨论敏捷可能带来的各种变化及影响。

对下列具体事宜做出决定:

  • 转型团队第一次迭代计划的日期;

  • 正式确定敏捷教练为转型Scrum团队的过程经理;

  • 正式确定李总为团队的产品经理;

  • 正式确定团队成员。

确定了下列任务项作为产品需求列表中的初始内容:

  • 所有转型团队成员完成Scrum联盟的ScrumMaster证书培训;

  • 研究并建立跟踪组织内部变化的方法及机制;

  • 确定敏捷试点范围:项目类型、试点项目项目团队;

  • 确定试点Scrum团队角色;

  • 确定试点范围完成准备要求的标准;

  • 制订并执行组织的敏捷实施沟通计划,通过各种会议,面对面地让所有人了解敏捷转型可能带来的变化;

  • 在公司内部网建立并维护“敏捷之角”,让所有人了解转型过程;

  • 调整公司内部过程改进反馈处理机制,确保任何人在任何时间、任何地点都可以提出针对敏捷实施的反馈及建议;

  • 制定组织转型需求列表追加机制,确保相关人员都可以将需要克服的困难加入列表中;

  • 调整度量体系,建立跟踪Scrum项目的度量项和使用指南;

  • 建立针对Scrum项目的汇报沟通机制。

启动会结束几天后,转型团队召开了第一次迭代计划会议,根据需求列表的内容及优先级,确定了下列迭代需求列表。

  • 在全公司范围内宣贯敏捷转型的目的、推动计划以及对组织和个人的影响。

  • 全员Scrum培训让大家了解引入敏捷的理由、Scrum过程及对个人的期望。

  • 通过“敏捷之角”回答大家提出的任何问题。

  • 确定下列实施Scrum的先决条件:建立一个全职跨职能团队;Scrum过程经理接受Scrum过程经理培训;产品经理接受产品经理培训;所有团队成员接受Scrum团队成员培训;建立一个能支持Scrum活动的办公环境。

  • 建立敏捷项目汇报机制及渠道。

  • 选择第一批敏捷试点项目。

  • 选择这些项目的Scrum过程经理、产品经理和团队。

  • 建立Scrum度量及其收集使用机制。

  • 开始建立维护敏捷转型产品需求列表。

  • 评估支持敏捷模式开发的考核办法。

敏捷实施执行团队具体执行迭代列表中所列任务,在实施过程中将识别出的困难障碍不断纳入需求列表中。这样第一轮迭代开始,也意味着敏捷转型在KS公司逐步推开。

从第二个月开始,更多的项目开始使用Scrum,转型团队面临的第一个问题是:是否一定要等一切都准备完美了,才能开始敏捷之旅?是否可以一边实施Scrum,一边解决这些问题?转型团队决定只要前提条件基本满足,项目就可以遵循Scrum开发模式。因为敏捷之旅本来就充满不确定性,用Scrum方法来指导Scrum实施是最好的保障。

新的任务项不断加到转型需求列表中,它们主要来自Scrum开发团队、转型团队和敏捷执行团队在实施中碰到的困难。产品经理李总将问题分成两类:一类是Scrum带来的问题,而另一类是原来就有现在被Scrum凸显的问题,识别出的大部分障碍都属于第二类。

前几个月中,主要问题集中在以下几个方面。

  • 瀑布习惯是敏捷转型的普遍问题,这不光体现在开发团队本身需要基本摆脱文档沟通、接力开发模式,其他利益相关人也需要适应敏捷模式。以往客户的参与主要集中在一头一尾,而敏捷的增量开发需要他们自始至终地介入。特别是政府客户,往往不习惯这种模式。人力资源部在做岗位设置、为员工做职业规划时,也是按瀑布模式来做的。转型团队发现观念的改变十分困难。

  • 执行团队缺乏必要的权力及技能推动敏捷转型。有些执行团队成员会将自已应该负责的工作布置给下属去做,没有尽到应尽的责任,在许多配合上不到位,难以达到Scrum的目的。

  • 所有的Scrum项目都在实施不全的Scrum,它们在不同程度上绕过了一些有难度的Scrum实践,实施过程遇到困难时有停滞不前的情况。

  • CMMI和敏捷结合带来的问题,如EPG(过程改进委员会)在转型中的定位、QA(质量保证)人员的定位等。

  • Scrum本地化的问题。一个简单的例子是如何将Scrum术语本地化,大部分转型团队成员建议用大家熟悉的叫法替代Scrum术语。但敏捷教练(转型团队过程经理)则建议为了显示敏捷转型的决心,还是尽量用Scrum中的术语,而且这些术语量也是非常有限的。例如,如果还用项目经理替代Scrum过程经理的话,会给这个角色以他还拥有传统项目经理的责和权的错觉。

  • 真正的透明需要有敢讲真话的环境,敏捷依赖于完全透明,在敏捷转型前期,很多项目团队还没有完全讲真话的安全感。

  • 在同一时间段想变革的东西太多,急功近利,欲速则不达。有些管理人员希望能“立竿见影”,短期内就“大见成效”,导致没有找到好的切入点。以最容易做到、最明显的改善成果来让每一个人都感受到Scrum的好处,从此改变意识,建立信心。

在第一年里,敏捷转型团队在摸索中完善,边做边总结,一轮一轮地迭代,李总要求碰到问题时要集思广益,准备多个解决方案;打开心胸,吸取不同意见,不要解释不能做的理由,要想出做下去的办法;不要等到十全十美,有5成把握就可以动手,错了就及时调整。随着时间的推移,KS公司中越来越多的项目引入敏捷模式,其带来的价值也逐步体现。我问李总最大的感受是什么,他说:“企业文化、习惯比任何策略都更加重要,敏捷转型更多的是企业文化的转型。”

目录

相关技术

推荐用户