开发前线的敏捷战例

这里纪录，展现和回顾了一个刚刚完成的某省移动通讯公司的全省项目管理系统。项目开发采用了极限编程开发流程，大量实践了极限开发中的测试驱动开发单元测试代码集体所有制、团队设计，持续集成等开发流程练习，也全面采用了成熟的Struts MVC架构,JDO2 O／R Maping框架，依赖注入设计模式等先进实用的设计，有效的缩短了开发周期和成本。

使用任务列表进行项目管理并提高进度透明度

今天竞争激烈的市场环境要求先将产品概念卖出去．然后再逐渐开发。我现在参与的4个项目都是客户根据最新版本完成哪些功能来决定下一阶段应该实现哪些功能。对于对北美地区的软件外包．这已经成为我们与印度大公司竞争的一个强有力的工具。这意味着项目管理者需要经常性的对工作任务进行较大规模的调整．

为小型团队明确设立质量跟踪和产品集成角色

对于一个5—10人的小型开发团队——正如我所在的团队，也许每个人都曾经或者正在承担着繁重的开发任务，但这不足以成为可以忽略质量跟踪与产品集成的充分理由。在软件过程中，质量跟踪与产品集成的角色是不可以被轻视的。前者负责全程监督并持续跟踪软件产品的质量状况，确保软件质量不出现问题：而后者则负责将软件各组分集成并统一于一个全局视图。

源代码管理工具的培训不可或缺

每个参加过高考的人．大约都知道“工欲善其势必先利其器”这句名言，这是某年的高考题。古人已经把真理告诉了我们能不能接受和实践之．那就看每个人的造化了。对于程序员来说开发工具肯定是最重要的。但对团队项目来说源代码的管理工具或许是更加重要的。比较常见和常用的是微软的Sources Safe和开源的CVS。

简单有效的bug和需求管理

我们从刚刚开始做软件不久，就把自己的缺陷管理和需求管理系统建立起来了。虽然那时候做得非常简陋，但我们一直持续下来，不断地完善这个系统，所以现在都还能查看到我们很久以前的bug纪录。当然这个系统并不需要很复杂，我们一直是采用数据库来管理。当时很简单地利用数据库，简洁有效地把bug管理起来，并围绕着这个bug的管理系统，我们还制定了一整套的协作机制。

通过迭代阶段回顾会议加速团队自学习

软件行业素来以节奏快而闻名。很多开发人员在工作三年后对软件开发产生了倦怠心理。在观察了一段时间后我发现真正的诱困在于。由于重复劳动，无法从以往的工作中学习到新知识，对于工作中需要用到的新知识也只是照猫画虎，无法真正理解。

技术争论的量化分析与最终裁决归属

有关技术的争论贯穿于任何软件开发过程中，但是对于这些争论处理适当的并不是很多。不少项目最后变成技术经理或者项目经理对任何问题都做最后决定的槽糕局面。之所以说糟糕是因为无论经验多么丰富，一个人都无法对软件开发的诸多细节都有非常深入的理解，因此产生的脱离细节的决定很有可能不是最优的，在某些情况下甚至是完全不可行的，

优秀框架助力高效团队的建设

在公司，我们的团队一向是对开发者最具吸引力的一支。这让我自豪，但也很为难。他们要求加入我们的原因很多，技术本身是这些原因其中之一。每个希望加入我们团队的同事，常常提到一个理由：你们采用的开发技术更加先进，加入你们可以接触到更多的新东西。

施行周计划/总结会议制度,有助于软件过程改善,并强化沟通

在我刚刚加入团队的前三个月里周计划/总结会议还没有开始推行。有一段时间，我能够明显感觉到，包括我在内的所有成员间彼此都十分封闭，大家多半都不清楚其他人正在做些什么，而我对自己所要承担的工作任务也十分模糊。

高效沟通——高效团队的助推剂

看一支团队是否高效的时候，首先可以看它是否能够高效沟通。所谓高效的效，其实有两层含义——首先是效果，然后才是效率。没有效率的好效果也胜过没有效果的高效率(其实是零效率)。因此，我们在建设高效团队的过程中，首先是重视培养可以产生好效果的团队文化，然后才把精力放到提高效率上面。因此，高效沟通，首先是能够产生好效果的沟通，然后才是高效率的沟通。