敏捷开发

在Scrum实践中，团队的交流和协作是至关重要的。如果团队成员的数量超过了10人，例如20人，30人，可以使用Scrum of Scrum的管理方式。

Scrum 理论是基于一个国外的学科，叫《过程动态学，建模及控制》，什么意思呢？过程控制方法有两种：预定义过程控制和经验性过程控制。预定义过程就是在执行之前 先要制定详细的计划，然后严格按照计划执行，这种控制方式在过程比较简单的情况下比较适用，但是如果过程不可能预测的非常详尽的话，预定义过程就显得力不从心，这时候“经验过程控制”就更合适于过程控制。

支付宝的研发体系是从自身实际出发制定的，既要保障产品的高品质，又要保持对业务变化的快速响应，加上协调多个团队高度并行开发的需要，整套研发体系是一个精心设计的严谨结构，也是比较重量型的。但还是可以从中找到敏捷方法中的一些重要元素。

Scrum实践经验

敏捷开发已经被有效地使用了很多年，即使项目结果很有希望，敏捷开发的采用也主要限制在公司内部。最近，采用敏捷开发的行业已经开始增加，比如保险行业，电信和金融服务领域，但是为了使敏捷开发变成主流，还需要主要产业积极参与者的支持，散乱的敏捷景象需要被统一起来，敏捷的转变需要是逐步演进的而不是革命性的。我们需要对大规模敏捷转变提供良好的支持，包括大规模的知识改变，处理必要的HR政策，以及可扩展的敏捷工具构架。

在传统开发方法中，架构设计是围绕着设计文档展开的。

以实际项目案例为蓝本，结合项目管理专家点评和会员分析，真实、深入、可鉴。

在敏捷开发中，重构是一个必要条件，文章以Scrum为例，阐述了重构的理由、遇到的问题以及实践中的做法。

确保自我管理团队成功：明确定义边界；容忍错误，并给予时间学习；让团队始终感受到挑战，但不能让他们筋疲力尽。

Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，将会介绍如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个 项目曾经在传统开发方式下被废弃过 。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。

敏捷开发包括很多模式：AMDD（Agile Model Driven Model），AUP（Agile Unified Process），XP（Extreme Programming），FDD（Feature Driven Development），Scrum，OpenUP（Open Unified Process），ADM（Agile Data Model），LSD（Lean Software Development）等等，以下重点介绍使用最为流程的五种Model。一图顶万字，每一种Model用最直接的流程图展示。本节介绍OpenUP。

敏捷开发包括很多模式：AMDD（Agile Model Driven Model），AUP（Agile Unified Process），XP（Extreme Programming），FDD（Feature Driven Development），Scrum，OpenUP（Open Unified Process），ADM（Agile Data Model），LSD（Lean Software Development）等等。本节介绍AMDD、AUP和FDD。

敏捷开发包括很多模式：AMDD（Agile Model Driven Model），AUP（Agile Unified Process），XP（Extreme Programming），FDD（Feature Driven Development），Scrum，OpenUP（Open Unified Process），ADM（Agile Data Model），LSD（Lean Software Development）等等。本节介绍XP和Scrum。

业务部门和开发团队依赖文档进行沟通的后果往往是理解出现偏差，开发出的系统的不能满足业务部门的真正需求，造成浪费。

在现在服务的公司里，我和我的团队应用Scrum已经快5个月了，感觉团队已经趋向于自管理的模式，主要的表现在：计划和承诺由团队做出，如何指派工作由团队做出。但还是有一点欠缺：工作角色概念突出。

我们的项目在开始的实践中，有几个sprint是不成功的。在sprint的结束时Team确实提交了产品，但产品不是可以部署的，而是只经过了简单的测试，没有文档说明，没有release notes等。现在回头总结，最主要的原因是在sprint planning时没有明确定义完成标准DOD（Definition of Done）。

作为一个组织，当我们一年前首次邂逅Scrum，第一感觉就相信它是管理层所期望做到的领域之一，因为对于工程方面运作方式的改变势在必行。那时，感觉减缩开支并不是非“敏捷”不可，可能只要些不一样的做法，而且这种方式也必然经历了当时“彻底的改革之风”潮流的洗礼。

开始实施Scrum之前，除了需要对所有涉及到的人进行培训之外，另外一项重要工作就是选择一个适合自己的Scrum工具。很多关于敏捷的论文或教科书都提到了白板和Excel电子表格。但白板与Excel电子表格明显不能满足一个注重过程资产的软件项目的要求。

敏捷开发的潮流并不是由敏捷工具来推动的，因为你可以仅使用命令行接口、单元测试工具和需求卡片来展开敏捷开发。但近年来，为了更好地支持敏捷开发，敏捷工具也有了很大的发展。其中部分工具是直接面向新型项目管理方式的，特别是有些种类的工具已与敏捷开发密不可分。根据Forrester研究公司(Forrester Research)高级分析师Carey Schwaber的研究结果，面向敏捷开发的项目管理工具、持续集成构建工具和自动测试工具已是敏捷开发不可或缺的工具。

敏捷中国大会2009(http://www.agilechina.net)于2009年9月11日至12日在北京举行，本次大会由InfoQ和ThoughtWorks共同举办，主题为“实效敏捷”(Pragmatic Agile)，包含勇气、反馈、简单和尊重等四个分主题，近20名国内外知名讲师参与，包括极限编程(XP)创始人Kent Beck，敏捷宣言创始人之一Dave Thomas，敏捷领域大师级专家Fred George和Dave Nicolette，ThoughtWorks中国首席技术官Michael Robinson等。