2022年敏捷开发绩效管理之1-11 .pdf

《2022年敏捷开发绩效管理之1-11 .pdf》由会员分享，可在线阅读，更多相关《2022年敏捷开发绩效管理之1-11 .pdf（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、敏捷开发绩效管理之一：序言及“敏捷开发是否考核个人”绩效考核“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C+绩效管理” 的搭配差不多。 但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量这和人们选择C+而不是C的原因还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理” ，而是“如何利用敏捷开发提高绩效”。何为绩效管理绩效管理常常被片面理解为绩效考核，即如何确定个人的绩效，如何提工资和发奖金的问题。实际上绩效管理还包含制定绩效目标，制定绩效计划， 制定配套的制度推动绩效

2、等等，当然也包括最后的绩效考核，以最终到达绩效持续提升的目的。上述内容在本系列中都有考虑，并根据笔者以往的经验和经历给出一些实际的案例供研讨使用。从一个经典问题看绩效管理的出发点绩效管理不是敏捷开发的要求如果能理解敏捷开发也不是瀑布模型的要求，敏捷开发爱好者们或许就会释然了绩效管理是企业管理的要求，是企业为了持续提升自己的绩效而采取的措施。从这个角度我们来看一个由来已久的问题：“敏捷开发是否考核个人？”很多人会脱口而出：“敏捷开发不考核个人。”但是如果再问“企业管理要求必须考核个人怎么办？毕竟工资和奖金不是发到团队总账户上的”估计再下去的答复，就只能说是闪烁其辞了。其实这也是一个伪命题，所以才

3、导致很难答复。下面一点点分析。企业绩效管理的目的不是为了考核个人，而是为了提升企业绩效，所以尝试考核个人的企业实际上在“利用考核个人提升企业绩效”尽管提升个人绩效会提升企业绩效，但勿入此牛角，因为前面有个尖 。因此这个问题从原始出发点来看，应该是：“企业是否应该通过考核个人来提升绩效？” ，那么答案就是： “敏捷开发有比考核个人更能提升绩效的方法”。不是因为用了敏捷开发就不能考核个人，而是选择了敏捷开发，就意味着已经选择了比考核个人更有效的提升绩效的方法，因此没有必要让企业管理和敏捷开发较劲，它们打不起来的。不过这个或者这些更有效的方法是什么呢？这就是本系列博文的主要内容。本系列博文将较多涉及

4、团队级别的绩效管理，内容包括团队管理的策略，个体管理， 团队的外部目标设定，如何分解到个人，不同团队绩效管理的差异，非物质激励等。另外一个高级话题则是产品级别的绩效管理，包括产品发布计划，产品版本计划， 产品线管理，产品负责人及产品负责人团队，不同产品类型的搭配等等。但这个话题以另外一个主线组织会更顺畅： 敏捷开发产品管理，因此会形成另外一个系列，但其核心内容仍是“如何通过敏捷开发管理产品提高绩效”，如果您觉得本系列所涉及的范围太窄，敬请关注。有读者反映每篇文章太长了，本系列会以较多的短篇文章形式发布，以便于选择关心的内容分别阅读。 精选学习资料 - - - - - - - - - 名师归纳总

5、结 - - - - - - -第 1 页，共 29 页敏捷开发绩效管理之二：用中医理论管理团队及其绩效绩效考核， 团队管理， 自组织团队团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。笔者因为工作原因在过去 16 年里与 100 多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。中医治病的原理中医和西医看待疾病的角度差异很大。中医受到当年条件所限，并不知道致病的原因是细菌、病毒还是其他什么。由于没有显而易见的敌人， 中医采取的策略是扶正去邪，就是让让人体

6、自身加强，从而自然地消灭” 邪气“。比方中耳炎，西医的解释是：“多由感冒引发急性中耳炎是中耳黏膜的急性化脓性炎症，致病菌乘虚侵入中耳常见的致病菌主要是肺炎球菌、流感嗜血杆菌等。”因此假设能将这些病菌铲除，则可治愈。而中医则认为：中耳炎是因肝胆湿热火邪气盛行引起，就是”情绪激动“导致中耳炎。因此应先”淡定“，然后配合治疗方可。中医的解释读者看起来可能感觉不可思议，但我很久以前得中耳炎导致内耳积水的时候去西医看了几天没好当时也没有感冒，给一位中医朋友打求助，他一语道破：你最近“激动”了，令我大吃一惊，也立刻相信他肯定能治好。实际治疗过程只有一上午，只使用了两根细针在离耳朵一米远的肢体末端扎了2 小

7、时，没有任何其他药物换言之从外表上看“没有任何东西被任何药物杀死”，但 10 分钟后鼻腔和耳朵就有明显干燥感，半个月后自愈了。后来一问， 原来他自己也得过此病，去过很多医院 医生各有所长， 也有去医院的时候呵呵花了几千块无法治愈，差点变成“聋子中医”，最后求人不如求自己，自创医术把自己给治好了，还治好了20 多个病人。他最近开始在梁冬开设的正安药房上班扎一米远的地方为何能治好耳朵？原因是那个地方有个穴位，可以调整和激发自身的自愈能力，由人体自己把疾病治好。对团队管理的启示团队也无时不处于众多“病菌”的围困之中，其中一个病菌似乎是“个体懒惰”，而对症下的药自然就是“考核个体”。很可惜，这个病菌不

8、是致命菌，看下面几个问题就知道了：“个体差异主要来自于哪里？”懒惰是一个方面，能力是另外一个方面。能力相同的人中，最懒的和最勤奋的程序员的工作产出相差多少？估计能相差30%就算不错了。 那么同是懒惰或勤奋的人，能力最差的和最强的程序职工作产出相差多少？10 倍！所以，这里有一个大得多的病菌。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 2 页，共 29 页“最近 M 公司和 N 公司业绩下滑了50%，原因何在？”因为大家变懒一倍？或者能力下降50%？显然不是，他们的产品管理出了问题。这个病菌大得致命。那为什么多数软件公司都简单地通过考核个人来提升

9、绩效呢？因为那样虽然无效，但是却简单。其实以往的很多处理策略，都有这个倾向，比方：需求变更频繁，客户说不清楚需求，工期紧，人员流动对每件事情单个而言，似乎都有几种 “青霉素” 一针见效： 需求变更频繁？就走需求变更流程，统计变更数量， 向客户递交变更工作量；客户说不清楚需求嘛？我们写需求让他们签字， 需求不签字不开工， 签了字就不准变更了；工期紧？加人加班！ 人员流动？多写文档， 不怕流动等等不一而足。然而到用的时候就会知道：几乎所有这些青霉素都导致过敏！敏捷开发的 “不考核个体”的思路，其实和中医理论很相近：尝试打造一个能自组织自更新的团队，来消除各种问题，而不是就问题论问题地处理。自组织团

10、队何为自组织团队？“领导放权了，让我们管自己，自己估算，自己领取任务，所以我们现在是自组织团队。 ”这个认识太浅。不是简单地去掉领导和流程后就能剩下一个“自组织团队”，这样得到的多半是一个无组织团队否则这也太简单了，我们的先人和领导们简直是傻子。事实是：自组织团队，是一个依靠团队的自组织能力，自我管理自我更新，消除各种有害因素，来到达提升绩效的团队。仔细分析一下，导致团队或公司绩效差的有害因素有很多：团队级别的也就是本系列希望讨论的包括大致由小至大：个体懒惰个体能力差个体懒惰导致团队懒惰个体能力差导致整个产品的质量差/进度慢如果领导放权了，我们自己估算，自己领取任务，但这些有害因素仍然在，那么

11、我们就不是一个自组织团队。我们只是一个生病了不打针不吃药的病人而已。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 3 页，共 29 页本文提到了敏捷开发对于提升绩效的主要机制：不是依靠一个有强大控制能力的领导，或一个固定的流程，而是一种能自我适应和改良的机制，进而让团队进入自组织状态，以自己的方法解决问题。下一章节将会提到用于取代“ 个体考核 ” 来激励个体的敏捷因素：同行压力。附： 导致团队或公司绩效差的有害因素产品级别 的包括大致由小至大：功能定义错误产品版本定义错误产品概念 /用户群定位错误产品线组合错误这些将在敏捷开发产品管理的系列中涉及

12、，敬请关注尚未开发，作者2011-08-21注。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 4 页，共 29 页敏捷开发绩效管理之三：个体动力之源同行压力松结对编程， 师徒制度， 跨职能团队，绩效考核如果有 10 个程序员，笔者相信至少有9 个是勤奋的。但是如果有一个10 人的程序员团队，其中1 个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一个共进退的团队。本文的

13、部分内容在之前的假设干博文中提到过，因符合本系列的内容，在此处从另外一个角度加以说明。领导压力领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或企业非常普遍。特征表现为：领导深度过问过程而不只是结果，领导现场监督在电脑时代，则有人发明了一种软件可让领导直接监控职工屏幕等等。领导压力的问题在于： 领导很难无处不在无时不在；领导很可能是外行； 领导就算不是外行，对单个任务而言，了解程度也一般低于任务承担者。领导压力一般是面向个体的，因为团队不会帮助领导管理个体，相反其整体上处于帮助个体而疏远领导的状态。如果你所在的企业越来越关注大家的考勤，已经在办公室安装了摄像头，

14、正在调研一款屏幕监控软件那么，代打卡现象一定很普遍，坐在电脑前什么也不做的人一定很多，定期切换屏幕的习惯正在大家中间养成办公室是一个团队合力解决问题的场所，而不是内部博弈的场所，因此领导压力是一个不明智的选择。同行压力同行压力是一种由职工管理职工的方法，因而解决了时间、空间、知识差异的问题。不过这种管理不是通过授权某人管理另外某人，而是通过为团队指明一个共同利益，从而使其在获取共同利益的时候互相管理。典型的同行管理行为发生在敏捷开发中的“每月计划会议”和“每日站立会议” 。在计划会议中， 团队在确认谁负责哪个任务之前，先共同估算每个任务的预计工时，之后才自由领取或指派负责人；而在站立会议中，任

15、务的负责人则报告进展情况，如果和计划有大的偏差，需要说明遇到的困难，以便大家进行帮助。其中所使用的共同估计和共同跟踪是实施成功的关键活动。同行压力的外在条件精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 5 页，共 29 页不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力” 的作用， 原因是同行压力的实现需要一些先决条件来支持。1. 跨职能团队如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队本身是跨职能团队如10 个都是开发人员 ，但却往往因为过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完

16、成。2. 先估计后分配原因显而易见：假设任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。3. 匿名估计即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。宽带Delphi 和估算扑克是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。4. 挑战和优化估计为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战Challege ” ， 寻求最优化的估计。之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由一般估计最低的先说，尝试

17、确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。5. 共同跟踪共同估计是共同跟踪的前提。只有这样，在跟踪时比方每日立会上大家才会关心别人任务的实际情况，在遇到困难时往往是发生了超出当年计划意料之外的事情，人们会更理解任务为何发生延期，且更容易激发热情去帮助任务负责人。在一个采用师徒制度和松结对编程的团队，共同跟踪活动不限于每日立会，而是会渗透到日常开发活动中。6. 团队绩效即认为假设某个工作没有完成，责任属于整个团队而不是具体负责人。这样既可以防止有任务没人

18、接，也可以防止有些人把着任务不放。在较大的团队里边由于有从众心理，往往很难让一个人在心理上承认自己应为另外9 个人中的一个没有完成任务而负有责任。但当把他们切分成小组时，情况会有所改观。尤其是师徒制度下师傅的团队责任感会很强。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 6 页，共 29 页7. 可完成的任务假设任务总是无始无终比方“开发可重用库”或很难有标准判断是否完成比方“需求分析” ，则很难估算和跟踪，也无法形成同行压力。8. 开放空间既包括物理上的开放空间即人们可以观察到每个人在做什么，也包括逻辑上的开放空间即人们可以观察到别人任务的进度

19、。匿名性被心理学分析为引发违规的重要诱因，比方群体事件中的蒙面者更加胆大妄为。跨职能团队、共同估算、开放空间等均起到破除个体匿名性的作用。在开放空间和个人空间之间有由来已久的纷争，仁者见仁智者见智。不过笔者放弃了所有拥有独立办公室的时机，坚持坐在团队的中间乃至正中央。因为工作并非永远令人兴奋、感觉顺畅，我非常担忧自己会放弃自律而有所松懈。那时候产生的所有负面效果的第一个受害者是我，而不是公司或其他人。上述内容在很大程度上已经替代个体考核管理了团队中的个体，帮助他们提升绩效，但如何最终考核他们的绩效正如前言，工资和奖金毕竟是发放到个人账户上的，日后会有博文再议。假设团队的个体绩效已经与团队的整体

20、绩效对齐，那么他们一起去做什么呢？那就是我们的下一个话题：为团队设定外部目标。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 7 页，共 29 页敏捷开发绩效管理之四：为团队设立外部绩效目标目标管理，外向型绩效最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有很多“外向型”思维，比方：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的比照

21、可以看出这点。“内向型”绩效及其导向进度： “各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。质量： “千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。成本： “与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。功能： “需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。此外还有一些更可怕的数据，比方“每月生产的代码行数” “每月

22、生产的功能点或故事点数”这个很有迷惑性 “每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出，无论是文档，代码，可运行软件乃至最终产品，假设尚未被销售，都只是成本的一部分。多数采用内向型绩效的公司和团队，其绩效结果都不好。究其原因，单个部门/工种 /个人各自追求自己的绩效，并不会导致整个项目外部绩效的提升这称为“合成谬误” 。某些内向型绩效甚至是互斥的，处于零和状态。 比方测试团队人均发现的缺陷数测试团队的绩效与开发人员人均缺陷数是开发团队的负绩效并存，则两个团队无论如何都无法同时提升绩效，导致他们永远无法像一个团队一样互相帮助。假设你的公司有这样的绩效，则研发人员与

23、测试人员打架就不用奇怪了。其他多数内向性绩效，都存在潜在的互斥关系。比方前面提到的个阶段按时完成率即内部存在互斥，而“需求规格中需求的完成比例”必与“客户需求响应率”互斥。外向型绩效下面是一些潜在的 “外向型”绩效，由于之前提过不同企业乃至产品的外向型绩效差异很大，请灵活运用。产品研发型进度：精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 8 页，共 29 页“与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。“响应分销商需求的时间”适合渠道比较强势的情况。这些外向型绩效应该作用在整个团队上，换言之不管哪个环节导致了进度差，都一起得到底的绩

24、效。从而促使整个团队一起思考如何提升绩效。需求和设计人员为了能让开发人员提前开工，可以采取分段写需求和设计的方法，把最影响架构又最不会发生变化的部分先写出来，让开发人员提前开工干活；而开发人员也可能会采取同样的策略， 阶段式地发布产品，让测试人员可以提前测试，防止最后缺陷太多导致产品延期；而需求和设计人员又回过头来用开发的进度和测试的缺陷率，来判断产品应该消减功能换取上市时间，还是增加更多功能以换取竞争力。可见一个为外部目标奋斗的团队，会很容易地团结起来，共同思考提升绩效的最正确策略。质量：“每月待处理质量问题数”咨询过的一家ERP公司的实际数据 但他们尚未用这个数据考核，此数据一般符合瑞利分

25、布，因此可预测未来的质量问题数量。“每月终端用户投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。“每月分销商投诉数”适合渠道比较强势的情况。“每月论坛缺陷提出数”适合我在的一家企业使用BBS免费处理缺陷。用最终用户提出的抱怨作为外部质量目标的策略，不是说大家不用测试了，把缺陷留给用户。而是： 用我们测试了但仍漏给客户让其发现的缺陷，来修订我们对缺陷的认识，修订发现缺陷的方法。有很多产品， 收到的客户关于易用性的抱怨，远远多于对功能和常规缺陷的抱怨，就应该将“易用性差”作为核心的质量问题，进而作为质量重点。我在下载一款总体评价4 星半的Android 短信软件时，发现近期的评价很多都是“越

26、来越难用了” “没用的功能越来越多”甚至“更新太频繁了给了1 星 ”等等，最近的一些评分平均估计会下降到4 星以下。这些抱怨应该当作质量管理的最终考核标准，因为下载者无疑会根据这些评价来决定是否安装软件，而不是看那些“千行缺陷率”“测试人员发现缺陷数”。成本：“产品实际投入产出”适合很长的战线。试想如果是研发，应该在开发阶段就做好测试、维护、重刷系统等接口，另外应该优化性能以选择低端硬件，否则整个产品极难保障盈利。而且还会发生假设软件做得好但软件的研发成本要上升，则可以节省一些硬件资源或减免某些专用硬件的情况。这时候假设要分别考核软件部门和硬件部门，就很难实现了。精选学习资料 - - - -

27、- - - - - 名师归纳总结 - - - - - - -第 9 页，共 29 页需求：“每月待处理需求数”咨询过的一家ERP公司的实际数据， 如果产品试销售过程中此数据很大而且消退很慢符合瑞利分布，则说明产品与客户的需求不符。估计也能呈现一些易用性方面的因素。“客户尖叫度 Customer Screaming Rate ”苹果成功的标志性绩效指标，不谈需求，因为他要超越需求。要学习这个很难，但要理解并表达其精神。“软件与硬件需求匹配度”适合消费电子， 比方假设硬件与软件研发平行，则最终交付产品中交付的软件和硬件应该匹配，而不能“18 个功能中，硬件完成了12 个，软件完成了13个，但其中6

28、 个不重合就是说这些功能交付不了” ，这样软硬件部门才会共同配合。某厂商很擅长上一条，他们一年的200 个项目中，只有3 个延期，就是很好地利用了功能排序 -软硬件对齐的方法，牺牲次要功能保证上市时间。项目开发型产品做的多，项目做的少，不敢多说，请各位补充吧！为团队设立外部绩效目标的目的，是对齐团队的不同角色、工序、人员的目标，从而互相帮助提升共同的绩效。外部目标多数可以被客户、用户或市场明确感知，其提升几乎意味着带来收入的增加。如果想在测试人员发现Bug 的时候发奖金但却发现账上没有钱，那就改到客户很少抱怨的时候发吧，那时候账上肯定有钱。注：这是一篇旧文，因符合本系列的内容，在进行了很大改动

29、后重新编辑发布在这里。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 10 页，共 29 页敏捷开发绩效管理之五：敏捷开发生产率上故事点估算度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。度量敏捷生产率的目的真正难以答复的是度量生产率的目的是什么？很多人都认为是考核绩效，发奖金。 根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目盈利，应该为团队设立外部目标， 否则很可能得到一个生产率很高，但是实际上很烂产品质量上或易

30、用性上很差，抑或其他想象不到但一定遇到的原因。这是我们说为什么用外部目标而非内部目标考核团队的原因。或许又有人说： “开发得快不快是团队的事情，产品好不好则是产品负责人的事情。”这样也不对，相当于我们在自组织之后，当我们享有勇气，尊重，沟通这些敏捷的特质之后，我们居然得到了一个只关心自己的开发速度，而置客户价值和企业利益于不顾的团队。“受激励的个体” 只被自己小团队的绩效所激励，并不爱也不关心自己的产品，这绝对不是敏捷开发的初衷。度量生产率的目的不是绩效考核，而是是希望提升生产率绩效。将度量结果进行横向和纵向比较，可以分析造成生产率差异的原因，并进而提升生产率绩效。微观度量方法 -故事点故事点

31、估算方法“每月完成的人天数”这个方法不说了，用尺子量尺子， 肯定不行的。 不过通过统计每月的实际投入天数，可以优化人员利用率，并间接提升生产率。“每月完成的故事点”这个是比较好的方法。所谓故事点法，就是提前选择一些大家都熟知的、以往做过的、典型的故事，比方：1. 对单个表进行增删改查2. 对父子表的增删改查3. 为一个已经存在的数据表增加一个复杂报表4. 修改一个中等难度的BUG实际上这些故事应该是具体的，而不是像上面例子中一样看起来更像是“分类”精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 11 页，共 29 页然后人拿出当年的历史记录，将当时

32、所投入的人天数称为“故事点数”也有别的做法但这个最简单。比方“对单个表进行增删改查”当年用了4 天，那么标准故事点就是4。当下次估算时，人们又发现有一个故事也是“对单个表的增删改查”，于是就先选定基数为4，再讨论这次与上次比，到底复杂多少。 如果一致认为可能复杂20%，那么故事点就是5。如果大家的生产率不变，那么这个故事应该5 天完成， 但是如果结果却是4 天就完成了， 则说明大家的生产率提高了。当然不是一个一个故事度量，而是把整个迭代内的故事点加起来度量。通过纵向比较故事点，可以知道大家是否比以前的生产率提高了。横向比较故事点比较有难度，因为每个团队乃至项目都会选定自己特有的标准故事，而且极

33、难说明这个团队和那个团队的标准故事的转换关系。故事点的局限性在推广故事点这件事情上笔者有所保留，建议尝试但需注意风险，必要时知难而退。在笔者遇到的这么多做敏捷的企业和人里边，还没有见到有人提到他们的故事点应用是成功的。原因在于找到大家都熟知的、以往做过的、 典型的故事很难，而让所有人记住它们当年的详细情况以便日后比照修订就更难。04 年笔者去做咨询的一家企业有他们的故事点模板他们并不做敏捷开发，但却使用完全类似的方法 ，一共有 17 种标准故事，已经记录了25 个项目的故事点数据和实际工作量数据，每个项目从4 个故事到上百的故事不等，他们希望笔者能帮他们计算一下“17 个标准故事分别对应多少人

34、天”。终于遇到了又有标准故事又有历史数据的情况，这比所有一穷二白想使用故事点的企业可乐观多了。这是一个所谓“线性规划”的问题，涉及“最小二乘法”“超越方程”这些玄乎的名词，但却在 Excel 表里有这个功能，不过是10 分钟的事情并不费力，真正费力的是解释其结果：求解的答案是某些标准故事是负数，也就是说如果把这几种故事当作负数对待，那么以往发生的 25 个项目的预测结果与实际结果最符合。再换一种直白的解释：用这17 种故事预测工作量不准。或许有人会说他们的17 种故事选得不好，或他们的水平很差。怎么说呢，他们是一家1000多人的电信企业，专职做过程管理的人就有5 人，还认真地记录了这么多数据，

35、恐怕当年选定故事的过程也是经过思考的。倘假设他们都难以建立其故事点，一般的10 人团队想自己做一套恐怕更难。回过头来观察他们公司的失败原因，是在为新的故事找到对应的标准故事后，没有根据其差异进行调整， 而是机械地选择了标准故事的故事点，导致误差很大。 在采用故事点的时候应该注意。但他们考虑到某些故事的回归结果居然是负数，即使“进行调整”结果也会是血淋淋的， 甚至可以说基本扔到了标准故事从头估算，最终放弃了故事点， 采用了另外一种方法，就是下篇文章提到的“功能点估算”。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 12 页，共 29 页笔者之前的一

36、篇文章有故事点估算方法的更详尽的介绍，但角度不同： 敏捷估算： 故事点与直接估算天数的差异故事点为我们提供了一种比较客观度量敏捷生产率的方法，但其局限性限制了其应用。下一篇文章将介绍另外一种广泛应使用的方法：功能点估算法。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 13 页，共 29 页敏捷开发绩效管理之六：敏捷开发生产率中功能点分析，FPA ，简化的功能点直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题， 或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。敏捷开发内部之所以没有

37、进化出来能做项目间比较、行业间比较、 用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情， 比天数、故事点，在老板眼中更接近生产率绩效。这时候就需要功能点估算。功能点估算由来功能点估算是另外一个世界的事情。每100 个懂敏捷的人中，可能才有1 个懂 CMMI ；而懂CMMI 的人中，可能才有 100个懂功能点，而 100个懂功能点的人中， 也只有 1个人懂敏捷这就是三个世界，但每个世界都和敏捷世界一样热闹，一样有可操作的方法，只是互相不通信而已结果是，每个世界都不知道别人已经早就解决了自己冥思苦想的问题。用功能点度量软件的目的，是在早期获知软件开发的工作量

38、，进而推算开发成本。由于这个目的，使得它实际上是与开发工作量的相关性也最强远远超过Delphi/ 代码行 /故事点 /用例点多个国家的政府使用此估算采购软件，中国大约2 年就后采用 ，而且居然和用户故事还有很好的对应关系。功能点本身很复杂，大家可以在网上查到一些资料，这里不多说了。 标准功能点分析尤其复杂，有一次有一个欧美发包商来到中国，问“我们现在已经有100 多页文档，谁看过之后知道这个项目要多少钱才能开发出来，以及为什么，我们就把这个项目给他。”笔者介入了此事，也知道标准功能点能解决这个问题，但是却不能在给定的时间内完成只有 2 天的时间解决此问题， 而用功能点至少需要1015 天国外I

39、SBSG也转发度量Guru Capers Jones的邮件称“只有极少数的项目采用了功能点估算，因为成本太高”。这件事情促使笔者尝试找简单的功能点估计方法，直到后来在另外一个世界发现有人早就解决了大约10 年了那就是 NESMA的简化功能点，如果不嫌麻烦请参阅:/ 点击左边Advanced 下面的 Early&Fast FPA 。不过建议直接看下面。下面的概念作了很大的调整以便于用有限的文字理解，如果有懂FPA的读者看出破绽不要奇怪本人是正规做FPA培训和研究的 。什么是简化的功能点估算在我们的开发工作中一共有两类东西要开发，一种是数据，一种是操作。所谓数据，就是比方要编写一个CRM，其中有“

40、用户、角色、权限”这三种东西，就是要管理的数据，这里权且记下用户有“3 个数据”要管理。所谓操作，就是对用户，应该有增、删、改、查、加入角色这些称之为操作，这里权且记下对用户，用户会做“5 个操作”。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 14 页，共 29 页倘假设角色和权限没有操作虽然这是不可能的 ，那么在 NESMA简化方法中由于每个数据是 7 点，而每个操作是4 点左右，那么就可以算出来一共有：3 7 + 5 4 = 21 + 20 = 41点。ISBSG/IFPUG包括中国的CSBSG 等都有不同行业/不同类型软件的生产率统计，如

41、果你在中国，用 C#或 Java开发一个类似OA/CRM 这样的业务流转软件，那么生产率大约是9 小时 /功能点来自于 10 多个学员的课后数据 ，也就是上面那个小软件，要用941 = 369 小时大约是46 人天。“什么？这点内容我不到一星期就能做完。”是，也不是。 这一时间的包含了需求分析/设计/编码 /测试 /集成 / 上线部署期间的所有时间，还包括开会讨论的时间，和别的功能联调的时间，培训的时间，修改万恶的Bug 的时间，提升性能的时间，改善易用性的时间，上网找图标的时间，上班看博客的时间总之一个真实项目中可能发生的时间全都平摊在这里。听起来够简单了，但其实还不够。谁能拿出 2 页纸的

42、需求文档假设昨天老板在酒桌上刚从客户那记下来的，就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。怎么办？请看下文。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 15 页，共 29 页敏捷开发绩效管理之七：敏捷开发生产率下简化功能点分析，NESMA ，两级简化功能点估算第一级简化上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。谁能在刚拿出2 页纸的需求文档时假设昨天老板在酒桌上刚从客户那记下来的，就猜出有多少个操作？而且还不遗漏？增删改查好猜，“ 加入角色 ” 就不好猜了。NESMA 早就遇到过这个问题

43、了，他们这么解决： 通过统计发现每个数据差不多有7 个操作，所以刚刚咱们找出了3 个数据，那么：3 个 数据 7 + 操作 4 7 个操作= 3 35 = 105 ，嘿，把角色和权限的操作问题也给解决了，不用猜了。如果有几个数据要管理也不知道怎么办？那也太粗糙了吧，再去细化一下吧 别细化报表上有几个按钮，按了按钮后的逻辑是什么 那个和规模无关；只确认是不是数据。这样准吗？来自课后的10 个数据说明，基于这种功能点作出的工作量估算与实际项目数据相比，最大误差在正负50% 左右本人手里没有详细数据所以没分析，应该取P50 就是中值的误差比较好，可能在30%左右。虽然听起来误差大得乍舌，但是在手里只

44、有2 张纸的时候，已经很准确了。某政府部门的要求是到400% 以内都可以接受，因为他们在一个项目的招标中， 4 个供给商报价最大差异是12 倍。总结一下这一级别的简化方法就是：每个内部数据35 点 。另外如果是外部接口数据比方要取 LDAP ，那么每个外部接口数据15 点。第一级简化适合项目合同期 /项目初始计划的早期估算。第二级简化如果项目已经完成了，不用猜了， 就可以数到底有几个操作，就不用猜每个数据有7 个了。不过，到软件界面上面数显的很不专业，如果我们的史诗故事是基于数据写的，用户故事是基于操作写的，数史诗故事+用户故事不就得了？比方图中这个：精选学习资料 - - - - - - -

45、- - 名师归纳总结 - - - - - - -第 16 页，共 29 页图中就是刚刚提到的用户/角色 /权限的局部，一共3 个数据小课本是史诗故事，外加19个操作蓝色的是用户故事，其中两个“ 新建 +查看 ” 分别代表两个，要 2，加起来是3 7 + 19 * 4 = 21 + 76 = 97，已经很接近105 个了 如果考虑到这个软件还没有编完，我们第一级简化还是蛮准的嘛归功于NESMA 的长期努力。完成这些功能需要105 9 = 945 小时= 118 人天。如果我们有一个迭代，正好要完成这些功能并将其部署上线，那么就按118 天计算吧如果只编写出来不测试，大约是70% 的工作量。当然这

46、不是说任何一个人都花相同的时间，而是基于现在业界收集上来的数据，团队人均花费这么多。个体的生产率差异可达5 倍，但团队却都差不了太多。另外单个故事的精度也很差，比方如果某人正好编过某功能，可能一小会就完成了。但是如果很多人编写很多故事，大数定理会起作用。总结一下这级别的简化方法就是：每个内部文件按7 点每个外部接口按5 点，每个操作按 4 点，加起来就是功能点。这个级别的简化适合每个迭代确定工作量；还可以在项目完成后，总体计算开发效率作为绩效管理的依据算是回到绩效管理了。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 17 页，共 29 页遗留问题

47、正如前言， 很多敏捷世界的新鲜事，在别的世界早就不是新鲜事了当然别的世界也有他们的新鲜事，提出和解决下面这些问题的很多前辈都已经去世了。本文只是指出有这么一种方法，并非这种方法的操作手册，这种方法还是需要培训的有现成的。1. 就这么简单？不是，简化的功能点大约需要一整天的培训，后续估算推导工作量/工期 /成本还需要一整天。里边有很多细节。复杂的功能点大约需要23 天培训， 另外一般5 天左右的指导， 如果要 CFPS 证书还有一个 3 天左右的考前指导。2. “每个用户操作= 一个用户故事？那修Bug 怎么办？做小的改动怎么办？提升性能怎么办？ ”可以记录成不同类型的故事，但是就别计算功能点了

48、。图中三个绿色箭头，就是三个对原有故事的 “ 增强 ” ，其特点就是无法描述为完整的用户操作。他们不计数，但是在统计时已经被平摊到计数的故事里边了。我自己实践的时候发现，有些故事为了开发方便，极有可能包含两个操作如上面的“ 角色首页 ” 包含新建和查询两个操作，建议可以当作一个故事，怎么舒服怎么来不要太生硬，但是加个记号知道是2 个操作，防止数错。3. 每个数据都是/才能是史诗故事吗？不一定，我有一个史诗故事叫做“ 性能优化 ” ，它就不是，也不计算它。4. 每个动词都是操作？不一定。简单而言就是只有” 主语是用户 “ 的动词才是操作。” 。暂时还没有遇到有些Backlog Item不是用户操

49、作但是很想当成用户故事的情况，如果有，可以在史诗故事/用户故事上设置一个字段，如果是才计数。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 18 页，共 29 页5. 非功能性需求怎么办？最早提出来也最早被解决的问题，标准功能点的非功能性调整因子是1970 左右 天啊 提出的有点老了多数都不适用了；个人最喜欢的是韩国标准中的调整因子，大致可以理解为普通的乘1，科学计算之类的乘左右，运营计费乘左右，生死攸关的乘2 左右。非功能性调整因子一般包括规模因子、领域因子韩国标准包括8 大类约 50 小类、质量因子韩国标准包括4 个质量因子，每个三个等级、开发

50、语言因子这几个。有时候不会觉得他们考虑不周，反而是多虑了6. 准吗？不准。因为这种方法虽然很准，但是那个”9 小时 /功能点 ” 是业界数据，最好用自己的数据重新回归一下。本人正在回归自己的，可惜只有一个项目在做，所以不得不每个迭代都当作项目来看待。一般稍微大点的企业有一年时间积累20 个子项目数据就可以了。7. 有前途吗？有。芬兰，澳大利亚，韩国，日本 的政府采购均采用这种方法计算价格。中国的国标预计在明年出台，即政府采购项目均将使用这种方法报价或指导报价。8. 有的项目好坏可不是光看开发的功能多少，还要看创意和是的， 用这种方法度量绩效的目的，是为了提升开发绩效，加快开发速度，而不是计算工