概述

学习敏捷：构建高效团队英文版原名《Learning Agile: Understanding Scrum, XP, Lean, and Kanban》，英文版副标题原义：理解Scrum（橄榄球中的争球的意思）、XP（eXtreme Programming 极限编程）、Lean（精益方法）和Kanban（看板）。结合中文版的副标题以及目录，我们可以大致的了解本书覆盖的内容：第1、2、3章介绍敏捷的价值观和原则；第4、5章介绍Scrum；第6、7章介绍极限编程的思想；第8章介绍精益方法；第9章介绍看板，第10章团队实战。实际上，如果我们拿Scrum、极限编程、精益方法、看板分别作为关键字来找书，每个关键字都可以找到很多的专门阐述该关键字的著作。所以，“敏捷”实际上是一个大课题，如果你还没接触过“敏捷”的概念，那么看这本书就对了，本书将带你游览“敏捷”的各个领域，为你的团队走向敏捷之路打开大门。

什么是敏捷?

我们这本书的封面是生活在亚马逊丛林里的跳猴（也叫尾狨猴，学名：Callimico goeldii），一般六只左右组成一个群体，通过叫声进行联系。想来编辑用跳猴🐒 作封面而不是用树懒（电影《疯狂动物城》里的那种）是有所寓意的。

如果你是一个项目经理或者团队Leader或者软件开发人员，你有没有为下面的事情困扰过？

✦ 说好了这个月底软件交付使用，真到了月底还差的远呢！

✦ 软件确实是交付了，但是带着一堆的bug，根本没法用！

✦ 源代码除了写的那个人能看懂，别人都看不懂！

✦ 用户根本不知道我们开发的这个软件能带来什么价值！

✦ 996算什么，我们天天在办公室睡行军床！

如果你遇到过这些困扰，那么祝贺你，“敏捷”作出了以下承诺

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

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

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

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

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

“敏捷”意味着什么？要想实施敏捷该怎么做？书里的回答是——重视改变团队的思维模式 （读者：给全团队进行洗脑❓），只要转变了思维模式，一个仅仅接触敏捷实践皮毛的团队就可以获得提升（是不是很令人兴奋💪🏽 ，以及更多的疑惑——不是吹的？🤔 ）

真的有那么神吗？可能每个读者心中都会发出疑问，如果看看一些具体的实践者的描述，情况可能不是那么的理想，下面是我在简书随意搜索出的几篇文章：《聊聊敏捷之死》、《十条敏捷失败之路》、《被曲解的敏捷苦了程序员们》、《敏捷QA，从入门到放弃》、《【玩坏了的敏捷】敏捷团队不是从石头缝蹦出来的》。看看敏捷都和什么关键词凑一块了：之死、失败、苦了、放弃、玩坏……

其实，本书也大大方方的承认，敏捷在实施过程中会遇到各种各样的困难，以致于被抵制、无法有效实施、失败……比如：

✦ 你尝试了一种敏捷实践，但是并没有成效。

✦ 每日站立会议已经实施，但你还是被各种问题所困扰，理不清头绪，而且无法按时完成任务。

✦ 也许你的团队尝试采用Scrum或极限编程之类的方法进行大规模敏捷化，但似乎总是感觉华而不实。

✦ 好像所有人都做了必要的事情，但是项目得到的改善却微乎其微。

其实吧，本书正是要帮助我们用正确的姿势来学习、领悟和实践敏捷的价值观、管理和思想，让我们早日脱离苦海，得道升天😇

“敏捷”的价值观

要实施好“敏捷”，首先要理解其价值观，还有另一种叫法：“敏捷软件开发宣言”(Manifesto for Agile Software Development)——

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

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

✦ 客户协作高于合同谈判

✦ 响应变化高于遵循计划

这四点应该在每一本介绍“敏捷”的书都会提到，但本书用了一个生动的故事来描述敏捷的价值观为什么会应运而生。太阳下无新鲜事，大概每个项目经理、团队Leader、程序员以及甲方都会遇到类似的故事——瀑布式开发带来的痛苦，特别是需求变动带来的痛苦

变化真要命

锅真的是“瀑布式”开发方法的吗？也未必，本书还是承认瀑布式方法是能够开发出好的软件的，前提是你的团队、工具、管理等方面都要足够的强大。

故事里，瀑布式开发如期扑街了，拯救团队的“敏捷”开发正式登场。如故事所述，在向敏捷靠拢的过程中，团队中每一个人的工作都变得更为顺利。架构师和开发人员开始养成更好的代码编写习惯。项目经理随时都可以掌握项目的进展，团队Leader可以专注于专业技能的改进并进行沟通。但是，他们还没有变成一个真正的敏捷团队，因为他们还存在着视角割裂(fractured perspective)的问题 —— 其实视角割裂几乎存在于大大小小的各种规模的公司和团队，团队里每个人只考虑自己的工作，不关心全局，那么最后就有可能出现这样的问题。

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

不那么好的“敏捷”结果并不是我们想要的，如何让每一个人融入到“敏捷”实践中去，这是个需要智慧和技巧的事情，而“敏捷”一再强调的就是沟通——团队成员在项目的始终过程中要保持高度的沟通而不是各自为战。

关于各个“敏捷”涉及到的关键字，本书推荐了一些书：