第 2 章 理解敏捷价值观

第 2 章 理解敏捷价值观

我们并非因为拥有美德和优点而行事正确,而是行事正确让我们拥有美德和优点。不断实践的行为会决定我们成为什么样的人。优秀不是一种表现,而是一种习惯。

——亚里士多德,《尼各马可伦理学》

作为一次变革运动,敏捷不同于以往的软件开发方法,它从思想、价值观和原则入手,形成了一种思维方式。拥有这样的思维方式,你会成为更加敏捷的实践者,也会成为更有个人价值的团队成员。

敏捷运动在软件开发的世界中是一次颠覆性的变革。采用了敏捷的团队会发现自己构建优秀软件的能力不断增强,有时候甚至会有巨大的飞跃。成功采用了敏捷方法的团队能构建更优秀、更高质量的软件产品,而且开发速度也比之前要快。

业界正处于迈向敏捷的转折点。敏捷方法不再是一种不入流的方法,而是成为了正规的学派。在敏捷方法出现的头几年,采用了敏捷方法的人费了很大力气才让自己的公司和团队相信它可行且值得实践。现在,没有谁会质疑敏捷方法在软件开发上的高效。事实上, 2008 年,一项重要的调查 1 表明,超过一半的受访团队正在遵循敏捷方法进行实践,或是遵循了一部分敏捷原则。敏捷正是从那个时候开始流行的。此外,越来越多的敏捷团队已经不满足于通过敏捷解决自己的问题,而是开始考虑怎样在全公司范围内推广敏捷开发。

1Forrester 2008 全球敏捷公司在线调查。

不过敏捷的推广并非一帆风顺。很多公司在运作软件开发项目的时候习惯于采用瀑布式流程(waterfall process)。在瀑布式流程中,团队首先定义好软件的需求,对项目进行完整的规划,然后开始软件设计,接下来再进行代码编写和产品测试。多年来,大量的软件(既包括非常好的软件,也包括垃圾软件)都是通过这种方式构建的。但是几十年来,不同公司的不同团队都遇到了相同的问题。因此有人开始怀疑,项目失败的根源也许就是瀑布式流程本身。

敏捷的故事始于一小群创新者,他们聚在一起试图找到解决这些问题的新方法。他们一开始就对以下这四则价值观达成了一致,认为这些是成功团队和成功项目共有的特质。他们把这四则价值观称为“敏捷软件开发宣言”(Manifesto for Agile Software Development)。

  • 个体和互动高于流程和工具

  • 可工作的软件高于详尽的文档

  • 客户协作高于合同谈判

  • 响应变化高于遵循计划

在本章中,我们会学习这些价值观,包括其来源、意义以及如何将它们应用到自己的项目中。我们会对一个厌倦了瀑布式开发的团队进行追踪,介绍在团队成员还没有真正理解如何应用这些价值观的时候是怎样初步尝试实现敏捷开发的。当你阅读他们的故事时,请思考为什么更好地理解这些价值观可以帮助他们避免问题。

故事:有一个开发流式音频点唱机项目的团队

  • Dan——开发主管和架构师

  • Bruce——团队主管

  • Joanna——新招进来的项目经理

  • Tom——产品所有者

2.1 团队主管、架构师和项目经理走进了一间酒吧……

Dan 在一家开发投币游戏和信息亭软件的公司担任开发主管和架构师。他参与过很多项目,从制作弹球街机到开发 ATM 机。在过去几年中,他与团队主管 Bruce 合作。他们负责开发公司最大的一款产品:一款名为 Slot-o-matic Weekend Warrior 的 Vegas 老虎机。

Joanna 是几个月前招进来的项目经理,负责领导一款新型流式音频点唱机的软件开发。公司希望在酒吧和餐馆推销这款产品。她在这个项目中非常重要,因为她是公司挖来的,她的老东家开发了一款风靡市场的点唱机。她已经与 Dan 和 Bruce 相处得非常好了,而且十分期待与他们一起开始的新项目。

与 Joanna 相比,Dan 和 Bruce 对这个新项目没有多少精神头。有一天他们一起出去喝酒,Bruce 和 Dan 聊到,团队私底下把老虎机项目叫 Slog-o-matic Weekend Killer,可见新产品并不被团队看好。

在这家公司,项目失败居然是规律而不是意外——发现这一点,Joanna 感到不舒服。公司的经理声称最近的三个项目是成功的,但是这些项目能发布靠的全是 Dan 和 Bruce 疯狂加班。更糟糕的是,他们故意在代码里偷工减料,导致现在的支持工作成为了噩梦。例如,他们为了某个特性而仓促地做了一个原型补丁,然后就推到产品中了。事后证明这里有严重的性能问题,因为有部分代码根本不能向上扩展。

在他们聊天的过程中,Joanna 找出了其中的模式,明白了导致问题的原因:公司采用的是特别低效的瀑布式流程。采用瀑布式流程的团队尝试尽可能早地对要开发的软件写出一份详尽的描述。一旦所有的用户、经理和主管都同意了软件要实现的功能(需求),就会给开发团队递交一份包含这些需求的文档(需求说明书),然后开发团队就动手构建说明书中描述的软件。完成之后,测试团队介入,验证软件与文档是否匹配。很多敏捷实践者把这种方式称为前期的详细需求分析(Big Requirements Up Front,BRUF)。

不过拥有多年项目经验的 Joanna 也知道理论和实践的差距,尽管有一些团队可以实施非常高效的瀑布式流程,但是有很多团队却为这个流程而感到痛苦。她开始感觉她所在的这个团队就是众多感到痛苦的团队之一。

{%}

图 2-1:瀑布式模型

在他们聊天的过程中,Bruce 和 Dan 又聊到了一些事情,进一步验证了 Joanna 的观点。 Joanna 怀疑公司里有无数说明文档藏在文件夹里蒙尘已久。从某种程度上看,所有人都期望一组用户、经理和主管给出一个完美的需求说明文档。实际上,需求说明书经常变化。到达开发团队手中的那一刻,需求说明书可能已经不准确了。当开发团队完成软件构建的时候,需求说明书可能已经面目全非了。Bruce、Dan 和公司里的很多人都知道完美的需求说明书并不存在,但是他们在运行项目的时候仍然假设需求说明书就是完美的。

时间越来越晚了,Bruce 也越来越放松(还有点小醉意)。他提出了另一个困扰他的问题:在公司里,他工作过的很多团队在构建软件的时候实际上存在很多困难。即使用户十分罕见地提出了准确的需求,即便整个团队破天荒地通过需求说明书完美地理解了这些需求,他们也常常会使用很糟糕的工具,而且在软件设计和架构设计上遇到了很多困难。结果,团队总是开发出有很多 bug 的软件,而且往往混乱而不可维护。

有很多项目的失败都是因为这两个原因,如果把需要长时间工作(每周 90 小时)的项目和充满 bug 的代码称为失败的话,那么以上两个问题就更能解释失败的原因了。Joanna 解释说这些失败的最主要原因就是公司采用的瀑布式流程无法应对变化。在理想情况下,瀑布式流程没有任何问题,因为在项目初期大家就精确地知道项目结束的时候需要造出个什么东西。这样的话,他们可以在一份优雅的需求说明书中把一切写下来,然后交给开发团队。但是项目开发其实从来不会这么美好。

Dan 和 Bruce 现在真的醉了,开始向 Joanna 进行马拉松式抱怨。Dan 说,他工作的项目几乎每一个都遭遇过客户中途反悔,总要开发和最初计划不同的功能。这样,所有人都要回到瀑布模型的最初状态。根据团队采用的严格瀑布流程,他们要从头写一份新的需求说明书,然后进行完全不同的设计,接下来再构建一个全新的计划。实际上没几个人这么做,而且人们极少抛弃已经编写的所有代码,因为时间不允许。相反,他们通常会在现有代码的基础上商定出一个修改方案(hacking)。这样的修改容易产生 bug。在为某一个需求而设计的代码上匆忙修改,使其满足其他需求,这种做法往往会得到混乱交织的代码,如果团队处于压力之下,则更是如此。根据新的需求重写代码会浪费宝贵的项目时间,因此他们最后都会采用糟糕的替代做法(workaround),编写出不可靠的代码。

这一夜结束的时候,Dan、Bruce 和 Joanna 开始意识到导致他们项目存在问题的原因——过分严格的文档、糟糕的沟通以及代码中的 bug。这些导致项目无法跟上正常的变化。

最后,酒吧的服务生帮他们三位叫了出租车。在离开之前,Dan 表示他抒发了胸中淤积已久的怨气。Joanna 很高兴她对于即将加入的项目有了更好的想法,不过并不乐观。她不知道自己是否能够找到方法来解决这些问题。

2.2 没有银弹

如今我们都知道软件构建没有最佳方法。现在没多少人会去争论有没有包治百病的灵丹妙药,但是业界在 20 世纪很长一段时间都坚信一劳永逸。很多从业人员认为能找到一种高度规范的方法,解决所有人在所有场景遇到的项目问题。很多人认为开发人员只要遵循一定的步骤就可以开发软件了,就好像看着菜谱做菜,或者在生产线上组装产品一样。

(具有讽刺意味的是,软件工程领域被引用最多的论文就是 Fred Brooks 在 1986 年发表的“No Silver Bullet”。在这篇文章中,他对这个不可能的目标下了定论。但是这并没有阻止人们去寻找象征着灵丹妙药的“银弹”!)

有不少人对这些类别的问题提出了银弹解决方案。这些解决方案通常都逃不出两种形式:一类属于方法(methodology),号称可以为团队提供一套防误操作的软件开发方案;另一类属于技术,据说可以让程序员防止或消除 bug。这背后的思想就是:如果一家公司决定采用某种方法或技术,那么所有的团队都要遵循公司的正统规范,这样就能源源不断地开发出优秀的软件了。

Dan 和 Bruce 以亲身经历证实这是不可能的,因为他们多年来在公司的项目管理中提出了很多方法和技术,但是都没有带来真正的长期改进。公司每一次寻找软件开发流程银弹的尝试都让所有人失望。Bruce 和 Dan 尤其感到烦恼,因为他们被要求遵循不断变化的流程,而他们并不希望流程发生变化。

Joanna 在职业生涯中也常常碰到类似情况。在上一份工作中,她总是收到一组组严格规定的需求,而且被要求制订计划,将新的需求体现在软件中。接下来她还把自己的计划转交给开发团队,要求严格执行。像这种“做计划,然后执行计划”的团队常常开发出丧失时效性的软件,即使是在部署当天也可能让用户觉得不实用。

让 Joanna 犹豫的是,她工作过的一些团队确实可以通过严重依赖前期文档的瀑布式流程发布优秀的软件。她在一家开发医疗设备软件的公司中用瀑布式实践管理了她最棒的几个项目。

瀑布式流程确实也有用。事实上,如果你明确知道想要做什么,那么在初期将需求写下来是构建软件非常有效的方式。Joanna 的医疗设备软件项目是少有的需求在一开始就很明确的例子,这种项目在实施期间需要做的改动非常少。

可是稳定的需求并不是瀑布式流程成功的唯一因素,这类项目总会遇到很多问题。可以采用瀑布式流程开发优秀软件的团队通常都有以下特点。

  • 沟通顺畅。在要求使用瀑布式开发的公司里,成功的团队都会在整个项目期间不断地与用户、经理和主管沟通。

  • 实践得力。代码审查和自动化测试阶段的工作尤其有效,可以在流程中尽早发现 bug。人们通常把这个过程称为缺陷预防(defect prevention)。这要求团队主动去思考 bug 最开始是怎样引入代码的。

  • 多数文档很少打开。团队成员都明白,写下计划这件事情本身(以及在制订计划的过程中提问)比盲目严格执行计划要重要得多。

这里还要说到一点。Dan 的职业生涯是在 20 世纪 90 年代软件开发工具和技术变革之后开始的,因此,他工作过的团队都会以面向对象的开发技术设计更好的软件。Dan 在工作中还会使用版本控制系统、自动化测试工具、包含自动化执行代码重构和类似设计功能的集成开发环境(Integrated Development Environment,IDE)以及其他一些革新的工具辅助代码的编写。Bruce 参与项目的时间比 Dan 要早,他目睹了团队中的开发人员不断采用新工具自动化一些重复性的日常任务。Bruce 和 Dan 通过实际项目经验认识到,最成功的项目会充分运用优良实践、工具和思想,将时间节省下来,与用户和同事沟通。他们应当思考如何解决问题,而不是花时间去与代码作对。

事实证明,在高效运转的瀑布式项目中,团队成员遵循的价值观、原则和实践往往与敏捷项目异曲同工。那些使用了一些敏捷技术和方法但是没有真正遵循敏捷价值观和原则的项目,通常都会遇到困扰瀑布式项目的问题。

遗憾的是,Bruce、Dan 和 Joanna 将要通过痛苦的方式意识到这一点。

要点回顾

  • 瀑布式流程要求团队在项目开始的时候完整地写下软件的描述,然后完全按照写下的文档构建软件。

  • 瀑布式流程很难应对变化,因为这种流程关注的是文档而不是协作。

  • 没有什么银弹流程或实践可以让项目完美运作。

  • 有些团队能够成功使用瀑布式流程,那是因为采纳了高效的软件开发实践和原则,尤其是加强了沟通。

2.3 敏捷可以拯救乱局吗

即便是第一次听到“瀑布”这个词,你大概也能明白瀑布式流程是个什么样子。2 Joanna、 Bruce 和 Dan 同样心里有数。在计划点唱机项目之前,他们在一起讨论了瀑布式流程在以往团队中是怎样出问题的。

2如果你是项目经理或者准备过 PMP(Project Management Professional,项目管理专业人员)考试,那么你肯定学习过瀑布式流程的全部内容。公平地说,瀑布式流程有其重要性,因为 PMP 认证并不仅限于软件开发领域,而是横跨很多行业,涉及多种方法。如果你要建造一栋摩天大楼或是一座桥,那么在初期制订完整的蓝图往往非常重要,纵然在建造过程中会有变化。

在上一个项目中,Bruce 和 Dan 与公司的客户经理 Tom 共事。Tom 花了大量时间参观游戏厅、赌场、酒吧,并帮助客户安装和使用其产品。在项目初期的三周里,他们三个坐在一起确定新投币机的需求说明。Tom 只有一半时间在办公室,他不在的时候,Bruce 和 Dan 便设计软件并规划架构。等他们三位都对需求达成一致,便请公司的 CEO 和高级经理开会审核,进行必要的修改,获得开工的批准。

彼时,Tom 继续四处奔走,剩下的工作就交给 Bruce 和 Dan 了。他们俩把项目分解为任务,派发给团队中的其他人,然后大家开始编写软件。整个团队快要完成软件构建时,Tom 把商业用户、项目经理和公司主管汇集到一间大会议室,然后演示快要完成的 Slot-o-matic Weekend Warrior 软件。

项目演示并没有像大家期待的那样顺利进行。

在演示的过程中,CEO 问了一个问题:“看起来很棒,但是这个软件不是应该有一个视频扑克的模式吗?”然后气氛就开始变得尴尬了。很明显,CEO 一直认为他们正在开发的软件应该既可以部署在投币机的硬件上也可以部署在视频扑克机的硬件上。高级经理、董事会以及两个最大客户已经多次讨论过这个问题。很可惜的是,没有人想到要告诉开发团队。

最糟糕的是,如果 Dan 在项目早期就知道了这件事,那么改变开发方向也不会太困难,但是到了现在这个节点,他们只能忍痛抛弃大量已经写好的代码,补上从视频扑克项目改过来的代码。他们花了数周时间处理代码整合带来的诡异 bug。Dan 多次在深夜向 Bruce 抱怨说这完全是可预见的,把某个项目的代码仓促地用到另一个项目几乎总会发生这种事情。现在他要处理一大堆混乱的意大利面条式代码。基本代码的维护也会非常困难,整个团队都感到很懊恼,因为这显然是不该发生的事情。

面临问题的还不只是 Dan 和 Bruce。这个项目的项目经理感到非常不快,因而离开了公司。他曾经信任整个团队的预估和状态,忽然出现的视频扑克要求毁了这一切。整个团队根本不知道他们还要去处理这种意外的硬件变更问题,项目经理的日子也不好过。尽管发生了这么大的变故,但是项目的截止时间仍然雷打不动。到项目结束的时候,最初的计划已经完全过时,基本上就是一份失效的安排,但是项目经理无论如何也要对这份计划负责。遭到公司高级经理斥责之后,他只能辩解说手下的团队在项目初期并没有做好合理的规划。很快,项目经理就离开公司找了另一份工作,接下来 Joanna 就受聘来到了公司。

Tom 可能是所有人中最窝火的,因为客户遇到问题的时候,他总是首先被推到风口浪尖。这个产品最大的客户是 Little Rock 公司,这是拉斯维加斯的一家赌场。这家赌场希望所有的老虎机都能自定义主题,这样他们就可以在阿肯色州的各个城市使用这些产品。客户希望游戏可以变换,而不需要移动游戏主机,并且对新特性提出了要求。他们的工程师后来一直都在与 Bruce 团队留下的 bug 作斗争,这也意味着 Tom 和 Dan 需要花数周时间在电话里与工程师商讨补丁和替代解决方案。尽管 Little Rock 并没有取消合同,但是他们把下一个大单留给了竞争者。而 CEO 和经理却把损失归咎于 Slot-o-matic Weekend Warrior 项目。

最后,所有人都知道项目出问题了。而每个人都有很好的理由把责任推给其他人。但是似乎没有人有什么好点子可以解决这类经常重复出现的问题。他们最终交付的软件也是一团糟。

2.3.1 引入敏捷,带来变化

Tom 再次回到市里,Bruce、Dan、Joanna 还和他一起吃了顿午饭。发完了旧项目的牢骚,Joanna 提议采用敏捷方法。

像很多团队刚开始接触敏捷一样,他们一开始也会讨论“敏捷”这个词到底是什么意思。对于 Bruce 来说,敏捷指的就是敏捷开发的世界:书籍、实践、训练课程、博客以及实践敏捷的人。对于 Joanna 来说,敏捷意味着“项目能够应对变化”,这就是实现敏捷的具体目标。Dan 认为敏捷就是不要任何文档,直接开始编写代码。而 Tom 完全不知道他们在说什么,不过,令他高兴的是,他们在讨论的时候给他展示了很多具体的示例,看来采用敏捷就可以避免上一个项目的悲剧。

团队中开始“敏捷化”的成员通常都会自学敏捷的技术、实践和思想,这个团队也是如此。Dan 加入了敏捷联盟(Agile Alliance,网址为 http://www.agilealliance.org/),开始接触其他的敏捷实践者。Bruce 和 Joanna 开始阅读敏捷开发和项目管理的相关博客和书籍。他们俩都接触了一些很棒的思想,并且以身作则地使用自己学到的方法,期待能解决项目中的问题。他们都学到了不同的技术,并立即开始组合使用这些技术。

Dan 已经为之前的项目写了自动化的单元测试,但是点唱机项目中还有很多开发人员从来都没有写过单元测试。他开始与其他开发人员一起写单元测试,进行测试驱动开发(test driven development)。他编写了一个自动化的构建脚本(automated build script),设置了一台构建服务器(build server),这台服务器每小时都会签出一次代码,构建软件,并运行测试。自动测试确实生效了!他们立即发现了代码中一处需要改进的地方。每天都会有一名开发人员发现一个 bug,如果没有自动化测试的话,这些 bug 永远都不会被发现。很明显,他们省下了数周在现场调试追踪诡异问题的时间。不仅产生的 bug 越来越少,他们还感觉构建的代码改动起来更加方便了。

(如果你还不熟悉包括测试驱动开发在内的这些实践,那也没有关系。本书会教给你所有这些概念,并且在第一次出现新的实践的时候用黑体标出,以方便你快速识别。)

Joanna 参加了 Scrum 训练,现在整个团队都开始叫她 Scrum 主管,尽管她在训练课程中了解到 Scrum 主管与项目经理之间有巨大的区别,而且她也不能百分之百地确定自己在项目中的角色真的算是 Scrum 主管。她帮助团队将项目分解为多个迭代(iteration),在任务板(task board)上跟踪迭代的进度,用上了项目速度图(velocity chart)和燃尽图(burndown chart),保证每位成员都能了解最新的情况。燃尽图是一种线图,记录每天项目中未完成的工作,“燃尽”到零意味着工作完成。这是团队成员第一次真正对项目经理做的事情感兴趣,而且这种做法确实改善了项目的进度。

Tom 也想加入敏捷化改造的过程中。Dan、Bruce 和 Joanna 称 Tom 为产品所有者(product owner),Tom 开始编写用户故事(user story),这样可以帮助团队更好地理解他们要开发什么样的软件。根据用户故事,他和团队一起制订构建发布计划(release plan)。现在他感觉自己直接掌控着整个团队要构建的产品。

最棒的是,Bruce 开始每天与 Joanna、Dan 以及所有程序员召开每日站立会议。Tom 也开始加入他们。一开始大家感觉有点尴尬,但是随着项目的推进,大家渐渐能够自在而诚实地交流进度,并知晓项目进度的真实评估情况。Bruce 说服大家在每一轮迭代结束时开回顾会议(retrospective),他欣然发现团队成员在努力实现发言时提出的改进。

2.3.2 “聊胜于无”的结果

所有的努力都开始有效果了。整个团队都在改善,项目的处境也越来越好——一定程度上确实如此。

在向敏捷靠拢的过程中,团队中每一个人的工作都变得更为顺利。Dan 和开发人员开始养成更好的代码编写习惯。Joanna 随时都可以掌握项目的进展。Tom 与团队的沟通也比以前多得多,这让他可以更好地控制开发团队构建的软件,更好地交付用户所需要的软件。 Bruce 可以专注于专业技能的改进并进行沟通。

但是,他们有没有变成一个真正的敏捷团队呢?

他们引入了很多优秀的实践。其中有很多都是之前实践的改进,所有这些都提升了团队成员的工作效率。这绝对是一种进步。

然而,尽管整个团队的幸福感提升了,而且点唱机项目也比之前的项目进展更顺利,他们还是对自己所接触的敏捷新流程有所保留。例如,Dan 认为尽管团队现在编写的代码质量肯定比以前好,但是他感觉为了赶进度,他在技术上有所牺牲。

Joanna 对于项目的运转方式有了一定的控制权,她对此感到满意。但是把项目分解为小迭代这种做法让她感觉有点盲目。现在没有一个自顶向下的大计划可以用作路线图,她发现自己越来越依赖于通过每日站立会议获得项目的进展。每日站立会议很有用,但是在每日站立会议上,大家只是陈述自己的状态,然后 Joanna 忠实地将这些内容记录下来并汇报给利益干系人。她越来越感觉到自己只是一个协调者或组织者,而不是控制整个项目的项目经理。她只关心当前的状态,因此她感觉很难看清项目会遇到的障碍,也无法帮项目铺平道路。团队更擅长应对变化,但是 Joanna 的处境比较尴尬,因为她只能关注如何应对,而无法做全局规划。

Tom 现在已经成了项目负责人,他控制团队构建需求的能力增强了,他对此感到非常欣喜。但是他也很纠结,因为他觉得大家似乎希望他能整天和团队在一起。他必须参加这些每日站立会议,还要不停地回复开发人员关于软件产品细节的邮件和问题。有时候,他也不知道如何回答这些问题,还有的时候他希望他们可以自己解决这些问题。他自己本来就有别的工作要做,他也不喜欢被打扰,他感觉好像其他人把构建伟大软件的责任都推到了他身上,而他自己也不可能解答所有问题。毕竟,他的本职工作是客户经理,那些点唱机又不会自己推销自己。如果整天都在回答程序员的问题,他哪还有时间去了解客户和用户的最新需求?

Bruce 很满意提高之后的团队交付频率。但是回头审视进展,他总感觉有一些事情不尽如人意。他也说不出个所以然。目前,项目毫无疑问得到了改善——他之前的项目都处在失败的边缘。对于 Bruce 来说,引入敏捷有利于项目的进展,没有人被迫逞强,也没有了那么多加班的周末和长夜。但是他也觉得引入敏捷也带来了别的问题。

团队成员,特别是团队主管也有着同 Bruce 类似的感受:采用敏捷的初次尝试让他们有点失望。他们读过的博客和书籍以及参加的培训都提到了“惊人的结果”和“生产力超强的团队”。而目前,点唱机项目相比之前的项目的确有所改善,但是团队绝对没有感受到“生产力超强”,也没有人对产生的结果感到惊喜。

大家普遍感觉项目的状态从不正常转变为了正常,这很好。我们称这样的结果为聊胜于无的结果(better-than-not-doing-it result)。难道敏捷方法就这么点能耐吗?

2.4 视角割裂

只要开发软件,团队就会遇到各种各样的问题。事实上,在 20 世纪 60 年代,人们就曾公开讨论过这样一种思想:软件开发从根本上就是有问题的。在 1968 年的 NATO 软件工程大会上,人们提出了软件危机(software crisis)这个词。而软件工程也是在这个大会上提出的 3。“软件危机”指的是 20 世纪 70 年代和 80 年代各大公司普遍存在的一种软件开发状态,导致项目失败的各种严重的问题(现在是大家熟知的问题)在当时非常普遍。随着时间的推移,业界开始理解软件危机的主要原因。Lockheed 公司的一名工程师 Winston Royce 在 1970 年发表的一篇论文有着里程碑意义。这篇论文描述了一种非常流行但是非常低效的开发模型。这就是 20 世纪 80 年代广为人知的瀑布式模型。又花了 10~20 年的时间,大家才真正开始避免盲目地采用这种模型。与 Bruce、Dan、Joanna 一样,很多团队发觉敏捷实践可以解决典型瀑布式流程中的问题,但实施过程不如想象中那么顺利。

3详见 Peter Naur 和 Brian Randell 编辑的 Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968

开发人员每天都会使用各种软件工具来编写代码。熟练使用多种工具的开发人员比不怎么会使用工具的同行更受欢迎。因此,刚一接触敏捷,很多开发人员立即把这看作一组工具、技术和实践。几乎所有实践了几个月敏捷方法的开发人员都会在自己的简历上更新一笔,添加上他使用过的敏捷实践。这样的初步印象对于敏捷而言还是不错的,因为好的印象可以让本来不关心敏捷的开发人员提起兴趣。

但是看到工具、技术和实践只是步入敏捷的第一步,而且这种做法有一个严重的副作用。首先从 Dan 的角度考虑:作为开发人员和架构师,他的关注点与开发直接相关,也就是能帮他避免 bug、提升代码质量的技术,能快速构建且易于运行的工具,以及帮他改进代码设计、审读以及构建的实践。项目经理 Joanna 更关心的是开发软件所需的工作量以及最终软件的质量,因此她关注有助于理解和沟通进度、预算以及工作量的工具。像 Tom 这样的商业用户在意的则是软件的商业价值。吸引他的主要是可以帮助团队理解用户真实需求的实践,这样团队才能开发出有价值的软件。团队主管 Bruce 期望确保团队中的每位成员都朝着同一个目标奋进,能够进行良好的沟通,而且可以从过去的经验中学到东西,所以他要的是能在这些方面提供帮助的工具。

以编写用户故事这项敏捷实践为例,一个用户故事通常只有几句话,写在一张索引卡上,描述一项非常具体的用户需求。用户故事有时会采用严格的格式,有时却很灵活。例如,点唱机项目中的一个用户故事是这样的:“我是一名酒吧常客,我希望能播放当日发行的最新热门歌曲。”

团队中每一位成员都会从不同的角度看待用户故事。

  • Joanna 是一名要努力成为 Scrum 主管的项目经理,在她眼里,一个用户故事就是一件要完成的任务,应该整齐地打包好并随时可以构建。她把每一个用户故事都写在索引卡上,并把这些索引卡贴在白板上,通过这种方式让大家不偏离正轨。

  • Dan 是开发主管和架构师,在他眼里,用户故事用简单易懂的方式描述了一项要实现的功能。他可以把用户故事分解为小的任务,并且为每一个任务创建一张索引卡。当他开始着手完成某项任务时,就会把自己的姓名写在对应的卡片上。当他完成某项任务时,则将对应的卡片转移到白板上专门摆放已完成任务的区域。

  • Tom 是产品所有者,在他眼里,每个用户故事都可以给公司带来价值,因为他可以通过用户故事清晰地看出团队正在开发的软件与用户使用之间的关联。用户故事可以帮助他与客户更好地沟通,让他更加了解客户需要什么样的点唱机软件。他要确保每一个用户故事都准确描述用户的一项需求。

  • Bruce 是团队主管,在他眼里,每一个用户故事都是团队要完成的一项目标。他帮助团队成员计划下一步要完成的事情,并且通过进度让整个团队保持动力。

这样在团队中引入用户故事可以改进团队开发软件的方式,因为以上四种角色中的每一种都可以通过用户故事改进自己的工作方法。

但这也有可能产生副作用。Dan 过去的项目都有一份详细的规格说明书,没有多少操作灵活性。而现在,他可以自由参与构建软件的相关决策。这是好事,但也会在项目中引入一些问题。当 Dan 在为“最新热门曲目”用户故事编写代码的时候,他想到的是编写一项功能,让酒吧顾客播放任何最新上传到服务器上的热门歌曲。Tom 不得不解释说,在点唱机上播放较新的歌曲意味着酒吧老板必须支付更高的版税。Tom 向团队解释了这个用户故事的细节,也就是让顾客播放最新热门歌曲的频率达到令人满意的程度,但又不会导致超支。Dan 对此非常沮丧,因为这意味着他不得不重写这项功能的大部分代码。而 Tom 也很生气,因为这意味着这份软件第一次发布的时候不会带上这项功能。

如果 Dan 一开始就能理解用户故事对于 Tom 验证用户真实需求的价值,那么他在动手编码之前就会找 Tom 讨论一下软件要开发成什么样子。另一方面,如果 Tom 肯花一点点时间,就会发现 Dan 参考用户故事这样有限的信息开发软件。明白了这一点,Tom 会在这一轮迭代开始之前找 Dan 讨论上述需求。但是他们并没有进行这样的对话,这个项目遇到了之前瀑布式项目也会遇到的问题:开发人员作出了错误的假设,然后开始编程,最后不得不对代码做一些本可以避免的修改,而这些修改使得软件更有可能出错。

如果每个人只考虑自己的工作,只关心用户故事如何帮助自己,而不进一步看一看整个团队可以怎样使用用户故事(或其他的敏捷工具、技术和实践),那么最后就有可能出现这样的问题。我们把这种问题称为视角割裂(fractured perspective),因为每个人对敏捷实践都有不同的看法。

现在我们把流式音频点唱机项目放一边,本书不会再讨论这个项目了。他们能否解决问题并交付软件?在你阅读本章剩余部分的时候,请尝试找出能帮助他们解决问题的方法。

2.4.1 视角割裂带来的问题

如果项目团队中的每一位成员都只从自己的角度看待一项实践,老问题就会重复出现。在软件危机的年代,开发人员会在还没有花时间理解用户需求的情况下着手开发。他们总是在软件开发中途发现突如其来的新需求,因此不得不删掉和替换一大堆代码。很多敏捷实践的目标都是帮助团队成员在项目初期充分理解客户的需求,由此避免低效工作。如果团队成员不主动沟通——例如,开发人员在还没有真正讨论好用户需求的时候就开始闷头写代码,然后把写好的代码丢给“墙外的”产品所有者——这种工作方式会频频产生需要事后修补的问题。

与此同时,产品所有者很高兴敏捷方法为团队指明了用户需求的正确方向。产品所有者本来感觉对项目缺乏控制,只能无助地看着开发团队开发去年的软件而不是新软件,因为程序员最后一次与用户沟通的时间就是去年。对于有这种感觉的产品所有者来说,敏捷方法会带来极大的宽慰。但是如果发现团队开发的软件并没有完全与他编写的用户故事匹配,产品所有者仍然会感觉很受挫。开发团队感觉产品所有者似乎希望大家可以读懂他的心思。产品所有者则感觉所有人都盼着他成天泡在团队里,回答一切问题。

项目中的其他角色也会遇到同样的视角割裂现象。项目经理和团队主管很高兴看到开发人员可以自主地添砖加瓦。他们看到了改进,但是工作的方式并没有发生根本性的变化,因为团队成员的工作可能相互抵消,导致整体工作方式没能真正改变。如果项目经理把钉在白板上的用户故事看成 Microsoft Project 甘特图文件的一种直接替代品,或者仍然一心想“指挥和控制”项目,那么为了严格服从原始计划,这名项目经理会经常要求大家加班应对项目变化。团队主管可能会有防御式的反应,例如为了避免团队加班工作而拒绝更紧张的时间安排,要求更宽松的期限,或是减少工作内容。项目经理和团队主管似乎都没有做错什么。如果在一开始都能看到对方与自己视角不同,那么他们也许可以避免冲突,同时也能收获好的结果。

换句话说,如果整个团队不进行沟通,那么就算团队中的每一位成员都采用了某一种工具(例如用户故事),他们也仍然保持老态度,因而会出现摩擦和团队问题。新的工具更为先进,因此项目运转更流畅。但是团队成员感觉变化并不大,因为很多老问题依然会出现。这时大家会开始怀疑敏捷不过如此。

有证据表明,很多团队都经历过这种问题,即单独地采用了一些“聊胜于无”的工具。 VersionOne 是一家开发敏捷软件工具的公司,这家公司还通过很多其他途径为敏捷社区作出过贡献。他们做的最重要的事情之一就是每年进行一次“敏捷开发状态”(State of Agile Development)调查。根据 2013 年的结果 4,我们很容易看出,很多团队确实通过引入敏捷做出了一些改进。

4在网站 http://stateofagile.versionone.com/ 上可以获得最新的 VersionOne 敏捷状态调查报告。

  • 2013 年的 VersionOne 敏捷开发状态调查中,88% 的参与者表示他们的组织采用过敏捷开发实践。

  • 92% 的参与者表示,该调查评估的每一个领域同去年比都有改进。其中,改进效果最好的几个领域包括:优先级变化的管理(92%)、生产力的提升(87%)、项目透明度的提升(86%)、团队士气的提升(86%)以及软件质量的提升(82%)。

尽管开发团队可以看到敏捷项目进展更快,而且团队成员应对变化的能力更强了,但是敏捷项目仍然会失败,原因通常都关乎瀑布式开发与敏捷方法之间的文化和理念差异。调查参与者将“缺乏使用敏捷方法的经验”“公司文化与敏捷价值观有冲突”和“要求遵循瀑布式实践的外部压力”三点列为敏捷项目失败的主要原因。

当新的敏捷团队遇到问题的时候,最常见的原因就是他们还没有真正抛弃老的瀑布式思维。例如在前述的点唱机团队中,仅仅是增加具体的实践并不能让他们化解导致冲突的问题,开发过程还是出现了本来可以避免的变更。也许点唱机团队中的每一位成员都认为自己已经步入敏捷了,但实际上,他们在很多方面依然是一个瀑布式团队,只是采用了一些很好的敏捷实践而已(Forrester Research 的 Dave West 为此发明了一个词:Water-Scrum-Fall5)。换句话说,他们已经达到了瀑布式团队能够实现的最高效率。

5Forrester 中 Dave West 的文章“Water-Scrum-Fall Is the Reality of Agile for Most Organizations Today”,2011 年 7 月 26 日,网址为 http://www.storycology.com/uploads/1/1/4/9/11495720/water-scrum-fall.pdf

2.4.2 为什么视角割裂只能做到“聊胜于无”

人们能交付的东西通常取决于他们所关注的东西。越是关注自己的目标,而不是整个团队的目标,那么他们能为公司交付真正价值的可能性就越低。

对于尝试走向敏捷的团队来说,这是一个悖论。专注于具体实践的团队最终会得到一些改善,但是仅限于他们非常擅长的领域,原因在于团队成员只关注他们已经知道的东西。任何人要想大大扩展自己已知的领域,都必须很好地掌控未知的事物。要求一个团队在自己还不熟悉的领域获得进展,这似乎是一种离谱的要求。

{%}

图 2-2:团队成员倾向于在项目中他们已经熟悉的领域采用敏捷实践,因此整个团队只能在这些领域有所改进,这就是视角割裂会导致“聊胜于无”的原因

这也就是为什么一些采用一项敏捷实践的团队通常都只能得到“聊胜于无”的结果。他们只是在擅长的领域采用了更好的实践,因而把这些事情做得更好。但是他们还没有触及项目以往没有得到关注的领域,因为影响这些领域的实践对团队中任何成员都没有吸引力。因此,相关问题都不会得到改善。然而,也许正是这些领域的问题妨碍了团队高效地交付惊人的产品。

团队怎样解决这个问题呢?

要点回顾

  • 更好的沟通可以帮助团队更好地管理变化。

  • 团队作为一个整体来制订计划(planning as a team)好过事先过度详细地制订计划,然后盲目执行。

  • 软件项目具有不可预知性,从 20 世纪 60 年代就开始产出不好的结果。这种状况在当时被称作“软件危机”。

  • 很多团队“步入敏捷”的方法是采用伟大的敏捷实践改善他们已经做得很好的事情。

  • 因为团队没有从根本上改变沟通和工作的方法,因此他们采用更好的实践得到的只是聊胜于无的结果

  • 用户故事是一种敏捷实践。在这种实践中,一名团队成员(通常是产品所有者)通过几句话描述用户操作系统的各种具体方式,使用的语言是用户可以理解的语言。

  • 目前,采用敏捷最常见的方法是一次采用一种实践,但是这并不是最有效的方法。

2.5 敏捷宣言帮助团队认识实践的目的

敏捷软件开发宣言也称敏捷宣言http://www.agilemanifesto.org/),由 17 位志同道合的 IT 人于 2001 年在犹他州盐湖城外群山中的 Snowbirt Retreat 旅馆写就。这份宣言意在为他们职业生涯中看到的软件开发问题提供一个解决方案。经过数日的讨论,他们对一组核心思想和原则(以及“敏捷”这个名称)达成了一致。他们把这些内容打包成了一份独立的文档,这份文档开启了软件开发世界思维的转换。

敏捷宣言包含四则简明的价值观。下面是这份宣言的完整内容。

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。

由此我们建立了如下价值观。

 

个体和互动 高于 流程和工具

可工作的软件 高于 详尽的文档

客户协作 高于 合同谈判

响应变化 高于 遵循计划

 

也就是说,虽然右项有其价值,但是我们更重视左项的价值。

为了理解敏捷并高效地使用敏捷,我们首先要解读这些价值观。

2.5.1 个体和互动高于流程和工具

盲目地遵循流程会使人走入误区。好的工具有时候可以帮你更快地犯错。软件的世界充满了各种伟大的实践,并不是所有的优秀实践都适合项目的具体情况。然而,这里有一个普适原则,那就是团队中的成员要心里有数。他们需要理解一起工作的方式,明白每个人的工作会对其他人造成怎样的影响。

对于想要改善自己所在团队工作方式的人来说,这是非常实际的想法。敏捷团队认为个体和互动高于流程和工具,因为仅仅拥有“正确的”流程和“最佳的”实践还不够。如果使用者并不认可他要使用的流程或工具,他就无法将这些东西坚持使用到最后。更糟糕的情况是,人们只是表面遵循这些流程规定的动作,即使这些做法会得到毫不相干的结果。在你打算实施一项流程的时候,即使从逻辑上说这种流程非常合适,而且从理性上看采用这种流程是非常正确的选择,你还是需要把这项流程推销给你的队友们。如果大家不明白你这么做的理由,也不明白你到底在做什么,那么在他们眼里,你只是在随意发号施令而已。

这也就是为什么你必须在任何一种情形下都意识到你是在和一个团队合作。团队中每个人都有自己的动机、想法和喜好。

有很多敏捷实践都支持这条原则,这体现了敏捷思想的诸多特点。因此,在本书中,你可以看到有很多支持个体和互动的实践,例如每日站立会议回顾会议。在回顾会议上,大家讨论当前项目或迭代的进展情况,以及可以吸取的教训。用户故事也是这样一种实践,故事本身并不重要,重要的是这些故事可以帮助团队一起讨论故事代表的真正意义。

2.5.2 可工作的软件高于详尽的文档

摆满大量软件详细卷宗的架子随处可见。在一个软件项目中,有太多的事情可以文档化。而且在项目升温期,很难判断哪些文档会在未来有用,而哪些文档只能束之高阁。因此,很多团队(特别是很多团队经理)都会决定采用详尽的文档,事无巨细,全部记录下来,也不考虑以后会不会有人读。

相对于详尽的文档,敏捷团队更为重视可工作的软件。但是“可工作的软件”这个词看上去有点含糊不清。这到底是什么意思?对于敏捷实践者来说,可工作的软件是可以给公司组织带来价值的软件。这可以是公司出售的软件,也可以是帮助公司员工更高效工作的软件。如果可以增加价值,那么这个项目能交付的价值或能节省的成本必须比开发项目本身的成本要高。尽管团队不会直接谈钱,但是价值大部分情况下最终都会落实到钱。团队应该着重于构建和交付可以带来价值的可工作的软件。文档只是实现目标的工具。

可工作的软件高于详尽的文档,但文档还是要写的。在一个团队中,有很多种类的文档非常有用。但是必须注意的一点是,撰写文档的人通常就是编写软件的人。好文档能帮助团队理解问题,与用户沟通,以及避免将错误的需求开发进软件。这种文档所消耗的成本与节省的时间和精力相比是划算的。程序员也不介意编写别的文档,例如线框图和时序图,遵循上述原则就好。

从另一方面看,关注可工作的软件能够确保团队没有偏离正轨。如果清晰地表明了可工作软件的方向,那么这种文档就对项目有贡献。实际上,团队通常可以采用一些将文档嵌入软件本身的创新方法。测试驱动开发就是这样一种敏捷实践。在测试驱动开发中,程序员首先开发自动化的单元测试,然后再开发上述单元测试测试的软件。自动化的测试代码和软件本身的代码并列保存。自动化的测试也可以当作文档使用,因为测试可以帮助程序员记录代码应该完成的功能,以及软件中单个组件预期的行为。

2.5.3 客户协作高于合同谈判

看到“合同谈判”,很多人可能会认为这只与咨询顾问以及合同制的承包商有关。实际上,在一个公司内部,有很多团队也需要接触这类事务。如果程序员、产品测试人员、产品所有者和项目经理都在不同团队中工作,而且不是真正朝着交付可工作的软件这样一个单一的目标而合作努力,那么他们的工作方式就好像是互相遵照合约合作。在很多公司中,不同开发团队之间、测试和开发之间以及开发团队和用户之间都会把服务级别协议(Service-Level Agreement,SLA)放在台面上讨论。

这样做也许可以降低风险,减少与老板之间的矛盾,因为你可以指责其他团队影响了软件的交付。但是如果大家要达到的目标是给公司外的用户交付可工作的软件,这种做法只会适得其反。一名开发人员如果总是想办法保护自己,那么他就不太愿意尝试新的合作方法,也不愿意为需要他们开发的软件的用户采用创新的方法。

敏捷团队落实这项价值观的一种方法是在团队中安置一名产品所有者。这名产品所有者可能不会参与代码的开发,但是他会参加会议,贡献想法。最重要的是,他要把最终的产品当作自己的东西。产品所有者通常通过用户故事与团队中的其他成员合作。

2.5.4 响应变化高于遵循计划

项目管理中有一句老话:“怎么计划怎么来。”遗憾的是,如果计划有误,那么构建出来的产品就是错误的产品。因此,开发团队需要不断地发现变化,当用户需求发生变化,或者软件构建方式需要变化的时候,团队要保证正确地响应变化。如果环境变化了,项目就需要新的计划。

制订计划的人抗拒变化是很常见的事情,因为改变计划需要消耗精力。例如,要把工作分割成多份,并估算每一份的工作量,这本身就需要消耗不少精力。一个变化就可能导致项目经理把这些事情全部重做一遍。如果他认为遵循计划高于响应变化,那么他可能会自己陷入困境中。尽管遵循计划有利于项目顺利执行,但是如果真的有变化出现,在代码完成度更高的时候处理变化更为困难。

任务板(task board)是一种良好的实践,可以帮助团队作出响应变化的正确决策。工作中的每一个要素(比如用户故事这样的典型要素)都写在一张索引卡上,并且贴在一块大板上,这块大板通常分为多个列,展示每一个工作要素的不同状态,Joanna 在点唱机项目中就是这么做的。任务板也可以通过计算机程序管理,但是很多团队觉得在一面真实的墙面上摆放这些索引卡效率更高,因为大家可以站在任务板前讨论、指点和移动用户故事。这些沟通方式比单纯的讨论要丰富得多。任务板这样设置,大家都可以重新规划任务的顺序,甚至为此跃跃欲试。如果发生了变化,那么大家可以往任务板上添加索引卡,而不是通过某一个项目经理来澄清一切。这样可以帮助大家跟上进展,让计划不断更新。

{%}

图 2-3:敏捷团队通常会使用任务板来展示任务并跟踪进度。他们会把任务或用户故事写在索引卡上,然后根据项目的进展移动这些卡片。很多团队还会在任务板上画图跟踪进度

2.5.5 原则高于实践

点唱机团队采用了一些优秀的实践,所以有了很不错的收获。这些好的实践对项目是有改进作用的。但是这个团队视角割裂,没有全体全力朝着构建软件目标奋进,所以也受益有限。在实践之上,还有一套敏捷的思维。那些发现了敏捷方法背后的思想的团队都找到了更好的合作和互动方式。

换句话说,在通过互动、协作以及对变化的积极响应来构建对客户有价值的软件时采用敏捷实践,团队会比仅仅在计划、编程和文档编写上采用收获更多。

Jim Highsmith 在他的著作《敏捷项目管理(第 2 版)》中进行了非常好的总结。

没有具体的实践,原则是贫瘠的;但是如果缺乏原则,实践则没有生命、没有个性、没有勇气。伟大的产品出自伟大的团队,而伟大团队有原则、有个性、有勇气、有坚持、有胆量。

那么,一个团队怎样才能超越引入实践的简单做法,变得“讲原则”,从而开发出伟大的产品呢?

要点回顾

  • 敏捷宣言包含了高效团队必备的共同价值观和思想。

  • “个体和互动高于流程和工具”的意思是说,团队应该首先关注团队中的人以及人之间沟通的方式,工具和实践是次要的。

  • “可工作的软件高于详尽的文档”的意思是说,交付满足用户需求的软件比交付描述这个软件的说明文档重要。

  • “可工作的软件”指的是可以给公司带来价值的软件。

  • “客户协作高于合同谈判”的意思是说,要把所有人看作同一个团队的成员。

  • 很多高效的敏捷团队把产品所有者当作项目团队中的一员,通过这种方式与产品所有者合作,而不是将其当作客户进行谈判。

  • “响应变化高于遵循计划”的意思是说,要意识到计划是会变的,交付软件产品比严格遵循计划更重要。

  • 任务板是一种敏捷规划工具,大家把用户故事粘贴在任务板上,并且根据用户故事在当前项目或迭代中的状态,把这些用户故事分类在不同的列中。

2.6 理解敏捷的“大象”

Lyssa Adkins 在她所著的《如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南》一书中讲解了比喻对概念理解的重要作用。

长期以来,专业的敏捷教练都知道比喻的实用性。事实上,敏捷培训的专业课程会教授这样的核心技能。敏捷教练会提出一些问题,帮助客户建立自己的比喻。这种比喻必须发自内心且能引起共鸣。客户借此整理生活中出现的各种事件。6

6《如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南》,Lyssa Adkins 著。

有一个非常有用的比喻可以帮我们理解视角割裂及其对高效工作的阻碍。下面是盲人摸象的故事。

受人邀请,六位盲人触摸大象身体的不同部位,判断大象的长相。摸到大象腿的那位盲人说大象就像一根柱子。摸到大象尾巴的那位盲人说大象就像一根绳子。摸到大象驱干的那位盲人说大象就像一截树干。摸到大象耳朵的那位盲人说大象就像一把扇子。摸到大象肚子的那位盲人说大象就像一堵墙。摸到大象长牙的那位盲人说大象就像一根坚固的管子。

国王对他们解释道:“你们都没有错。你们每个人都给出不同答案,因为你们触摸的是大象的不同部位。这头大象具有你们每个人提到的特点。”7

7引用自故事 Blind Men and the Elephant 的维基百科页面(网址为 http://en.wikipedia.org/wiki/Blind_men_and_an_elephant,本文加入维基百科的日期为 2014 年 6 月 25 日)。

那些采用了敏捷,却得到“聊胜于无”结果的团队往往在采用敏捷方法之前就可以交付质量不错的软件产品。他们对敏捷方法寄予厚望。问题在于在此之前,他们遭遇了问题。而这些问题并不是十分严重,没有带来毁灭项目的软件危机,只是会给团队带来摩擦和不安。这就是视角割裂:开发人员考虑的是开发人员的问题,项目经理考虑的是项目经理的问题,而他们直接把代码丢给考虑业务问题的业务用户。每个人都忙于自己的项目工作,太专注于自己这一块。谈到团队之间的隔阂和失调,他们常常会说“甩包袱”这样的话。每个人只考虑自己的工作,人和人之间没有太多的沟通。事实上,他们都在为同一个项目单独工作,而并没有真正形成团队。

这里就可以用“盲人摸象”的故事来打比方了。以割裂的视角采用敏捷方法,每个人都只会使用对自己的工作有影响的实践,就好像每一个盲人只摸到大象的一部分。例如,开发人员会关注测试驱动的开发、重构和自动化构建。项目经理喜欢任务板、项目速度跟踪和燃尽图。商业用户通过发布计划和用户故事来更好地了解团队的进度。团队主管通过每日站立会议和回顾会议管理和改进团队。大家都想从项目中得到不同的东西,每个人都只在意对自己有帮助的实践。(再提一下,我们在本书中会学习上面提到的每一种实践,所以如果感觉不熟悉的话也不要担心。)

大家各自采用这些实践肯定能对现状有所改善,因为敏捷实践真的很棒。问题在于开发人员、项目经理、商业用户和团队主管看待项目的角度各不相同。如果每个人只关注对自己有直接吸引力的实践,只看敏捷实践中对自己有用的那部分,并且认为敏捷的意义就在于让其他所有人都围着自己的观点转,那么就会得相反的效果(“看,我一直都是对的!”)。

敏捷这头“大象”由很多优越的实践组成,而整体比零散个体的总和更为强大。如果只看到某个方法,甚至只看到对自己有用的方法,那么你只能认识到敏捷的一小部分。敏捷由各种日常实践组成,但是敏捷本身却远远超越了这些实践。

图像说明文字

图 2-4:敏捷的“大象”作为一个整体比具体的各个实践加起来要大

如果成员看到的只是一个个独立的实践,而不去思考背后的原理,那么这个团队就会错过人和人之间重要的互动。不同人的视角会一直处在割裂状态。团队成员互相独立,不能真正地发挥团队力量。尽管依然可以把工作完成,但是他们忽略了团队成员间重要的互动和合作,而这才是敏捷真正发挥力量的地方。

互动已经内建在敏捷方法中了。这里再看一下敏捷宣言中的第一则价值观。

个体和互动高于流程和工具

流程、方法和工具依然非常重要(因此敏捷宣言最后谈到,虽然右项有其价值,但是我们更重视左项)。但是比具体实践更重要的是个体和互动。这些价值观(以及第 3 章要学习的 12 条原则)展示了如何把实践整合在一起使用,也指导了团队的具体工作。

让实践快速上手

理解了敏捷宣言中的价值观(及其背后的原则),你还需要真正改变团队开发软件的方式。幸运的是,在敏捷开发中还有一个重要的方面专门解决这个问题。敏捷方法的作用就是帮助团队采用敏捷并改进自己的项目。

敏捷方法非常有价值,因为它可以帮你在具体情境中了解敏捷实践。对于那些不熟悉所有敏捷实践的团队来说,这一点尤为重要。每一种方法都经过了多年的开发和改进,从事相关工作的正是专注于整个敏捷开发方法的专家。采用完整的敏捷方法意味着遵循一种经过检验的可靠路径,从头到尾完成软件项目,避免导致割裂视角的反复试验。

敏捷方法是一组实践的集合,除此之外,这里还包含了相关的思想及建议,以及大量来自敏捷实践者的知识和经验。一种敏捷方法会罗列出项目中所有人的不同角色和职责,并且在项目的不同阶段对每一位成员提供具体的实践建议。

VersionOne 在 2013 年的敏捷开发状态调查报告中列出了一系列最流行的敏捷方法,其中位居榜首的是 Scrum,后面是 Scrum 和极限编程的一种混合版本。调查参与者还谈到了精益方法和看板方法,尽管这些方法并不属于敏捷方法(参见第 8 章和第 9 章),但是仍然可以反映敏捷的核心思想。

Alistair Cockburn 在《敏捷软件开发(原书第 2 版)》中这样描述 Scrum。

虽然使用起来另有要点,但我们可以对 Scrum 概括出以下几点。

  • 团队及项目出资方在一起创建一个优先级列表,包含这个团队需要完成的所有工作。这个列表称为产品积压工作表(product backlog),它既可以是任务的列表,也可以是特性的列表。

  • 每个月,团队取出列表最上面的一部分,这是团队预估的一个月的工作量。团队将这部分工作扩展为一个详细的任务列表,称为冲刺积压工作表(sprint backlog)。团队向出资方承诺在月底可以演示或交付上述积压工作表的处理成果。

  • 团队成员每天碰面,花五到十分钟同步进度,交流阻碍。这项活动称为每日站立会议。

  • 将一个人指派为 Scrum 主管。这个人要负责亲自或指派他人解决站立会议上提出的问题。8

8《敏捷软件开发(原书第 2 版)》,Alistair Cockburn 著。

对于很多刚开始采用敏捷的团队来说,这些可以直接对等为具体的实践(在此以楷体字突出表示,第 4 章会详细解释这些实践)。

  • 产品所有者创建并维护一个产品积压工作表,即软件的需求列表。

  • 团队在限定的时间内完成月度冲刺(sprint):在产品积压工作表中找出满足一个月工作量的需求,对这些需求进行开发、测试和演示。当前冲刺对应的需求列为冲刺积压工作表。(有一些采用 Scrum 的团队将一个冲刺的时间跨度定为两周或四周。)

  • 团队召开每日站立会议,每个人都汇报昨天完成的工作以及当天计划完成的工作,讨论在工作中遇到的任何困难。

  • Scrum 主管扮演的角色是领导者、教练以及为团队完成项目保驾护航的指导者。

不过采用 Scrum 并不仅仅意味着采用这些优越的实践。这些实践本身都可以以不考虑敏捷价值观和原则的方式使用。比如,对于仅仅以实践协同推进项目的团队来说,每日站立会议运转得很好。但是每日站立会议也可以让项目经理给每个人分配任务,并且知晓每个人当前的状态。在会上,每一位开发人员都会这样向项目经理汇报——这些是阻碍我进展的障碍,你去把它们都搞定吧。如果每个人只顾自己,总认为很多责任是别人的,那么每个人都会把障碍看成别人的问题。这样的会议就变成了讨价还价,而不是一种合作。陷入这种境地的团队可能采用了类似 Scrum 的实践,但是并没有真正地使用 Scrum。

(本书后面会详细讲解 Scrum 的工作方式及其实践。)

第二套方法称为极限编程。James Shore 和 Shane Warden 在 The Art of Agile Developmenthttp://shop.oreilly.com/product/9780596527679.do)中这样总结极限编程:“通过同步推进工作阶段,极限编程团队每周都能发布可以部署的软件。在每一次迭代中,开发团队都会分析、设计、编码、测试并部署一个功能子集。”(很多极限编程团队选择的迭代周期为一周,还有一些团队选择两周或一个月。Scrum 也可以适应多种不同的迭代长度。在本书后面我们会深入学习敏捷方法的使用。)极限编程描述了具体的开发实践,这些实践的目标是增强与用户的合作、计划、开发以及测试。而极限编程则更进一步,通过使用这些实践来帮助团队构建简单、灵活的软件设计,同时方便团队维护和扩展。

Scrum 和极限编程有很多共同之处,例如这两种方法都需要迭代。项目要分解为多个迭代,开发团队在每一次迭代结束时产生一个可工作且可部署的软件。在这些迭代的过程中完成整个项目的所有工作。很多极限编程团队使用持续一周的迭代,而很多 Scrum 团队采用的是持续一个月的迭代。对迭代持续的时间设限的称为时间定量(timeboxing),这样可以帮助用户了解新特性交付的期望时间。

很多团队,特别是采用了 Scrum 和极限编程的团队,发现采用整套方法比采用实践更为有效。尽管零散地采纳实践可以让团队中每一位成员针对自己的工作作出选择,但是采用完整的方法可以鼓励整个团队齐心协力,帮助团队认识到如何恰当地引入一套方法中所有的实践。为此,团队成员需要改变有关工作的思维方式。敏捷方法都是围绕着敏捷价值观和原则构建的,观念的转变也要顺应团队合作、互动、可工作的软件并响应变化。其他敏捷实践者的书籍和知识积累通常可以为这种转变提供帮助,采用这些方法的团体也会树立正面榜样。

精益不是一种方法,而是一组思维方式。它包含一组价值观,以及帮助你接受这套价值观的思考方式。在敏捷领域,精益的重要性不亚于极限编程和 Scrum。理解了这三种方法之间的共性,你就可以充分了解精益对敏捷的意义。看板可以改进团队开发软件的方式。看板方法的构建基于精益价值观,包含了一组帮助团队改进和演化的独特实践。

极限编程方法的实践和关注点与 Scrum 方法在很多方面有不同之处。精益和看板也有不同的实践和关注点,采用了完全不同的方式。既然这些敏捷的方法都采用了完全不同的实践和关注点,这些方法怎么可能都能称为敏捷方法呢?这是因为所有的敏捷方法都基于相同的原则,而且都依赖于团队中的每一位成员齐心协力完成项目中的每一个部分。敏捷宣言中的价值观和原则把所有这些方法和实践绑在了一起。

{%}

图 2-5:Scrum、极限编程和精益的核心都是敏捷价值观,这些方法之间也会有一些共同的价值观、思想和实践

2.7 着手采用一套新方法

当团队成员一起努力采用一套方法的时候,每一位成员都会探讨实践、思想和视角。这就彻底避免了割裂的视角。把整套方法看作一个整体,团队开始理解单个实践之间如何互相影响。这是 Bruce、Dan、Joanna 和 Tom 想要达到的境界,但是他们不知道怎样走到这一步。

准备接纳新的实践和思想时,团队成员还无法理解这些新事物与他们已经熟悉的实践有什么关系。这样的理解要等团队收获经验时才能获得。敏捷方法之所以能够起效,是因为它有一套完整的体系,其中包含了一组已知交互良好的实践,而且团队也能利用这些实践提升生产力。采用一组完整的实践是了解实践交互的基础。

不过,采用一套方法比寻找适合团队当前工作方式的实践要难得多。如果可以一次引入整套方法,那么团队就更有可能获得最佳的敏捷效果。从某种程度上说,这是因为除了那些与原先行事风格类似的实践之外,这样还会引入一些大家一开始觉得没有用处的实践和思想。

根据我们之前了解的情况,点唱机团队陷入困境的原因在于 Bruce、Dan、Jonna 和 Tom 各自独立地引入了敏捷实践。要想获得最好的敏捷效果,仅仅引入一些实践是不够的。大家一开始就应该坐在一起认真讨论每一项实践会带来什么样的好处。但这种做法具有挑战性,因为他们不知道怎样开展讨论。和很多团队一样,他们也面临着这样一种困境:如果已经知道这些敏捷实践会给项目带来怎样的效果,并且知道如何真正实施这些实践,那么他们也就不需要这类讨论了。但是他们恰恰还不知道这些。

这个问题也有解决办法。我们需要查看与敏捷宣言所列价值观紧密结合的 12 条原则。我们在第 3 章会学习这些原则。

要点回顾

  • 只关注单个实践的团队看不到加强沟通和响应变化的大目标

  • 敏捷方法涵盖了实践、思想、建议和团队。

  • 诸如Scrum、极限编程和精益这样的敏捷方法不仅包含了很多优越的实践,还要求团队关注这些目标背后的思想。

  • 敏捷教练通常使用隐喻帮助团队学习。

常见问题

敏捷宣言中谈到不要写详尽的文档,是不是说什么都不要写?

 这是一个关于敏捷宣言的常见问题。我们再看一下敏捷宣言中关于详尽文档的描述。

 可工作的软件高于详尽的文档

 这并不是说敏捷实践者不在乎详尽的文档。而且这句话显然也没有说什么文档都不要写!有很多文档尽管并不“详尽”但是依然很有用。

 这句话的意思是说,要让用户认可团队的进展,最好的办法就是把可工作的软件交付出去。不过项目里还有一个地方可以写写文档。我们会通过代码注释给代码添加文档(例如,解释为什么需要做某个决策,或为什么不用另外一种方法或算法实现某个功能)。本书后面还会介绍一种特定的文档形式:用户故事。用户故事通常写在索引卡上,可以用来帮助成员、团队、用户以及利益干系人共同准确地了解正在开发的产品。敏捷团队还会使用一些其他类型的文档,其中有一些比另一些更为详尽。

你确定吗?肯定有人跟我说过敏捷的意思就是什么文档都不写,而且什么计划也不做,直接开始编程。这样不是更高效吗?

 敏捷团队从来不做计划——这是一种十分常见的误解。事实上,敏捷团队做的计划比很多传统项目团队细致。但是对于新的敏捷开发人员来说,敏捷项目看起来没有多少计划,因为整个团队都在积极参与,没有人抱怨。(说实话,在传统的团队中,收到项目计划会的邀请会让程序员心生不满。)

 比如,Scrum 团队通常会花一整天(8 小时)计划 30 天的迭代。然后他们会召开每日站立会议(通常限定在 15 分钟之内),大家一起审阅计划。对于一个 5 人团队来说,这相当于在迭代开始的时候耗费 40 个工时制订计划,另外 40 个工时分布在接下来的 30 天中。这样的计划工作量算下来多于很多传统团队 30 天软件开发中的计划工作量。难怪 Scrum 团队能很好地按期完成任务。而对于团队成员来说,这种计划工作并不会让人感到“无聊”。这是因为他们都参与到这个过程中了,他们关心的是产出,而且他们有理由相信计划能让整个迭代周期进展顺利。(在第 4 章中我们会深入学习 Scrum 项目计划。)

 然而,从局外者的角度来看,他们好像没有计划就直接进入项目了。团队只在 30 天迭代周期的第一天做迭代计划,这意味着团队在第二天就可以开始编写程序(如果他们认为这样最合理的话)。这样一来,计划看似没有,但制订计划的零散时间加起来还是很长的。

这是不是意味着只有擅长计划的资深开发人员才适合敏捷开发?

 不是的。敏捷开发适合所有技能水平的所有人。计划是一种技能,提升这种技能的唯一方法就是实践。即使是有经验的开发人员有时候也会作出错误的估计(其实他们经常犯错!)。我们真的看到过很多团队的初级开发人员成功采用敏捷开发出远超公司预期的软件。有一点需要注意的是,在高效敏捷团队中,初级开发人员很快就不是初级水平了,这可能是有人认为敏捷只适合资深开发人员的原因之一。

我能不能只让团队中的开发人员采用敏捷,而让其他成员(测试员、业务分析师、用户体验设计师和项目经理等)维持原状?

 可以的,但是这样可能会影响效率。当人们谈到只让开发人员采用敏捷方法的时候,他们真实的意思是让这些开发人员采用敏捷方法中的一部分实践。这样可以让开发人员自己的生产力得到提升,因此这么做是值得的(即“聊胜于无”的结果)。但是团队并没有改变思考项目的方式,因此这样采用敏捷,团队得到的改进非常有限。这是团队落入“瀑布式 Scrum”境地的原因之一。团队成员最终会感觉他们采用敏捷的尝试是徒劳的或是不完整的。

如果我没有用 Scrum、极限编程、精益和看板方法,是不是意味着我的团队就不敏捷了?

 绝对不是。敏捷方法有很多种,我们这里只关注了其中的几种。本书的目的是通过这些方法讲解敏捷背后的思想。更重要的是,本书还要帮你了解敏捷的真实含义。在本书剩下的部分中,你会学到不同方法的价值观和实践,并且通过这些内容学到敏捷的真实奥义,以及这些迥异的方法如何共同体现敏捷。

现在就可以做的事

下面是你现在就可以自己或与团队一起尝试做的事情。

  • 列出你和团队开发软件使用的所有实践。这些实践可以是:编写规格说明书、在版本控制系统中管理代码签入、使用甘特图记录项目计划、开每日站立会议等。

  • 请团队中其他人也写一写这样的列表。比较你们的列表。有哪些实践没有被所有人纳入列表?请就此展开讨论。你能不能找出成员间视角的不同?

更多学习资源

下面是与本章相关的其他学习资源。

  • 《敏捷软件开发(原书第 2 版)》,Alistair Cockburn 著:深入了解敏捷价值观和原则。

  • 《敏捷项目管理(第 2 版)》,Jim Highsmith 著:深入了解原则和实践的关系。

  • 《如何构建敏捷项目管理团队:ScrumMaster、敏捷教练与项目经理的实用指南》,Lyssa Adkins 著:深入了解敏捷教练。

教练技巧

下面是帮助团队理解本章思想的敏捷教练技巧。

  • 培训一个新团队的时候,单独与团队成员聊天,尝试理解不同角色之间视角的差异。

  • 单独询问团队成员对敏捷宣言中价值观的理解:怎样看待这些价值观?哪些价值观最重要?这些价值观是否可以用在日常工作中?

  • 团队通常会有一种“聊胜于无”的感觉,但是不知道如何表达。直接提出这个概念,要求团队成员想出一些感到“徒劳”的实践或一些事半功倍的实践。

  • 发起关于敏捷宣言中某项价值观或原则的讨论。例如,如果团队谈到了他们与客户之间协商定下的“合约”,那么可以以这份合约作为起点讨论合同谈判与客户协作之间的异同。帮助他们理解在哪里作出选择。

目录