浅谈敏捷开发模式
最近在软件行业逐渐兴起的一种开发模式--敏捷软件开发。对于一个没有什么经验的菜鸟在这谈论开发模式，有点不切合实际。但是通过看了相关的一些资料，对这种开发模式还是有点潜在的个人观点。
敏捷开发并不是人们所认为的没有文档的开发。这个是肯定的，从我参加的一个项目中来说一点。之前和一个同学给一个老师做的一个 普通话成绩分析系统，本来打算给老师帮帮忙，毕竟自己的时间也很宝贵，当时说是1000块钱。我先说一下我们这个项目的做法（当然是很失败的）：第一次和老师交流后，了解到了大概的意思，这时候真的感觉和用户交流的困难，总是想用专业的知识给老师解释，但是老师都不懂，这很自然。因为用户本来如此。 谈了一个多小时，挖掘出一些东西。对于这个项目，第一步就失败的是就是没有弄一个文档，以至于在后来总感觉很简单的东西，却不知该做什么了。 和自己的团队也没有太多的交流，不过是每个人负责一个模块，然后再把代码凑在一起。拖拖拉拉的很久了。虽然最后大部分功能都实现了，但这个项目给我的感觉是失败的。
还是那个句话，谈开发模式，应该是具有丰富的开发经验的牛人会有更深刻的体会，我的观点也仅仅是我的一些理解。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 这里总的概括一下，敏捷开发由几种轻量级的软件开发方法组成：
极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。
·极限编程(XP)
就是每天得到用户的需求，能够第一时间获得用户的要求；采用的是结对编程的方式。我们所说的没有文档，其实在极限编程里面，团队之间的交流不是通过文档，文档不是必须的。团队成员之间通过日常沟通，简单设计，测试，系统隐喻以及代码本身来沟通产品需求和系统设计。还有就是通过反馈，团队之间，用户和团队之间都有反馈。在极限编程的团队中，每个人不得将未通过单元测试的代码集成到系统中。因此，每个人的代码质量必须过关。
一些核心的做法：
·小规模，频繁的版本发布，短迭代周期。
·测试驱动开发（Test-driven development）。
·结对编程（Pair programming）。
·持续集成（Continuous integration）。
·每日站立会议（Daily stand-up meeting）。
·共同拥有代码Collative code ownership.
·系统隐喻（System metaphor）。
我觉得每日站立会议是一个很不错的做法，一个团队中，每天都通过这个15分钟的会议，来讨论项目的情况，交流，完善，对项目的成功很有帮助。我那个项目最遗憾的就是，每个人分一部分功能，然后就没有了交流（项目上的），弄完了之后在组合，到时候出现了各种各样的问题，不光会出现问题，而且我觉得没有交流很容易疲劳。
其他的部分即使说，似乎菜鸟们总感觉《软件工程》没什么用途。。。
说说敏捷开发和瀑布模型式的一个对比吧。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试规划和代码审阅等等。 微软就是在开发软件的时候每一个阶段，都要经过严格的步骤，它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
而敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。
虽然阅读了一些资料，但是因为没有经验支撑，所以读起来比较抽象。潜在的见解，与大家分享一下。