敏捷倡导团队文化

需求在不断地变更，客户的权力接力棒在不断地转接，很多的软件开发企业的领袖都选择敏捷开发作为其软件过程，那么在打算实施敏捷以前先得知道是否具备敏捷的一些潜质，敏捷的本质又是什么？而我们的建议是不要让敏捷成为混乱的一个借口，这同时也是软件架构师可以考虑的问题。

一般而言很多人都把2001年敏捷联盟大会的成立作为敏捷软件方法的诞生日期，实际上追溯敏捷的产生可能时间更早。早在上世纪末，XP技术就已经崭露头角，Kent Beck在很多的软件工程的大会上发表其关于XP相关思想的一些讲话。

众多的大师积极研究敏捷的原因是因为由于软件开发所涉及的人、物投入越来越多，越来越多的项目被拉进了延期的泥潭中，相应的投入越来越多，但是产能比却不断下降。

工程师一再抱怨工作压力太大，每天根本没有足够的睡眠时间，而客户却不断的指责谩骂开发的软件产品为什么如此多的Bug。

这与上世纪软件英雄时代所形成的鲜明对比，所以所有的这些使得这些大师都在思考，到底是什么造成了软件开发如此臃肿的身躯？软件开发过程中到底那些部分可以省略？为什么人们对软件过程的定义越来越多，但是所开发出来的软件质量却不见多少好转？面对这种状况又如何去改变？于是在2001年敏捷（Agile）软件联盟宣布成立，并发表了软件敏捷联盟宣言作为团队宗旨。敏捷软件开发宣言认为：

◆个体和交互胜过过程和工具;

◆可以工作的软件胜过面面俱到的文档；

◆客户合作胜过合同谈判；

◆响应变化胜过遵循计划。

根据这四条宣言，敏捷联盟提出了12个敏捷的原则，这12个原则也是区别基于敏捷开发和传统过程方法的准则，分别如下：

◆最优先要做的工作，持续交付有价值的软件使得客户满意；

◆拥抱变化，通过变化为客户创造价值；

◆经常交付软件；

◆业务人员要和开发人员加强沟通；

◆基于被激励起来的个人构建项目；

◆最有效的沟通的面对面的交谈；

◆工作的软件是首要的进度度量标准；

◆要保持恒定的开发速度；

◆不断关注优秀的技术和好的设计模式；

◆简单是软件的根本；

◆最好的架构和设计出自自己的团队；

◆时时反省，随时调整。

对敏捷的理解

上世纪60、70年代一直到90年代中期，软件产品一直笼罩了很多的英雄主义色彩，从微软帝国的Billgates到Linux之父Linus Torvalds，从UCDOS作者鲍岳桥到WPS的求伯君，所有这些大师的开发团队无不是激情四溢的。

确定一个简单的开发目标，快速动手实现原型，以卓越技术为追求目标，每个团队成员都是被激发起来的“编程机器”等这些方法使得整个的开发过程的效率和成果质量迅速提升。因此当软件的开发成本越来越高、时间越来越长的时候，借助这些方法实现软件的好、快、省成了顺理成章的事情。

可以肯定的是很多敏捷的思想并不是从敏捷联盟成立的时候才有的，通过长期的一点一滴地积累，一次一次地实践，敏捷思想形成了一个体系。目前流行的敏捷开发的方法大概有极限编程(XP)、特征驱动开发（FDD）、SCRUM、自适应软件开发（ASD）、动态系统开发方法（DSDM）和水晶方法族（Crystal Methods）等。显然这些方法彼此之间是有差别的，但是敏捷编程肯定是有一些共性的，敏捷首先是一种氛围，一种文化。

自信

自信是敏捷开发的重要因素之一。这里自信的意思是相信自我，一个采用敏捷开发的团队首先要相信自己的团队是最优秀的团队，做的是世界上最优秀的软件。敏捷的团队是绝对不允许有人比我更好的，那对他们而言是一种耻辱。

很多的敏捷开发书籍中将这种行为描述为“追求卓越”，这并不全面，除了追求卓越，更重要的是追求适用、质量、市场等一系列的目标。一直持续追求超越自我的团队，一种不断改进的文化是敏捷开发的核心。如果没有这样的一个核心作为基石，即使采用小版本编译，测试驱动这些敏捷的方法，也终究不过是习之皮毛。更有甚者，如果成了“邯郸学步”那就更为糟糕。

诚然创建一种人人激情四射的氛围不是一件容易的事情，但是如果认为无法创建这样的一种氛围，不如早早的打消敏捷开发的目的。

敏捷12条原则中有一些是基于这个核心的，比如“围绕被激励起来的个人构建项目 ”，“敏捷过程提倡恒定的开发速度”等，这几条原则的目标其实就是想创建一种敏捷的氛围，让所有参与项目的人能够保持一种持续激情的状态。这和软件英雄主义的团队目标何其的相似。而不断的应用新的技能和好的设计模式更可以提高团队的自信，使得团队自信度不断的提升。

交流

创建敏捷团队敏捷氛围的另一个假设是成员之间相互信任。互信这种说法针对中国国情而言尤为重要，由于基于东方人的特点，大多数时候喜独处，不喜交流。特别是对于技术上的问题，很多人宁愿自己一次一次的从搜索引擎中查询也不愿意和伙伴交流，即使这个知识点别人可以给以帮助。

很多编程者根本无法容忍两个人同时共享同一段代码的做法，所以互信或可以称为交流的这个因素就尤为重要了。就个人的实践而言，如果两个人能够同时编写同一段程序是有好处的，一方面可以扩充知识层面，除了帮助文档以外又多了一个更重要的帮助——编程的伙伴，更重要的是可以避免走入“死胡同”。

写过程序人大多都有这种体验，有时候经常在一个地方无法进展下去，总是认为自己是对的，可是结果总是不在自己的预想之内，但是当第二天再来看程序的时候会发现原来昨天的错误是那么的“愚蠢”，其实如果两个人共享这段代码，伙伴一定会在第一时间提醒错误在哪里，这是多么省时省事的一种做法。

敏捷开发的原则中认为最有效的沟通方式就是面对面的交流。而XP中对“互信”有更加详细的规范，结对编程是互信的一个典型体现。结对编程要求结对人员强烈的进行交互，而最终的代码由两人共同设计、维护。这大大加快了思想、知识在整个团队中的传播速度，使得整个团队形成统一的合力，使得整个项目不单单依赖个人的力量，在一些关键时刻，常常能有“替补队员”代替所需要的专家。

敏捷开发的原则对交流也有说明，“团队内部最有效果，最有效率的传递信息的方法就是面对面地交谈”，所以交流是敏捷开发的另一个要素。采用敏捷开发的团队在软件开发过程往往到处可以听到讨论的声音，但也有人担心这样的一种氛围会影响开发的进度，致使工作效率降低。

自律

很多人在讨论敏捷与混乱的区别，的确使用敏捷开发的缺点之一就是如果控制不好团队会演变成“有组织，无纪律”的一个群体。因为敏捷方法通常是没有很多的条文框架的，敏捷的规范不是来自规范制定者，而是来自实施者，大部分的敏捷团队的程序员不是遵守纪律，而是进行自律。

敏捷团队中的成员未必是最优秀的开发工程师，但是这些工程师却都知道自己应该做什么事。敏捷团队的任务不是由项目经理派送的，工程师往往自己决定自己应该做的工作。

那么敏捷团队是如何做到这点的呢，其实自律的文化和自信、交流两个话题紧密联系。首先团队成员相信自己是世界上最优秀的团队，每个人都有这样的目标；其次团队内有很多的交流，这样每个人都能了解其他人做的事情，整个项目的进展如何。这样每个工程师就知道自己应该做什么事情，而且也能很快地定位自己应该做的事情。

敏捷在中国的传播

实际上中国对敏捷的思想接触较早的，从2001年敏捷联盟成立以来，很多的敏捷编程就开始被翻译成中文，其中势头最盛的就是极限编程（XP）。

敏捷编程能够在中国大行其道是有国情背景的，一直以来软件工程的思想在中国的推进都不是一帆风顺的，CMM和RUP等这些在国外执行的还不错的思想在中国本地只能是课本上的一种教材案例，或者是一些企业拿来撑充门面的旗帜。所以如何建立有中国特色的软件项目管理体系是很多的项目管理者苦苦探求的事情，而敏捷似乎给了中国人一次机会。