关于敏捷软件开发新的理解

前两天，在一次聊天中，我问了问未来开发组的组长：眼看设计过程就要结束了，项目启动到现在进行了3个月的时间，想一想，前一阶段我们所做的工作中，有百 分之多少是对后面的工作有意义的？开发组长无奈的苦笑了一下。显然大家心里面都有数，这个比例很不理想。尤其是设计文档中的模块设计部分，大量的工作量， 完全是为了设计文档能够评审通过。

对于敏捷软件开发，目前理解期最重要的目的是识别软件过程中没有必要的任务或者是性能低下的任务，然后去除之或者改进之。基于这个出发点回顾一下目前的情况：

1. 需求分析。唯一不变的就是变化。项目的早期集中时间进行需求分析然后确认基线，再等到真正动手开发某一模块的时候可能已经过去了一段时间，并且需求已经发生了变化。这样还需要对新的需求进行再次分析。在这样的情况下，前后的需求分析则存在工作量的浪费。
   1. 敏捷过程则是需求分析存在与整个项目的始终。细节的需求分析工作尽在真正开始代码之前才进行。虽然以后仍然有可能发生变化，但起码针对上面的情况做了优化。
2. 软件设计。目前的项目，设计阶段需要的交付物有：架构设计，概要设计，详细设计，物理模型设计，接口设计等等。设计的目的当然是为了能够知道开发。这一部分工作显然是必须的，但是能否优化呢？敏捷过程典型的对策是1.仅仅做足够的设计；2.测试驱动开发。
   1. 系统的架构设计是需要的。但是针对某一功能来讲，仅仅在开发之前才做相应的详细设计。设计仅仅做到能够指导开发的程度，对文档的格式要求比较宽松。
   2. 传 统的UML设计包括类图、顺序图、协作图、活动图、状态图等等。这个敏捷过程一般没有强制要求。XP过程中推荐以TDD和CRC分析来代替。其中CRC分 析基本上是UML协作图的替代物，但是更加强调团队共同完成。而TDD则是在保证了测试自动化的同时还能够对软件设计进行指导，做一件事达到两个效果，体 现其高效率。
3. 界面原型。我前面说过，希望能够在需求分析阶段就能够对系统的界面进行确认，还找了一些专业做页面原 型的辅助工具。现在看来，其实也存在浪费。其实更高效的做法是以最快的速度拿出开发出的成品或者半成品让用户进行确认（这样一来，唯一的问题是你能有多 快？;-) ）。界面草图有的时候是需要的，但是它变成了非常不正式的中间产物，不必要进行存档。
4. 重构。仔细想想，其实重构的工作对于任何一个项目来讲都是必须的。而现实是，如果没有采取全面的自动化测试的话，传统的软件开发项目没有能力也不敢进行深度的重构。而相反基于TDD的XP团队则更有勇气对软件进行彻底重构。
5. 集成。集成的工作量无法节省。敏捷过程的做法是持续集成——将工作量分散到整个软件生命周期。这样能够及时发现问题，并从感受上减少工作量。

我有一个朋友，看他上网打桥牌的时候，经常发现他的搭档在抱怨他发生了失误。而实际的情况是怎么样的呢？我的朋友是全国顶级桥牌赛事的前四名获得者。那些被抱怨失误的牌都是由于他的搭档的水平不够，对于他的精妙招数无法理解。
在软件开发领域，其实我们也正在处于我的朋友的搭档的水平。经历的项目越多，越会发现业内大师的很多理论的精妙之处。很多情况是：如果大师们的理论你认为有很大问题的话，其实是因为你的层次还不够。

现实很残酷

现在手头是这样的一个项目：

1. 为期7个月
2. 工作量分析的结果，项目团队需要60个人或者更多
3. 项目组中只有包括我在内的3个人有相关行业经验
4. 开发团队中有大约20多个人是刚刚招聘到位的
5. 对于所使用的技术，除了JAVA开发之外，JAVA开发框架、BPM/BRM引擎、B2B网管、字符终端开发等等都是项目组第一次使用
6. 项目组中几乎没有人有面向对象的设计和开发经验
7. 客户方面政治斗争严重

这是我所经历过的第二个死亡之旅项目。