CMMI与Agile敏捷开发比较之二:需求管理篇(兼谈用敏捷实现和满足CMMI的ReqM过程域)
发布日期:2021-07-13 12:12:20 浏览次数:2 分类:技术文章

本文共 3832 字,大约阅读时间需要 12 分钟。

作者:陈勇

出处:blog.csdn.net/cheny_com 

 

这是CMMI与敏捷开发比较系列的第二篇(,,之三)。

CMMI

 前面在提到CMMI与敏捷的根本差异时提到CMMI是美国用于筛选其供应商的,而其项目的特点也在于大型团队/强分工/长周期,这样就不难理解CMMI为何提出了以下要求(基于CMMI V1.1):

  • GP1:管理需求
    • SP1:与客户达成一致理解
    • SP2:取得开发团队的承诺
    • SP3:管理变更
    • SP4:追溯不同层次的需求关系
    • SP5:追溯需求与后续工作的关系

笔者之前做过一些军工项目,所以对军工项目有所了解,以下这些词汇在军工项目里边是非常关键的:甲方乙方,系统工程,预算,结帐,多个供应商联合开发,集成,验收……因此: 

  • SP1/SP2带有很强的甲方乙方买卖的色彩
    • “一致”“承诺”是在买卖合同语境下无奈之举,在外包环境中无论做法如何都是必要的。
    • 不应在企业内部开发中也过度强调,比如在自主研发中实施产品经理/开发团队签字等“仪式性”举措。
  • SP3/4带有很强的系统工程的色彩
    • 就是每个项目多半是一个软硬结合的大系统(比如一种型号的飞机),很少有一家企业能完全包揽。Telelogic有一个工具叫做DOORS,其主要客户群就是制造业(包括军工),其核心思想不是敏捷中的那种条目化的需求分析及跟踪/优先级排序(也有),而是系统需求逐级分解/层层对应:整架飞机可能十年前设计的,但今天组装起来,不少一个零件,不多一个零件。在大型系统工程中,按部就班地完成事先预想保证项目成功的必要性远远超过创新性(尤其是飞机已经定位好了,但几个程序员在开发过程中因为“被激励”了所以想进行创新……这在军工项目里边是不可思议的,他们应该以更受控的方式参与创新)
    • SP3突出了在跨企业研发的语境中,一个变化应该被多个可能受到影响的企业理解和实现
    • SP4则突出了多个企业开发,却“不多一个零件,不少一个零件”
  • SP5也带有系统工程的色彩
    • 阿波罗计划有2万家企业的30万人参与,11年完成,这里边就有一个“他们在干什么”的问题,以及“他们能按时完成吗”“有没有漏掉什么需求”的问题

从这一点看,在大型系统工程中,CMMI作为其“神”而存在是很恰当的。尽管有很多人强调军工/航空航天也能应用敏捷开发,但这和Intel说自己参与了奥运会因为奥运会用了Intel Inside的电脑一样,只是“形”和配角而已。笔者认为推广敏捷开发的同好们不应该追求这种虚荣,而是应该在自己擅长的领域先把事情做好。

另一方面,如果实施CMMI的企业并非处于上述语境中,应该恰当地选取适合自己的实践。

 

敏捷-Scrum与XP

仅从需求管理的角度看,可以排一个顺序:CMMI-Scrum-XP,越往前越强调可追溯性/一致性,越往后越强调创新型/灵活性。这个倒没有好坏之分,而是我们想要什么的问题。

Scrum中对需求管理的解决方法与CMMI的要求很相似。注意这里的用词:对Scrum,是一种具体解决方法;而对CMMI,是一种要求。不过CMMI的要求还包括一些GP(Generic Practices通用要求,主要包括计划,角色与技能,记录,对记录的管理等内容),因此不能认为实施了Scrum就满足CMMI的需求管理了(满足CMMI3的含义就是:如果没有别的限制,任何时候都可以参与美国国防部招标了)。

 

下面是用敏捷方法来满足CMMI要求的一些对应。

  • GP1:管理需求
    • SP1:与客户达成一致理解
      • 敏捷对需求的理解,较少提到合同的死条文。敏捷假设你已经告诉我你的商业价值,而我正是要交付这些价值。
      • 在Scrum中未提及太多与客户进行需求沟通的过程(这个不等于Scrum要求“不要管理与客户的需求沟通”,只是“我不管”的意思)。在XP中提到了现场客户的解决方案,不过XP的提法不涉及需求的范围这个至关重要的因素,而是更关注要实现的需求是什么的问题。之所以有这个“明显的失误”,是因为敏捷的创始者(们)绝大多数并不负责与客户洽谈合同,当他们开始介入工作的时候,项目已经进入“遵循(一个令人无奈的)合同”的阶段了。
      • 因此在使用敏捷的时候,不能持有“我们已经用敏捷的方法管理与客户的沟通,所以一切应该万事大吉了”的观点,应该补充对需求范围的管理,尤其是在甲方乙方的语境中。需求范围的管理应该基于商业心法,而不是开发心法,在这一点上澳大利亚(SouthenScope方法)/韩国(软件成本估算标准-知识经济部公告)/日本/芬兰都有相应的法律和条文,大致都基于IFPUG或NESMA功能点分析方法(FPA)。
      • 具体应用方法:
        • 使用XP的现场客户时,应配合Scrum的PO制度,也就是说由于甲方(也包含内部的甲方)很难找到一个高度足够,而又能天天处于现场的代表,极有可能导致产品在最终验收时被推翻。引入PO可以缓解现场客户的局限性,尤其是如果建立PO团队,可以有效避免现场客户个体的局限性。
        • 即使使用现场客户,定期利用Scrum中的评审会,引入客户(含内部客户)的高层参与,保证大方向不偏。
        • 如果在甲乙方的语境中,评审会应留下纪要
        • 应该配合早期范围管理,防止需求开发的过程变成需求蔓延的过程。请关注“早期软件成本估算”这个词汇,未来两年中将会出现面向政府行业的中国的一系列国标,也适合其他行业。
    • SP2:取得开发团队的承诺
      • 这是Scrum和XP尤其前者做得很好的地方,即通过计划会来取得开发团队的承诺。
      • 值得注意的是承诺包含两部分,一部分是理解了要做什么,第二部分是要花费多少工作量。因此在缺少充分沟通的情况下,简单地由开发人员提交一个估算清单是不行的。
      • 具体应用方法:
        • 应确保使用Scrum中的共同估算制度,也就是说承诺是一种在充分理解、集体智慧下的产物,而不是给你一个清单,填多了算你赚,填少了算你赔的赌博。
        • 为承诺划定“模糊界限”,也就是使用MoSCoW方法,用一种透明的管理方法平衡冒险、保守、缓冲、激励……等各种矛盾因素
        • 承诺的变更管理,既然承诺=理解+工作量,理解变了,承诺就相应变了。
    • SP3:管理变更
      • 先说一下管理变更的心法,所谓心法,就是做一件事情的时候心里所想的事情。如果变更过程中心法如下,则任何技术管理方法都无解:
        • 甲乙方语境:甲方-不用加钱把这功能加上;乙方-价钱工期已定,千万别变
        • 内部研发语境:高层-加上这功能但工期别变;乙方-工期快到了,千万别变
      • 敏捷既拥抱变化,又迭代期内无变更,其实在一定程度上默认改变了上述语境(但历来敏捷相关文章中都没有说破)。
        • 拥抱变化在于如果你感觉变化有价值,又愿意为变化付出,开发团队乐意效劳。因此不能理解为无条件的拥抱,尤其在甲乙方语境。
        • 迭代期内无变更在于项目(产品)是有其商业目标的,迭代期内无变更表明在迭代前,应该从商业目标出发做出版本计划,从而保证大家不是跟着某个人的脑子在跑而是跟着商业目标在跑。因此如果PO在之前不正确理解商业目标做出计划,而是认为可以随时变化,是对开发团队工作的不尊重,也迟早会造成项目/产品的失败。
        • 关于以上两点另有两篇博文详述。
      • 具体应用方法:
        • 应配合早期需求范围管理方法(参考SP1中),防止变更过程变成不受控的蔓延过程。
        • 应建立长周期的商业目标和版本计划,要变化的是怎么实现,而不是实现什么。在无框架约束下进行变更,是一件非常危险的事情。
        • 应使用MoSCoW方法,平衡变更与承诺的矛盾。
        • 在甲乙方语境下,变更管理应以商务人员的意见为主。
        • 如果是采用XP方法,应引入Scrum的PO制度。尤其是在甲乙方语境下,PO必须是基于企业(供应商)利益思考的,而不是甲方派来的打着“追求客户价值最大化”招牌的卧底。
    • SP4:追溯不同层次的需求关系
      • XP中提到的史诗故事-用户故事较好地支撑了这个实践,不过这个和前面提到的系统工程中的需求拆解不是一个概念,两者目的和颗粒度差别很大。
      • 具体应用方法:
        • 在产品研发语境中,应基于目标客户群(用户建模)和商业目标来导出产品的需求条目和结构,也就是所有功能最后都多少地被某些客户经常使用,并因此促成了采购。有很多产品不断升级但却没有人购买新版本(比如多数人都在用7年前的2003 Office,和更早一点的XP操作系统),就是因为缺少代表产品之神的上级需求;可怕的是无论有没有神,任何产品都能找到需要升级的功能。
    • SP5:追溯需求与后续工作的关系
      • XP中的TDD和持续集成与此非常相关,因为每次测试和集成,都是对某些需求满足情况的验证和证明。
      • Scrum中提到PB的颗粒度较大,到SB中需要拆解为具体任务(也有观点说不拆解的,下详),也支撑了这个实践。
      • 具体应用方法:
        • 面向用户故事(或者说用户价值,用户需求,PB)来进行迭代评审,而不是开发任务。这也是笔者整体偏向在SB中直接使用PB中的故事而不进行任务拆分的原因,因为一旦拆分了任务,极有可能任务全都完成了,故事却不能交付。

其他说明

 CMMI中的GP的满足,敏捷中较少提及(也没有必要提及),比如所需的技能是否有培训等;如果正好在做CMMI,请做好相关记录。

这些GP并不是说不做项目就不能成功,产品就不能热卖,只是说作为美国国防部(DOD)选择供应商,或许Google转身很快,或许IPad很热卖,但我还是很想找个稳当点的公司来造飞机。

这不是方法论之争,只是商业目标造成的价值观差异而已。

 

点击下载免费的敏捷开发教材:《》

 

转载地址:https://blog.csdn.net/cheny_com/article/details/6524447 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:[视频]怎样提升asp.net mvc 软件的性能 - 微软免费视频Improving ASP.NET MVC Application Performance
下一篇:IT人员及程序员怎样学好英语(关于如何利用极其有限的时间和条件学好英文)

发表评论

最新留言

不错!
[***.144.177.141]2024年03月05日 02时53分41秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章

mysql期末考试时间2018_2018年9月计算机二级MySQL考试巩固练习题(6) 2019-04-21
vnc 字体设置_安装和配置VNC 2019-04-21
java io封装_Java程序员开发面试宝典之Java IO篇 2019-04-21
java 复制一段对象集合_java 日志脱敏框架 sensitive-新版本0.0.2-深度拷贝,属性为对象和集合的支持... 2019-04-21
java反射测试方法_Java反射知识重拾 2019-04-21
sqlplus中怎么导入java类_oracle调用java方法的例子(下面所有代码都是在sql/plus中写)... 2019-04-21
摩托罗拉v3java_拆一代超薄经典手机-摩托罗拉V3 2019-04-21
java调用asp.net webapi_ASP.NET Web API编程——客户端调用 2019-04-21
k近邻算法python解读_机器学习(K-近邻算法)Python的基础知识 2019-04-21
java timer并发_Java并发编程笔记之Timer源码分析 2019-04-21
java项目事故_记录 Linux环境下java web项目CPU爆表 “事故”,肇事者:GC 2019-04-21
mysql 存储过程 select insert_存储过程执行select与insert同一个表sql语句 2019-04-21
java声明变量保存性别_java第二次课变量第一次上机 2019-04-21
js装修计算器java代码_JavaScript代码实现简单计算器 2019-04-21
功夫传人java_PAT L2-020 功夫传人【BFS】 2019-04-21
联机侠控制台JAVA_联机侠控制台常见问题 | 我的世界 | MC世界侠 2019-04-21
2018转行的java学习_2018java平均工资,想转行学java的快点上车 2019-04-21
glade java_如何在Java Gnome / GTK程序中使用Glade UI(.glade文件)? 2019-04-21
java 常用数据库_java连接常用数据库 2019-04-21
sublime php运行环境_【转载】Sublime Text 3设置吊炸天PHP开发环境 2019-04-21