还需要面向实体编程吗

        分到了一个项目，开发流程是什么，首先要做什么？

        之前很多人也问过我这个问题，我总是根据经验不加思索的说出几个大概步骤：做需求，画原型，设计数据库，定架构分层，编码测试，部署发布。

        有这种思路很正常，因为我们一直在严格遵循软件工程的思想，文档很重要，文档驱动。想当年学习写文档的时候，把十几个文档都尝试了一遍，整个写下来足足用了半个月，印象之深可想而知。进而形成了我们之后的开发流程：组长写文档，组长画UML图，组长画原型。组长做完这些工作，没有一周基本是不可能的。但是往往出现这种情况：UML图刚画完，原型也快出来了，突然有点需求有问题，或者需求有变更，那么就得改！！补图，文档，没开发呢，修订版文档1.1已经出来了。组长成了实实在在的文档农，组员成了码农。组长压力山大，组员学不到东西。

        当然这样开发也自然有其好处：组长如果很厉害，设计一个结构性能都不错的数据库，需求细节做的也很好，做出来的东西就是想得那样，也有详细的文档可查，很好维护。但是也就过于依赖组长了，或许有人说可以把文档分下去写，但这道理是一样的，也就是这是一个开发流程的问题，先出文档再做开发，就是面向实体编程，先需求确定，做好实体，从下往上开发。

        现在参与了gxpt项目，工期很紧，我们组做的这个块是对之前的一个系统的重构。虽然算是有原型了吧，文档就没有写那么多，但是之前的系统还是有好多问题，我在分发任务的时候还是按照之前的思路，作为组长要先把需求弄好，其他组员先搭建开发环境。我做需求用了两天，做完之后我们就开始设计实体，用了一天。之后才开始全组写实体，用了一天的时间。实体层出来了，这样前期的工作算是完成了，之后就是做上层的开发。我们在做项目之初就说本次要采用敏捷开发，但是我们这是敏捷开发吗？

        当时不是。为什么需要敏捷？我们之前的开发模式只是适用于小作坊或者有积累的重构，如果一个大的项目，需求都还不确定，如何写文档，即使需求确定了，写文档的时间是否消耗的起。当然，敏捷不止是开发文档多少的问题，关键是开发流程思路的转变！敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。充分发掘组员的能力，需求模块分配下去，有专人负责，这样的开发就是面向需求，有关这个需求实现的界面、service以及实体都需要该人来设计和维护。这样开发速度很快，还有一个好处就是快速迭代，对于一些理解偏差的需求能及时发现和修订。

        敏捷，还需要在实践中慢慢理解，希望本次项目完成后有所提高。