首次敏捷项目开发实践

 

首次采用敏捷方式进行开发，我想把我们的做法与大家分享下，同时希望大家指出我们的不足和需要改进的地方，让我们的项目进行的更顺利，目前项目已过三分之一，客户比较满意，还算顺利。

 

项目简介：一个DMS小项目，预计时间14人月.客户需求不是很明确，想一边做一边提，适合引入敏捷开发（实际上用户的需求也一直在变，当他们看到每次的small release时都会有新的想法）。

 

Team主要成员：一个team leader（兼BA职责），两个工程师，一个UI设计师。

成员主要职责：team leader主要负责召开会议，明确每天的开发任务以及项目的总体大概进程，保持团队成员清楚的知道项目目前的状态，保持团队沟通顺畅让团队保持高昂的士气。还有个作用是敢于对项目的成败负责（当然团队每个成员都有责任）。工程师的主要职责是开发，设计师主要职责是UI设计。

 

开发环境配备：硬件：两个PC机两个显示器两套鼠标键盘（工作的时候切换到一个PC机上pair编程，共享一个主机，用转换器使一个主机上面接两个显示器，两套鼠标键盘，这样就不用挤在一个显示器前抢一套鼠标键盘pair了），一个测试服务器，上装svn服务器和cruisecontrol来管理代码和实现定时自动化测试（测试一定要自动化，这样可以让机器来干它喜欢并擅长干的事情，让工程师专注自己的业务；我们使用yahoo的一个模拟熔岩灯来监视测试结果。），一个发布服务器，客户可以远程及时试用后给出反馈意见和建议。

 

开发简介：

一、迭代（Iteration）和发布（release）计划

由于项目开发人员比较少，我们决定采用最短的迭代周期（一周），每个迭代前由BA评估story需求风险，开发人员评估story技术风险和cost，选出能在本轮迭代周期中完成的任务；每个迭代结束来一次small release

 

二、我们对实现XP价值观所做的努力

1、  沟通（communication）

再怎么强调沟通的重要性都不为过，尤其是在软件行业。所以在XP中communication被放在首位也不为奇。

我们项目组每天早上开一次Standup Meeting，通报彼此昨天做了哪些工作，以便让开发小组所有人了解各自的工作情况，然后确定今天要做的task，目前公司地牌儿还不够辽阔，我们小组还没有足够的地儿挂白板，就把story和task写在Excel表里面；每个星期一的早上（迭代开始前）会有一个IPM（迭代计划会议），主要内容是大概确定本次迭代周期开发需开发的story，工程师评估每个story完成所需的时间开；每个周五下午（迭代结束前）会有一个Retrospective（迭代结束前会议），会议主要内容是对本次迭代做的好的方面以及待改进的地方进行总结；工程师pari编程。

2、  简单（simplicity）

保持代码和设计尽可能简单是系统可扩展性和可维护性的重要保障。关于Simple Design的讨论可见徐X的Agile 101: Pair Programming & Simple Design  。kent beck用四个条件定义了简单的系统代码：运行所有的测试获得通过、意图明确、没有重复、使用尽可能少的类和方法。我和accompanier也一直在向这个目标努力。

3、  反馈（feedback）

没有持续的反馈，敏捷将无从谈起。customer、accompanier、team以及test result的反馈给我们向用户交付真正需要的系统提供了保证。我们的BA每天和客户沟通，掌握用户真正、迫切需要的功能和需求。由于我们的系统是一周发布一次，所以客户也能在很短的时间内知道完成的新功能，并及时提出改进意见和建议（其实客户的需求也是一直不停地在变的）。

4、  勇气（courage）

为了使代码更加清晰、质量更好，对工作代码进行大范围的修改和重构需要勇气，把某些代码彻底抛弃需要勇气，告诉客户无法再添加新功能需要勇气。我和accompanier目前都还有这样的勇气，希望系统越来越大、代码越来越多的时候还有这样的勇气。

 

三、测试驱动开发（TDD）

关于TDD我们一直在尝试寻找更爽的方法，目前采用的是webwork、spring、hibernate的组合框架，在大脑里无意识的已经存在了三层结构，我觉得采用TDD，这三层结构应该是最后被驱动出来产生的，而不是一开始就定好三层，然后再TDD编码。

我们目前是分别对每层进行TDD，还是觉得service层驱动最有成就感，看到green bar 就令人兴奋，action层老是mock来mock去的走流程实在属没啥意思。

最近又看到了使用Selenium和Castle进行测试驱动开发 ，本想采纳，但是使用Selenium进行至顶向下的驱动的话通过一个测试所需的时间太长了，我是对green bar有点上瘾了的人，不能忍受那么长时间的red bar，怀疑它会对偶的身心健康造成影响，所以就作罢，还是由底至上的方法使测试通过的实践最短，不知道各位对这样的三层结构是怎么TDD的？

 

Robert C. Martin大叔的TDD三条军规如下：

1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。

2.只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）

3.只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必须停下来开始编写产品代码；但是到了原则3，你就只能编写产品代码，直到让测试编译成功或通过断言为准。

 

这三条军规我觉得太经典了，完全做到了才算TDD做到位了。

 

前几个迭代周期我们没有采用TDD,功能代码写了然后写测试，两个月后对系统进行了一次比较大的重构时，所有的测试都通过了，但是发布上去了还是由bug，所以这种干法是不行的，测试不能达到令人满意的覆盖度。TDD完全可以使测试达到令人满意的覆盖度。基本上只要测试通过了，就能确定重构没有对系统造成影响。

 

四、验收测试（acceptance test）/客户测试(customer test)

    验收测试我们是放在最后做的，由BA代客户写验收测试，工程师使用selenium 进行验收测试的实现，我们发现selenium对frame支持的不是很好，有这儿我想到采用至顶向下如：使用Selenium和Castle进行测试驱动开发 进行TDD的话是最合理的，不知道大家是不是这么做的？

 

五、pair 编程

    pair的好处我就不说了，试过了就知道了。

评论

27 楼 完善自我 2012-07-18  

好贴，支持一下

26 楼 clamp 2007-05-23  

snomile 写道

clamp 写道

如果用户数非常多的话，面向正式环境的release是需要比较慎重的。
但是直接发布一个大的release包的风险也是很高的。
还是尽可能切的小一点比较好，另外不是每次发布都一定要培训的，除非有大量的新增功能。

clamp兄做过很多大的项目，你们的产品是怎么发布的呢，是否是每次只发布整个产品的一部分子系统，给客户进行升级？可能我们做的东西子系统划分不是很好，每个版本升级，各个子系统之间的依赖都非常重，没办法只好所有子系统同时升级，包括数据也一起迁移，搞得异常痛苦。
所以我现在想，是否把子系统关系明确拆开，就可以降低产品的发布成本。现在我们也正在做这方面的工作，目前还没有出成果，不过心里不太有底啊。如果客户的需求涉及了多个子系统，那无论如何划分依赖关系也必须全部升级，还是挺麻烦。

常规意义上的子系统的划分和release的时候package的划分，两者是有一定差异的。
通常所说的子系统往往是从业务角度来考虑的，但是在设计时往往会有很多公用的部分。
造成相互之间依赖比较严重。

因此面向release的package的划分是比较头痛的，尤其是系统和系统之间的接口。
我们目前有一个系统大概有五十多个package，其中最大的是一个独立的子系统（不包括该子系统和外部的接口程序），最小的只有一个xml配置文件（用于配置web首页的各类入口）

每次发布少则一两个package，多则五六个package

25 楼 snomile 2007-05-22  

温柔一刀 写道

举个能量化数的例子还真不好举呀。
举个小例子吧，在我们这个项目里面有一个角色之间互相通信模块，情况分的比较细，也比较繁琐，采用TDD我们一点一点前进，每次我们只考虑一种情况写测试，别的都不关心，直到所有的测试都通过了，我们就基本确定代码实现没有问题了。如果不TDD肯定也是可以实现的，但是情况多了一起考虑我会头大，混乱。感觉TDD给了你一个方向，向着这个方向走就行了。而且整个开发过程当中感觉还是比较轻松愉悦的。

这个功能是不是业务功能呢，还是一个系统的底层支撑平台提供的功能，或者说框架功能？如果是业务功能，难道你们不稍微整理一个领域模型吗，如果说“一起考虑我会头大，混乱”，我觉得有点说不过去。你这样一种情况一种情况地TDD，最后代码出来时，我想应该很难基于一个统一的领域模型，那以后重构这个模型的时候岂不是很麻烦。没有全局观念的重构有时候会碰到业务一致性上的问题，就是测试用例都通过了，但是用户一测试就发现这结果不是他们想要的。
另外你们是否每个TDD的时候，都会修改以前的代码呢。比如这个通信模块，有10种情况，每种情况一次TDD，是否每次TDD的时候，都会修改以前几次TDD过程中产生的代码？如果说“一起考虑我会头大，混乱”，说明每次TDD的时候，对业务的整体结构考虑的比较少，那么在以后TDD的过程中，我觉得八成会修改之前的代码，这样工作量是否很大？与预先设计一个简明的领域模型的方式相比，哪个方式更清晰更有效呢？

我的观点还是TDD不能代替领域模型设计，当然也不能搞大而全的设计，领域模型是够用就好的。不知道这个观点你怎么看。以前我也想过，设计领域模型的过程是否可以用TDD的方式，但后来觉得还是比较困难，因为分析领域模型是OOA的过程，TDD比较适用于OOD和OOP。所以后来我就又转向预先详细分析的方式了。

clamp 写道

如果用户数非常多的话，面向正式环境的release是需要比较慎重的。
但是直接发布一个大的release包的风险也是很高的。
还是尽可能切的小一点比较好，另外不是每次发布都一定要培训的，除非有大量的新增功能。

clamp兄做过很多大的项目，你们的产品是怎么发布的呢，是否是每次只发布整个产品的一部分子系统，给客户进行升级？可能我们做的东西子系统划分不是很好，每个版本升级，各个子系统之间的依赖都非常重，没办法只好所有子系统同时升级，包括数据也一起迁移，搞得异常痛苦。
所以我现在想，是否把子系统关系明确拆开，就可以降低产品的发布成本。现在我们也正在做这方面的工作，目前还没有出成果，不过心里不太有底啊。如果客户的需求涉及了多个子系统，那无论如何划分依赖关系也必须全部升级，还是挺麻烦。

24 楼 clamp 2007-05-16  

snomile 写道

项目规模增大后，有些困难非常难以克服，例如我上面举的例子“客户培训”。这时是否TDD或者pair都已经是次要矛盾了，主要矛盾体现在客户不断增加需求、系统规模不断增大与release期限的矛盾上。项目规模增大后，尤其是项目产品化后，release的约束非常严格。例如产品发布需要产品说明书、客户培训文档、产品升级文档（主要是数据迁移与升级，工作量很大）、产品安装配置手册，而且考虑到产品需要同时满足多个客户的需求，以上工作量很可能会根据客户化工作而乘以n（n是需要实施的客户数），每次release都会花费很高的成本。
像我们搞到三个月一个release，就是因为release的成本太高，不能轻易release，而且就算想把release的时间缩短，自己也确实做不到，每个release之间要做的事情实在太多了。release一定要慎之又慎。

对于客户来说，拿到一个release版本，至少需要关键人员熟悉两周，然后对下面人员培训一周，再测试一周，时间就是一个月了。再加上收集反馈意见，与开发方进行沟通，都比较花费时间。频繁的release客户也受不了。

如果用户数非常多的话，面向正式环境的release是需要比较慎重的。
但是直接发布一个大的release包的风险也是很高的。
还是尽可能切的小一点比较好，另外不是每次发布都一定要培训的，除非有大量的新增功能。

23 楼 温柔一刀 2007-05-16  

听你的描述，你的TDD经验应该比我丰富，我才进行了几个月，处于学习摸索阶段。

关于代码质量方面，我觉得不进行TDD，然后不停的对代码进行重构，也会得到高质量的代码，但是这样代价比较大，我觉得不进行TDD，代码测试的覆盖度很难达到令人满意的程度，产品代码都出来了，也不会耐心的去想每种可能的测试情况了。这样以后进行重构的时候也会信心不足吧。

举个能量化数的例子还真不好举呀。
举个小例子吧，在我们这个项目里面有一个角色之间互相通信模块，情况分的比较细，也比较繁琐，采用TDD我们一点一点前进，每次我们只考虑一种情况写测试，别的都不关心，直到所有的测试都通过了，我们就基本确定代码实现没有问题了。如果不TDD肯定也是可以实现的，但是情况多了一起考虑我会头大，混乱。感觉TDD给了你一个方向，向着这个方向走就行了。而且整个开发过程当中感觉还是比较轻松愉悦的。

我们能够成功实施xp的方式来进行开发，确实也得益于项目规模比较小，大项目偶没有这方面的经验，但是采用xp确实也不会有错，这方面的经验ThoughtWorkers应该比较丰富

呵呵，偶都是些浅见，处于学习中

22 楼 snomile 2007-05-16  

关于TDD这个问题，你能举出具体的例子吗，尽量量化你的数据，证明TDD确实有好处。仅仅说代码质量提高说服力很打折扣，比如说如何证明不TDD代码质量就不高呢。
另外我对TDD没有成见，我感觉你好像认为我对TDD有意见似的，呵呵。我自己开发框架代码时都TDD，开发框架不TDD是不可想象的。因为开发框架这种东西时，你对自己要开发成什么样子都没有明确的概念，只有一个如何使用框架的大致想法，所以用TDD可以很好地启发自己的思路，同时使程序即时可测。
但开发业务逻辑不一样，业务逻辑相对来说比较明确，起码开发之前开发者肯定知道自己要实现的业务逻辑是什么，没有人做业务逻辑编码之前还不知道自己要写什么的。就我的经历来说，烦琐的业务逻辑用TDD的方式来处理，不如预先好好分析领域类关系来得实在，好好分析哪些行为应该放在哪些实体上，也就是说用DDD的方式来对付复杂的业务逻辑。
所以我对你说使用TDD开发业务逻辑代码可以带来良好的效果感到比较疑惑。

其他的我觉得咱们基本达成共识了。

最后我认为你们能够成功实施xp的方式来进行开发，主要得益于项目规模比较小，也就是说这种规模的项目无论什么方法论也能成功实施，保证效果，这与敏捷的关系不大。项目规模增大后，有些困难非常难以克服，例如我上面举的例子“客户培训”。这时是否TDD或者pair都已经是次要矛盾了，主要矛盾体现在客户不断增加需求、系统规模不断增大与release期限的矛盾上。项目规模增大后，尤其是项目产品化后，release的约束非常严格。例如产品发布需要产品说明书、客户培训文档、产品升级文档（主要是数据迁移与升级，工作量很大）、产品安装配置手册，而且考虑到产品需要同时满足多个客户的需求，以上工作量很可能会根据客户化工作而乘以n（n是需要实施的客户数），每次release都会花费很高的成本。
像我们搞到三个月一个release，就是因为release的成本太高，不能轻易release，而且就算想把release的时间缩短，自己也确实做不到，每个release之间要做的事情实在太多了。release一定要慎之又慎。

对于客户来说，拿到一个release版本，至少需要关键人员熟悉两周，然后对下面人员培训一周，再测试一周，时间就是一个月了。再加上收集反馈意见，与开发方进行沟通，都比较花费时间。频繁的release客户也受不了。

我们现在可以用的敏捷法宝只剩下沟通了，呵呵。虽然不能随时release，但是可以随时和客户沟通，唯有通过沟通，才能保证产品做出来不是鸡同鸭讲。我前面那个帖子这么强调沟通，也是基于这个原因。
xp中其余的办法，比如用户故事，结对，TDD，持续构建，似乎都是搔皮毛之痒。
项目稍微变大的时候，我觉得整个项目的运作过程必然会转向RUP的方式，即以架构为核心进行迭代的过程，此时有一个稳定的技术架构和一个包含深厚商业底蕴的业务架构才是真正重要的东西。

以上，不知你是怎么看待这些问题的。另外我说话有不少听起来不太好听，实在不好意思。不过我相信你是来讨论问题的，不是来听别人夸你的。言语中有唐突的地方，多多包涵。

21 楼 温柔一刀 2007-05-16  

snomile 写道

咱们还是就这3点讨论，你们做的相当不错呀，在任何一个公司里做创新都是相当困难的。

1.你说的pair的好处，主要是保证每个成员都熟悉程序以及互相学习，但这个对项目未必有好处。我的感觉是这种规模的项目不pair，项目的工期不会受到影响，甚至可以缩短。当然说pair利于团队建设，从长远看来有好处，这个是肯定的，我也有切身体会。是不是你们领导很看重团队建设，所以允许你们进行pair。我们这边说pair就很困难，因为工期实在太紧，又拿不出来很好的证据说pair可以提高开发速度，没法量化评估。
往大了说，我觉得结对编程、同行评审与其说是为了项目质量有保证，不如说是对团队建设有好处，结对和评审都是加强团队内部沟通很好的手段。

我们公司领导比较重视团队建设，提倡敏捷开发，pair是必须进行的，pair短期内是不能提高开发速度的，但是不会降低开发速度，从长期来看，pair能更快的提高开发人员技能，从而自然也会提高开发效率。

引用

TDD，你说TDD保证程序都是可测的，但这个测试有多大的意义呢，对于复杂度不高的程序，如果业务逻辑都是增删改查加点判断，用不用TDD都没区别。所以我还是说不知道你们的程序到底多复杂。我们这边有些东西确实很复杂，用TDD效果就很好，但是复杂的毕竟是极少数。
我不清楚你如何区分“确实应该用TDD”和“为了TDD而TDD”，或者说，如果你们不TDD，项目工期会延长多少，或者会缩短多少呢，你能否量化评估？这也是我说的我们试图进行有效TDD时遇到的困难。当然我不是想证明给领导说TDD是有效的，我只是希望自己做的事是有效的，时间没有浪费。

测试的意义是很大的，测试是重构和功能修改和扩展的基础，没有测试或者是测试不充分，修改起来可以说是噩梦了，如果全部是增删查改的话先写测试跟先写功能再写测试的效果貌似差不多，但是有几个项目是这样的呢？我们这个项目用户角色有5种，以后还要加一种，角色之间的交互是比较强的，业务不难，但是还有很繁琐的，用TDD效果也是很好的，如果不TDD肯定会花更多时间才能比较完美的完成。
我不知道为什么你一直说“为了TDD而TDD”？既然TDD有那么多好处为什么不从心里接受，让它成为自然开发行为，成为习惯？如果不TDD，我不敢说工期会延长，但是工期肯定不会缩短，而且项目和代码质量上面肯定会大打折扣。我觉得仅仅为了“提高代码质量”这一条理由就应该TDD。

引用

充分沟通在任何时候确实都是最重要的，包括团队内沟通和团队与客户的沟通。沟通的形式可能是开会，或者给客户发需求文档，当然这个形式不是很好。也可以用给客户看原型请客户提意见的方式沟通，或者你们一周一个release给客户用也是非常好的沟通。沟通的重要性我觉得远远大于其他几点之和，保证项目成功的大部分因素都是靠它。

这个确实。

引用

2、3.这个我明白了，你们客户确实非常配合。不过这么大量的人员支持你们发布和测试，客户关系做的可够好的。客户那边的培训是怎么做的呢，1万多个导游，1周一个release，培训成本肯定是无法负担的。是否软件功能非常直接地面向业务，不用培训也会使用呢。我的经验里，频繁的release，对客户来说最大的困难就是培训成本无法负担。

培训我们还没有专门做过，只针对最大客户给予指导，很多功能都是比较容易使用的，碰到他不能理解的，我们就向他们说明。每次的功能添加还有一个使用帮助文档。其实我们还提供了一个所有使用人员在线交流的模块，很多问题都是用户相互指导。当然不可能每次release都来一次培训，这样培训成本肯定太高。

引用

我们现在做的产品3个月才有一个release，比较无奈，因为子系统太多了（十几个），又没有办法一次只发布一个子系统给客户使用。尤其是一个迭代周期的中晚期时间内出现了紧急需求，必须在该周期的release中实现的时候，更是雪上加霜。每个release前写培训文档也是个让人头大的活，单单是培训实施人员一周时间就不见了。如果你们将来用敏捷方法开发产品，希望到时候咱俩再讨论一下release这个事情，我现在也是无奈呀，3个月一个release，什么事情都敏捷不起来了。

系统比较大的话，培训肯定需要适当投入的，三个月一个release时间可能有点长，我们公司还有一个项目组是开发产品的，大概8个人，也是完全采用敏捷方法，貌似业务比较复杂，现在在尝试DDD。你们能否把release的周期减到一个月？三个月时间似乎有点漫长。

20 楼 snomile 2007-05-16  

咱们还是就这3点讨论，你们做的相当不错呀，在任何一个公司里做创新都是相当困难的。

1.你说的pair的好处，主要是保证每个成员都熟悉程序以及互相学习，但这个对项目未必有好处。我的感觉是这种规模的项目不pair，项目的工期不会受到影响，甚至可以缩短。当然说pair利于团队建设，从长远看来有好处，这个是肯定的，我也有切身体会。是不是你们领导很看重团队建设，所以允许你们进行pair。我们这边说pair就很困难，因为工期实在太紧，又拿不出来很好的证据说pair可以提高开发速度，没法量化评估。
往大了说，我觉得结对编程、同行评审与其说是为了项目质量有保证，不如说是对团队建设有好处，结对和评审都是加强团队内部沟通很好的手段。

TDD，你说TDD保证程序都是可测的，但这个测试有多大的意义呢，对于复杂度不高的程序，如果业务逻辑都是增删改查加点判断，用不用TDD都没区别。所以我还是说不知道你们的程序到底多复杂。我们这边有些东西确实很复杂，用TDD效果就很好，但是复杂的毕竟是极少数。
我不清楚你如何区分“确实应该用TDD”和“为了TDD而TDD”，或者说，如果你们不TDD，项目工期会延长多少，或者会缩短多少呢，你能否量化评估？这也是我说的我们试图进行有效TDD时遇到的困难。当然我不是想证明给领导说TDD是有效的，我只是希望自己做的事是有效的，时间没有浪费。

充分沟通在任何时候确实都是最重要的，包括团队内沟通和团队与客户的沟通。沟通的形式可能是开会，或者给客户发需求文档，当然这个形式不是很好。也可以用给客户看原型请客户提意见的方式沟通，或者你们一周一个release给客户用也是非常好的沟通。沟通的重要性我觉得远远大于其他几点之和，保证项目成功的大部分因素都是靠它。

2、3.这个我明白了，你们客户确实非常配合。不过这么大量的人员支持你们发布和测试，客户关系做的可够好的。客户那边的培训是怎么做的呢，1万多个导游，1周一个release，培训成本肯定是无法负担的。是否软件功能非常直接地面向业务，不用培训也会使用呢。我的经验里，频繁的release，对客户来说最大的困难就是培训成本无法负担。

我们现在做的产品3个月才有一个release，比较无奈，因为子系统太多了（十几个），又没有办法一次只发布一个子系统给客户使用。尤其是一个迭代周期的中晚期时间内出现了紧急需求，必须在该周期的release中实现的时候，更是雪上加霜。每个release前写培训文档也是个让人头大的活，单单是培训实施人员一周时间就不见了。如果你们将来用敏捷方法开发产品，希望到时候咱俩再讨论一下release这个事情，我现在也是无奈呀，3个月一个release，什么事情都敏捷不起来了。

19 楼 温柔一刀 2007-05-15  

snomile 写道

不知道这个项目复杂度如何，也不清楚你们的人员水平，所以我想问楼主个问题，看看能不能讨论讨论。

1.楼主能否大致量化一下一到五这五点的重要程度吗，比如TDD带来多大好处，结对带来多大好处？如果砍掉TDD，砍掉结对编程，对项目会有什么影响呢。进一步说，如果只保留一个“充分沟通”，尤其是和客户的沟通是否就足够了呢。
我的经验里，做到有效的TDD和有效的结对是非常困难的，尤其在比较简单的项目里，太多TDD都是在走流程，闭着眼睛都能写，真正值得写的测试用例并不多。也有太多结对最后都在项目进度压力增大的时候流于形式。所以希望楼主也能举出例子，说明敏捷真的给你们带来了好处。

2.客户对1周一个release的看法如何？有不少客户时间都很宝贵，会不会一周一个release，客户会觉得开发人员太随意，没有仔细考虑。

3.“客户比较满意”这个感觉是怎么得来的？因为有太多客户在签终验报告之前都是“比较满意”了

以上

这个项目复杂度一般，技术本身没有什么复杂度，工程师水平还是不错滴。其实这个项目上个星期已经差不多结束了，预计的是12人月左右，其实大概只花费了8人月，由此可见效率还是比较高的（至少效率没有下降）。客户打算再继续投资扩展业务。

1.这五点其实在敏捷开发的流程中都算重要的，沟通应该是排在首位的，pair使沟通变的容易和快速（如果开发人员有七八个的话，pair在沟通方面就更重要了，可以每半天换个pair，保证项目的每个模块每个团队成员都是熟悉的，而不是某个模块只有某个开发人员熟悉），当然pair的好处还远不止在沟通方面，在提高开发人员的专业技能方面也是大有好处的，七八个人的团队每天互换着pair对于开发人员的成长也是非常快的，另外重要的有点是pair工作很开心，不会觉得累，基本不会走神，效率比较高。我不知道你说的“充分沟通”是怎么进行的？每天和客户沟通？开会讨论？另外想问一下你们在有效的TDD和有效的结对碰到的困难是什么？TDD带来的好处是显而易见的，保证程序都是可测的，bug极少，代码比较优美。其实很多业务逻辑不测到位是很危险的，只靠人手工测也是不容易测出来的。

2.客户对1周一个release还是非常配合的，其实我们这个系统开发到第二个月的时候客户已经投入试运行了，客户基本每天都登录测试，而且还有大量的使用人员（一万多个导游，几百家旅行社）都同时在测试使用，反馈也是非常快的，我们很早就在系统里面加入了反馈的功能，使用人员可以随时提出修改意见和bug报告。

3.客户比较满意是客户自己的感受，客户在使用过程中也提出了一些超出项目以外的要求，我们都尽量满足了，客户要继续加大投入也可以看出客户是满意的。

18 楼 snomile 2007-05-15  

不知道这个项目复杂度如何，也不清楚你们的人员水平，所以我想问楼主个问题，看看能不能讨论讨论。

1.楼主能否大致量化一下一到五这五点的重要程度吗，比如TDD带来多大好处，结对带来多大好处？如果砍掉TDD，砍掉结对编程，对项目会有什么影响呢。进一步说，如果只保留一个“充分沟通”，尤其是和客户的沟通是否就足够了呢。
我的经验里，做到有效的TDD和有效的结对是非常困难的，尤其在比较简单的项目里，太多TDD都是在走流程，闭着眼睛都能写，真正值得写的测试用例并不多。也有太多结对最后都在项目进度压力增大的时候流于形式。所以希望楼主也能举出例子，说明敏捷真的给你们带来了好处。

2.客户对1周一个release的看法如何？有不少客户时间都很宝贵，会不会一周一个release，客户会觉得开发人员太随意，没有仔细考虑。

3.“客户比较满意”这个感觉是怎么得来的？因为有太多客户在签终验报告之前都是“比较满意”了

以上

17 楼 2knows 2007-04-11  

2K

16 楼 firstline78 2007-04-11  

不错，真有项目这么干了，支持

15 楼 myali88 2007-04-10  

有多少项目用这样的开发方式

14 楼 温柔一刀 2007-04-08  

lordhong 写道

lz在team里面是哪个?

我属于pair programing中的一个

13 楼 lordhong 2007-04-08  

lz在team里面是哪个?

12 楼 温柔一刀 2007-04-06  

adamzhao 写道

呵呵，终于走出了第一步，恭喜LZ！

有时间的话，可以说一下你们实施敏捷的原因，如何让大家乐意接受的，已经在真正的实施中碰到的困难和解决方式。

呵呵，是的，一旦走出了第一步就很难回头了

实施敏捷是公司发展的需要，客户也比较青睐

公司以前也一直都提倡敏捷，但苦于找不到路

我们公司领导对实施敏捷也是大力支持的

给于了尽可能的硬件配置和环境布置

现在公司的开发方式处于转型期

我们小组是第一个采用敏捷的，接着第二个项目组也开始了

再接下来的项目的开发方式都会转到敏捷上来

关于如何让大家乐意接受，我想只要尝试过的人都再也不会拒绝了

TDD会给人一成就和满足感

pair编程会令人愉悦，虽然有点累，但是心里感觉比较快乐

11 楼 小天蝎 2007-04-06  

pair方面没那么详细，讲了很多书中提到的东西

另外支持adamzhao:

adamzhao 写道

呵呵，终于走出了第一步，恭喜LZ！

有时间的话，可以说一下你们实施敏捷的原因，如何让大家乐意接受的，已经在真正的实施中碰到的困难和解决方式。

10 楼 温柔一刀 2007-04-06  

asticx 写道

LZ似乎对测试的覆盖度比较看重，但我个人觉得尽早进行集成测试更为重要一些，当然单元测试的覆盖度应该还是需要达到一个标准的。

另外这个项目的Pair Programming是怎么实施的，感觉成本太高了...

你是指人力成本吗？不会高的，你能连续8小时不停工作吗？一直都是高效工作？


当然成本不会高还不是它的主要优势，prai还有助于简单设计，风险控制等

9 楼 j2j 2007-04-06  

有个类似的过程，好熟悉的红绿灯，

8 楼 asticx 2007-04-06  

LZ似乎对测试的覆盖度比较看重，但我个人觉得尽早进行集成测试更为重要一些，当然单元测试的覆盖度应该还是需要达到一个标准的。

另外这个项目的Pair Programming是怎么实施的，感觉成本太高了...