敏捷过程中的需求分析.docx

【摘要】 在日趋激烈的电信业竞争态势下，持续而快速地发掘和响应商机成为新的课题。 作为响应机制中的关键环节，需求工程应用 敏捷过程方法，以关注商业价值、快速响应、持续迭代的特征来应对变化和难 测的未来，是尝试提高组织敏捷能力的核心。在这其中，作为沟通桥梁的 需求分析 同样可以应用敏捷的过程方法参与到生命周期的演进。敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面 展现其不同传统的特性。本文将结合电信业背景及企业实际情况，对敏捷需求分析作出初步的探索。 1、敏捷需求分析：电信行业背景与敏捷过程的需要 从中国电信行业 ITSP 战略推出至今， 数年中我们已经看到了明显的变化， 作为其信息化体系落地的 C TG-MBOSS ，也已初具规模和成效。大规模实施的下一个阶段，将是在商业价值引领下的重构竞争模式、 市场细分，以及作为支撑的需求深入研究。在项目实施过程中，各种挑战和困难纷至沓来， 项目管理 者不 管是做时间、成本、质量的三角平衡，还是人与技术的双向选择，始终无法绕开的一个问题跟源是：如何快速响应环境的变化，使客户在优化的体验过程中满足其商业目标，从而实现企业本身的价值？ 用失控的过程膨胀来形容近 10 年的许多软件公司的情形是很合适的。 虽然有很多团队在 工作 中没有使用过程的方法，但是采用庞大、重型的过程方法的趋势却在快速增长，在大公司中尤为如此。但现实的发 展确与此不相同步， 竞争态势造成了更多的不确定性和快速调整的机会。 从近年 ERP 上线的平均速度来看， 项目的交付时间都比较长， 这让用户产生了顾虑。 但实际上软件上线仅仅是一个软件生命周期早期的阶段， 软件的价值是在使用中体现出来的，其投资回报也只能在后期的运营得到完成。未来的变化如同纳西姆？ 塔勒布的黑天鹅一般不可预测且重要，已知和过去琐碎的重复并不足以预测未来的重大影响。以预测性度量为控制基础的过程模型，只能以经验涵盖一般性事件，所以与此同时，随机应变，保持快速集成和持续改进以应对商业环境的不确定性，延长软件的生命周期提高它的最大价值，从而为获取更多投资回报提供保障，也成为软件工程发展的必然。 敏捷过程（ Agile Process ）的主要优势是能够适应系统需求的不确定性，将客户作为需求团队中密不 可分的成员， 而在实现过程中尽量在最短时间内实现对用户来说业务价值最大的需求； 同时， 敏捷开发 （A gile Development ）是一种面临迅速变化的需求快速开发软件的能力， 它帮助处理了未来不确定性的问题； 但是对于过去，应该没有不确定的事。而敏捷需求分析，是面对迅速变化的商业状况，提高其响应和组织 成可理解和接受的需求说明并对敏捷开发作出能力保证的方法论。 2、敏捷与过程改进和度量模型 从软件工程发展起，过程改进在全球日益得到重视， ISO 9000/SW-CMM/CMMI 各级的评估也在业界得以推展， 这种氛围下， 以 RUP 等为代表的过程模型也得到了广泛的应用。 但与此同时，敏捷的论调却异 军突起，方兴未艾。软件过程的多样性，源于过程环境和层次的不同；而过程选择的多样性和 CMMI 目 标的通用性决定了过程改进途径的多样化。 运用一系列重方法，将在应对商机方面造成挑战；尤其是在企业的管理考核和过程模板仍更多的是一种瀑布式体系下，软件的实现过程将在不同模型下摇摆却显得不那么灵活。一个合适的生命周期模型选择 是重要的，由于惯性的教育，瀑布在我们的工作环境中随处可见。但如果不去分析 CMMI 等的实质，将无助于改进这一点而提高响应。 强调结构化方法与重型的管理策略， 往往在内心中拒绝变更， 把变更作为被管理甚至被 “管制 ”的对象； 而为了尽可能避免变更，常常要求开发之前的需求获取、分析与定义要完整无误且精确。这是一种理论上 的理想状态，尽管我们可以采取诸如 CMMI 的一些理念及过程改进模板对其管理，但实际上往往会出现与 用户商业价值要求的脱节；而为达成此目标，使得前期的需求开发工作变得小心翼翼，最终有可能在压力与时间约束下难免简单化而草草了事，在后期又不能得到及时的修正，从而形成一个隐患。 但实质上，重型、轻型过程方法论之间并不存在根本性的矛盾冲突，这体现于它们最终理念和出发点 的一致。 把这些互补方法论拼在一起， “恰好可以发现整个软件过程体系全貌的一部分 ”。CMM/CMMI 中不包括更为具体一点的如何写好需求，如何做好设计，如何写好 测试等许多方面的软件工程技术、技能方面 的指导，而这些恰好是敏捷的强项。敏捷方法整合了一套轻量的管理、过程和工程技术方法，这是它作为 一种先进方法体系补充于 CMMI 的地方。敏捷过程并不像业界所传的那样只适合小项目和新项目的研发， 实际上它对于各种类