回顾一个人的小项目

尽管这只是一个小项目，耗时也很短，但个人觉得这个项目的整个过程还是值得回顾的，项目虽小，五脏俱全，项目经历了两个小的迭代，迭代过程中经历了典型的需求调研、设计、开发&重构、集成测试过程，采用了现场客户、TDD等实践，这里就以第一迭代来对这个项目的过程做些总结。
初期调研
初期调研阶段确定了项目的范围和边界，同时对于其中一部分最为紧急的功能调研清楚了。
第一迭代
根据初期的调研，确定了第一迭代的功能目标，用rose简单的划分了use case，简单的用MindManger做了个第一迭代的工作计划，由于此项目是基于原有系统的一个扩充，所以未经架构设计过程。
在划分了use case和工作计划后，开工干活，对于每天的工作同样用MindManager做了计划，开始干活时首先仍然是对use case做业务建模的工作，首先完成业务对象模型和业务实体模型的建立，在完成了此步工作后，直接将业务对象模型和业务实体模型转化为了实际的代码，而没有进一步去做从业务模型到技术方面模型的工作，一方面是因为项目简单，另一方面是因为采用Hibernate自然减少了这块的工作。
在建模完成后，开始对use case做业务过程分析，在业务角度是不存在什么从界面提交给action，action到service什么的，而只是完成此项业务功能的一个过程，在做完业务过程分析后结合架构设计转化为了对应的序列图，通过序列图完成了对象图，到此use case的设计工作宣告完成，一个人的项目不存在交流问题，自然没形成什么文档，设计时切忌过度设计，在架构的约束下先使用最为简单的方法进行实现，到了需要在此基础上扩展和添加新功能时逐步的重构，这个时候设计自然会不断的提升。
设计完成后，开始写代码了，根据设计开始写测试代码，建立接口，测试写完后开始写接口的实现，通过测试则继续按照序列图逐步完成所有类的实现，在这些过程完成后即可部署到系统中做集成测试了，在这个项目中，基本上没碰到集成测试中出现什么错误的现象，这得益于设计过程和TDD过程的较好的执行，如果不是这样的话，在这个项目的开发过程中肯定会痛苦S，之前的系统启动至少都需要3分钟，如果依靠部署、测试、调试、重启这样的过程的话，时间就会全部被消耗掉了。
尽管项目的架构有所限定，但在这个扩充上仍然突出了service大粒度的特征，service作为use case级别功能的入口点，use case中的所有功能都能在service上找到对应，而service则会结合多个业务对象和dao来完成其他的工作。
现场客户在这个迭代中尽管没达到XP过程中期待的效果，但还是不错的，现场客户对于需求的把握以及其他一些方面的支持保证了迭代一的顺利完工。
迭代一按计划提前一天完工，到客户方进行版本的演示，收集反馈，同时对第二迭代的功能进行了调研。
第二迭代同样按照第一迭代的过程进行，同样第二迭代也是顺利的完工，进度比计划稍有提前。

在这个小项目中，迭代版本的及时发布垫定了客户方的信心，同时，结合迭代版本的调研更加准确的挖掘了客户的需求，使得这个小项目得以很好的完成。
在这个小项目中，真正的着手提升交互，这对于客户以及自己而已都起到了很好的作用。
简单总结下：
1、迭代版本的频繁发布能很好的建立客户方对于系统的信心；
2、结合真实系统的调研能够更加准确的挖掘(引导)客户的需求；
3、简单而完整的设计过程和TDD能保证开发较好的完成；
4、把握设计的尺度，依靠重构来不断的提升设计。
5、提升系统的交互对于客户是直接而明显的帮助。
当然，对于不同的项目在项目过程上是要有所不同的把握的，不能对于所有的项目都采用同样的方法，就像不能对所有的客户都采取一样的方法建立关系一样。