开发者社区> 狼人2007> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

艾伟也谈项目管理,解读敏捷需求分析五大关键因素

简介:   大多数学计算机语言的人都会有过这样的感受,过去一直认为编程和架构是整个软件生命周期里最了不起的部分,但实际工作后才会发现在商业产品里,需求分析才是一个商业软件成功与否的关键。   放眼望去,在当今软件工程领域出现的许多问题,诸如缺陷及资源运用不当,都源于需求的不清晰,甚至有软件人戏称:“需求变更乃万恶之源”,一时也获得了颇多响应。
+关注继续查看

  大多数学计算机语言的人都会有过这样的感受,过去一直认为编程和架构是整个软件生命周期里最了不起的部分,但实际工作后才会发现在商业产品里,需求分析才是一个商业软件成功与否的关键。

  放眼望去,在当今软件工程领域出现的许多问题,诸如缺陷及资源运用不当,都源于需求的不清晰,甚至有软件人戏称:“需求变更乃万恶之源”,一时也获得了颇多响应。时至如今,业务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名开发人员是比较合适的。

  需求文档化与敏捷的平衡点

  至于用例和用户故事。按照敏捷大师Martin博客中的说法,两者都是组织需求的方式,只是目的不同而已,用例的目的是为了把需求描述清楚,而用户故事的目的是把需求分解成可用于迭代计划的单元。对应到产品级和项目级文档,用例是产品级,例如做咖啡机,不管有多少不同版本,有些核心功能是不改变的,这些都是产品级需求。而用户故事则是项目级,属于做完就扔的“抛弃型”。

  进一步理解的话,用户故事其实是一个或多个完整的业务场景,而用例是场景的抽象,一个用例里可以包含成百上千个场景。用户故事是基于开发思想的,不光要考虑业务,还要考虑如何实现包括工作量大小、任务分配、项目风险以及架构风险等多重因素。有人认为写用户故事是极简单的事,但在吴穹看来,现在有很多人都还在用功能点套用用户故事,显得不伦不类,而没有理解到用户故事的精髓。

  以ATM取款为例,正常流程是插卡、取钱、把钱拿走。这个看似简单的场景其实工作量很大,可以在整个流程中做一些必要的简化。有人认为既然用户故事是一个场景,那就把它变成一个场景步骤吧,于是就成了功能点。其实他们忽略了一点,用户故事还是一个简化了但还保证完整业务价值的场景。ATM取款建立用户故事会涉及哪些因素呢?取款是否需要输入密码?小额取款时能否取消密码输入的步骤?取钱后打印账单,查询余额等,在这里面哪些功能是风险级别高的,哪些需要与银行核心数据通信?这不仅涉及(功能)优先级的问题,还可以根据原则简化用户故事。例如可以考虑做一个用户故事,储户用不需验密的卡,限额是一千块,取几百块钱的时候,把去银行验证的过程取消掉。这种情形下很多时候都要考虑到账户的风险情况,这些都需要多方沟通。类似的用户故事简化的情形有很多,但这时一定基于黑盒方式来做简化。而在简化的过程中,考虑如何实现如何合理调整工作量提高效率,这些都是找(用户)故事的过程,也是一个白盒的过程。

  在实现上,除了强调快速交付或生命周期很短、业务模式高度可变的互联网、网游等项目,可以采用纯用例的模式,现阶段让(大型)企业IT项目全面接纳需求完全无文档化还是不现实的,更实际的解决办法是在文档化和敏捷需求分析之间找到一个平衡,一份需求用例加上用户故事,然后驱动开发这种方式,目前看来,这是现阶段更适合大型企业的敏捷需求实践模式。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
艾伟也谈项目管理,利用简单的一元线性回归分析估计软件项目开发时间
  引言       前两天一个朋友给我打电话,问我如何估计项目开发时间。对此我很诧异,问他以前他们是怎么估计的,他说以前基本都是大家开个会,大约都说说自己意见,最后负责人一拍脑袋,给出一个时间。不过这次遇到一个非常认真的客户,要求不但要估计出项目开发时间,还要明确说明具体的依据和估算方法,这下我这朋友有点犯难,才询问我。
1078 0
艾伟也谈项目管理,个人管理:写书之前应该回答的几个问题
  我在06年和一个同事写过一本Delphi入门的示例书籍Delphi数据库通用模块及典型系统开发,当时体会到了写书不像想象中的简单,基本上业余时间都没了,所以我之后就不想出书了,其中更重要的一个原因是,我还没有找到一本真正想与大家分享并且自己能写出来的书籍。
1110 0
艾伟也谈项目管理,对项目管理的几点认识
自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”,同一个问题站的角度不同,可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正。
813 0
linux内存管理2:内存映射和需求分页(英文名字:demand Paging,又叫:缺页中断)【转】
转自:http://blog.csdn.net/zhangxinrun/article/details/5873148 当某个程序映象开始运行时,可执行映象必须装入进程的虚拟地址空间。如果该程序用到了任何一个共享库,则共享库也必须装入进程的虚拟地址空间。
1012 0
艾伟也谈项目管理,敏捷教练的工具箱
  学习并不是简简单单的阅读和浏览,而是一个积累的过程,一个通过持续的学习,对自己的知识体系不断丰富、索引的过程。接下来我会从四个方面入手分享我的经验。   高质量的信息源和高效的学习   Google是一个很好的工具,通过它,我们可以找到很多很好的资源,但前提是必须先知道要搜索的关键字,没有关键字,就不知道该查什么。
1083 0
艾伟也谈项目管理,我的项目管理观点
公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面。我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得。
860 0
艾伟也谈项目管理,软件架构引言之项目管理的问题
  软件架构引言之项目管理的问题     很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?     不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是“进度拖延”。
1009 0
+关注
狼人2007
个人对技术的追求:代码少而精捍;思路清晰美观;可扩展好维护;技术驱动商业; 人生格言:只要你有信念,有追求,并且坚持,那你一定比随波逐流,行得远行得正...
3523
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载