当别人告诉我“Sprint是一个小型瀑布”时，我马上回应“不是”。我经常这样做，因为我经常听到刚接触敏捷的人这样说，甚至也听到有些已经在项目中运用敏捷开发方法的团队也这样说。在这篇文章中，我们用5个推论来证实Sprint不是一个小型的瀑布。它们是：持续的设计、开发、集成和测试；跨职能团队成员； Sprint期间不允许变更；时间盒；严格定义的开发节奏。
1.持续的设计、开发、集成和测试
设计、开发、集成和测试在sprint中是一个持续的活动，而不像瀑布项目是顺序的过程。下图描述了它们的不同之处：
瀑布项目
敏捷项目
2.跨职能的团队成员
Sprint团队是一个跨职能的团队，以一种动态的模式组织工作。这与瀑布是不同的，瀑布项目的各个 团队独立工作，将任务从一个团队交付到另外一个团队：
瀑布项目团队
敏捷项目团队
3.Sprint期间不允许变更
瀑布项目制定了硬性的变更控制过程去管理项目的变更。相比之下，敏捷中的变更控制几乎不存在。这给了PO非常大的灵活性在sprint之间去改变他或她的想法。然而，一旦Sprint开始，任何变更都不会被接受，直到这个sprint结束。
瀑布项目：
敏捷项目：
4.时间盒
无论sprint进展如何，Sprint时间总是固定的。在瀑布模型中，如果项目落后于计划，那么项目通常需要延时。在敏捷项目中，即使承诺的任务不能在Sprint期间完成，Sprint也不会改变结束时间。如果在计划的Sprint期间还有条目没有完成，条目会被重新加进产品backlog列表中，然后被排序并被安排到后面的Sprint中完成。
5.严格定义的开发节奏
在瀑布项目中，不能够预先定义项目的进行节奏，相比之下，Sprint总是按照一个定义良好的节奏工作。下图描绘了一个典型的两周的Sprint节奏：
Sprint和瀑布式项目方法的五个特点阐述了两者之间的主要区别，因此不要再让你或者你的团队错误地认为Sprint“只是”一个小型瀑布模型。
作者:Chand Warrier
原文地址：http://www.scrumalliance.org/community/articles/2012/january/a-sprint-is-not-a-mini-waterfall
