敏捷开发之 历史背景
20世纪60年代：软件作坊，软件规模小，以作坊式开发为主；
70年代：软件危机，硬件飞速发展，软件规模和复杂度激增，引发软件危机；
80年代：软件过程控制，引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机；
90年代：重型过程，软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度发慢；
2001~今：敏捷正在流行，随着信息时代到来，需求发化更快，交付周期成为企业核心竞争力，轻量级的，更能适应发化的敏捷软件开发方法被普遍认可并迅速流行。
敏捷开发之 敏捷宣言
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
|
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning |
Robert C. Martin
Steve Mellor |
敏捷开发之 12条敏捷原则
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化。
3、经常地交付可以工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交流。
7、可工作的软件是进度的首要度量标准。
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10、以简洁为本，它是极力减少不必要工作量的艺术。
11、最好的构架、需求和设计出自与自组织团队。
12、团队定期地反思如何能提供成效，并依次调整自身的举止表现。
敏捷开发之 5个价值观
专注：由于我们在一段时间内只专注于少数几件事情，所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。
公开：在团队合作中，大家都会表达我们做得如何，以及遇到的障碍。我们发现将担忧说出来是一件好事，因为只有这样才能让这些担忧及时得到解决。
尊重：因为我们在一起工作，分享和成功失败，这有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人。
承诺：由于对自己的命运有更大的掌握，我们会有更坚强的信念获得成功。
勇气：因为我们不得单打独斗，我们能够感受到支持，而且掌握更多的资源。这一切赋予我们勇气去迎接更大的挑战。
敏捷开发之 Scrum
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周（最常见的是两周），并且无间歇地相继进行。Sprint是受时间箱限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。通常由Scrum团队来选定一个Sprint的时长，并且对于他们所有的Sprint都使用这一时长，直到这个团队能力提高，可以使用较短周期。在每个Sprint的初始，跨职能团队（大约7名成员）从排好优先级的列表中选择事项（客户需求）。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见，这些交付应该是有形的并且能被真正“完成”的。在Sprint过程中不可以增加新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。说了这么多看一下Scrum框架图就明白了。
小结
1、敏捷宣言：个体和互动 高于 流程和工具，工作的软件 高于 详尽的文档，客户合作 高于 合同谈判，响应变化 高于 遵循计划
2、12条敏捷原则
3、5个价值观：专注、公开、尊重、承诺、勇气
4、Scrum是一个框架，不是方法论