前奏：

在写这篇文章时，我考虑怎样尽量避免一些概念性很强的东西，比如敏捷的一些原则，我会用我实践的经验来阐述相关概念性东西，但是在开始之前，还是有必要对一些概念进行一些总结和认识。我现在所在的开发团队是一个有10多人的小团队，虽然是一个小团队，但在初期的研发过程中也暴露出很多问题，面临的问题：

针对于这些问题以及对其他一些公司的研发流程的考察，大致总结出如下思路，这些也都是些常用的敏捷方法：

Scrum初识：

谈到敏捷，很多人感到这是个比较泛泛的概念，敏捷开发是90年代初逐渐兴起的新型软件开发方法，它主要是应对需求多变的快速开发模式。敏捷本身只是一个短短的宣言，这个宣言一直缺乏一个好的实践方式，Scrum的出现，正是作为一个敏捷框架（姑且称为框架啊）解决了这一问题。它包含的是一系列实践和预定义角色的过程骨架。

Scrum原理：

Scrum是一种基于经验主意的流程控制，Transparency(透明性)，Inspection(观察)，Adaptation(调整)是它的三大支柱。这几个概念，我们会在实践中阐述。注：Scrum不是一个解决问题的方法，他只是让问题显现出来的手段。

Scrum结构框架:

职能（角色）：一般主要分为三个角色

产出：产品的backlog->节点的backlog->节点总结

仪式：之所以称为仪式，是因为Scrum强调一点：形式大于内容，像每天召开的scrum会议，迭代计划会，总结会和评审会。

下一篇，将详细讲解scrum的迭代流程和backlog，任务墙以及spring meeting（节点会议）的相关概念，接下来将会用我实际开发经验来详细解释这些概念性的东西。