作为项目经理，我们经历了不同的项目，却总是受限于相似的困局。比如以下三个典型难题：

团队目标不一致

团队成员不熟悉

信息发布不顺畅

倘若我们任由问题存在，而不在每次项目中进行总结和提炼，就会反复的徘徊于丰满理想与骨感现实当中。

敏捷思想和实践能够为我们提供一种可能性，帮助我们解决在项目交付过程中遇到的具体难题。

敏捷的项目管理——追求最大价值的成功

当我们提到敏捷的项目管理，就得先说说瀑布式开发和迭代式开发的区别。

（图片来自：）

大家都知道瀑布式开发的特点是大批次、缓慢流动、在每一阶段追求工作完整，但因其缺乏并行迭代的概念，对变化的响应必然很慢。而迭代式开发则恰恰弥补了这个弱点。在迭代式开发过程中，整个开发工作被组织为一系列短小的、固定长度（在ThoughtWorks通常是2周）的小项目，我们将其称为一系列的“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。

采用这种方法，开发工作可以在需求被完整地确定前启动，并在每次迭代中完成系统的一部分功能开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代。

ThoughtWorks的敏捷开发通过逐步细化、迭代前进的方式，分阶段地将需求予以实现。比如说，我们先从整体功能规划中定位出一小部分核心功能，打造能基本运转、对用户有价值的最小可用产品（Minimum Viable Product，MVP），然后迅速迭代开发，听取用户反馈，及时调整功能规划。

我曾在一次培训中听到同事谈到敏捷团队与西游团队的相似性，他认为唐僧师徒可以被看作敏捷中的全功能团队：团队有共同的目标——取到真经；他们历经了九九八十一难，好比九九八十一个迭代，每次打怪成功都是完成了一次交付；在不断迭代的过程中，这个团队不断地收集反馈、持续改进，一步步地完成了最后的目标。取到了真经，意味着完成了项目的交付，同时使得团队能力得到质的提升。这是一个美妙的结果。

项目成果的交付和团队能力的提升，这是项目经理在项目管理中最希望达成的目标。 传统项目管理的定义是：“在有限资源限定的条件下，实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角：需求是范围，资源包括时间和成本。

那么这个定义是正确的吗？

大家都看过电影《泰坦尼克号》，如果我们套用上面这个“范围、时间和成本”定义的框架，《泰坦尼克号》会被判断为一个失败的项目。为什么呢？这部电影在拍摄过程中多次延期，j2直播，预算也超出很多，无论从成本还是时间来看，这都是一个失败的项目。可是我们都知道，《泰坦尼克号》直到现在仍然是一个难以超越的票房神话。

由此可知，左图的“传统项目管理铁三角”概念忽略了“价值”这一重要因素。右图的“敏捷项目管理铁三角”强调，团队应得到来自市场的真实反馈，以此来帮助敏捷团队持续不断地、尽早地交付有价值的软件。

在追求价值交付过程中，我们越来越多地发现敏捷项目管理中有着至关重要的一环——人，也就是我们的团队。价值是人创造的，是为人服务的，很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人，是以创造力、洞察力、对客户的感知力为核心特征的，我们相信这样的团队能创造最大的价值。

下文将以我在ThoughtWorks的项目经历为例，讲述ThoughtWorks日常交付项目中主要使用的敏捷实践是如何帮助团队实现最大价值的。

用户故事

用户故事(User Story)是敏捷开发的基础，它从用户的角度来对需求进行描述。软件开发是为了实现产品的商业价值，满足用户需求。只要需求足够明确，所有人都了解其具体内容，团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。为了实现这个目标， 需要找到一种方法来描述需求，让所有人都能对任务的范围有一个共同的认知。这样团队对任务完成会有一个共同的定义，不会出现“你做的不是我所要求的”、 “我忘了告诉你这个需求”等类似的问题。