如何采用敏捷方法？

 

敏捷方法是相对于传统软件过程方法而言是一种轻量级的方法，可以简化流程，提高效率。这是很多软件组织青睐敏捷方法的原因，但是敏捷方法不适放之四海而皆准的真理，不是任何组织，任何软件开发都可以使用XP（ExtremeProgramming，极限编程，敏捷方法的一种）的。敏捷方法有其适用的条件和适用场合，如果在没有满足使用条件的情况下使用敏捷方法，可能效果适得其反。因此必须分析组织的现状和实施敏捷方法的可行性。逐步导入敏捷方法，才有可能获得成功。关于敏捷方法的详细介绍，可以参看本人文章：

 http://blog.csdn.net/routent/archive/2008/09/06/2892331.aspx

大家都知道敏捷方法可以简化管理，提高效率，快速响应客户需求，快速推出产品。敏捷方法如何在简化流程，简化管理的情况下提高工作效率和提高软件质量呢？这是敏捷方法的诱人之处，答案就是敏捷方法的核心思想：以人为本。敏捷方法强调以人为本，人是软件开发中的第一因素。这一方面体现了敏捷方法对人的重视，另一方面又对人提出了很高的要求，要求实行敏捷开发团队成员具有高水平的编程技术，出色的沟通协调能力和积极主动地工作作风。比如敏捷方法取消了文档，那么软件组织就必须通过频繁的，面对面的交流获知软件的设计情况。敏捷方法强调简单设计，这就需要程序员在设计之初就要设计出简单但是基本符合实际需求的设计模型，而不是字面上的单纯的简单设计，否则日后根本无法满足要求。XP中的pairprogramming是一种紧密合作的最小开发团队模式，这也是需要pair programming的程序员能够协调彼此关系，互相监督和检查，互相促进，要知道，让两个不同个性的程序员亲密无间的工作，这本身就是很大的挑战。

 

CodeReview实例

简化流程后留下的大量管理空白需要程序员自己主动沟通，协调完成。试举一例，比如说敏捷开发方法XP中提到要建立coding standard。然后大家要遵守它。但是如何保证大家都遵守coding standard呢？传统软件过程采用定量测量的方法。首先规定一个code review的评审活动，评审code是否符合coding standard。但是如何保证大家进行code review活动呢？为此还要制定code review的活动规范，可能还需要一些技术手段，比如你不进行code review活动，你的开发状态就是“未评审”的状态，Manager就会找到你，采用管理手段或者经济惩罚手段督促你完成code review活动；然后还有一个code review的质量如何测量的问题，因此又会开发出来一个code review的review活动，还要制定code review评审结果的检测规范，这个规范要规定怎样的review的结果是合理的，怎样的code review过程是有效的等等。一个简单的code review活动，就需要多个不同的相关活动去支持，监测，评估。为了进行这个review的review活动，程序员又不得不进行code review过程的记录从而方便以后的追查。为了方便以后的追查，这个记录最好包括review的活动，参与者，review的问题，修改情况，再次review的情况和最后的结果等等内容。为了方便的统计，浏览各个feature review的信息，最好把它放在一个公共的服务器上，为了方便统一，还要开发相应的工具软件查询和统计review的结果。。。。，为了review 10行代码，你可能需要付出5倍的时间或者更多。。。但是实际效果呢？我相信很多有实际经验的程序员都知道，收效甚微，代价巨大。为什么呢？答案就在于人，所有的活动都是人在参与。仅仅依靠严密的过程控制和所谓的审查标准是很难定量地评估代码质量和评审过程的，或者是很难使用一个量化的标准评估一种智力活动的质量，是每千行发现5个bug作为标准呢？还是10个？评审的时间是1小时合适呢，还是2小时？即使在相同的时间内，一个认真负责的人的review效果和一个漠不关心的reviewer的效果是不一样的；一个有经验的程序员和一个初学者review的结果也是不一样的。但是标准肯定不是简单的时间和数量。

通过流程，文档，各种记录管理人的生产率也是不切实际的，目前软件生产率的测量方法还很落后，测量的结果无非是一些简单的时间和数量的量化指标，有专家论证目前的软件质量，生产率测量方法是有缺陷的，是不符合实际的，所以并没有太多实际的效果。

敏捷方法怎么做呢？他同样要解决这个问题呢，1，如何保证大家都遵守它？如果保证大家很好的遵守它并取得了很好的效果？敏捷方法很简单，取消繁琐的过程，它可能也会有一个code review过程，但是不需要很多的记录，也不需要特定的形式。首先程序员要自觉地按照code standard去写程序并尽最大努力写好它。其次采用尽可能简化的方式请reviwer帮助程序员发现更多的问题，而不是为了惩罚，或者为了统计测量等其他任何无关的目的和任何与code review无关的任何行动。Review的过程集中于发现问题和解决问题，而不是记录问题和惩罚措施，这样就可以做到简单高效。但是前提是所有人已经适应了敏捷开发的文化和具备了敏捷开发的能力。

 

敏捷的人

因此，建立敏捷过程必须有敏捷的人。敏捷的人才有敏捷的思想。就像一些实施面向对象设计的组织和个人，对面向对象的设计思想一知半解，似是而非，以为使用了C++就可以进行面向对象设计了，殊不知，不了解面向对象思想，使用C++也只能写出非面向对象的C++程序，顶多是有类的C程序而已。

敏捷的人都长什么模样呢？首先有敏捷的编程技能，敏捷方法采用适应性方法进行设计，通过不断重构去适应新的需求和逼近设计目标。这就需要程序员有高超的设计和编程能力，能够高效率的开发和重构代码，并能高效的通过测试。另外，还要有敏捷的思想和个人素质，敏捷的人必须一切从敏捷出发，打破常规，高效率的工作，因此，必须有改变的勇气和信心，相信自己越变越好，程序越重构越好，而不是拒绝改变。另外，敏捷需要组织内部和组织之间要高效的协调，通信，项目才能平稳向前推进，这就要求程序员要具有高度的自律，高度的责任感，非凡的沟通能力。否则，敏捷无从谈起。

敏捷的人在哪里呢？不多，我估计现在的组织里能有几个就不错了，这些人肯定是开发骨干，因此，如果想使用敏捷方法，就必须按照开发骨干的要求培养每一个人，把大家都培养成敏捷的人，然后这个组织就可以采用敏捷方法了。当组织中的每个人都变成敏捷的人之后，这个组织就是敏捷的组织，这个组织拥有敏捷的文化，他们不惧怕改变，她们不惧怕改变任何东西，包括他们自己，他们愿意为了敏捷作任何事情。这就是真正敏捷的组织。

 

敏捷组织

根据我多年的经验和观察，国内没有几个有资格可以实施敏捷方法的软件组织。所以敏捷虽好，但是还要适合自己。当然我们也不必悲观，我们可以自我改变，从自身做起，首先要把自己培养成敏捷的人，然后把组织改变成敏捷的组织，在此过程中，可以根据组织的实际情况，实际人员的水平，逐步导入敏捷方法。这个过程可能会很慢，但是不能着急，必须逐步的，持续的改变，最后才能成功。