相关资料
- 百度百科
为什么会产生敏捷开发
传统开发模式存在以下问题
- 开发周期长，使得开发过程难以预期，无法按照计划进行交付
- 由于无法按照计划交付，无法得到可交付成果，会产生沮丧感，无法得到成就感
什么是敏捷开发
是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
关键词：短周期，处于可交付状态
为了做到敏捷开发我们能做到什么
- 控制需求大小，使每个需求开发尽可能保持在可控范围内
- 主张简单，最简单的解决方法就是最好的方案，不要过分构建，只要基于现有的需求进行构建，日后需求有变更时再开重构这个系统；（要有这样的勇气 ）
- 拥抱变化: 开发方式尽可能的能拥抱变化，比如某个需求的推迟不会影响其他需求的发版。类似于需求组装的形式，各个需求之间尽可能的独立，不会相互产生印象
- 有目的的建模，在建模之前要了解为什么建模，为谁建模，如果连这些都不了解，最后的产出物很可能和需求方产生误差。例如，如果你是为维护人员建立模型，他们到底需要些什么？是厚达500页的详细文档才够呢，还是10页的工作总览就够了？你不清楚？去和他们谈谈，找出你想要的。
- 快速反馈
从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。
- 软件是你的主要目标
- 软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。
- 轻装前进
- 一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。
宣言原则
- 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
- 可以工作的软件是进度的主要度量标准。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
- 简单——尽可能减少工作量的艺术至关重要。
- 最好的架构、需求和设计都源自自我组织的团队。
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
