引言
世界上不存在这样一种方法：
只要套用，就可以写出完美的软件，无论使用的哪种设计模式；
但确实可能存在一种开发方式，可以帮助我们一步步构造出需要的软件和架构——这有可能就是敏捷开发。
源自贝尔北方实验室的开发流程
Scrum的敏捷流程
随着技术的演进，尤其是互联网的发展，BS架构的广泛应用，用户反馈的及时响应成为了可能。从90年代开始逐渐引起广泛关注的一些新型软件开发方法出现了，如XP ( Extreme Programming )，Scrum 等，统称为敏捷开发。敏捷开发主要是通过高透明性、可检验性和适应性来管理复杂性、不可预测性和变化。
以Scrum为例，典型的开发模型如下：
这是一张被广泛引用的图片，还有一张烂大街的图片就是Sprint 的流程图：
难点在于一个sprint周期有多长，个人觉得Sprint周期的长度要依赖于你能在多长时间内保证在Sprint期间的需求不发生变更。
敏捷是一种方式，不是单纯的方法，通过各种的行为方式来实现目标。
首先是，Sprint 计划会议。计划会议要有足够的时间，最好至少8个小时。取出部分产品需求做成sprint需求，并写成索引卡。确定并细分每一个索引卡的故事（User Story）, 然后进行工作认领（不是分配）。同时，确定每日站立会议的时间和地点，确定好演示会议和回顾会议的日期。
站会是敏捷中的一个显著特点，每次10-15分钟，迟到将接受惩罚，每个成员自问自答三个问题：昨天做了什么，今天要做什么和遇到了什么问题，会后再沟通问题的解决方案，最重要的是更新燃尽图。
在开发过程中，要使用好任务看板，关注产品的整个生命周期：需求，设计，开发，测试和维护。注意燃尽图，对于小团队而言，建议不要使用软件取代看板，可以选择性的和XP或其它敏捷的某些方式相结合。
演示会议是至关重要的。演示是跨团队的，会产生不同团队之间的交流。不要关注太多的细节，以主要的功能为主，一定要让老板或者客户看到。演示会议
非常的重要，绝对不可以被忽略。
回顾会议的时间一般在1-3个小时，要找最舒适的地方（最好有回顾看板）。开始的时候轮流发言，而不是主动发言。记录问题并总结，并讨论改进的方法，放在回顾看板上。每人将最重要的2-3个改进点，成为下一轮产品需求的一部分。
还是那就话，“没有银弹”，敏捷也不是万能的。Scrum的主要缺陷有，团队压力大，不方便跨时区和跨语言的协同团队，而且一旦启动无法被中断，更重要的是程序维护的成本偏高，对工程师的要求较高，尤其是应用的架构和可扩展性。
敏捷开发12个准则
但是，敏捷开发的12个准则还是应该理解的，个人总结成一句话，按花生酱，赞不绝口。
Clic 按
Concise：简洁开发
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
Lean：精益求精
对技术的精益求精以及对设计的不断完善将提升敏捷性
Iteration：高速迭代
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
Change：拥抱需求变更
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
Jif 花生酱
Join：全员参与
项目过程中，业务人员与开发人员必须在一起工作
Incentive：员工激励
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
Face2Face：当面沟通
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
Raves 赞不绝口
Rethink：反思
团队要定期反省如何能够做到更有效，并相应地调整团队的行为
Availabiltiy：可用第一
可用的软件是衡量进度的主要指标。
Value：尽快给用户带来价值
最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
Evenly：匀速前进
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
Self-orgnazation：自组织团队
最佳的架构、需求和设计出自于自组织的团队。
敏捷开发的“三两招式”
敏捷开发的“开发四式”
- 意图导向编程，简单地说，就是把注释变成代码，让代码拥有自解释性
- 测试驱动开发，尤其是对后端而言更为重要，可以结合日志系统可以更快捷定位问题
- 创建和使用分离，这就是大家常说的“高内聚 低耦合”了
- 单点修改原则，单点修改可能只是一种理想状态，但应该铭记在心
团队敏捷和敏捷团队
总结
老曹眼中的敏捷开发，还是以我喜欢的一行python 代码作为共勉：
$ python -c "import this"
The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
