世界上不存在这样一种方法：

只要套用，就可以写出完美的软件，无论使用的哪种设计模式；

但确实可能存在一种开发方式，可以帮助我们一步步构造出需要的软件和架构——这有可能就是敏捷开发。

相对于软件开发流程，有一门专门的学科——软件工程。最早接触软件工程，是20年前在北电贝尔北方实验室工作的时候，当时的开发流程是这样的：

其他主流的瀑布式开发流程也大致如此。然而，随着技术的演进，尤其是互联网的发展，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个准则还是应该理解的，个人总结成一句话，按花生酱，赞不绝口（参见http://blog.csdn.net/wireless_com/article/details/40622377）。

敏捷开发乃至一般的开发过程都会涉及到一件事，任务估点，就如何见招拆招。个人觉得，一个task 最好以2个小时为单位，半小时设计，半小时编码，半小时测试，半小时文档、注释以及重构。原因可能是这样的，互联网上流传着一句名言——3个月就是一年，也就是1周相当于1个月。那么，2个小时就相当于1天了，也就是说，我们的团队要将每两个小时当成一天来计算。众所周知，所有的估算都是不准确的，以2小时为单位是为了降低误差。就像我们度量的时候，以米为单位度量，误差就是米，以毫米来量，误差就是毫米。2个小时一个task，就相当于开发中的“毫米”。

敏捷开发中最重要的还是代码，优秀的代码质量决定着产品或者服务的质量。个人以为，有四种手段可以提升一下代码质量：

1）意图导向编程，简单地说，就是把注释变成代码，让代码拥有自解释性

2）测试驱动开发，尤其是对后端而言更为重要，可以结合日志系统可以更快捷定位问题

3）创建和使用分离，这就是大家常说的“高内聚 低耦合”了

4）单点修改原则，单点修改可能只是一种理想状态，但应该铭记在心

至于敏捷团队，就是我提倡的ABC了：

具体的，我在旧文《和 <创时代>》（http://blog.csdn.net/wireless_com/article/details/52904654）中有描述，这里不在重复。对于团队敏捷，我只想澄清项目和产品开发（project developement vs product developement）的区别，这两者在目标上还是又着区别的，例如持续演进，架构的可扩展性等等。