敏捷开发一些百科。

简单的说，敏捷开发是一种以人为核心、迭代、按部就班的开发方法。在敏捷开发中，软件项目的构建被切分红多个子项目，各个子项目的成果都通过测试，具有集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也价值观
编辑

敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提升开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可使你更深层次的理解敏捷开发。
沟通

建模不但可以促进你团队内部的开发人员之间沟通、还可以促进你的团队和你的project stakeholder之间的沟通。
简单

画一两张图表来代替几十甚至几百行的代码，经过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言很是重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也可以很容易的改进。
反馈

Kent Beck在Extreme Programming Explained中有句话讲得很是好：“过分自信是编程的职业病，反馈则是其处方。”经过图表来交流你的想法，你能够快速得到反馈，并可以按照建议行事。
勇气

勇气很是重要，当你的决策证实是不合适的时候，你就须要作出重大的决策，放弃或重构（refactor）你的工做，修正你的方向。
谦逊

最优秀的开发人员都拥有谦逊的美德，他们总能认识到本身并非无所不知的。事实上，不管是开发人员仍是客户，甚至全部的 project stakeholder，都有他们本身的专业领域，都可以为项目作出贡献。一个有效的作法是假设参与项目的每个人都有相同的价值，都应该被尊重。可独立运行的小项目，并分别完成，在此过程当中软件一直处于可以使用状态。
原则
主张简单
核心原则

◆主张简单
当从事开发工做时，你应当主张最简单的解决方案就是最好的解决方案。不要过度构建
敏捷开发
敏捷开发
（overbuild）你的软件。用AM的说法就是，若是你如今并不须要这项额外功能，那就不要在模型中增长它。要有这样的勇气：你如今没必要要对这个系统进行过度的建模（over-model），只要基于现有的需求进行建模，往后需求有变动时，再来重构这个系统。尽量的保持模型的简单。
◆拥抱变化
需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，所以你的开发方法必需要可以反映这种现实。
◆你的第二个目标是可持续性
即使你的团队已经把一个可以运转的系统交付给用户，你的项目也还多是失败的－－实现Project stakeholder的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），可以适应往后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要作到这一点，你不只仅要构建高质量的软件，还要建立足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑不少的因素，包括你现有的团队是否是还可以参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到将来。
◆递增的变化
和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么作也不太可能。并且，你不用在模型中包容全部的细节，你只要足够的细节就够了。没有必要试图在一开始就创建一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，而后慢慢的改进模型，或是在不在须要的时候丢弃这个模型。这就是递增的思想。
◆令Stakeholder投资最大化
你的project stakeholder为了开发出知足本身须要的软件，须要投入时间、金钱、设备等各类资源。stakeholder应该能够选取最好的方式投资，也能够要求你的团队不浪费资源。而且，他们还有最后的发言权，决定要投入多少的资源。若是是这些资源是你本身的，你但愿你的资源被误用吗。
◆有目的的建模
对于本身的artifact，例如模型、源代码、文档，不少开发人员不是担忧它们是否够详细，就是担忧它们是否太过详细，或担忧它们是否足够正确。你不该该毫无心义的建模，应该先问问，为何要创建这个artifact，为谁创建它。和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你须要和高级经理交流你的方法，也许你须要建立描述系统的文档，使其余人可以操做、维护、改进系统。若是你连为何建模，为谁建模都不清楚，你又何须继续烦恼下去呢？首先，你要肯定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。一旦一个模型实现了目标，你就能够结束目前的工做，把精力转移到其它的工做上去，例如编写代码以检验模型的运做。该项原则也可适用于改变现有模型：若是你要作一些改变，也许是一个熟知的模式，你应该有作出变化的正确理由（多是为了支持一项新的需求，或是为了重构以保证简洁）。关于该项原则的一个重要暗示是你应该要了解你的受众，即使受众是你本身也同样。例如，若是你是为维护人员创建模型，他们到底须要些什么？是厚达500页的详细文档才够呢，仍是10页的工做总览就够了？你不清楚？去和他们谈谈，找出你想要的。
◆多种模型
开发软件须要使用多种模型，由于每种模型只能描述软件的单个方面，“要开发现今的商业应
敏捷开发
敏捷开发
用，咱们该须要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于artifact的清单，能够参阅AM的建模artifact）。有一点很重要，你没有必要为一个系统开发全部的模型，而应该针对系统的具体状况，挑选一部分的模型。不一样的系统使用不一样部分的模型。好比，和家里的修理工做同样，每种工做不是要求你用遍工具箱里的每个工具，而是一次使用某一件工具。又好比，你可能会比较喜欢某些工具，一样，你可会偏心某一种模型。有多少的建模 artifact可供使用呢，若是你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，若是你但愿作进一步的了解，能够参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。
◆高质量的工做
没有人喜欢烂糟糟的工做。作这项工做的人不喜欢，是由于没有成就感；往后负责重构这项工做（由于某些缘由）的人不喜欢，是由于它难以理解，难以更新；最终用户不喜欢，是由于它太脆弱，容易出错，也不符合他们的指望。
◆快速反馈
从开始采起行动，到得到行动的反馈，两者之间的时间相当紧要。和其余人一共开发模型，你的想法能够马上得到反馈，特别是你的工做采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工做，去了解他们的的需求，去分析这些需求，或是去开发知足他们需求的用户界面，这样，你就提供了快速反馈的机会。
◆软件是你的主要目标
软件开发的主要目标是以有效的方式，制造出知足project stakeholder须要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动（activity ），若是不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。
◆轻装前进
你创建一个artifact，而后决定要保留它，随着时间的流逝，这些artifact都须要维护。若是你决定保留7个模型，不论什么时候，一旦有变化发生（新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术...），你就须要考虑变化对这7个模型产生的影响并采起相应的措施。而若是你想要保留的仅是3个模型，很明显，你实现一样的改变要花费的功夫就少多了，你的灵活性就加强了，由于你是在轻装前进。相似的，你的模型越复杂，越详细，发生的改变很可能就越难实现（每一个模型都更“沉重”了些，所以维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（因此才须要增强团队之间，团队和project stakeholder之间的沟通）。千万不要小看权衡的严重性。一我的要想过沙漠，他必定会携带地图，帽子，质地优良的鞋子，水壶。若是他带了几百加仑的水，可以想象的到的全部求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？一样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。
宣言原则

最重要的是经过尽早和不断交付有价值的软件知足客户须要。
咱们欢迎需求的变化，即便在开发后期。敏捷过程可以驾驭变化，保持客户的竞争优点。
常常交付能够工做的软件，从几星期到几个月，时间尺度越短越好。
业务人员和开发者应该在整个项目过程当中始终朝夕在一块儿工做。
围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，知足他们的须要，并相信他们可以完成任务。
在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
能够工做的软件是进度的主要度量标准。
敏捷过程提倡可持续开发。出资人、开发人员和用户应该老是维持不变的节奏。
对卓越技术与良好设计的不断追求将有助于提升敏捷性。
简单——尽量减小工做量的艺术相当重要。
最好的架构、需求和设计都源自自我组织的团队。
每隔必定时间，团队都要总结如何更有效率，而后相应地调整本身的行为。[1]
补充原则

◆内容比表示更重要
一个模型有不少种的表示方法。例如，能够经过在一张纸上放置即时贴的方法来创建一个用户界面规格（基本/低精度原型）。它的表现方式能够是纸上或白板上的草图，能够是使用原型工具或编程工具创建和传统的原型，也能够是包括可视界面和文本描述的正式文档。有一点颇有意思，一个模型并不必定就是文档。它们一般做为其它artifact的输入，例如源代码，但没必要把它们处理为正式的文档，即便是使用CASE工具创建的复杂的图表，也是同样。要认识到一点，要利用建模的优势，而不要把精力花费在建立和维护文档上。
◆三人行必有我师
你不可能彻底精通某项技术，你老是有机会学习新的知识，拓展知识领域。把握住这个机会，和他人一同工做，向他人学习，试试作事的新方式，思考什么该作，什么不应作。技术的变化很是的快，现有的技术（例如Java）以难以置信的速度在改进，新的技术（例如C#和.NET）也在有规律的产生。现存开发技术的改进相对会慢一些，但也在持续的改进中－－计算机产业属于工业，咱们已经掌握了其中的试验基本原理，但咱们还在不断的研究，不断的实践，不断的改进咱们对它的了解。咱们工做在一个变化是屡见不鲜的产业中，咱们必须经过训练、教育、思考、阅读、以及和他人合做，抓住每个机会学习新的处事之道。
◆了解你的模型
由于你要使用多种模型，你须要了解它们的优缺点，这样才可以有效的使用它们。
◆了解你的工具
软件（例如做图工具、建模工具）有各类各样的特色。若是你打算使用一种建模工具，你就应当了解何时适合用它，何时不适合用它。
◆局部调整
你的软件开发方法要可以反映你的环境，这个环境包括组织特征，project stakeholder的特征，项目自身的特征。有可能受其影响的问题包括：你使用的建模技术（也许你的用户坚持要看到一个细节的用户界面，而不是初始草图或基本原型）；你使用的工具（可能你没有数字照相机的预算，或是你已经拥有某个CASE工具的license）；你遵循的软件过程（你的组织采用XP的开发过程，或是RUP，或是本身的过程）。所以你会调整你的方法，这种调整多是针对项目的，也多是针对我的的。例如，有些开发人员倾向于使用某一类工具，有些则不用。有些人在编码上花大力气，基本不作建模，有些则宁肯在建模上多投入一些时间。
◆开放诚实的沟通
人们须要可以自由的提出建议，并且人们还应该可以感觉到他们是自由的。建议多是和模型有关的想法：也许是某些人提出某部分新的设计方法，或是某个需求的新的理解；建议还多是一些坏消息，例如进度延误；或仅仅是简单的工做情况报告。开放诚实的沟通是人们可以更好的决策，由于做为决策基础的信息会更加准确。
◆相信直觉
有时你会感受到有什么地方出问题了，或是感受什么地方有不一致的状况，或是某些东西感受不是很对。其实，这种感受颇有可能就是事实。随着你的软件开发的经验的增长，你的直觉也会变得更敏锐，你的直觉下意识之间告诉你的，极可能就是你工做的关键之处。若是你的直觉告诉你一项需求是没有意义的，那你就不用投入大量的精力和用户讨论这方面的问题了。若是你的直觉告诉你有部分的架构不能知足你的须要，那就须要创建一个快速技术原型来验证你的理论。若是你的直觉告诉设计方法A要比设计方法B好，并且并无强有力的理由支持你选择某一个方法，那就尽管选择方法A。勇气的价值就已经告诉你，若是将来证明你的直觉是错的，你也有能力来挽救这种状况。你应该有这种自信，这很重要。