敏捷需求分析

今天与范同学偶然聊到点感触... 记录之

敏捷采用的迭代式需求分析带来的好处已经不言而喻。迭代式需求分析首先引入项目快速启动，确定整个项目的范畴和相对模糊的系统架构，然后得到熟知的Master story list. 在随后的迭代过程中，需求被逐步细化，直至精确的描述用户商业价值。迭代分析过程也是不断帮助用户探索商业模式，寻求商业价值的过程。用户基于已经发布的系统提出反馈，变更需求成为了可能。

但在实践过程中，我们也看到被很多团队滥用。这并不意味着迭代式需求分析存在问题，迭代分析的前提是，假设需求是无法一次并且准确的确定，为规避前端预测型分析思路带来的风险而不得不采用这种模式。一些密切结合实际商业环境的项目多是满足这样的前提，例如商业网站 。

但是，对于项目前期就能明显确定需求的项目，是否一定要采用迭代方式？答案显然是否定的。对于需求变更，我们采用系统重构来解决，但重构总归会带来修改系统的成本，比如变化架构，修改数据等，如果能够一次性确定准确的需求，大可不必一定要放在后期迭代。纵观所我所经历的项目，这样的项目还真的不少，比如基于电信计费的数据平台，数据仓库架构的报表和数据挖掘系统，尽管这些系统还是有需求变更，但变更规模很小，前期分析的准确度还是相当的高的，在成本和风险的权衡中，风险已经不能成为问题。

以前也有过很多关于瀑布模型和敏捷项目开发的讨论。常有这样的说法：瀑布模型未必不能带来项目的成功，敏捷开发也未必能保障项目一定成功（这是一个巧妙且安全的说法）。一个成功的项目需要有很多种因素，人，团队，客户，技术，资源，商业环境，业务模式，合作方式，等， 而失败的项目只需要破坏一项因素就可以了，又一次验证木桶理论！那如何决定你用瀑布模型，还是迭代式方法？其中之一就是对项目性质的了解， 对于需求原本就明确的项目，对于建立在稳定的组织流程上的项目，在快速启动阶段多做些精确需求性质的工作也是不错的选择。这样的项目多侧重技术和组织层面。而其他的侧重商业应用，市场行为的项目，多采用迭代式分析是必须的。

现在似乎进入了另一个误区：某些项目还是需要用瀑布模型来解决。并非如次！瀑布模型总归会逐渐体现它的弊端，而敏捷也并非就仅仅指迭代式开发。实践过程还得活学活用，书本会把敏捷包装成一个包裹，给读者的感觉是要么不用，要么全用。而实际情况多种多样，裁剪敏捷必不可少，择其适者而为之是团队和PM的职责，至于来源哪里，以前的瀑布？流行的敏捷？精艺思想？已经不再重要。

把应用敏捷当作照剧本演戏是不足取的！！