我没有什么敏捷、什么XP编程的概念，所以我这次的格斗没有套路。
从去年开始我担任了项目经理一职，已经负责公司的三个项目的开发和实施了。
我可以籍以此发表我的看法。
本主题内容是极限开发
首先说说我概念当中的极限开发。
项目特点：面向应用、面向服务的中小企业应用。
先哆嗦一下业务需求：
我们在实际调研企业现状后，最大限度的了解与我们应用范围相关的实际业务。随后进入业务需求分析，其实就是抽象实际业务到软件功能设计。同时考虑到我们应用
范围外的业务，用户可以不太关心这一块，但是我们必须得做。最终的业务需求分析由公司内部评审，（尽管我们的管理不完善，但是我有权力让什么也不懂的领
导参与），再与客户去交涉。直到取得最终评审。
极限开发之前：
我们首先要做概要设计，其实是对前业务需求分析的细化，当然这文档是面向业务的，这个文档是修改最多的，所以在你开始写这个文档以前一定要做好版本管理（包括有效版本的管理）。
概要设计长话短说吧，就是对企业实际业务管理的理想模型，是尽可能的去理想（理智的想象，而不是单纯的想象），同时不能够把软件的功能划分在合同的需求功能之外（这个一定要把握一个度的问题）。
概要设计是一个相对漫长的过程，这个过程马虎不得，一定要有耐心说服用户和有权力的领导，说什么能做，什么不能做，我们为什么这么做，以及变通的业务实现等等。
极限开发之数据库设计篇
大家可能不理解，为什么我首先要对数据库进行设计呀，这个完全和我的习惯有关。（我的地盘我做主）
在对以上概要设计完以后，我的心理就对实际的软件功能有具体的描述了，当然这个是我最清楚了，我在写概要设计的时候会把这些映射成软件的具体实现，并且使
用一些工具比如VISIO在写完概要设计的实际业务时，我会把软件的实现图、逻辑图同时画出来，害怕以后没有时间来想这些，呵呵。
所以在其后的工作当中，我对软件的具体实现就胸有成竹了，所以我直接进行数据库设计。
数据库设计我使用DB Design，这个工具很好用，我在数据库设计时有两个准原则：
原则一：数据库表对应程序功能模块，一个模块一个前缀，并且如果无太多关系的业务模块对应一张表，并且这些表没有关联关系，都是独立的。
原则二：所有的表如果无复杂关系都使用统一的UUID做为主键，同样，如果处理同样的事务，字段名能够统一的话就统一命名，或者有统一规则生成等。
根据以上原则，我的数据库表没有想象当中的复杂，所以在程序实现时就不用考虑数据库间的关系。
极限开发之程序实现－统一增加、删除、修改数据库
数据库设计完以后，就建立映射成实体，并根据现行的软件架构实现统一的对数据库的增加、删除、和修改的操作，比如现在的STRUTS+SRPING+
HIBERNATE的架构，我根据数据库表，生成对本数据库表的增加、删除和修改的类接口，剩下的工作由下面的员工完成，（很想自动生成，但没有时间来写
这些东西。以后这个东东肯定会有人发明）
极限开发之程序实现－封装业务逻辑层
我一般使用VISIO或者现在的WEB FLOW给手下的员工画出程序实现方式，让他们来完成，我的工作是检查他们的代码是不是符合规范，是不是能够符合
业务需求，所以这个时间我的主要工作是质检和修改程序实现的业务逻辑，（有些刚刚毕业的大学生，你要给他讲明实现的业务关系呀，还不如告诉他你应该往哪个
表插入什么数据来得快，这是一个怪圈）
极限开发之程序实现－关键业务实现
关键业务的实现是至关重要的，这个我一个可能是不行，而且可能当时用户的需求在改变或者改进等，所以我就要找一个比较实在、能力比较强的员工来担任这个职务，要尽可能的给他讲明实际的业务和用户需要的效果和目的，说不定他还能帮助你的思维呢。
这个是个重要的环节，所以生产的重点就是这里，在最复杂的业务逻辑时，对程序的处理，一定要画个VISIO或者什么图告诉员工每一步的实现如何做，包括很
多的错误处理等。如果你在这里偷懒了，说明你这个项目的有很多的隐患在其中，这个工作比较艰巨，变数也多，需要多多鼓励员工。
极限开发之程序实现－单元测试
单元测试不是很严格，由公司相关人员测试，不过经过我质检过的代码，一般没有太多问题。
极限开发之程序实现－业务测试
根据项目的实际业务来测试，由我和能力很强和人来测试，最后由测试人员来测试，
极限开发之用户试运行及上线
这个就不用说了，要用服务的意识来帮助客户来认知这个东东，就好象到理发店让小妹妹给你按摩一样，不要害羞。也好象很累了到冼足浴室一样，无微不至引导消费。
我的这三个项目分别是库存管理+财务管理、EAI项目和CRM+服务。
用人最多的时候不超过6人，开发周期没有超过2个月的。
库存管理+财务管理 6人 1.5个月
EAI项目 3人 20个工作日
CRM+服务 5－6人 不到两个月
所有项目均是新写。