文档介绍：敏捷开发简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。目录 1 价值观?沟通?简单?反馈?勇气?谦逊 2 原则?核心原则?宣言原则?补充原则 3 实践?核心实践?补充实践 4 名词详解 5 建模者?团队竞赛?畅所欲言?脚踏实地?好奇?凡是都问个为什么?实事求是?根据实验?有纪律 6 建模误区?误区一?误区二?误区三?误区四?误区五?误区六?误区七?误区八?误区九 7 开发宣言 8 遵循原则 9 敏捷开发与测试的关系 1价值观敏捷建模( Agile Modeling , AM ) 的价值观包括了 XP ( Extreme Programming : 极限编程) 的四个价值观: 沟通、简单、反馈、勇气,此外,还扩展了第五个价值观:谦逊。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。沟通建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的 project stakeholder 之间的沟通。简单画一两张图表来代替几十甚至几百行的代码, 通过这种方法, 建模成为简化软件和软件( 开发) 过程的关键。这一点对开发人员而言非常重要-它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。反馈 Kent Beck 在 Extreme Programming Explained 中有句话讲得非常好: “过度自信是编程的职业病,反馈则是其处方。”通过图表来交流你的想法,你可以快速获得反馈,并能够按照建议行事。勇气勇气非常重要,当你的决策证明是不合适的时候,你就需要做出重大的决策,放弃或重构( refactor )你的工作,修正你的方向。谦逊最优秀的开发人员都拥有谦逊的美德, 他们总能认识到自己并不是无所不知的。事实上, 无论是开发人员还是客户, 甚至所有的 project stakeholder ,都有他们自己的专业领域,都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值, 都应该被尊重。 2原则敏捷建模( AM ) 定义了一系列的核心原则和辅助原则, 它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从 XP 中借鉴而来,在 Extreme Programming Explained 中有它们的详细描述。而 XP 中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见!基本上,本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作;这样,对于这些借鉴于 XP 的原则,我们可以从另一个角度来看待。核心原则◆主张简单当从事开发工作时,你应当主张最简单的解决方案就是最好的解决方案。不要过分构建敏捷开发( overbuild )你的软件。用 AM 的说法就是,如果你现在并不需要这项额外功能,那就不要在模型中增加它。要有这样的勇气: 你现在不必要对这个系统进行过分的建模( over-model ),只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单。◆拥抱变化需求时刻在变, 人们对于需求的理解也时刻在变。项目进行中, Project stakeholder 可能变化, 会有新人加入, 也会有旧人离开。 Project stakeholder 的观点也可能变化, 你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行, 项目环境也在不停的变化,因此你的开发方法必须要能够反映这种现实。◆你的第二个目标是可持续性即便你的团队已经把一个能够运转的系统交付给用户, 你的项目也还可能是失败的--实现 Project stakeholder 的需求, 其中就包括你的系统应该要有足够的鲁棒性( robust ), 能够适应日后的扩展。就像 Alistair Cockburn 常说的, 当你在进行软件开发的竞赛时, 你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的系统的运转和支持。要做到这一点,你不仅仅要构建高质量的软件,还要创建足够的文档和支持材料,保证下一场比赛能有效的进行。你要考虑很多的因素,包括你现有的团队是不是还能够参加下一场的比赛,下一场比赛的环境,下一场比赛对你的组织的重要程度。简单的说,你在开发的时候,你要能想象到未来。◆递增的变化和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上, 你就算想这么做也不太可能。而且, 你不用在