之一：文化根源分析

最近研究敏捷项目管理，发现其中很多的最佳实践体现出了非常多的项目团队的文化变革，在此小结分享。

相信很多人还记得五年前曾经非常火过一段的软件工厂的概念，当时有一些公司基于软件工程工具平台，建立起覆盖软件交付全生命周期的软件交付生产线。生产线上的每个开发人员就像是汽车生产线上的工人，关注如何基于流水线的速度，根据任务单的要求，高效地完成自己负责的软件交付环节的工作。甚至每个开发人员工作的工作终端没有存储接口，不能浏览Internet，所有的信息确保被安全的保存在公司的配置管理库。在当时的软件工厂的概念中，一向被认为是从事高智商和高知识内涵工作的软件交付人员被毫不留情的称为软件蓝领。

然而，软件毕竟不是汽车，软件的生产速度也不是靠生产线的流动速度来决定的，泰勒的科学管理思想在软件的世界里明显显示出来对人性本身分析和利用方面的不足，作为软件交付主体的人和团队，在软件交付过程中起到至关重要的作用。而整个软件行业从业人员在被各种重量级的软件交付流程，各种软件成熟度模型折腾得筋疲力尽，终于迸发出解放思想、追求变革的呼声。加之很多业务快速变化或需求快速变化的行业，例如游戏开发、Internet应用、电子商务等，要求开发团队必须在更短的时间内能够交付新的发布版本，必须能够对需求做出更加快速的响应。敏捷运动正是在这种软件交付文化革命的大背景下，快速的发展、成熟和广为接受。

很多喜欢敏捷开发的朋友都喜欢用RUP作为对比对象。然而，平心静气、仔细思考之后，我们不难发现，RUP其实和敏捷一样，它提供给我们迭代式软件开发、业务驱动的团队协作、有效平衡干系人需求、持续质量保证、两级项目规划和合适的流程等最佳实践，并且提供了企业采纳这些最佳实践的客户化工具RMC。因此，在敏捷革命来临之际，喜爱敏捷的人们很快就基于RUP，定制出面向敏捷的AUP和OpenUP，广为敏捷爱好者接受。因此，在软件交付的世界里，错不在RUP本身，而是我们在推广RUP的过程中没有做好的非常关键的一件事，就是流程推广的文化导向，关注适用还是标准化；关注作为软件交付主题的大多数人:开发人员，还是少数软件过程管理者需求；关注客户的需求，还是开发商的资质。因此，认真思考敏捷带给我们管理中的文化变革，理解其精髓，是我们能否真正敏捷的关键。

之二：敏捷的文化基因-平衡之道

敏捷最有智慧的地方在于它只为我们提出了核心价值观和12条原则，它并没有告诉做什么和怎么做，因此基于这一基础，任何符合敏捷核心价值观和原则的方法、实践，我们都可以称之为敏捷。正是敏捷开发的这种开放性和动态发展的特性，留给敏捷开发人员巨大的空间，赋予了敏捷无限的魅力，但同时也留给敏捷实践者太多的困惑和无奈。

众所周知，敏捷开发是一个涵盖性术语，它包括SCRUM，XP，LEAN，AUP等多种类似的方法和实践。基于这些内容，产生出了敏捷开发的基本价值观和12条原则：

• 人和交互重于过程和工具。
• 可以工作的软件重于求全责备的文档。
• 客户协作重于合同谈判。
• 随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

敏捷开发的12条原则：

• 首要目标：更早地持续地交付有价值的软件，满足客户需求
• 即使到了开发的后期，也欢迎需求变更
• 频繁交付可工作的软件
• 关注协作，业务人员和开发人员必须每天协同工作
• 围绕被激励起来的个人来构建项目
• 面对面的交谈，是最有效和效率最高的沟通方法
• 可工作的软件是度量进度的主要标准
• 敏捷过程提倡可持续的开发速度
• 持续地优化技术和设计，会增强敏捷能力
• 简单--使工作效率最大化的艺术--是基本原则
• 最好的构架、需求和设计，出自自组织团队
• 定期总结回顾，思考团队如何更加高效，并作出相应调整

敏捷的核心价值观和12条原则赋予了敏捷开发团队基本的思想文化基因，我们可以将其理解为敏捷之道中规律的部分（道之无名）；而敏捷开发团队基于敏捷的核心价值观和12条原则所进行的各种敏捷实践，我们可以将其理解为敏捷之道中表象的部分（道之有名）。观“有名”而悟“无名”，据“无名”而推“有名”，此正所谓“一阴一阳谓之道”。

1 敏捷的“平衡”思想

从敏捷宣言对敏捷的核心价值观的阐述方式上，可以看到敏捷是一个相对的概念，它最终体现的是敏捷实践者对敏捷实践的一种拿捏和平衡。在一个团队推行敏捷的过程中，问得最多的问题就是关于敏捷开发流程的轻重、敏捷开发团队的大小分布、敏捷开发过程中工具的使用、敏捷最佳实践的采用顺序和数量，聪明的敏捷实践者知道上述所有问题都没有明确的答案，因为它需要具体情况具体分析。敏捷开发推崇的是做在指定环境中正确的事情，做对指定团队有效的事情，因此敏捷是一种实践方法和哲学，而不是一种理论方法，它讲究的是一种基于实践的平衡之道。

在敏捷开发中存在几个非常著名的实践平衡：

1.1 项目和迭代间的平衡

项目越大，管理的复杂度就越大，带给项目管理团队的管理难度也就越高。敏捷开发中最重要的一个开发实践就是迭代式开发，其本质就是变长的、复杂的项目周期为短的、简单的迭代周期，从而改变了我们多久运行项目一次？同时通过不断重复的迭代周期，不断积累项目管理经验，提高团队绩效，改进团队开发速度。通过有效平衡项目和迭代，使团队在实现把复杂问题简单化的同时，积小胜为大胜，积珪步而至千里。

1.2 计划的平衡

计划的主要作用无外乎以下几点：

• 统一思想，明确目标
• 团队沟通
• 整合团队工作
• 作为项目监控的基准

然而，地球人都知道计划赶不上变化的道理。尤其是当今业务飞速发展、经济市场环境不断创新的时代。敏捷团队不相信大的计划，取而代之敏捷团队使用分层的项目计划：发布计划、迭代计划和每日计划，迭代式软件开发和两级项目规划两个敏捷最佳实践，将规划过程分成了发布规划和迭代规划两个动态过程，发布规划的目标是制定出发布计划，发布计划中包含主要的项目远景、发布时间节点和里程碑要求，忽略善变的细节；而迭代计划中则包含具体计划实施的细节内容，它是个动态的计划，主要关注当前迭代和下一迭代工作内容，包括具体实施细节。由此可见，敏捷规划过程本身就是一个平衡过程，粗粒度的目标节点和细部的任务规划之间远粗近细的平衡，计划中不变的里程碑要求和善变的工作内容之间的动态平衡。

1.3 需求管理的平衡

众所周知，项目的本质是渐进明细的，而需求开发过程的本质是启发式的，尤其是软件需求，整个开发过程就是一个由抽象到具体，由概念到实体的过程，因此项目需求变更成为必然，新的需求的不断提出也成为必然，这导致项目范围管理难度较大。同时加上很多软件生存的快速变化的业务环境和市场环境，如何保证快速响应需求变更的同时，保证软件的快速交付就成了一大难题。

敏捷开发基于需求不断变化的事实和快速响应客户需求变更的要求，通过很好的平衡需求中的变与不变的部分，做到了需求的动态平衡。

敏捷项目中，需求在整个生命周期中是不断变化的，但为了保证软件开发团队工作的相对稳定，进入迭代规划的需求却又是相对固定不变的。敏捷开发团队正式通过这种对需求变与不变的相对平衡，智慧地即满足了快速响应客户变更，又保证可开发团队不为变更困扰。

之三：敏捷的文化基因 - “拿来主义”和“实用主义”

纵观敏捷开发的发展过程，充满了“拿来主义”和“实用主义”的思想

二十世纪三十年代，当中国闭关自守的大门被砸破之后，帝国主义列强为中国“送来”了鸦片、枪炮、电影 及各种小东西进行军事、经济、文化侵略，因而使清醒的青年们对于外来的东西“发生了恐怖”，产生了一种盲目排外、全面否定的思想。面对这种社会现状，鲁迅先生提出了“我们要运用脑髓，放出眼光，自己来拿！”的“拿来主义”。而实用主义则是由美国的皮尔士提出，其根本纲领是：把确定信念作为出发点，把采取行动当作主要手段，把获得实际效果当作最高目的。

敏捷开发的聪明之处正在于它只定义了核心的价值观和12个基本原则，而把如何基于“拿来主义”和“实用主义”思想，有效利用基于核心价值观和基本元则的各种最佳实践，实现真正的敏捷开发的任务交给了使用者。成功了，功在敏捷，倘若失败了，则败在实施。在敏捷宣言发布之前，很多最佳实践就已存在。例如RUP中的迭代式软件开发、两级项目规划、风险和价值驱动的生命周期等；例如XP中的持续集成、整体团队、测试驱动开发等；象“精益开发”中的减少浪费、快速交付、尊重个人等。而敏捷开发只是奉行“拿来主义”原则将其我们所有。而决定每种最佳实践是否被我所有的原则就是“实用主义”。敏捷开发关注如何快速交付客户价值，避免交付对客户没有价值的东西，避免过度规划和设计造成的浪费，这些都是“拿来主义”和“实用主义”思想在敏捷开发中的体现。

敏捷开发 VS RUP

在敏捷开发最佳实践中我们很容易看到昔日RUP的核心思想：迭代式软件开发、两级项目规划和持续集成的影子。同时顺应敏捷开发的发展，RUP经过敏捷化定制推出的OpenUP，正是RUP全面支持敏捷、贡献敏捷的具体表现。同时，RUP在解决今天敏捷开发过程中存在的问题方面有着无法忽视的价值。尤其是在敏捷走向规划化的时候，很多敏捷实践者都会发现敏捷团队的沟通、文化冲突、架构管理和变更管理等方面，正遇到越来越多的麻烦。而在这方面，RUP的风险驱动的生命周期管理和以架构为核心的最佳实践，会对在组织级推广敏捷过程时，提供完美的解决方案。怪不得敏捷开发大师Scott Ambler会说：RUP实施的好，就是敏捷的过程；而敏捷过程实施的好，就是RUP。

RUP以其完整的软件开发过程和过程中每个环节具体工作方法、最佳实践的定义，奠定了软件工程方法和思想基础，它培养了整整一代软件工程从业人员。今天随着敏捷开发过程的出现和成熟，Rational已经完成了由传统的RUP向今天合适的软件开发过程的演进，赋予RUP以新的内涵和能力。因此，由RUP发展而成的RMC最佳实践库是整个软件工程领域（IBM和整个软件工程社区）最佳实践的结晶，它既包含传统的软件开发过程，也包含业界最新的敏捷开发和大规模敏捷开发的最佳实践。它更像是一个能够满足不同企业、不同规模项目要求的软件开发过程的过程族，丰富而不死版，默默贡献却又不拘一格。

敏捷开发 VS 精益开发

敏捷开发的成长得益于很多其它软件交付方法的发展，这其中精益开发为敏捷带来很多的思想精髓。精益(Lean)开发始于丰田汽车的流水线生产的管理方法，它的核心思想是避免所有的浪费和尽早地让客户参与。而敏捷开发的哲学是集中精力向客户交付价值，避免生产对客户没有价值的东西，因此有效利用精益方法关于如何减少浪费的相关经验，会对敏捷方法大有裨益。

基于Poppendieck的统计分析，软件开发过程中的九大浪费主要在于：

1. 部分完成的工作：成为过时的、价值不明的工作，造成潜在浪费

2. 额外的特性：额外的成本、额外的工作，产生的却是可能对客户没有价值的功能

3. 重新学习：同样的事情做两遍，并可能重新犯同样的错误

4. 任务转换：必然带来流动损耗和资源浪费

5. 移交：关键信息的损失，导致价值的衰减和资源浪费(特别是通过文档 )

6. 延迟：意味带来更多的变更机会和未能向客户交付价值

7. 缺陷：成本 = 影响 x 修正时间

8. 多余的流程 ：代表了不必要的文档工作和无效的沟通

9. 管理活动 ：不恰当的管理活动意味着浪费的工作量和失去关注点

基于以上统计结果，如何有效利用敏捷开发实践，避免上述的各种浪费，是精益开发带给敏捷实践者最大的礼物。