敏捷开发方法

　　王老师让撰写一篇博客关于敏捷开发方法，让我们深入理解敏捷开发方法。

　　简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。（这是百度百科的解释）

　　我看来，在爆发软件危机以来，我们一直没有找到一个完美的方法解决。敏捷开发是在人们探索中由以前的开发方法中探索和总结出来的，虽然不完美，但是正在逐步适应。

　　敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

　　敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。

　　简单，变化，持续性，迭代，成本。。。这是敏捷开发中常见的几个词。

　　简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建（overbuild）你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。

　　变化：需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

　　持续：即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现Project stakeholder的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。

　　迭代：和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。

　　成本：你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。

　　

　　除此之外，还有一个重要的词是团队，什么是团队，这也是敏捷开发必须需要考虑的，团队不是一群人做一个人的事。

　　团队中必须有人是领导者，有人是执行者。好比僚机和战斗机的关系。团队的每日站立会议也很重要，团队要变成自己领导自己，从消极的听从指挥变成自己主动，是团队的主导不是个人的主导，向团队利益最大化的方向发展。

 

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