敏捷方法是软件工程方法论和实践的新发展，它能够更快、成本更低、风险更少地开发质量更好的软件，团队的活力和成就感也更好。软件开发团队和企业应该学习和实践敏捷开发方法和过程。现在很多公司都采用了敏捷方法进行软件开发的管理，敏捷方法、过程和相关的工具已经普及。
scrum是一种灵活的敏捷软件开发管理过程，这个名词来源于英式橄榄球。scrum方法由Ken Schwaber和Jeff Sitherland提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标——发布产品的重要性高于一切，团队高度自治，成员们熟悉开发过程中设计的各种技术，紧密合作，确保每个迭代都朝着最高目标推进，而且每隔2~4周，每个团队成员都可以看到能实际工作的软件，并据此决定是发布这个版本还是继续开发以增强它的功能。
scrum是当前最流行的敏捷方法，还有一些其他符合敏捷思想的开发方法，比如XP（极限编程）、RUP（Rational统一过程）、Lean（精益软件开发方法）。
XP极限编程便是另一种敏捷方法，思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。在这里，“eXtreme”的意思是希望将软件开发过程中一些好的方法发挥到极致。XP注重的核心在于沟通、简明、反馈和勇气，用一句话来概括XP的这4个核心价值观就是：通过充分的交流和沟通，使产品的设计尽可能简单明了；同时通过客户经常性的反馈，生产出符合客户要求的软件产品，并且有勇气迎接需求的改变。还总结出了一系列经典的实践，形成了XP的12个主要实践方法，这些方法对极限编程具有指导性意义，分别是客户计划的定制、小版本发布、隐喻、结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、现场客户。
scrum对于那些功能需求可能经常发生变化的项目来说，是最为理想的选择之一。
产品backlog指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。产品backlog是产品所要具备的所有功能的总纲。在sprint计划会议上，产品负责人为产品Backlog中的任务确定优先级，并向scrum团队描述这些任务。scrum团队随后根据团队整体情况，确定他们能在这个即将到来的sprint中要完成哪些功能，并把它们挪到sprint backlog中去。
角色
在Scrum中有三种角色，分别是产品负责人（Product Owner）、Scrum Master和Scrum团队。
产品负责人需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级。在每个sprint开始之前，Product Owner可以修改功能需求和优先级。
Scrum Master的职责是：负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；保证开发团队不受外力的干扰和阻挠；尊重产品开发进度，参与每日scrum会议、sprint计划会议和sprint评审会议。
scrum团队一般由5~10个能全职工作的成员组成较为理想。
scrum管理工具
常用的几个管理工具，ScrumWorks、Rational Team Concert、XPlanner等。
ScrumWorks是一个专门针对scrum项目管理的商业软件，网站是http://www.danube.com/scrumworks，有两种版本，pro和basic，其中basic是免费的，功能比较少。有桌面和web两种界面，产品负责人（Product Owner）和Scrum Master可以使用桌面应用程序入口，而普通团队成员可以使用web应用程序入口。
Rational Team Concert是IBM的一个十分强大的开发协作平台，属于商业软件，是基于一个jazz的IBM开源平台开发的，jazz本身是基于eclipse的，所以具有跨平台的特性。最强大的地方在于可以和IBM Rational软件配置管理工具进行集成，比如著名的代码管理工具ClearCase、软件缺陷管理工具ClearQuest和Build管理工具BuildForge等。其自身也带有一个代码控制管理工具。
XPlanner是一种针对敏捷开发，尤其是XP的项目管理工具。不过，其对于scrum也是同样适用。XPlanner本身是一个轻量级的开源项目，而且完全免费，是一个基于java的web应用。计划模型简单，支持迭代开发，比较简单，适合非常小的团队使用。
敏捷开发的核心价值观是：软件开发最重要的是给用户提供有价值的、可以工作的软件。
如何保证提供有价值的软件， 是通过反馈机制来完成的。采用敏捷开发后，我们更有意识地希望得到各种反馈，包括来自外部的和内部的。我们产品的大部分功能都直接来自客户的需求，并按优先级排序。
可以工作的软件，其含义就是软件是可交付给客户使用的。
采用敏捷开发，对于分布式开发的团队来说，也大大加强了沟通。
在敏捷开发中，测试很早就介入了，开发人员不仅可以立即解决问题，还能够有效地调动测试人员的积极性和主动性，让他们也参与到软件的设计中来。在敏捷开发里，测试和开发的交流更多了。测试和开发是真正意义上的团队，还有效避免了过去测试和开发之间一些消极的争斗和不合作的场面。采用了敏捷开发，大大提高了测试人员的积极性，过去测试人员一直处在被动的角色，而在敏捷开发中，在开发中就需要测试人员的大量参与，参与需求、参与设计。
在文档管理方面，摒弃了过去繁冗的文档管理，节省了大量的时间和经历。需求、计划以及设计文档通常只保留一个一页多的版本，并且放在wiki这样的敏捷文档系统上，任何人、任何时候都可以更新它。
自我管理的团队是敏捷里的一个比较“酷”的理念，老板变成了教练的角色，从琐碎的项目管理中解放出来，把精力放到了更重要的带领我们进行技术创新和团队个人成长上。团队成员有了更多的决策权，可以调动更大的潜能，可以领取自己最感兴趣的任务。
