010-82146680
首页
 

联系人:陈老师

电   话:010-82146680

E-mail:bscea@bscea.org

地   址:北京市海淀区上地信息路11号一幢三层西309室

 

技术文章

敏捷与功能规模——整合项目与产品

点击:时间:2018-10-16

  在这个行业里混迹了很多年,最近这几年我一直在想个问题:软件到底是什么?应该归类为——科学?工程?还是艺术?
  最近看了西班牙软件专家Albero先生在MetricView杂志上的一篇文章——《敏捷与功能规模》,开篇就说道:尽管软件行业总是能够发明和创造一些新的技术,但是归根结底可以将其归属为艺术。比尔盖茨也曾经说过:软件是艺术与工程的伟大结合。
  这篇文章给了我很多启示,我大致地给国内的朋友们介绍一下,并不会完全依赖于原文,同时也会夹杂一些我的感想。                                                                                   
  怎么体现软件的艺术性呢?假设,有两个软件产品拥有相同的功能,表面上看来没有差别,但是内涵却截然不同,肯定其中有一个的性能更好;维护费用更低;用了更少的代码行;有更少的缺陷和风险。总之,有一个软件相比较会做得更加“艺术”。
  软件是否艺术,取决于以下几个因素:
  开发团队的技术知识;需求的质量;开发团队和管理团队的“常识(common sense)”。
  在英文世界里,common sense,是个魔力词组。从公元前300多年,亚里士多德就开始思考,直到2000多年后的今天,很多人还是不能够理解其哲学思辨。

 

亚里士多德.jpg

 

  这几项要求有时候很简单,有时候也很难实现。
  如果在开发的过程中,团队从技术视角来做决策和行动、存在狭隘的利益冲突、缺乏知识、存在大量的灰色概念。软件产品很有可能就沦落“平庸”。
  这一点,其实国外的专家讲得还比较“乐观”,在国内,我们经常可以看到“这根本不是我想要的”场景。尽管这些软件已经“发版、上市、交付、验收”了,但是从某种意义上来讲,它们甚至都不能被称之为产品。
  很有挑战性,也很有必要,我们要升级自己的观念,那就是要给“常识”增加一个定语——“卓越的常识(common sense excellence)”。
  其中一个卓越的常识,其实在国内也不陌生,那就是要将目标SMART化。
  软件开发和管理团队的目标——给用户、客户提供质量最好的产品;客户(外部客户,或者是内部客户)的目标——以最好的价格收获最大的价值。
  这些目标就需要SMART(Specific明确,Measurable可度量,Achievable可实现,Relevant相关性,Time bound时限性)。
  其中的这个M,就是度量,是一切科学管理的基础。这也是本文所要讲述的重点。
  那么我们应该度量什么呢?
   IT项目只是个“一次性”的过程——我国有很多的PMP,对这个常识应该是不陌生。而IT的产品才能够给客户提供战略价值,或改善流程(更快、更便宜)。
  所以,我们应该度量、监控的目标应该是产品,而不是项目。这个常识,国内了解的可能还不多。

 

敏捷——项目管理领域里春天的故事

  2001年的2月中旬,在美国犹他州的“雪鸟”滑雪场,17位软件开发的思想者(thinkers)发表了著名的《敏捷宣言》。其全称应该是“敏捷软件开发的宣言”。
  这个敏捷宣言,也是一个“卓越共识”。总所周知,宣言里包括了十二条“原则”。
  仔细分析这些原则,其本质也是要强调:给客户提供价值。(我们的最高优先级就是确保客户满意——通过尽早并持续地交付有价值的软件)产品一定要满足用户真实的需要(needs),要做正确的事情,同时也要正确地做事,在所有的层面都要步调一致……
  从“卓越共识”的角度来看,这个宣言其实并没有什么新意。但是有时候,尤其是我们困惑于的项目具体问题中,这些语句还是能够给我们指南的。
  无疑这些年来,敏捷给项目管理领域带来春天。国内也是有越来越多的企业在尝试。但是其给我们带来的价值,很少有组织能够度量、统计。
  这里还是要插一句,我以前看到的一个数据是:美国著名的IT咨询公司——Standish,从1996年开始,在每年的报告中都发布关于项目成功率的统计信息,在随后持续超过20年的时间内,虽然IT技术以及软件工程方法日新月异,但IT项目的成功率一直徘徊在40%左右。也就是说,敏捷并没很好地拯救IT项目管理领域。

 

要清楚4个概念

  我们一定要清楚地分清两个概念:项目、产品,并且分别对其进行正确的管理和度量。尽管这个管理思想本身很简单,但是无论是大公司还是小公司,也无论中外,在实践中做得都不是很好。几乎所有的度量工作都集中于项目,甚至是合同。
  客户要实现一个IT解决方案、产品、或者是增强包,可以与开发团队签署不同类型的合同(固定总价,单价,成本加成)。而开发团队既可以选择瀑布模式,也可以进行敏捷。所有这些工作都不会影响到最终产出物——产品。
  只有IT产品,才能过为客户提供价值,并且核算最终的“有形成本”(可能包括了多个项目、多个合同、多个供应商、多个开发团队的费用)。
    另外两个重要的概念就是:工作量与规模了,对于这两个概念就很少有人混淆了。也许是因为两者之间的相似性很小,当然了,很多人都会有个误区——认为规模越大工作量越大,反之亦然。
  无论是国外,还是国内,几乎所有的项目都会管理工作量,但是很多项目都不会去管理、度量规模。

规模.jpeg

  在敏捷中,经常使用“故事点”来度量规模,并计算软件开发的工作量。故事点方法最大的问题就是太“随心所欲”(arbitrary)——从某种意义上来讲,这也是此方法的优点,相比较于“功能点”方法,学习成本、制度的管理成本要低很多。
  但是,也正是由于这个特点,同一个公司的两个不同团队,对于同一个故事,会估算出不同的故事点数量。尽管如此,这种方法对于独立的故事而言,还是能够起到估算、计划、跟踪的作用。
  国际著名的软件工程专家Caper Jones曾经总结出“软件度量的十三条准则”,故事点方法最多只能满足其中的四条。这个方法不能标准化,非常含糊其辞(容易引发歧义),不足以发布组织级的数据(例如:生产率),不适用于其他的新项目或历史项目,不能转换为其他相关的度量数据,不能适用所有的产出物,不能够支撑所有类型的软件,也不支持重复使用。
  无论是敏捷的度量,还是传统的度量,都可以为我们打开“产品度量”的大门。如此度量得出的数据,可以作为其他战略性度量的基础。
  相同的IT产品其“规模”肯定也是相同的,而不管是其创造的过程是敏捷,还是瀑布。也不管是用什么的合同类型。如果有可能,我们倒是可以做个对照试验,用不同的项目管理方式打造相同的IT产品,比较不同项目的进度、成本、质量等特性指标

 

完美的结合
  在敏捷的项目度量中,使用ISO标准的“功能规模度量”来度量产品,将会是一个完美的结合。
  实际上,客户接收、使用的只是产品,而不是项目。
  就像是我们去超市(电商)买东西一样,我们要预先分析一下:产品的质量、价格、品牌等等特性,但是我们几乎不关心生产厂商如何管理内部项目,使用什么样的设备和工具。这些本身也是“黑箱”。
  作为客户,我们更应该关注、度量产品的功能、质量、价格。对于某类的商品,我们还会比较单价——每平方米、每升、每斤。
  我们买一些标准的软件产品,也是如此。但是,对于一些“非标”的软件产品,作为用户、客户的我们,为什么要去纠结项目的度量?而不是产品本身的。
  这里,我要补充一下,无论是买软件还是其他东西,首要关注的还是——产品功能以及应用场景,是否能够满足自身的需求。
  国际上有5个关于“功能规模度量”的ISO/IEC的标准,这5个标准表面上是竞争关系,但实际上,互相之间有着较强的联系和互补。
  在使用这些ISO的规模度量方法,我们应该有意地去忽略项目的概念,而更加关注于(内部/外部)产品本身。一个产品,可能由不同类型的项目生成,但是规模是固定的。也就是说,产品的规模,与项目的类型没有关系。
  将产品与项目的管理信息结合,我们将得到、推算出更有用的信息。“产品所有者”(product owner),企业的高层管理者最关心的也是这些内容——产品的收入和成本。
  敏捷项目管理度量,比较于传统项目管理,可能有自己的节奏和目的。很多人会出于种种目的,将敏捷度量搞得于传统项目度量大相迳庭。
  但是无论如何,敏捷其最终目的还是产品。产品要被度量,产品的规模、质量、生产率和价格等指标,也都是与项目、项目集独立的。
  敏捷只是项目管理领域的一个“常识”,而不是一个独立的“生态”。
  最后,说下我的反省——
  第一点:目前,在我国的IT领域,是否也是有点重项目而轻产品?就拿度量这个事情来讲,在国内做得最好的金融行业里,度量的也大多是与项目管理有关的指标。
  第二点:我国很多传统的IT应用领域,无论是甲方还是乙方,还没有开始意识到IT项目度量的重要性,而国外的企业就已经要将管理的重点转移了。(本文版权归北京软件造价评估技术创新联盟所有,转载需标明出处)

相关新闻
 
关闭
010-82146680