听完敏捷开发的课后，感觉敏捷了开发在我们程序的设计和构思中发挥着极其重要的作用。在此我们应该认识敏捷开发的价值
1、个体和交互
2、可以工作的软件
3、 客户合作
4、响应变化
敏捷思想注重一人的需求为中心，而不是那些形式主义。他更符合软件的发张规律，遵循循序渐进的原则，迭代实现各个模块的功能，
并最终以最大的条件满足客户的要求，达到双赢的效果。
下面我从三个方面来谈谈自己对敏捷开发的理解：
一、敏捷开发的原则
1、主张简单
当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建
你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分研究，
你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分研究，
只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。
2、拥抱变化
需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。
3、
递增的变化
和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。
4、
多种模型
开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应敏捷开发
用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术。
用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术。
有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。不同的系统使用不同部分的模型。
5、
高质量的工作
没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。
6、
软件是你的主要目标
软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动，如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。
7、宣言原则
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
二、敏捷的价值观
敏捷开发是针对传统的瀑布开发的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，
模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。
三、团队意识
1、团队竞赛
第一点，也是最重要的一点，敏捷建模者总是积极的寻求协作，因为他们意识到他们不是万事通，他们需要不同的观点，这样才能做到最好。软件开发可不是游泳，单干是非常危险的。在敏捷的字典中没有“我”这个词。
2、畅所欲言
队员都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听，能够主动获取反馈，并且能够把需要的写出来。都应当脚踏实地 他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。
3、有纪律
要坚持不懈的遵循敏捷的实践。对你来说，你可能会在不经意间说，“加上这个功能吧！无伤大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏离方向，是需要一定的纪律性的。
以上就是我自己对敏捷开发的理解，虽然只是我自己片面的描述，但是通过对敏捷的了解与学习，自己对程序开发有了新的认识。
信1101-1班 学号：20112829 董芳健