敏捷开发，软件开发的正途

  一直对敏捷开发很感兴趣，但是一直以来，所涉及的项目中都没有这种方式的用武之地。前面，刚刚做完了一个不大不小的项目，也正好借这个契机，好好总结一下项目的需求，设计，实现，各个环节中的经验教训和如何利用敏捷的观点。

 

  2008年12月8日，我从天津坐上了北上的列车，终点不远，北京。为了做一个项目，也有金融危机的因素，天津的项目暂时没有接到。到了目的地，经过短暂的适应，我开始了对于这个项目的熟悉和接手的过程。

 

  这是一个物料管理的项目，说起来很简单，就是，货物入库，项目转移，货物发货，这三个过程。在各个流转过程中，不断地改变货物的状态，以及所属的项目。还有就是，各个过程都伴随着审批流程，这部分是通过工作流控制实现的。

 

  开始的时候，审批部分我没有花费太多的精力去构想，因为这一部分无非就是审批流程的控制，在工作流中进行控制就可以实现。虽然这部分我之前没有接触过，但是也应该没有什么问题。货物流转的过程，从一开始就很麻烦，我这里指的是业务。

 

  先从货物入库说起，根据客户反映，货物入库时，能够提供的入库产品的信息是一张pdf格式的箱单。但是，有现成的工具把它转化成excel格式的文档。我们负责把excel格式的数据文档，转化为数据库中的数据，这样产品就正式纳入了我们这个系统的管理。这一块的开发，是遵循原型开发的模式，即我们先开发出一个最小化的模型，供用户使用，在客户体验的过程中，提出更细化的需求。由于项目交付的时间是必须保证的，客户提出的需求又源源不断的汇总到我们这里，当时的压力是可想而知的，如何保证客户提出的需求的收敛是急需解决的一个问题。经过和客户及时的沟通，在确保准时上线的要求下，客户同意优先实现其中的一部分功能，其余功能，可以上线后实现。

  

  项目转移是这个系统中，业务最复杂的一个功能。因为，产品入库的时候是属于一个项目的，然后，可能现在另一个项目很急需相同的产品，于是就把这部分产品转移到了另一个项目下。由于，客户最开始，也没有提出转移的最小进行单位是什么。所以我们的页面实现不可避免的和后台逻辑都是按照，我们设想的方式，实现的。但是，随着时间的推移，以及客户的不断试用，提出，项目转移以及所有货物的流转的最小单位是货物的批次，不会出现打破批次的情况。这给我们带来了很大的被动，所有之前的页面和逻辑，都要重新实现，这个时侯距离产品的正式上线还有不到一个月的时候。其实，后来想想，这一情况的出现，一大部分由于我们自己做需求分析的时候没有做细致，没有很好的引导客户，没有把我们的实现的想法和客户的想法进行及时的沟通。

 

  切记，我们实现的每一个功能都是以客户的确认为前提的。这一点是大家所公认的，毋庸置疑。但是，客户的确认的东西，有很大的盲目性和随意性不确定性，如何把这个风险降到最低，是很值得重视的一个问题。一个是，在做需求的时候，推进要及时，有深度，有宽度。尽可能早的划定问题域的范围边界。二是，尽可能早的，拿出逼真的模型。

 

  在分层实现系统的时候，也遇到一个常常出现的问题，由于系统的数据访问层实现，是通过sql拼接的方式，这就导致访问途径的杂乱，一个业务需求的变化就会导致比较大的修改量，另外，数据访问的高内聚，也遇到一个问题，底层的修改会影响很多的上层业务。其实，最好的方式应该是做到，业务和数据的严格分离，这样既不会出现，业务和数据访问杂合，导致访问途径杂乱，也解决了数据访问高内聚对业务逻辑的影响。