我们部门是一个基础平台研发部门，主要为其他各部门提供技术接口和服务支持。

    也正是由于这个特性，部门内正在考虑基于wcf搭建一套服务平台。

    部门内提倡敏捷开发，谈谈我自己对敏捷的简单理解。

    对需求做足功课

    个人认为敏捷的前提是要对需求做充足的功课。

    一、明确需求

    比如我们每天都要为别的部门提供很多接口，在开发过程中逐渐发现我们其实做了很多重复性的工作。

    同时大量的技术接口（webservices调用、post调用）非常分散，难以管理。针对这种情况，我们迫切的需要一套统一的服务平台。

    我们的目的就是能够提供各种部门之间甚至是公司对外合作的技术接口支持。具体这个平台叫什么，都包括什么，可能还不是很明确。

    二、合理的拆分需求

    我们的目的很明确，所以我们决定对目前的需求进行分析。通过和各部门同事交流我们对目前存在的需求做了分析。一是从业务上拆分，我们可以

    得到很多子系统。二是从技术上考虑，我们理出一些通用的基础的功能以及支持业务扩展的功能。这样呈现在我们面前的就是一个个经过组合的子系统。

    虽然目前的这个模式还是没有名字，不过我们已经有了进行下去的勇气。

    在我们了解需求的过程中，部门的同事都会提到两个字“目前”。“这是我们目前的工作。”，“这是我们目前存在的问题”。

    没错，没人敢预测未来。我们也没打算做一劳永逸的系统。但我们该如果应对变化呢？

    了解变化点，我们做不到预测未来。但我们可以尽力去掌握哪些地方有可能变，哪些地方会经常变。甚至能分析出他会朝着那个趋势变。

    齐头并进开发子系统

    一、“并列式”开发

    将开发团队分割成小组，不同的子系统交由各个小组负责开发。大家可以同年同月同日开工，不一定非得同年同月同日完成。总比一条线的“瀑布”要快的多。

    二、关注代码，以人为本

    不必在开发的每一个阶段整理无穷尽的文档。整齐的代码更能体现程序员的智慧。可以没有详细设计，这样其实更不害怕变化。

    没有计划变化也就无所谓变化了。

    三、迭代

    这是迭代法的解释：迭代法也称辗转法，是一种不断用变量的旧值递推新值的过程,跟迭代法相对应的是直接法（或者称为一次解法），即一次性解决问题。

    敏捷开发中鼓励迭代，周期性的停下来歇一歇，看看过去几天写的东西，整理整理思路。其实这是我们在自己寻找变化。所以说敏捷的核心思想是适应变化！