拥抱敏捷

“敏捷创新法”革新了信息技术。在过去25到30年间，这些方法大大提高了软件开发的成功率，改善了质量，加快了进入市场的速度以及提升了IT团队的积极性和工作效率。

目前，与指挥—控制式管理有着本质区别的敏捷方法学（包括一系列新价值观、原则、实践和优势）已经传播到各行各业和诸多职能部门，甚至高管层。敏捷方法帮助美国全国公共广播电台（NPR）创造新节目，帮助约翰迪尔（Jonh Deere）开发新机器，助力萨博（Saab）生产新战斗机；它还被云备份服务领先企业Intronis应用在市场营销上，被全球第三方物流供应商C.H. Robinson应用于人力资源领域。从造酒、仓储到高管层的运营，Mission Bell酒庄将敏捷方法用到了各个方面。通用电气也是依靠敏捷方法，才得以加速实现“从20世纪集团到21世纪数字行业公司”的著名转型。通过把员工从职能孤岛中解放出来，让他们加入以顾客为中心的跨领域自管理团队，敏捷方法不仅加速了盈利增长，还有助于培养出一代训练有素的管理者。

敏捷方法的传播带来了各种振奋人心的可能性。试想以下情景若成为现实，将会如何？公司在新品推出增加50%的情况下实现盈利；市场营销项目带来的顾客问询增长了40％；人力资源聘用的首选目标增加了60％；积极参与工作的员工数量提高了一倍敏捷方法已让IT部门实现了上述改观，在公司其他部门也大有可为。

然而，敏捷方法的前路绝非坦途。当我们向高管问起他们对敏捷管理的理解时，得到的回应通常是尴尬的笑容和“我可不敢冒这个险”之类的揶揄。他们可能会提到诸如“冲刺”、“时间盒”等敏捷行话，然后声称自己的公司正变得越来越“敏捷”。但他们未曾经过训练，并没有真正理解该方法。后果就是，高管们不知不觉沿用着那些有悖敏捷原则和实践的管理方式，影响了部门中向他们汇报的敏捷团队的工作效率。

这些高管同时发起数不清的新项目，截止日期也都迫在眉睫；而不是只布置两三个最紧迫的任务。他们自己和最优秀的部下同时负责太多项目；他们要经常与敏捷团队成员会面，迫使敏捷成员不得不缺席工作会议或找替补出席。很多这样的高管过度参与具体团队事务；他们说的太多，听的太少；他们提出的意见很可能是团队之前已经考虑过并搁置的次要观点。他们经常推翻团队决定，并增加复查和管控环节，以保证错误不会重犯。尽管出于好意，但其实高管们的做法削弱了敏捷创新能带来的效益。

创新是敏捷方法的精髓所在。尽管敏捷方法对常规运营和流程不那么有效，但如今多数公司面临的环境都瞬息万变；它们不仅需要新产品和服务，还需要职能流程的创新，在新软件工具迅速传播的情况下，更是如此。公司若能创造出让敏捷方法充分发挥效用的环境，就能让团队更迅速地产出大量产品服务创新和职能流程创新。

通过研究此类公司以及为它们提供咨询服务，我们发现了6种领导者须采用的关键实践，让他们得以充分发挥敏捷方法的潜力。

1 了解敏捷方法的真正原理

有些高管似乎把敏捷方法与混乱无序（每个人都随心所欲行事）联系在一起，另一些人对敏捷方法的理解则是：“照我说的做，只不过更快”。但这两者都是对敏捷方法的曲解（见下文《敏捷方法的价值观及原则》）。敏捷方法确实有不同变种，所强调的方面略有不同，但所有变种都有共同之处。它们包括：司克兰（Scrum橄榄球术语，意为“密集争球”，寓指整个团队攒足力量，为了一个共同目标，一起向前快跑——译者注），强调用富有创意和适应性的团队工作来解决复杂问题；精益开发，强调不断减少浪费；看板，聚焦于缩短交付周期（产品从设计到投产的时间——译者注），以及过程中的工作量。本文作者之一，杰夫·萨瑟兰协助开发了司克兰，他此举的灵感正是来自1986年HBR发表的文章《新产品开发新游戏》（The New New Product Development Game）。该文章的合著者竹内弘高，也参与了本文的创作。因为司克兰及其衍生法的应用次数至少是其他敏捷方法变种的5倍，我们选用司克兰来说明敏捷实践。

司克兰的基本原则相对简单。面对某机遇，组织通常成立只有3到9名全职员工的小团队，并赋予该团队权力。该团队跨越职能部门，具备完成任务所需的全部技能。团队进行自管理，对工作的各个方面严格负责。

团队的“项目负责人”（通常也被称为产品负责人）最终负责向顾客（包括内部顾客和未来用户）交付价值。承担这一职责的员工通常来自某一业务部门，他／她的时间花在两方面：与团队一起工作，以及协调关键利益相关者，比如顾客、高管以及业务经理。项目负责人可能会使用设计思维或众包等技巧，针对有潜力的机遇，构建完备的“组合积压工作（Portfolio backlog）”清单。然后他／她会根据对内部或外部顾客以及对公司所具价值的最新估算，不厌其烦地更新该清单上的工作顺序。

项目负责人不会规定团队成员每个人应该做什么，也不会限定完成任务需要多长时间。团队会制定出简单的路线图，只详细规划那些在执行前不会改变的活动。团队成员将最优先的任务划分成小模块，决定团队承担的工作量以及如何完成工作，对“完成”进行明确定义，然后开始创建在短期内迭代的产品版本，每个周期以一个月为限，被称为一次“冲刺（Sprint）”。整个过程由一名流程促进员（process facilitator）进行引导，通常只有训练有素的司克兰行家才能担任该职。流程促进员使得团队更加专注，并促成集体智慧发挥效用。

该流程对任何成员公开透明。团队成员每天召开简短“站会”（stand-up meeting），检查流程，发现障碍。他们通过实践和反馈而非无休止的辩论或上报领导来解决争端。他们让少量顾客在短期内测试产品的部分或全部小工作原型。如果顾客欢欣雀跃，那么该原型可能会立即发布，哪怕有些高管对其并不买账，哪怕其他成员觉得还缺了点附加功能。然后团队进行头脑风暴，探讨改进未来周期的方法，并为解决下一优先事项做准备。

与传统管理方法相比，敏捷方法具有很多明显优势，这些优势全部经过研究和记录。敏捷方法提高了团队生产率和员工满意度；最大限度地减少了冗繁会议、重复计划、过度记录、质量瑕疵以及低价值产品功能等问题。通过提高透明度，并持续适应顾客多变的优先选项，敏捷方法提高了顾客参与度和满意度，让最有价值的产品和功能问市更迅速、更可预测，并降低了风险。通过让来自不同专业的团队成员成为合作伙伴，敏捷方法拓宽了组织经验，建立起互信和尊重。最后，通过大幅减少浪费在微观管理职能项目上的时间，敏捷方法让高管能更多投入到只有他们能负责的、价值较高的工作中：创建和调整企业愿景；区分战略计划的先后次序；简化和集中工作；把任务分配给合适人选；增加跨部门合作以及扫清进程中的障碍。

2 了解敏捷方法的适用范围

敏捷不是万灵药。实施敏捷方法最有效和便利的条件普遍存在于软件创新中。这些条件包括：亟待解决的问题很复杂；解决方案最初是个未知数；产品要求在未来很可能改变；工作能够被模块化；与终端用户紧密合作（以及从他们那里很快获得反馈）是可行的以及创意团队往往比指挥－控制式团队表现更佳。

根据我们的经验，这些条件存在于很多产品管理的开发职能、营销项目、战略规划活动、供应链挑战以及资源分配决定中。他们不像工厂维护、采购、销售电话和会计等常规运营那么常见。（详见《敏捷方法适用条件》）因为敏捷方法需要培训、改变行为以及新信息技术，高管必须决定预期回报能否覆盖这一过渡所付出的努力和开支。

敏捷创新还仰赖于一支由积极参与者组成的精英队伍。其核心原则之一是“围绕积极性高的员工成立项目，给予他们所需的环境和支持，信任他们能完成工作。”当公司、职能部门或团队中的大多数人选择使用敏捷方法时，领导者可能就须给那些顽固派施压，让他们也接纳敏捷方法，甚至换人。但最好还是召集热情高涨、自觉自愿的敏捷方法支持者，而非强迫顽固派“就范”。

已投资了30多家公司的风投公司OpenView Venture Partners就采取了上述办法。从其所投资的一些公司中接触到敏捷方法之后，创始人斯科特·麦斯维尔（Scott Maxwell）开始将该法应用于自己的公司。他发现，敏捷方法更适用于某些运营活动。例如，敏捷方法很适合战略规划和市场营销，可将其中的复杂问题切分成模块，再由跨专业团队各个击破。但在销售方面，敏捷方法就不那么奏效：任何销售电话都能当场改变销售代表的待办清单，但如果每个小时都要重组销售团队、改变组合积压工作，以及重新分配客户，则太过复杂又耗时过长。

麦斯维尔为OpenView所投资的公司提供敏捷原则和实践的培训，并让它们决定是否采用敏捷方法。有些公司很快赞同实施该法，另一些则有不同优先选项，决定搁置。其中Intronis就属于敏捷方法支持者之一。当时Intronis的市场部依靠一项以贸易展为主的年度计划，但销售部抱怨说，市场部太保守且拿不出成果。因此，Intronis聘用理查德·德拉哈耶（Richard Delahaye）做专员，来实施敏捷办法，理查德原先是网络开发员，后转行做市场营销。在他的指导下，市场部团队学到了很多，例如如何将组织话题在线研讨会的时间从数周缩短为几日。（一次迅速组织起来的关于恶意软件CryptoLocker的研讨会吸引了600人注册，是公司迄今为止的最佳成绩。）如今团队成员继续为数字营销部门制定日程和规划预算，但精简了登记在册的项目细节，增强了应对偶发事件的灵活性。这样一来，销售部的满意度大幅提升。

3 从小做起，有口皆碑

大公司通常下大力气开展变革项目。但推行敏捷方法最成功的公司往往从点滴做起。它们经常从IT部门入手，因为软件开发工程师一般对敏捷原则最熟悉。然后敏捷方法可能被传播到另一个职能部门，由之前的实践者充当教练一职。每一次成果，都会造就一批热衷敏捷方法的宣传员，他们会迫不及待地告诉组织中其他人敏捷方法是多么有效。

农机公司约翰迪尔对敏捷方法的应用和拓展就是一例。软件工程师乔治·托姆（George Tome）在约翰迪尔的公司IT部门担任项目经理，从2004年开始，他悄然应用敏捷原则。经过数年时间，该公司其他部门的软件开发团队也开始使用敏捷方法。随着兴趣日益高涨，公司的其他业务拓展和市场部门也更容易接纳敏捷方法。

2012年，托姆在研发部的“企业先进营销（EnterpriseAdvanced Marketing ）组”担任经理，负责寻找能够革新约翰迪尔产品的技术。组长杰森·布兰特利（Jason Brantley）担心传统的项目管理技巧会拖延创新。为此，托姆和杰森决定试试敏捷方法能否加快创新速度。托姆请来了两名其他小组管理者参加敏捷培训课。由于所有的术语和例子都来自软件领域，其中一名没有相关背景的管理者觉得像在听天书。托姆意识到，其他人很可能产生类似反应，于是找到一名了解如何指导没有软件背景员工的敏捷教练。在过去几年里，他和这名教练培训了研发部全部5个中心的团队。托姆还开始每周发表一篇一页的简短文章，介绍敏捷原则和实践，并把文章用电子邮件的方式发给任何感兴趣的人，以及在公司社交网站Yammer上发表感想的人。“我希望建立一个专门属于约翰迪尔的敏捷知识库，让公司里所有人都能理解敏捷方法，”托姆说，“这将为敏捷方法在公司所有部门的应用奠定基础。”

利用敏捷技巧，企业先进营销组极大地压缩了创新项目的周转时间——在某些情况下，甚至节约了75％以上的时间。例子之一是，在约8个月时间内开发了一款“新机型”的工作原型（该机型尚未公布）。布兰特利说：“按照传统流程，如果一切进展顺利，这一过程快则1年半，慢则2年半或3年。”敏捷方法还带来了其他进步。组内的团队参与度和愉悦度的评分迅速从全公司的倒数第三名跃居到正数第三名；质量也有所提高。周转速度（以每一冲刺中完成的工作量衡量）平均加快了200％以上；有些团队超过400％，有一支团队甚至达到了800％。类似的成功引人注目。据托姆介绍，如今在约翰迪尔的各个部门内，或有人开始使用敏捷方法，或有人正在考虑如何利用敏捷方法。

4 允许“大师”团队定制敏捷实践

日本的习武之人，尤其是合气道学员，通常要学习被称为“守—破—离”的过程。在“守”阶段，他们学习已经过论证的规矩。掌握了规矩后，学员便进入“破”阶段，可以进行扩展并开始修正传统形式。在最后的“离”阶段，学员已经对所有规矩和原则了然于心，可以选择自由发挥。

掌握敏捷创新的过程与合气道异曲同工。在开始修正或定制敏捷方法前，员工或团队可以践行已经给数千家公司带来成功的普适方法，并从中获益。例如，明智的做法是，避免一开始让团队接手兼职任务或采取成员轮岗制。实证数据显示，和成员轮岗的团队相比，稳定团队的工作效率高出60％，回应顾客意见的积极度高出60％。

时间一长，经验丰富的敏捷方法实践者应被允许定制敏捷实践规则。例如，一项敏捷原则规定，团队应随时保持工作进展和遭遇障碍的透明度。起初最流行的做法是，手工将（标有工作任务的）彩色便签从大白板（即敏捷创新中的“看板kanban”）上的“待办”栏转移到“进行中”栏再到“已完成”栏。很多团队依旧坚持使用此法，而且愿意邀请非团队成员拜访团队办公室，观摩并讨论该过程。但其他人则乐于依靠软件项目和电脑屏幕，尽可能缩短输入时间，并允许信息在多个地点同步共享。

此类自由发挥须遵守一大关键原则：如果团队希望改进某些实践，应该进行试验，并记录结果，保证这些变化真能提高顾客满意度、工作周转速度和团队士气，否则将适得其反。

流媒体音乐平台Spotify就是定制敏捷试验的老手。Spotify成立于2006年，自诞生之日起，就具有敏捷基因。从产品开发到营销和综合管理，整个商业模式都围绕着利用敏捷创新提供更佳顾客体验而设计。但现在Spotify的高层领导不再硬性规定具体实践细则，而是鼓励实验和活学活用，只要改良措施符合敏捷原则，而且可以被证明能够改善结果即可。因此，该公司的70个“小分队”（Spotify给敏捷创新团队起的名字）和“章节”（公司用来描述用户界面开发和质量测试等职能能力的术语）的实践都不尽相同。几乎每个小分队都由跨职能小团队组成，它们所使用的改进工作流程的形式也五花八门，包括视觉过程追踪，优先选项排列，自适应计划和头脑风暴会议等等。但很多团队都不再使用“燃尽图”（burndown chart，用于显示完成工作和剩余工作）这一敏捷团队的常见做法；它们也不常衡量速度、保留进度汇报，或利用同样技巧来估算指定任务所需时间。这些小分队都对自己的改良方法进行过测试，并确定它们能够改善结果。

5 高管层的敏捷实践

有些高管层的活动不适合应用敏捷方法，诸如常规且可预测的任务（绩效评估，媒体采访，工厂访问以及拜访顾客和供应商等）。但很多被认为最重要的任务，适合敏捷方法，比如战略规划和资源配置，研发突破性创新，以及改善组织协作。那些组成敏捷项目，然后学习将敏捷原则应用于适用任务的高层管理者，都取得了影响深远的成果。他们自己的工作效率和士气也得到了提升。他们与自己赋权的团队在交流上畅通无阻，与团队感同身受共同应对挑战，并学习如何克服这些挑战。他们识别出妨碍敏捷团队的行为，并予以阻止；他们在工作中学习做减法和保持专注。结果得到了改善，增加了组织上下的信心，提高了参与度。

不少公司重新分配选中的敏捷领导者工时，将他们25％甚至更多的时间，从职能孤岛转为投入敏捷领导团队。这些领导者将全公司的组合积压工作排序，在组织其他部门建立和协调敏捷团队，解决最优先的事项，然后系统性排除成功路上的绊脚石。下面是高管层应用敏捷方法的3个例子：

1. 与员工步调一致。拥有525名员工的软件公司Systematic从2005年开始应用敏捷方法。随着敏捷方法扩散到公司所有的软件开发部门，CEO和联合创始人迈克尔·霍尔姆（Michael Holm）开始担忧：他的领导团队阻碍了工作进展。他告诉我们：“我有种感觉，我在说‘跟着我’时候，实际上是我自己在后面。开发团队使用司克兰，以新方式行事；而管理团队还墨守传统方式。”——动作迟缓，而且过于依赖过多（且看来过时的）书面报告。因此，2010年霍尔姆决定以敏捷方式运营其9人高管团队。

高管团队重新厘清了管理事项的轻重缓急，取消了超过一半重复出现的报告，并将其他报告转化为实时系统，同时增加了对销售计划和顾客满意度等攸关业务事项的关注。高管团队每周一先进行1到2小时会面，却觉得这样决策节奏太慢。因此，他们决定每天早上8:40拿出20分钟开“站会”，讨论成员们前一天都做了什么，当天的计划，以及哪里需要帮助。最近高管团队开始使用记事板追踪自己的行动，以及业务单元取得的进步。包括人力、法务、财务和销售在内的其他职能部门，现在也采用了高管团队的敏捷方式。

2.加速企业转型。2015年，通用电气自我重新定义为“数字行业公司”，聚焦于以数字技术为支撑的产品。部分转型涉及创立GE Digital部门，该部门容纳了全公司与所有软件相关的员工，有超过2万人之多。GE Digital现任COO布莱德·苏拉克（Brad Surak）曾是一名软件工程师，对敏捷方法稔熟于胸。他在开发工业互联网应用的领导团队里试用司克兰，最近开始将其应用到新单元的管理流程中，比如运营检查。苏拉克是项目负责人，另一名工程专业高管担任司克兰大师。两人一起为高管团队列出了积压工作优先清单，包括简化团队购置硬件须遵循的行政流程，以及解决需要征询多个GE事业部意见的，棘手的产品定价问题。

司克兰团队成员进行为期两周的冲刺，每周召开3次站会。他们将进度表贴在开放会议室的记事板上，让任何员工都能看到。苏拉克说：“这样做让高管的日常工作没有了神秘感。他们希望知道，高管所关心的是否和员工关心的内容相一致。”司克兰团队收集员工快乐度调查，进行根本原因分析，找出工作效率提高的障碍，以及向组织中所有员工进行反馈，这些传达了这样的信息：“我们听到了你们的诉求，我们将这样作出改进。”苏拉克认为，这样做是在告诉组织：“高管和工程师在以同样方式工作”，提高了员工的积极性，让他们对敏捷实践更信赖。

3.以共同愿景协同各部门与职能。艾瑞克·马泰拉（Erik Martella）是星座品牌公司（Constellation Brands）旗下酒业Mission Bell酒庄的副总裁兼总经理。他为酒庄带来了敏捷管理，并最终使其在整个酒庄发扬光大。每个部门的领导者是内部各敏捷团队的项目负责人。这些敏捷团队都取得了傲人的成绩，但马泰拉担忧他们的时间会过于分散，具体部门和企业级别的优先事项可能不总完全一致。于是他决定让各部门领导者组成一支高管敏捷团队，集中管理具有最高价值和最佳跨部门合作机会的企业级项目，比如利用仓库加快进程流动。

高管敏捷团队负责发现并不断优化企业优先选项的积压工作，保证敏捷团队处理的是正确的问题，而且具有充足资源。该团队成员也负责避免让组织在判断项目的优先级别时，免受个人好恶的影响。例如，马泰拉刚开始实施敏捷管理不久后，就收到了来自星座品牌公司某上级的电子邮件，建议Mission Bell 酒庄研究其个人的某项喜好。换作以前，马泰拉可能回复：“好的，我们马上开始。”但如今他的回信遵守了敏捷原则：该建议将被加入潜在机会清单，然后进行优先级别判断。实际情况是，该上级欣赏这种处理方式，当他得知自己的建议被判为低优先级时，心甘情愿地接受了决定。

管理敏捷团队也能够帮助职能部门管理者更好地向综合管理职位过渡。在如今过于细分的组织中，部门管理者少有机会能离开职能孤岛；而敏捷团队让他们能接触到其他专业人员，传授他们合作实践，并强调与顾客紧密合作的重要性——都是未来领导者所须具备的能力。

6 扫清敏捷行为的障碍

据成员数量超过40万的独立非盈利机构司克兰联盟调查，超过70％的敏捷方法使用者表示，他们的团队同组织中其他部门关系紧张。这很容易理解：他们选择了完全不同的路线，而且前行速度也不同。

下例颇具说服力：我们考察的一家大型金融服务公司利用敏捷方法开展了新移动应用研发的试点项目。当然第一步就是要组建团队，这就需要提出预算申请，授权并资助该项目。此项申请与一批提议一起竞争通过下个年度计划。经过数月审议后，公司最终批准了该预算。该试点项目造就了一款成功的应用，得到了顾客夸奖，整个团队为业绩自豪。但在应用发布之前，其必须要通过传统“瀑布式”流程的漏洞检测（一道拖沓的程序，用来检测计算机代码的文件编制、功能、效率和标准化），而且等待的队伍很长。然后，这款应用必须被整合到核心IT系统中，整合过程同样需要经过另一道瀑布式流程——又是6到9个月的漫长等待。最终发布应用的总时间并没加快多少。

下面是一些为敏捷方法扫清障碍的技巧：

让所有人保持同步。专注于复杂大问题切分成小部分的特别团队，须能看到公司整体的优先事项清单，并按照同一清单的安排工作，哪怕不是所有对这些优先事项负责的团队都在使用敏捷流程。如果一款新移动应用对于软件开发是最优事项，那么对于安排预算、漏洞检测和软件融合也都应该是最优事项。否则敏捷创新将阻碍重重。这一点是践行敏捷方法高管团队的关键职责。

不要马上改变结构；而要改变角色。很多高管以为，建立更多跨职能团队必将导致组织结构发生重大变化，这种情况其实很少发生。就其本质而言，充分享有自主权的跨职能团队，需要某种形式的矩阵式管理，但这样做首先需要让不同的专业人才学会如何一起同步工作，而非各自为政或按流程工作。

家有千口主事一人。员工可能有不止一个老板，但决定只能一个人做。在敏捷运营模式中，以下几点必须做到百分百清晰：由谁来任命跨职能团队；遴选和替换团队成员；指定团队领导者；以及批准团队决定。敏捷领导力团队通常授权一名高管来发现关键问题、设计解决这些问题的流程，以及为每个创新项目指定一位负责人。其他高管必须避免事后诸葛或推翻负责人的决定。提供指导和协助没有问题，但如果你对结果不满意，可以更换项目负责人，而不要阻挠他／她工作。

聚焦团队，而非个人。MIT（麻省理工学院）集体智慧研究中心及其他一些研究都发现，尽管个人智慧影响团队表现，但团队的集体智慧更重要，而且更容易改变。敏捷团队利用流程促进员采取以下办法不断提高集体智慧：澄清角色、传授化解矛盾技巧，以及保证团队成员做出同等贡献。其他办法还包括：将评判标准从产量和利用率（员工忙碌的程度）转变为业务结果和团队快乐度（员工价值和积极程度）；以及建立更重视团队结果，而非个人成果的认可和奖励机制。

问题导向，而非命令。巴顿将军说过一句话，劝诫领导者永远不要告诉人们怎么做：“告诉他们做什么，他们的足智多谋会使你惊讶。”除下命令，敏捷组织的领导会通过问题引导员工，比如“你推荐什么？”，“我们怎么对其进行测试？”这种管理方式让各领域专家成长为总管，让企业战略家和组织摆脱在孤岛上争夺权力和资源的状态，融合成为相互协作的跨职能团队。

敏捷创新让软件行业改头换面，有人甚至认为在过去的30年里，软件业经历的变化之剧、变化速度之快超过了其他任何商业领域。而现在敏捷创新蓄势待发，将巨变几乎带到每一行业的每一职能部门。到了这一节点，最大的阻碍并非缺乏更好的方法论、对可观利益的经验实证，或是敏捷方法能在IT之外成功应用的证据，而是高管们的言行。谁能将敏捷方法延展到更广泛的商业活动中，谁就能让盈利性增长来得更快。（刘铮筝 |  译   王晨| 校   钮键军 | 编辑）

达瑞尔·里格比是贝恩公司波士顿办公室的合伙人，领导该公司全球创新和零售业务。

杰夫·萨瑟兰是敏捷创新“司克兰模式”的共创者，以及司克兰咨询和培训公司的CEO。

竹内弘高是哈佛商学院战略领域教授。

敏捷方法的价值观及原则

2001年，17名离经叛道的软件开发工程师（本文作者之一杰夫·萨瑟兰也在其中）齐聚美国犹他州雪鸟城，探讨改进传统“瀑布式”软件开发程序的办法。瀑布式开发先制定出具体的要求和执行计划，然后按照各自职能分步骤进行。这种方法适合稳定的环境，但当软件市场开始发生迅速和不可预测的变化，便不再适用。在新变化之下，等把软件送到顾客手中时，产品的具体细节已经过时，而开发者则被官僚制度束手束脚。

这17位叛逆工程师提出了软件开发的4项新价值观，描述了遵循这些价值观的指导原则，号召同行响应他们发起的这一“敏捷宣言”。迄今为止，遵循这些价值观和原则的开发框架作为敏捷技巧为人所知。以下是该宣言的精简版： 

人才比流程和工具重要

项目的规划应以人为本，参与项目的人才应该被赋予所需的帮助，用人莫疑，疑人莫用。团队应摒弃“流水线”心态，代之以便于解决问题的有趣、有创意环境，并应保持可持续的开发速度（开发者每周超时工作不利于提高效率，最好每周工作时间不超过40小时——译者注）。管理者应该面对面讨论改善工作环境的方法。管理者应消除障碍，促成更便利、更高产的合作。

工作原型比案牍重要

创新者如果在真实市场状态中看到他们的结果，就能学得更快、心情更佳、在同一职位上停留时间更长，以及完成更有价值的工作。团队应在短期内，让少数顾客实验少量部分产品；留下那些顾客喜欢的部分，让团队研究修补或放弃其余顾客不喜欢的部分。团队成员应该通过实践解决争议，而不是通过无休止的辩论或上报领导。

应对变化而非遵循计划

对传统项目管理，进行极尽详细预测和计划不过是浪费时间和金钱。尽管团队有必要谋划未来和制定计划，但仅仅计划那些在未来执行时不会发生改变的任务就够了。而且，成员们应该为能够学到可以转变他们方向的事物感到高兴，哪怕转向在开发过程的晚期发生。这样做能让他们贴近顾客，获得更好结果。

顾客协作比死板合同重要

问市的时间和成本是重中之重，因为顾客很少能预测出他们真正想要什么，所以具体细节应该在项目当中逐步落实。快速原型、频繁市场测试以及不断协作让工作始终围绕着顾客最终看重的内容开展。