这个月刚进入公司，加入了一个10人左右的团队，用Java做一个网站后台。
客户是日本公司，他们做了项目的大部分分析(Requirements, Use cases, Domain model...)。我们负责的是详细设计和开发。我是项目开始几星期后才进的公司。Schedule也已经为我分配好了。大家都按照schedule上的安排工作着。
上星期开会的时候得知，日本这次采用的是agile过程。而我们的schedule更类似于RUP这样的过程。RUP这个学院派和Agile这个造反派狭路相逢，问题也就出现了。
大家工作都很卖力，为了能按进度提交制品，有时还通宵达旦解决问题。我们这支团队的战斗力和信心是不容怀疑的。可是大家努力的结果换来的却是用户的抱怨。大家都困惑不解。问题究竟出在哪儿？
日方在项目中强调的是Agile过程，我们采用的则是传统的过程。一开始，两个过程方法之间的差异并不大；对我们提交的制品，客户也没有什么异议。但是，直到客户提出问题之前，我们所提交的制品都是一些设计文档。而我们的制品也仅限于此——没有一个可用的EAR包、没有写过 test case。很明显，我们犯了agile的大忌。
Agile所强调的是快速的构建、轻量级的迭代、TDD等。由于之前没有写test case，详细设计也没有test case可以参照。设计本身是不是合理，是不是testable也不得而知。致使在设计test case的时候无从下手，很多类甚至都没有办法测试。整个架构的可行性很难估算。
往后考虑。一次大规模的重构可能是少不了的。虽然agile过程本身提倡以TDD为基础的重构。但是现在的重构可能造成的代价已经不是一次轻量级的增量迭代了。
说到这里，总结几点，希望能在以后的工作中引起注意：
1. Agile很难管理，项目早期应该对各种风险有尽可能全面的评估，schedule的设置中应该定义好 test case 和 build 的时间点。
2. 设计不必太详细，用频繁的测试和重构完善设计。
3. Test case 优先设计，这样在架构中就会对testability有足够多的考虑。
4. 团队内部对共同的难题应该及早进行讨论和解决，问题的解决方案应该传递到每个组员，尽可能保证团队的能力同步。