下面这张图能简单说明敏捷的人员组成以及一些基本实践。

需要完成的工作：产品代办列表（Product Backlog）、冲刺代办列表（Sprint Backlog）、工作项分解。

通常通过“用户故事”的方式来表示产品代办列表、冲刺代办列表，产品代办列表的用户故事可能比较大，需要进一步细分为比较细的用户故事，然后放入不同的Sprint中，作为不同Sprint的代办事项，而Sprint中的用户故事，还可以继续拆分成更细的工作项分解。

这些需要完成的工作，需要通过大小迭代来完成。

大迭代是指：Sprint（冲刺，也就是小版本），通常是30天的时间，每30天增量式的交付“可运行的软件”。“可运行的软件”这个说法还不太好，应该是“可工作的软件”，否则你可能认为编译通过程序能跑就是“可运行”了，而“可工作”才是重要指标，不仅仅能运行，还能为客户带来实在价值，才叫“可工作”。

小迭代是指：每天的项目会议，通常是15分钟内。开会时间可以是早上、中午或下班前。形式和时间都不是关键，关键是要有效，要领会24小时开一次会议的核心思路！我们都知道问题越早发现越早处理，处理成本越低，24小时开会让问题被发现时间不会超过24小时，将问题消灭萌杀状态，同时每天修正项目的方向，保证我们一直在做正确的事情。

需求方面最佳实践：

1）User Story（客户故事）

2）客户全程参与

测试方面最佳实践：

1）测试驱动开发（TDD）

2）自动化测试

编码方面最佳实践：

1）结对编程

2）持续集成（每日构建）

项目管理方面最佳实践：

1）Sprint（冲刺）、小版本发布

2）每日站立会议、每日晨会

3）每周工作40小时

4）Burn Down Chart（燃尽图）