第 1 章 学习敏捷

第 1 章 学习敏捷

对继续学习的渴望是一个人可以形成的最重要的态度。

——约翰 · 杜威,《经验与教育》

这是一个令人激动的敏捷时代。对于一直困扰软件开发团队的种种问题,IT 行业首次找到了真正可持续的解决方案。以下是敏捷承诺的几种解决方案。

  • 敏捷项目可以按时完成,为那些苦恼于交付期限和预算的团队带去了福音。

  • 敏捷项目交付高质量的软件,那些受困于 bug 和低效软件的团队会迎来巨大的变革。

  • 敏捷团队构建的代码结构优良且易于维护,那些常常维护复杂又混乱的代码的团队会得到解脱。

  • 敏捷团队会让用户满意,不再交付无法为用户带来价值的软件。

  • 最重要的是,在出色的敏捷团队中,开发人员不用加班,可以与亲朋好友共度晚间时光和周末。这在他们的职业生涯中可能是史无前例的。

敏捷之所以流行,是因为很多走敏捷路线的团队都表示收获颇丰。它们构建出了更好的软件,团队成员间合作更为愉快,用户的需求也得到了更好的满足,工作环境也更加轻松愉悦。一些团队在接纳敏捷理念之后终于可以在困扰多年的问题上有所进展。那么,伟大的团队如何利用敏捷理念构建更好的软件?更准确地说,我们自己怎样才能利用敏捷理念取得如此好的结果呢?

在本书中,读者会学到两种最流行的敏捷方法:Scrum 和极限编程(eXtreme Programming,XP)。此外,读者还会学习到精益(Lean)方法和看板(Kanban)方法,了解如何通过它们理解当前采用的软件构建方法,并改进当前的状况。通过本书,读者还将明白一点:尽管这四种敏捷学派关注的是软件开发中的不同领域,但它们有一个重要的共同特点:重视改变团队的思维模式

正是因为转变了思维模式,一个仅仅接触敏捷实践皮毛的团队就可以获得提升,从而真正改进其软件构建方式。本书的目标是帮助读者深入了解敏捷的两个方面:一方面是日常工作中的种种实践,另一方面是敏捷的价值观和原则。后者能够帮助团队从根本上改变构建软件的思维模式。

1.1 什么是敏捷

敏捷是指能够让团队思考更加有效、工作更为高效,并且作出更好决策的一组方法和相关理念

这些方法和理念适用于传统软件工程的所有领域,例如项目管理、软件设计、软件架构和流程改进。每种方法和理念都包括实践。这些实践经过了精简和优化,应用起来非常方便。

敏捷也是一种思维模式,思维模式的正确与否会影响团队具体实践的高效程度。正确的思维模式有助于团队成员共享信息,从而共同作出重要的项目决策,而不是让经理独自负责所有的决策。敏捷思维模式涉及整个团队的开工计划、设计和流程改进。在敏捷团队所采用的实践方式中,大家不仅共享信息,而且对实践的应用方式都有发言权。

敏捷在有些团队中还没有取得成功,这造成了现实和承诺之间的差距。这种差距形成的关键往往在于项目团队的思维模式。很多构建软件的公司都尝试过敏捷开发。许多团队尝到了成功的甜头,而一些团队却结果平平。尽管这些团队在项目运作上有所改善,这些改善也足以证明采用敏捷的努力是值得的,但是他们并没有看到敏捷方法承诺的那些实质性改变。这就是改变思维模式的意义所在。走敏捷路线意味着帮助团队找到一种高效的思维模式。

那么,改变思维模式到底意味着什么?如果你是软件团队中的一员,那么你每天的工作就是规划、设计、构建和发布软件。思维模式与这些有什么关系呢?事实证明,你在日常工作中采取的实践很大程度上取决于你和其他团队成员对待实践的态度。

举个例子:每日站立会议(daily standup)是很多团队都采用的一种最常见的敏捷实践。在每日站立会议上,每一位成员都会讲述自己手头的工作以及面临的挑战。为了使会议简短,大家在会议期间全程站立。很多团队在项目中引入每日站立会议,因而获得了很大成功。

假设有一位刚开始学习敏捷的项目经理,他想在项目中引入每日站立会议。令他意外的是,并不是所有人都像他那样对这一新实践欣喜若狂。组里的一位开发人员非常气愤,项目经理竟然要增加一种新的会议,而且他似乎也感觉很不舒服,因为每天都要在会上被问及自己的工作情况。

那么这里到底出了什么问题?是开发人员不讲道理,还是项目经理要求太多?为什么这样一项被广泛接受的简单实践会引发一场冲突?

项目经理和开发人员双方各执一词,言之凿凿。项目经理面临的最大挑战之一是项目规划,这需要投入大量的精力。如果在构建软件时遇到问题,那么团队就有可能偏离当初的计划。项目经理必须努力了解每个人的工作情况,这样才能调整计划,帮助大家解决问题。

{%}

图 1-1:一个项目经理想要在团队中开展每日站立会议,却惊讶地发现,并不是所有人都立即表示赞同

而从开发人员的角度看,每天的各种会议会频频打断手头的工作,导致任务很难完成。他知道如何构建自己的代码,不需要另一个人在他耳边唠叨什么计划和变化。他只想一个人静静地写代码,他最不愿意做的事就是再多开一个会议。

{%}

图 1-2:两个人似乎都有充足的理由解释自己为何如此看待每日站立会议。这将对项目产生什么影响呢

设想一下,假设这位项目经理能说服所有人(包括上面那位有抵触情绪的开发人员)参加每日站立会议,那么这个会议会是什么样子?项目经理主要关注实际执行情况与最初计划的差距,因此他会关心每个人的工作情况。而开发人员则希望会议尽快结束,所以根本不注意听其他人汇报,只等自己开口汇报,而轮到自己的时候,则尽可能地长话短说,快点结束。

我们应该清楚,这就是许多每日站立会议的现状。这样的每日站立会议并不理想,但仍然有成效。项目经理能看出自己的计划存在什么问题,而且从长远看,开发人员也能从中受益,因为对他们确实有所影响的问题可以由此尽早解决。从总体上看,这利大于弊,值得付诸实践。

那么要是开发人员和项目经理的思维模式不同会怎么样?如果团队中每一位成员对每日站立会议的态度都截然不同会怎么样?

例如,如果项目经理希望团队中每一位成员都参与到项目计划中,会怎么样?项目经理会真心倾听每一位团队成员,不仅仅是为了检查团队成员是否偏离了自己的计划,还要尝试理解群策群力下的计划可能需要怎样改变。项目经理不会简单地将计划丢给团队并下达命令,然后考核团队执行计划的程度,而是与团队成员一起找出完成项目的最佳方式。每日站立会议就是这样一种合作方式,这有助于确保所有成员时刻保持高效。项目的状况每天都会变化,而团队可以利用每日站立会议作出最有效的决策。由于团队每天都会碰头,所以会议上讨论出来的计划变更可以立即应用于实际工作,这就节省了在错误的道路上渐行渐远的时间。

如果开发人员觉得开会不仅报告了状态,还可以理解当前项目的进展,并且可以每天与大家一起探讨如何更好地工作,会怎么样?果真如此,每日站立会议对他来说就会非常重要。优秀的开发人员不仅对自己的代码有想法,而且常常对整个项目的发展方向怀有见解。通过每日站立会议,他可以确信项目正在以合理高效的方式运行。他还可以确认,从长远看自己的编码工作可以得到更好的回报,因为项目中的其他部分也在正常运转。他还会知道,如果他在会议中对计划提出问题,那么其他所有人都会倾听,项目也会因此更健康地进行下去。

图 1-3:如果团队中每一位成员都觉得自己在项目规划和运行中享有同等地位,那么每日站立会议就会变得更加有价值,而且更加有效

换句话说,即使团队中所有成员都认为“每日站立会议就是一种不得不一起做的进展汇报”,这仍然值得实施,尽管它只比传统的进度报告稍微有效一点儿。要是所有团队成员都明白,每日站立会议的目的是保证每一位成员都在正轨上,大家都在为同一个目标努力,而且每个人都可以对项目的运转方式发表自己的看法,那么每日站立会议就会高效得多,而且所有人都会更加满意。开发人员应该明白,每日站立会议从长远看对他自己和整个团队都是有帮助的。而项目经理应该明白,当团队成员齐心协力完成计划的时候,项目可以得到更好的结果。有了正确的态度,每日站立会议就可以帮助大家更高效地团结协作,更直接地沟通,更轻松地把工作做好。

上面这个例子展示了团队的思维方式和态度对于接纳敏捷实践的巨大影响。本书的一个重要目标是帮助你理解团队的思维方式会对项目和敏捷实践产生怎样的影响。通过探究 Scrum、极限编程、精益和看板方法,你可以从原理和实践两方面学习敏捷,还可以学会如何综合利用这些敏捷方法,构建更好的软件。

1.2 本书的读者对象

你和你的团队有没有遇到过下面描述的这些情况?

你尝试了一种敏捷实践,但是并没有成效。也许你们确实实施了每日站立会议,现在团队每天都会碰一次头,但你还是被各种问题所困扰,理不清头绪,而且无法按时完成任务。也许你已经开始编写用户故事,并且与团队和利益干系人一起审核这些用户故事。但是你手下的开发人员仍然在手忙脚乱地添加特性,应付不停变化的需求。也许你的团队尝试采用 Scrum 或极限编程之类的方法进行大规模敏捷化,但似乎总是感觉华而不实,好像所有人都做了必要的事情,但是项目得到的改善却微乎其微。

又或许你们还没有开始尝试敏捷,但是你已意识到你的团队正面临严峻的挑战,而你不知道从哪着手。你希望敏捷方法能帮你应付那些总是在改变想法的严苛用户。用户每次改变需求,你的团队都需要做更多的工作,最终得到的代码打满了补丁,像意大利面一样纠缠不清。于是软件越来越容易出错,也越来越难维护。你的项目可能一团混乱,最终能够发布全靠加班和逞强,而你希望能通过敏捷给团队指一条出路。

你可能是一位担心手下团队无法交付重要项目的高管。你也许听说过敏捷,但是并不知道敏捷到底是什么意思。你能不能直接命令手下的团队采用敏捷?或者说你是否需要跟着团队一起改变思维方式?

如果你面临上述情况中的任意一种,而且想改进团队工作的方式,那么本书可以帮助你。

本书会解释敏捷方法的理念,包括敏捷方法的产生、能解决的问题,以及包含的价值观、原理和思想。本书会讲解敏捷的过程,进而讲解其着眼点,让你能够找出相关原理,以解决团队、公司和项目中遇到的问题。本书会教你如何利用这些信息选择正确的方法和实践。

本书还适合一类人,那就是敏捷教练(agile coach)。公司和团队越来越依赖敏捷教练来指导他们采用敏捷方法和实践,以及为团队中每一位成员树立正确的思维方式。敏捷教练可以通过本书学习一些方法,借此更好地与团队沟通敏捷思想,应对日常敏捷训练的挑战。

1.3 本书的目标

我们希望你可以通过本书达成以下目标。

  • 理解高效敏捷团队背后的思想动力,以及整合这些思想所需要的价值观和原则。

  • 了解最流行的敏捷流派(Scrum、极限编程、精益和看板),理解这些各不相同的方法如何实现敏捷。

  • 学会可以立即用到项目中的具体敏捷实践,同时熟悉高效实践所需的价值体系和原则。

  • 更好地理解自己的团队和公司,进而选择与你自己的思维方式匹配(或尽可能匹配)的敏捷方法。让你和你的团队开始学习一种新的思维方式,从而向更高效的敏捷团队迈进。

这些不同的敏捷方法和实践对于构建更好的软件到底有什么帮助?为什么这些方法可以让团队更好地处理变化?为什么这些东西是敏捷的?这些具体的做法,比如在规划的时候使用索引卡或开会的时候站着,真的有用吗?对于刚刚踏上敏捷之路的人来说,这些问题很难回答,而且往往让人感到困惑。读完本书之后,你就会有自己的答案了。

查找讨论敏捷软件开发的博客和文章,你可能首先会看到这样的观点:“敏捷开发好,瀑布式开发不好。”为什么敏捷开发好,而瀑布式开发不好?为什么这两种方式互相冲突?有没有可能让一个采用瀑布式开发方法的团队敏捷起来?读完本书之后,这些问题也会有答案。

1.4 努力建立敏捷思维

本书名为《学习敏捷》,因为我们真切地希望你学会敏捷。过去二十多年,我们一直在与为真实用户开发软件的团队一起工作。过去十多年,我们也一直在撰写与软件开发相关的图书(包括 O'Reilly Head First 系列中非常成功的两本书,分别是关于项目管理和学习编写代码的)。借助这些经验,我们发现了很多介绍复杂概念和技术概念的方法,可以让枯燥的内容变得平实易懂。

我们尽量让这些材料有趣且吸引人,但这里仍然需要你的配合。下面来介绍一下本书通篇使用的教学技巧,它们可以帮助你牢牢记住书中的知识。

  • 故事

    回想一下你读过的上一本技术书。你能不能回想起那本书涵盖的所有主要内容,以及这些内容的顺序?你可能做不到吧。那么再想想你看的上一部电影。你能不能回想起那部电影中的重要情节,以及这些情节的顺序?你可以做到。这是因为大脑天生擅长记忆引起情感共鸣的事情。本书充分利用了人脑的这个特点,以叙事的方式展开,故事中有人,有对话,有冲突,由此表现人们遇到敏捷时的真实反应。这些人会碰到问题。

    我们需要你做的是:想象自己和书中人物遇到了同样的情况,这样可以与敏捷思想建立起情感连接,从而更容易记住并理解这些概念。对于书中的小故事,请保持开放的心态。如果你不喜欢看小说,那就更要如此。在每一个叙事场景中你都可以学到真正的知识,而这些知识就是本书的核心。

  • 图示

    不同的人会采用不同的学习方法。有些人是视觉型学习者,这些人看到真实画面的时候更容易记忆。我们希望为你提供尽可能丰富的学习工具,因此本书中穿插了大量的图示。在某些情况下,我们会大量使用视觉隐喻,例如通过不同的几何形状来表示不同的特性,或者通过齿轮的形状表示复杂的软件。

    我们需要你做的是:如果不是视觉型学习者,你可能觉得有些图示是多余的,而某些图示根本没有意义。但这对你来说是一个很好的学习机会。如果真有这种感觉的话,你应该花一分钟时间思考一下视觉型学习者能从图示中学到什么。这有助于更深入地理解概念。

  • 重复

    大部分技术书都会采用这样的模式:首先介绍一个概念,然后详细阐述这个概念,接下来讲解下一个概念。这种方法可以有效地在一本书中尽量塞入更多的信息,但并不契合人脑的工作方式。有时候,人们需要反复接触才能真正理解一个概念。因此,本书会在一章或几章中反复提到某个概念。这种重复是有意为之,目的就是帮助你深入理解概念。

    我们需要你做的是:当你第二次或第三次看到某个概念的时候,可能会想:“前面不是提过这个概念了吗?”没错,确实提到过,能注意到这一点说明你很棒!其他的读者可能没有注意到,而你也很难发现每一次重复。这些重复的目的就是为了帮助你学习。

  • 由简入繁

    有时候,为了更轻松地理解一个复杂的主题,你可以先了解一些浅显的知识,然后再深入进去。本书便时常采用这种方式:介绍新概念时,首先讲解一个简化的版本(当然,此处并无原理性漏洞),之后再进行详尽的介绍。这种方式有两个层面的作用。如果已经深入理解了这个概念,那么你可以认出这种简化,并且在情感上有反应,这可以让你保持参与。另一方面,如果你还不了解这个概念,那么简化的版本可以帮助你入门,为接下来深入的描述打好基础。

    我们需要你做的是:如果觉得有的内容过于简单,先别急着跳过,也不用担心我们避重就轻或是忘记了重要的内容。你很可能会在继续阅读的过程中发现正在寻找的内容。你可以把复杂概念的简单介绍看作某种“Hello, World!”程序。这些内容可以让不熟悉这些概念的读者受到一定的鼓励。他们会有步入正轨的感觉,并且为后面更深入的学习打下基础。

  • 对话式的口语文风

    为了使内容更加吸引人,本书通篇采用轻松随意的文字风格。我们在写作中使用了幽默,时不时抖一些文化包袱。有时候我们会用“我们”和“你”这样的代词,表示我们在直接与你对话。这种做法背后是有科学依据的,认知研究 1 表明,如果感觉自己在进行对话,那么你的大脑就能记住更多东西。

    我们需要你做的是:尽管大部分人觉得随意一点并没有什么问题,但是有些人的确讨厌这种风格。例如,有的读者看到缩写就会气愤,还有一些人看到随意的文风会觉得内容不够权威。我们理解这些顾虑。不管你信不信,你很快就会接受本书的风格。

  • 要点回顾

    每一章都会随时总结刚刚讲解的要点。这样可以帮你掌握所有的知识,不会遗漏重要的概念。你的大脑也可以借机稍事休息。

    我们需要你做的是:不要跳过“要点回顾”部分。花点时间看看这些要点。看看能不能回忆起其中的每一个点。如果想不起来的话,往前翻几页增强一下记忆。

  • 常见问题

    我们花费了大量时间与为真实用户构建真实软件的团队一起工作,也花了很多时间做关于敏捷的演讲,还与很多人沟通过。在沟通的过程中,有一些问题是大家反复提到的。

    我们需要你做的是:阅读每一章末尾的“常见问题”部分。思考一下,这里列出的问题你是不是遇到过?如果是,你觉得这个答案怎么样?你也许不喜欢我们给出的答案,但是请思考一下,并找出其中的真理。如果那不是你遇到的问题,也请思考一下为什么会有人问这样的问题,这种思考可以帮助你从不同的角度理解书中的内容(在第 2 章,你会明白为什么在团队中这种思考非常重要)。

  • 现在就可以做的事

    最有效的学习方法就是付诸实践!每一章的结尾都给出了现在就可以动手去做的事情,包括你可以独立完成的,以及需要与团队合作的。

    我们需要你做的是:显然,你最好真的动手去做!不过现实情况是,并不是每一个团队或公司都对此持开明态度。因此,本书要教给你的最重要的一件事情就是:不要推行与团队思维方式相抵触的实践,这样做不会有好的结果。在尝试动手之前,你要首先考虑一下团队会有什么反应。这与实际动手一样重要。

  • 更多学习资源

    牛顿曾经说过:“我能看得更远,是因为我站在巨人的肩膀上。”在这样一个时代写作本书是幸运的,因为现在已经有了众多关于敏捷软件开发的开创性图书。在每一章的末尾,我们会给出一些与该章内容相关的参考资料。

    我们需要你做的是:不断学习!本书全面概述了 Scrum、极限编程、精益和看板方法,但是我们不可能涵盖这些方法的所有细节。本书介绍的大部分思想都不是我们想出来的;幸运的是,你可以向想出这些方法的人学习。

  • 教练技巧

    敏捷教练是帮助团队学习敏捷的人。本书为学习敏捷的人而编写,同时也可以作为一份指南,帮助有经验的敏捷教练向团队介绍这些概念。如果你是一位敏捷教练,那么可以在每一章末尾找到教练技巧。教练技巧可以让你理解我们使用的概念和方法,并且帮助你在自己的团队中使用这些方法。

    我们需要你做的是:即使不是敏捷教练,你也应该读一读教练技巧,因为教别人是一种有效的学习方法。如果是第一次学习这些概念,你可以想象一下自己要怎样利用这些教练技巧帮助团队更深入地学习敏捷。

1如果你想知道对话式文风如何有助于学习,可以看一看 Ruth C. Clark 和 Richard E. Mayer 的著作 E-Learning and the Science of Instruction

1.5 本书结构

本书讲解了高效软件团队的价值观和原则、包含这些价值观的学派以及具体实践,以此帮助你理解敏捷。

下面两章讲的是接受敏捷思维方式所需要的价值观和原则。借助这两章所介绍的方法,你可以判断团队和公司是否准备好了接受敏捷,以及哪些敏捷方法适合你的团队而哪些方法可能很难实施。

  • 第 2 章阐述了敏捷的核心价值观。我们会展示软件开发项目团队和困难作斗争的例子,帮助你识别问题的主要来源,也就是“割裂的视角”。我们会讲解敏捷价值观,并且通过一个隐喻帮你理解这些价值观如何统一整个团队的视角。

  • 第 3 章介绍了敏捷团队在进行项目决策时要遵循的原则。我们会通过一个实际的软件开发项目的例子,展示每一项原则背后的目的和思想。

接下来的 6 章讲解最流行的敏捷学派:Scrum、极限编程、精益和看板。学完书中讲解的基本应用,你就可以在团队中进行实践。

  • 第 4 章讲解了流行的敏捷方法 Scrum,并且说明了自组织团队如何工作。我们给出了在自己的项目中引入 Scrum 的方法,还给出了帮助团队学会自组织的工具。

  • 第 5 章展示了 Scrum 团队规划项目时采用的具体实践,以及如何利用这些实践在团队中整合力量,交付有价值的软件。我们会揭示 Scrum 价值观与团队及公司文化的契合程度,这决定了 Scrum 的接纳程度。我们还会谈到不契合的情形,以及应对方法。

  • 第 6 章会教给你极限编程的主要实践及其价值观和原则。你会了解它们如何有助于每一位团队成员建立正确的思维模式,以便写出更好的代码:不要憎恨变化,团队中的每一位成员都要学会拥抱变化。

  • 第 7 章讲解了极限编程的最后三个主要实践,以及如何利用这些实践避开严重的代码和设计问题。你会了解所有极限编程实践如何构成一个生态系统,帮助构建更好、更易维护、更灵活以及更可变的软件。

  • 第 8 章讲解了精益方法,以及建立精益思维方式所需要的价值观。我们会讲解如何利用精益思考工具帮助团队发现并消除浪费现象,以及如何对构建软件的系统建立全局观。

  • 第 9 章介绍看板方法及其原理、看板方法和精益方法的关系,以及看板方法的实践。你会明白强调流和排队论的看板方法如何帮助团队将精益思考用于实践。你还将学会如何利用看板方法帮助团队建立一种持续改进的文化。

思维方式、方法和学派并不是敏捷世界的全部。很多公司越发依赖敏捷教练帮助团队接受敏捷方法。因此本书的最后一章献给敏捷教练。

  • 第 10 章讲的是敏捷训练:团队怎样学习敏捷方法;敏捷教练怎样帮助团队改变思维方式,以便更轻松地采用敏捷方法;敏捷教练怎样帮助你和你的团队变得越来越敏捷。

{%}

图 1-4:Andrew Stellman 在 STRETCH 2013 会议(匈牙利布达佩斯)上演讲的现场图记。这个演讲的内容基础就是本章

图记:Kata Máthed 和 Márti Frigyik

http://www.remarker.eu

目录

  • 版权声明
  • O'Reilly Media, Inc. 介绍
  • 献词
  • 本书赞誉
  • 前言
  • 第 1 章 学习敏捷
  • 第 2 章 理解敏捷价值观
  • 第 3 章 敏捷原则
  • 第 4 章 Scrum 和自组织团队
  • 第 5 章 Scrum 计划和集体承诺
  • 第 6 章 极限编程与拥抱变化
  • 第 7 章 极限编程、简化和增量式设计
  • 第 8 章 精益、消除浪费和着眼全局
  • 第 9 章 看板方法、流程和持续改进
  • 第 10 章 敏捷教练
  • 关于作者
  • 关于封面