敏捷需求分析关键因素解读.docVIP

敏捷需求分析关键因素解读 大多数学计算机语言的人都会有过这样的感受，过去一直认为编程和架构是整个软件生命周期里最了不起的部分，但实际工作后才会发现在商业产品里，需求分析才是一个商业软件成功与否的关键。 放眼望去，在当今软件工程领域出现的许多问题，诸如缺陷及资源运用不当，都源于需求的不清晰，甚至有软件人戏称：“需求变更乃万恶之源”，一时也获得了颇多 响应。时至如今，业务IT间需求分析过程中存在的问题主要有哪些？什么是敏捷需求分析？产品级和项目级需求有何异同？敏捷需求分析方法论中的五大关键点是 什么？就以上热点话题，雅各布森中国区总经理吴穹分享了他的看法。 三大症状 在吴穹看来，两份需求、合同式验证、产品需求缺失成为了当前需求沟通的三大症结。 两 份需求——用户（业务）需求和软件需求。用户需求由不熟悉IT的业务人员完成，大多归于天马行空的意识流，基本上是想起什么写什么。而软件需求由IT人员 编写，经过技术思维的过滤、梳理、增删，包含进了算法、数据库设计、架构之类的技术专业词汇，业务人员往往已不知文档内所云。 合同式验证——业务人员和技术人员企图在沟通后以合同形式将需求固化并且确定下来，而没有充分考虑到软件开发过程中可能出现的需求变更。 产品需求缺失——项目是片段，产品是总量，两者的关系在于项目其实就是一个不断完善产品的过程。由于国内PMP（ProjectManagement Professional）和项目管理流行，更多IT需求都是以项目形式存在，而往往忽视了产品需求的积累，导致最后的结果多是项目（需求）很多，但产品需求缺失。 项 目级和产品级需求的具体区别，如果放在几年或十多年前并不明显，对于全新产品而言，项目（需求）=产品（需求）。随着时间推移，两者的区分逐步明朗，由于 全新项目越来越少，更多的需求都是在维护和升级老的产品。以咖啡机为例，从基本型升级到1.1版，或许是加入一个按钮。此时和客户沟通的时候就需要引导客 户想清楚，需要的是项目级还是产品级的需求，是做整个咖啡机的需求还是仅仅只是新添按钮的需求。如果未来再做1.2版，继续添按钮，这时候的需求又该如何 写？新按钮的需求，然后和以前的按钮有些变化。如果不能明确两种需求的差异，随着项目需求的累积，到最后会发现所有的（需求）都是片段的，都是增量而缺乏 一个总的全景。 事 实上，业务IT需求造成如今的混乱状况，CMMI（Capability Maturity Model Integration，能力成熟度模型集成） 和国内企业对CMMI的僵化理解可以说“功不可没”。在对“两份需求”的认识上，CMMI里有明确分项，用户需求和软件需求。但值得一提的是，其实里面并 未明确要求是两份文档或由两部分人来写，而只是表示需求细化的两个阶段。遗憾的是，很多国内CMMI认证企业也并没有真正打算去了解它的内涵，只是僵化地 表现出自己是否有这样的能力。 最近接触到一些项目也出现了这样的情形，大家先做了一份用户需求，然后花费大量时间写软件需求，以满足认证的需要，但到头来软件需求根本没人看，大家都只是应付，CMMI成为了摆设。 需求贯穿于软件开发测试全过程 在 吴穹看来，敏捷的最大贡献在于它是对整个软件工程的一次再认识。具体到敏捷需求分析领域，其实涉及到一个核心问题：是否承认（软件）需求可以在一开始就搞 清楚并确定下来？敏捷的答案是No！而在传统瀑布式开发中，更多的是合同式验证的情形，大多数客户的思想基础都是基于需求最初就能确定下来的。但事实上， 这在当前阶段基本属于“不可能完成的任务”，不符合软件开发本质。在敏捷需求分析中，需求应是贯穿于整个软件生命周期全过程中并在其中不断变更、迭代和完 善。 敏捷需求分析认为，需求应建立在以用例为中心的需求文档体系，采取协作式而非合同式的沟通方式之上。具体可分为五个关键点： ? 用例； 协作； ? 迭代，即需求不是一次最终确定，而是先完成主要框架，再通过迭代逐步精化； ? 整个过程中以分析为支撑，做需求同时也在做分析，分析模型的输出结果应跟需求分开； ? 把用例分解到用户故事，在整个软件生命周期过程中来驱动开发和测试。 业务/技术沟通频现“两份需求” 同 时还要考虑到的是，将两份需求改为一份文档，而不必死抠CMMI概念区分出用户和软件需求。首份需求稿将由SA（系统分析师）来牵头完成，负责各方协调和 沟通的工作。理想的情况下，整个团队在项目开始前就应搭建完毕，包括客户、开发测试人员都参与的写作和迭代，而不是以往的由技术人员对用户进行里程碑式的 教辅。通常来说，一个项目里一名SA同时对应5~9名开发人员是比较合适的。 需求文档化与敏捷的平