懵懂中的迭代与敏捷开发

    迭代，两层意思：重复、前进。典型的迭代方法有XP、Scrum等等。

    敏捷，含有快速、高效、准确的意思，敏捷开发方法通常应用时间定量的迭代和进化式开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性（快速和灵活的相应变更）的价值和实践。（摘自《UML和模式应用》）

    随手翻翻关于软件设计与开发中的迭代、敏捷，感觉在这些概念出现在自己视野之前，其部分零碎的思想早早出现在过去软件项目实施过程中。记得研究生时和另外一位同学，跟着一位有丰富软件开发经验（8年）的博士师兄做项目，那是个遗留项目，开发人员不稳定，项目需求变动大，并且我们和之前的项目开发组之间没有项目交接，实施过程中碰到了不少困难，当时我想着充分利用之前积累的客户需求资料，加上经常和客户业务人员沟通，先整理出整个需求文档，重新做软件业务建模、对象UML设计、数据库设计等等，然后干干净净重写代码。师兄的想法就是先根据已有的资料做出软件的整体框架和业务应用的主干，在最快的时间内到用户现场去安装，让用户提意见，然后我们再修改、完善，重复几次，每次都是一次迭代，是从细化到构造的过程，最终稳定整个开发框架与思路，完成软件开发，当时没有明确的敏捷UP开发理念，但回想起来基本就是典型的敏捷UP案例，包括每阶段开发的会议、建模、编码、测试……。自己是个完美主义者，特别是在校园年代，自己当时心里真的是一百个不愿意，觉得软件开发应该遵从标准软件开发模式，这样才能做出文档、软件设计、代码注释等等皆完美的软件，对软件不停修修改改，甚至有时局部颠倒重来极为反感！现在看来，按照师兄的方法，项目完成了，如果按照自己的想法，也许我们留下的不是一个实用软件，而是更多乱七八糟的文档给接下来的师弟师妹们。

    不知道师兄是不是有意按照迭代、敏捷思想来推进项目的，但之前的软件开发经历说明了迭代与敏捷确实是实际软件开发的经验总结，特别是在应对需求不稳定的情况下，能够体现出它独特的一面，毕竟我们是以应用、软件为核心，而不是完整的项目artifact，现在关于UP、XP、Scrum、敏捷方面的书籍和网络资料非常多，有时感觉像是在玩概念，但是一旦开始了解这些思想，会发现不少的方法自己已经在用了，继续看下去，会总结出自己过去开发经历中的种种经验，更高效的、有条理的完成以后项目的设计与开发。