敏捷开发--经验交流

浅谈敏捷开发模式

　　最近在软件行业逐渐兴起的一种开发模式--敏捷软件开发。对于一个没有什么经验的菜鸟在这谈论开发模式，有点不切合实际。可是经过看了相关的一些资料，对这种开发模式仍是有点潜在的我的观点。

　　敏捷开发并非人们所认为的没有文档的开发。这个是确定的，从我参加的一个项目中来讲一点。以前和一个同窗给一个老师作的一个 普通话成绩分析系统，原本打算给老师帮帮忙，毕竟本身的时间也很宝贵，当时说是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分钟的会议，来讨论项目的状况，交流，完善，对项目的成功颇有帮助。我那个项目最遗憾的就是，每一个人分一部分功能，而后就没有了交流（项目上的），弄完了以后在组合，到时候出现了各类各样的问题，不光会出现问题，并且我以为没有交流很容易疲劳。

　　其余的部分即便说，彷佛菜鸟们总感受《软件工程》没什么用途。。。

　　说说敏捷开发和瀑布模型式的一个对比吧。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果做为衡量进度的方法，例如需求规格，设计文档，测试规划和代码审阅等等。 微软就是在开发软件的时候每个阶段，都要通过严格的步骤，它的严格分级致使的自由度下降，项目早期即做出承诺致使对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明而且在项目进行过程当中可能变化的状况下基本是不可行的。

　　而敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽可能小的可用的功能交付使用，并在整个项目周期中持续改善和加强。 

　　虽然阅读了一些资料，可是由于没有经验支撑，因此读起来比较抽象。潜在的看法，与你们分享一下。