-1- 雪鸟山庄小聚义
2001年2月，北美大陆还处在早春，整整一个冬季的寒冷依旧没有散去。
这显然不是一个工作的季节，除了围着火炉喝咖啡、聊天、思考以外，一切都显得那么暗淡与多余。
就在这个时候，位于美国犹他州瓦萨奇山区的雪鸟滑雪胜地迎来了17位客人，显然他们是为了某种目的相约而至。
这17位客人中，有极限编程的追随者，有SCRUM实践者，有自适应开发支持者，有完全透明法的支持者，有特征驱动开发或务实编程的支持者。
他们个个身怀绝技，但却不无一致地对基于文档驱动的重量级软件开发模式感到不满，希望能够找到一种适应时代特点的轻量级软件开发方法。
俗话说，道不同不与相谋，相似的痛苦经历和理想追求促使他们聚在了一起。
谁也没有想到，这次聚会对软件开发模式产生了巨大的影响，各种争论也一直没有平息过。
这17人莫不是天罡地煞下凡， 搅得整个软件世界不得安宁?
-2- 时代背景
那么，在那个时代（2000年左右），软件开发都出现了哪些特点呢？
大叔总结为：
- 新经济模式出现，例如：e-business, e-commerce，B/S结构转型
- 资本急于抢占市场
- 需求增多并超出软件生产能力
- 新市场处于探索期，需求随时变化
- 投资人的资金和耐心都有限
说白了，就是在资本贪婪的驱动下，要求软件生产活动能够多、快、好、省地满足资本欲望罢了。
这里需要澄清的是，大叔并不反对贪婪，反而是资本逐利的赞同者。
德国著名政治经济学家和社会学家马克思-韦伯在他的经典著作《新教伦理与资本主义精神》里，就深刻阐述了资本主义精神与加尔文宗在伦理观念上的渊源关系，逐利没有违背宗教价值观，反而在诚实守信前提下的逐利，完备了人的天职，推动了资本主义与整个西方文明的发展。
天下熙熙，皆为利来；天下攘攘，皆为利往；仓廪实而知礼节，衣食足而知荣辱。
大叔反对的是那种土匪抢夺式的贪婪，甚至分明被抢劫了，还不允许说话。这种贪婪，禽兽不及。
-3- 宣言的诞生
言归正传。就在一年前，类似的由极限编程者组织的聚会就搞过那么一次。只可惜俄勒冈州的罗格河畔景色过于优美，与会者吃喝一通，除了纷纷表示赞同轻量级编程方法以外，并没有留下什么结论性成果。
这次17位义士相聚雪鸟山庄，可不是为了吃喝和滑雪来的。
经过三天的讨论（2月11-13），共同拟定出了一份关于轻量级编程的思想纲领：《敏捷宣言》
宣言包含了4条价值观和12条基本原则，熟悉的读者可以直接忽略。
价值观：
原则：
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
-4- 宣言的本质
《敏捷宣言》实际上仅仅是一种思想与方法论，并不涉及具体的方法。
其核心内容主要包括：以人为本、持续交付、响应变化。其它内容都是为了围绕这个核心展开的。
在大叔眼里，宣言更像是一种新时代背景下对客户的承诺，大叔把它翻译成：
“亲爱的客户，我们承诺将尽一切可能，采取最实用的方法，在合理的时间内，持续的有效的给您交付可靠的产品，并欣然接受一切变化。”
具体细节、方法都包含在了“尽一切可能”和“实用”这两点上，这样的思想，充满了西方实用主义哲学的精神。
因此，我们说，《敏捷宣言》的本质就是软件工程领域里的一种充满实用主义哲学思想的方法论。
实用主义是19世纪70年代在美国本土产生的一个哲学流派，并在20世纪成为美国的主流思想，对美国的方方面面影响甚广。
实用主义哲学调和了理性主义与非理性主义哲学，放弃了对终极真理的追求，认为有用即为真理。有用无用是判断真理与谬误的唯一标准。
实用主义强调以人为本，尊重人的经验，追崇行动。相信行动优于教条，经验优于僵化的原则。
细看敏捷的价值观和原则，无不透着实用主义的思想光辉。我们在后面对假敏捷的判断，也主要是采用了实用主义对真假的判断标准。
-5- 敏捷方法及其特征和局限性
敏捷思想在布道者的宣传下，很快风靡全球，相应的敏捷方法（SCRUM, KANBAN）以及一系列敏捷开发工具（Jira, Leangoo, Teambition...）也纷纷传播。
敏捷方法是在敏捷思想指导下的软件工程领域的方法，敏捷方法的目的是为了实现敏捷思想提出的目标（以人为本，持续交付，响应变化...）。
作为软件工程领域的方法，一定具有一切技术工程类方法的通用特征，大叔总结为以下几点：
- 方法源于经验 脱离经验实施敏捷，是不科学的，尤其要尊重工程技术经验。
- 方法具有多样性 方法有多种，侧重点不同，很难找出万能方法。
- 方法具有灵活性 方法以解决问题为目的，而不应沦为死板的教条。
- 方法通过行动实现 方法不是优美的口号，需要行动才有意义。
- 方法依据有效性评判 敏捷是实用主义方法，真假的判别依据就是有用和有效。
这个世界很有意思，再好的思想，方法不得当不行；再好的方法，使用不得当也不行。倘若思想邪恶了，方法得当不得当反倒都不重要了。
这个例子近代就不少，也常被冠以《某某某宣言》，技术也罢，社会也罢，大都如此。
敏捷方法尤其被软件外包公司追崇并奉为圭皋，外包公司在对客户宣传的时候，不无例外的宣扬他们遵循敏捷开发之道。
一时间，谈软件必敏捷。你若还没有用敏捷，出门都不好意思说自己是搞软件的。
趋之若鹜，熙熙攘攘，一片尘土飞扬。
人们似乎忘记了敏捷的本质与目标，而沉浸在五花八门的敏捷实践过程当中。
当然，有真的，也有假的。
-6- 你可能遇到了假敏捷
事实上，判断一个敏捷方法实践的真伪，并不依据有没有使用敏捷管理工具，也不依据是否引入了SCRUM流程。
真假敏捷方法的判断只有一条：是否符合并遵循了敏捷思想的价值观和原则，并获得实用效果。
假敏捷的危害有时候比不敏捷还大，敏捷用不好，反倒会把简单事情复杂化，增大成本，阻碍软件生产。
是敏捷，非敏捷，而名敏捷也。
我们列举一些常见的假敏捷例子，你看看自己在敏捷实践中有没有遇到过，希望对你有所帮助。
1）已经计划好的Sprint不能更改
你有没有听到过这样的声音：
“是谁给当前Sprint Backlog增加了Ticket? Sprint的Capacity都增大了。”
“你把这个Ticket挪出去有没有给Project Manager通知？”
“Sprint Backlog已经计划好了，增加和删除都不允许”
这种论调都是假敏捷的表现。
实际上，软件开发过程中各种突发事情都有可能发生，或新想法，或新障碍。Sprint Backlog不应被视为一种承诺，而只能是一种短期预测。
在不影响Sprint Goal的前提下，Sprint Backlog可以由开发根据实际情况做临时调整。
判点：尊重个人能力和价值，关注交付
2）Release只能安排在Sprint结束的时候
Sprint只是定义了持续增量的最小边界范围，用以完成可提交特性。Sprint和Release没有关系。
判点：Sprint的概念
3）会议一个都不能少
会议应该根据实际情况，有问题了说问题，没问题了不开也可以。敏捷团队都在一起工作，及时沟通很容易。
雷打不动的开会，都是浪费时间。
判点：简洁，高效，务实
4）总结回顾会不够私密
总结回顾会是Scrum内部成员的会议，不允许成员以外的任何人参加。开发人员需要一个私密的环境畅所欲言。
严格意义上，Manager是不应该参加Scrum团队的总结回顾会的。会议的结果通过邮件发送给所有人，这种做法更不正确。
判点：激励个人，对个人的尊重与信任
5）Product Backlog包含Technical Item
Product Backlog是Product Owner维护的，除了产品特性需求外，不应该有技术性项目。所有跟技术相关事务由技术人员自治维护。
这么做的目的是为了清晰划分PO和Scrum Member的责任和权利。
判点：责权清晰简单
6) Scrum Master以领导自居
当前常见的一个现象是Project Manager兼职Scrum Master，Scrum Master时常习惯性的以领导自居，分配任务，安排优先顺序。
实际上Scrum Master只具有三个责任：推动Scrum流程, 打造高效率团队，排除障碍。
敏捷的一个重要理念是团队具有高度的自治力，团队成员自己主动决定要做什么，怎么做。他们会主动pull任务，而不是由任何人assign任务。
如果你发现Scrum Master参与任务分配, 安排先后顺序，甚至插手技术，对技术指手画脚，那一定是一个假敏捷。
判点：责权清晰，团队自治，信任
7）保持KPI的漂亮比什么都重要
为了保证各种KPI看上去稳定漂亮，人为加以配合。
Plan的点不能多不能少，Defect比例要稳定，Burdown不能过快或者过慢，这些都是假的表现。
判点：荒谬
8）简单事情复杂化
分明从技术的角度很简单的事情，一定要走敏捷流程才能完成。
判点：灵活性高于管理
9）教条地划分Story
一个Story的故事点超过13就必须划分，理由可能是领导不想看到点数太大的Story。
实际上Story的点数跟时间没有关系，有些Story可以并行工作，不一定花费太长时间。
判点：实用主义反对一切教条
可见，敏捷并不是万能神药，一旦吞服不当就容易走火入魔。
不忘初心，理解敏捷的核心理念和思想，比起教条的遵循流程要重要的多。
开放、自由、信任、互动、创新这些软实力，才是打造高效团队保障优质产出的推动力。
让我们一起提高鉴别力，共同走向求真、务实、高效的软件开发道路。
谢谢！