讨论下敏捷方法中的项目驱动力

项目的推进必须有一种推动方式，这种推动方式是通过超短期目标来实现的，有效的项目管理，这种短期目标甚至可以规定到小时的级别，这个小时干什么，下个小时做什么都可以制定到项目计划里面。实际工作中，如果能把任务精确到天，那么这个项目的推进就已经是非常之高效的了。

而在敏捷方法论中，不同的具体方法强调不同的项目驱动方式，比如用例驱动开发，测试驱动开发，需求驱动开发等等。在宣传自己具体的项目管理方法时候，各种具体方法都在强调自己的驱动力是万能的，可以作为核心驱动力来把握。以TDD测试驱动为例，很多信仰测试驱动的项目经理，恨不得把所有东西都抽象为单元测试，但是用户需求和单元测试之间存在大量的系统设计工作，在把复杂的用户需求抽象提取设计为的可以进行单元测试的测试用例的过程中会遇到大量的难以逾越的困难，从而导致测试驱动变成了纸上谈兵。

在敏捷过程最为推荐的测试驱动，在我们单位的开发工作中也会碰到特别情况，因为我们在单位的开发工作，都是在日常运维工作的间隙中进行的，虽然都是为了单位工作，但是具体的开发流程更类似于“义务劳动”，是出于责任感和为业务部门排忧解难的职责才进行的开发工作，属于没有强有力制度下的“人情”项目管理，而这种没有强有力制度下的“人情”的测试驱动，很难做到大公司那样规范和苛刻，所以实际开发中我们搞的是非正式的记录的测试用例。一个文本文件，专门用来测试的素材，脑中形成的测试方案。讨论时，随手用简单的A4纸记录，订书机订好备用。

在软件开发实践中，我们通过对项目的迭代划分，在不同的迭代过程试用不同的驱动方法：

在项目启动阶段，设计驱动，大致划分模块，分别编写支撑模块的主干核心代码；

在执行阶段，采用接口驱动方法，精确设计模块之间的接口，驱散设计模型中的云雾，让系统的设计形式化，程序化，确定化；

在实现阶段，需要具体业务需求，才能进一步精华系统，破除接口的设计杂质，于是我们用需求用例驱动开发。

下一个阶段，为了追求的质量，测试驱动开发。

不同阶段，都有不同的驱动力。不能生搬硬套，没有一种驱动力是贯穿整个项目的生命周期的。

还有最后的一个阶段的驱动，则用户驱动。根据用户的需求，做一些表面上的修改。

这个特色阶段，当然对系统架构也提出了非常高的要求，首先就是将系统业务和显示进行尽可能的分离，在设计时采用大量Facade和Mediator设计模式，进行略显与多余的隔离。