首次敏捷项目开发实践

关于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的方式，即以架构为核心进行迭代的过程，此时有一个稳定的技术架构和一个包含深厚商业底蕴的业务架构才是真正重要的东西。

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

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

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

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

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

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

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

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

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




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

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

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

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