敏捷软件开发的神话之一在于它不需要文档，或者说文档并不实用。确实，可工作的软件胜于文档是敏捷宣言的核心价值之一。但是，注意句中的“胜于”一词。宣言并不是说不需要文档，而是说比起文档来说，可工作的软件更好。它的目标在于去除系统中的糟粕，取其精华来提升其价值。
如果你的团队还在创建冗长的文档来介绍软件，并且你仍在为按时发布软件以及不超出预算而挣扎，那么问一下自己这个问题：“文档带来的附加价值是什么？”这个价值问题是敏捷以及精益思想的必不可少的部分。丰田普及了精益思想，精益思想在许多工业领域也被广泛采用。它的前提是从系统中消除损耗，并且着手于研究其实质——它需要什么从而给客户带来价值。它同时也通过关注自我组织以及自我纠正团队的方式来提升系统中的质量和效率。
敏捷需求定义和管理的理念并不是新的。然而，努力找出如何将传统的需求周期去适应敏捷框架仍然比较复杂繁琐。对于一个可工作的系统而言，团队需要考虑到整个生命周期，而不仅仅是软件的开发部分。如果你在公司内从高层做起，分析那些为了完成编码而正在被撰写的文档，你可能发现超过50%的文档并未被使用过。那么为什么我们还在创造浪费？
有这样一个与复杂度系数相关的观点。当一个系统开始变得成熟的同时也开始变得越来越错综复杂。理解，组织，管理和维护这些系统逐渐变得困难。人们倾向于向系统增加更多的东西来帮助弥补缺陷，创建协议来维护控制系统。而当组织进行调整，规章制度以及企业气候发生了变化时，系统也必须适应其变化。这导致了系统的复杂性成倍的增长，直到它很难正常运转，或者说甚至无法工作。就此而言，这恰好解释了为什么最好的系统或者产品，是简单的，流线化的。这正是精益思想里提到的为什么要去除系统中损耗的原因所在。需求定义和管理与复杂度系数的脆弱性没有什么区别。这正是为什么有时候公司在完成了几百页的需求说明书后，但却极难实现和管理的原因。
如果你正在考虑采用敏捷，并且打算运行一个相对简洁的操作，你必须对组织架构有一个全盘的看法。敏捷中的需求定义需要通过单独的视角来看，而不是纯粹的和开发团队一起来看。然而在敏捷软件开发中同样的原理也可以运用到需求定义和管理上去。下面让我们通过一个简短的用例来看它是如何工作的。
如何工作 —— 在Scrum中，它不起作用
当前最受欢迎的在使用中的敏捷框架是Scrum。另外其他的框架，还有XP，Crystal以及Kanban等，但由于Scrum是最常见的敏捷框架，所以我们通过他来做演示用途。（但是这里有一点重要的提示，这些框架中，有一些是可以结合使用的。例如，在Scrum中可以结合部分的Kanban，通过限制进行中的工作来控制团队能力上的约束。）
Scrum允许开发团队基于2周到4周或者sprint的基础上来逐步构建软件（参见下图1）。需求在sprint开始之前就被输入到产品待办列表；通过sprint计划，需求被分为sprint待办列表项。基于团队的需求和策略，开发团队开始讨论在给定的sprint里需要开发哪些内容。工作项目由product owner从产品待办列表中拉过来，并且进行指导，由ScrumMaster进行过程控制和管理。工作的目的在于确保他们满足了产品待办列表，以及可以支持和描述在sprint开始之前，开发团队需要构建些什么内容。
有这样一个问题，大多数的团队都努力试开发与其保持步伐，但在产品待办列表中他们没有细节定义的正确度来适当地关联开发的sprints。
图1：Scrum/Sprint
敏捷需求定义和管理的介入
通过赶超开发团队速度的方法，人民专门设计了敏捷需求定义和管理来解决这种问题。换而言之，以比开发团队撰写代码更快的速度来满足产品待办列表。这个框架可以适用于及时的需求定义或者创建一个需求资料库以便于将来的使用。不管在哪种情况下，如果一个团队正在使用Scrum，那么他们就是在从产品待办列表中获取工作。由于产品待办列表是工作的“待办列表”，因此填写待办列表所需要的时间取决于Sprint的时间范围。它的目标在于确保其业务（尤其是对product owner）能够清晰准确地表达什么需要被构建，以及定义什么是需要高质量的。为了实现这个目标，需求周期保持以领先两三步的速度遵循类似Scrum的过程来反应开发周期（见下图2）。其目的在于创建一个可以及时反复并且注重质量的过程，通过这个过程在一定程度上，需求可以被完全的检查，组织以及表达。
图2：敏捷需求定义和管理
这一切从确认和填写需求待办列表开始。这种类型的待办列表是为了完成产品待办列表而定义的项目清单。它的终极目的可能是用户故事，可视化，功能上的需求等等。通过需求规划及优先化，需求团队在商业策略和对象的基础上，决定哪些需要被定义以及构建。与开发团队相同，需求团队设计他的sprint，执行工作以及评审其输出结果。如果输出结果满足预期结果，那么它们可以被移到产品待办列表。在许多情况下，团队需要创建文档来通过某些“关卡”，或者组织的里程碑。这些项目同样可被放入需求待办列表，但是他们不能最终放入产品待办列表。取而代之的是，这些文档通常会成为开发团队的参考材料来使用。这就是可追溯性——从产品待办列表到任何外部文档在建立项目的连续性上变得越来越重要。
分解
需求定义和管理的另一重要部分被成为分解。分解是个过程，通过这个过程，产品待办列表被表达和改善，从而协助开发团队来进行工作。我们可以通过几种方法来运用分解。一种是建立一种合作的文化，在需求阶段就融入开发团队，从而完善产品待办列表。在Scrum中，这就是通常所指的“梳理待办列表”。
另一种方法是将分解与交付，推迟时间，或者三者同时联系起来使用。一些项目经历告诉我们，在需求被定义好到开发开始进行工作这段期间存在时间间隔。有许多理由可以来解释它发生的原因，但需要重点指出的是，它的发生是定期的。需求定义和开发间的时间间隔越长，开发正确的产品而产生的风险也越大。时间间隔越大，团队内重要成员，知识以及团队飞可利用率流失的风险也随之提升。在这种情况下，我们可以通过产品待办列表来交流和分享需求，从而利用起这些空隙时间降低这些风险。
敏捷正在迅速地成为最受欢迎的开发软件方式，因为它有助于持续的改善，限时的开发周期，以及能够更快地向终端用户提供价值。通过需求的质量和清晰度从而满足软件开发的过程，这个价值会被提升到很大一个程度。以敏捷，精益，因应时需为出发点有助于确保过程的优化。
在当今的市场上有许多种敏捷可供选择，在本文中我们已经讨论了一部分。其重点在于找出什么适用于你的团队，然后开始着手于试验。你钻研尝试想使工作变得更敏捷的速度越快，那么你看到它为你所带来的利益也越快。
