敏捷开发绩效管理之1-11

《敏捷开发绩效管理之1-11》由会员分享，可在线阅读，更多相关《敏捷开发绩效管理之1-11（39页珍藏版）》请在装配图网上搜索。

1、敏捷开发绩效管理之一：前言及“敏捷开发与否考核个人”（绩效考核）“敏捷开发绩效管理”自身是个伪命题，由于敏捷开发自身不想波及绩效管理，这就像“C+绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理措施是有因素的：更高的交付保障，更高的生产率，更高的质量这和人们选择C+（而不是C）的因素还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”，而是“如何运用敏捷开发提高绩效”。何为绩效管理绩效管理常常被片面理解为绩效考核，即如何拟定个人的绩效，如何提工资和发奖金的问题。事实上绩效管理还涉及制定绩效目的，制定绩效筹划，制定配套的制度推动绩效

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

3、才导致很难回答。下面一点点分析。公司绩效管理的目的不是为了考核个人，而是为了提高公司绩效，因此尝试考核个人的公司事实上在“运用考核个人提高公司绩效”（尽管提高个人绩效会提高公司绩效，但勿入此牛角，由于前面有个尖）。因此这个问题从原始出发点来看，应当是：“公司与否应当通过考核个人来提高绩效？”，那么答案就是：“敏捷开发有比考核个人更能提高绩效的措施”。不是由于用了敏捷开发就不能考核个人，而是选择了敏捷开发，就意味着已经选择了比考核个人更有效的提高绩效的措施，因此没有必要让公司管理和敏捷开发较劲，它们打不起来的。但是这个或者这些更有效的措施是什么呢？这就是本系列博文的重要内容。本系列博文将较多波及

4、团队级别的绩效管理，内容涉及团队管理的方略，个体管理，团队的外部目的设定，如何分解到个人，不同团队绩效管理的差别，非物质鼓励等。此外一种高档话题则是产品级别的绩效管理，涉及产品发布筹划，产品版本筹划，产品线管理，产品负责人及产品负责人团队，不同产品类型的搭配等等。但这个话题以此外一种主线组织会更顺畅：敏捷开发产品管理，因此会形成此外一种系列，但其核心内容仍是“如何通过敏捷开发管理产品提高绩效”，如果您觉得本系列所波及的范畴太窄，敬请关注 。（有读者反映每篇文章太长了，本系列会以较多的短篇文章形式发布，以便于选择关怀的内容分别阅读。）敏捷开发绩效管理之二：用中医理论管理团队及其绩效（绩效考核，团

5、队管理，自组织团队）团队管理是个由来已久的话题，各式各样的管理理论和措施层出不穷。笔者由于工作因素在过去里与100多家公司的团队或团队领导者有较为进一步的交流，看到了听到了想到了诸多有关的内容，下面做一种总结。但是受个人经历所限，这不是一种客观的全面的总结，而是带有本人的角度和主张，仅供参照。中医治病的原理中医和西医看待疾病的角度差别很大。中医受到当年条件所限，并不懂得致病的因素是细菌、病毒还是其她什么。由于没有显而易见的敌人，中医采用的方略是扶正去邪，就是让让人体自身加强，从而自然地消灭”邪气“。例如中耳炎，西医的解释是：“多由感冒引起急性中耳炎是中耳黏膜的急性化脓性炎症，致病菌乘虚侵入中耳

6、常用的致病菌重要是肺炎球菌、流感嗜血杆菌等。”因此若能将这些病菌铲除，则可治愈。而中医则觉得：中耳炎是因肝胆湿热（火）邪气盛行引起，就是”情绪激动“导致中耳炎。因此应先”淡定“，然后配合治疗方可。中医的解释读者看起来也许感觉不可思议，但我好久此前得中耳炎导致内耳积水的时候去西医看了几天没好（当时也没有感冒），给一位中医朋友打电话求助，她一语道破：你近来“激动”了，令我大吃一惊，也立即相信她肯定能治好。实际治疗过程只有一上午，只使用了两根细针在离耳朵一米远的肢体末端扎了2小时，没有任何其她药物换言之从表面上看“没有任何东西被任何药物杀死”，但10分钟后鼻腔和耳朵就有明显干燥感，半个月后自愈了。后

7、来一问，本来她自己也得过此病，去过诸多医院（医生各有所长，也有去医院的时候呵呵）花了几千块无法治愈，差点变成“聋子中医”，最后求人不如求自己，自创医术把自己给治好了，还治好了20多种病人。（她近来开始在梁冬开设的正安药房上班）扎一米远的地方为什么能治好耳朵？因素是那个地方有个穴位，可以调节和激发自身的自愈能力，由人体自己把疾病治好。 对团队管理的启示团队也无时不处在众多“病菌”的围困之中，其中一种病菌似乎是“个体懒惰”，而对症下的药自然就是“考核个体”。很可惜，这个病菌不是致命菌，看下面几种问题就懂得了：“个体差别重要来自于哪里？”懒惰是一种方面，能力是此外一种方面。能力相似的人中，最懒的和最

8、勤奋的程序员的工作产出相差多少？估计能相差30%就算不错了。那么同是懒惰或勤奋的人，能力最差的和最强的程序员工作产出相差多少？10倍！因此，这里有一种大得多的病菌。“近来M公司和N公司业绩下滑了50%，因素何在？”由于人们变懒一倍？或者能力下降50%？显然不是，她们的产品管理出了问题。这个病菌大得致命。那为什么多数软件公司都简朴地通过考核个人来提高绩效呢？由于那样虽然无效，但是却简朴。其实以往的诸多解决方略，均有这个倾向，例如：需求变更频繁，客户说不清晰需求，工期紧，人员流动对每件事情单个而言，似乎均有几种“青霉素”一针见效：需求变更频繁？就走需求变更流程，记录变更数量，向客户递交变更工作量；

9、客户说不清晰需求嘛？我们写需求让她们签字，需求不签字不动工，签了字就不准变更了；工期紧？加人加班！人员流动？多写文档，不怕流动等等不一而足。然而到用的时候就会懂得：几乎所有这些青霉素都导致过敏！敏捷开发的“不考核个体”的思路，其实和中医理论很相近：尝试打造一种能自组织自更新的团队，来消除多种问题，而不是就问题论问题地解决。自组织团队何为自组织团队？“领导放权了，让我们管自己，自己估算，自己领取任务，因此我们目前是自组织团队。”这个结识太浅。不是简朴地去掉领导和流程后就能剩余一种“自组织团队”，这样得到的多半是一种无组织团队否则这也太简朴了，我们的先人和领导们简直是傻子。事实是：自组织团队，是一

10、种依托团队的自组织能力，自我管理自我更新，消除多种有害因素，来达到提高绩效的团队。仔细分析一下，导致团队或公司绩效差的有害因素有诸多：团队级别的也就是本系列但愿讨论的涉及（大体由小至大）：个体懒惰个体能力差个体懒惰导致团队懒惰个体能力差导致整个产品的质量差/进度慢如果领导放权了，我们自己估算，自己领取任务，但这些有害因素仍然在，那么我们就不是一种自组织团队。我们只是一种生病了不打针不吃药的病人而已。本文提到了敏捷开发对于提高绩效的重要机制：不是依托一种有强大控制能力的领导，或一种固定的流程，而是一种能自我适应和改善的机制，进而让团队进入自组织状态，以自己的措施解决问题。下一章节将会提到用于取代

11、“个体考核”来鼓励个体的敏捷因素：同行压力。附：导致团队或公司绩效差的有害因素产品级别的涉及（大体由小至大）：功能定义错误产品版本定义错误产品概念/顾客群定位错误产品线组合错误这些将在敏捷开发产品管理的系列中波及，敬请关注（尚未开发，作者-08-21注）。敏捷开发绩效管理之三：个体动力之源同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一种10人的程序员团队，其中1个人不是勤奋的，并且仍然拿到与其她人完全相似的报酬人们猜这个团队会以90%的生产率运营，还是更低的生产率？不管人们信不信，我是相信后者的。这个是敏捷开发中对个体管理的出

12、发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一种共进退的团队。本文的部分内容在之前的若干博文中提到过，因符合本系列的内容，在此处从此外一种角度加以阐明。 领导压力领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或公司非常普遍。特性体现为：领导深度过问过程而不只是成果，领导现场监督（在计算机时代，则有人发明了一种软件可让领导直接监控员工屏幕）等等。领导压力的问题在于：领导很难无处不在无时不在；领导很也许是外行；领导就算不是外行，对单个任务而言，理解限度也一般低于任务承当者。领导压力一般是面向个体的，由于团队不会协助领导管理个体，相反其整体上处在协助

13、个体而疏远领导的状态。如果你所在的公司越来越关注人们的考勤，已经在办公室安装了摄像头，正在调研一款屏幕监控软件那么，代打卡现象一定很普遍，坐在电脑前什么也不做的人一定诸多，定期切换屏幕的习惯正在人们中间养成办公室是一种团队合力解决问题的场合，而不是内部博弈的场合，因此领导压力是一种不明智的选择。同行压力同行压力是一种由员工管理员工的措施，因而解决了时间、空间、知识差别的问题。但是这种管理不是通过授权某人管理此外某人，而是通过为团队指明一种共同利益，从而使其在获取共同利益的时候互相管理。典型的同行管理行为发生在敏捷开发中的“（每月）筹划会议”和“（每日）站立会议”。在筹划会议中，团队在确认谁负责

14、哪个任务之前，先共同估算每个任务的估计工时，之后才自由领取或指派负责人；而在站立会议中，任务的负责人则报告进展状况，如果和筹划有大的偏差，需要阐明遇到的困难，以便人们进行协助。其中所使用的共同估计和共同跟踪是实行成功的核心活动。同行压力的外在条件但是有时某些应用敏捷开发好久的开发团队并没有真实感觉到“同行压力”的作用，因素是同行压力的实现需要某些先决条件来支持。1. 跨职能团队如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队自身是跨职能团队（如10个都是开发人员），但却往往由于过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完毕。2. 先估计后分派因素显

15、而易见：若任务已经分派，多数“无关人员”的爱好和注意力将大大减少。3. 匿名估计虽然是一种跨职能团队，如果第一种人一方面说出估计成果时，其她人也许由于多种心理问题而导致无法客观地体现自己的意见，特别当第一种人是最强或最弱一员的时候。宽带Delphi和估算扑克是两种常用的匿名估算措施，其中后者由于简朴快捷在敏捷开发中广为使用。4. 挑战和优化估计为了避免筹划会变成一种无聊的监督行为，在匿名估计中数值相差较大的成员要进行“挑战（Challege）”，谋求最优化的估计。之因此称之为挑战，是由于团队不能简朴地进行求均值、投票，而是人们分别说出理由（一般估计最低的先说），尝试确认与否有可重用的组件、额外

16、的测试规定等诸多也许影响估计成果的因素，重新投票直至成果接近。优化估计的过程借助团队的知识和智慧澄清了诸多种体似是而非的猜想，成果不仅为人们所接受，也更客观。5. 共同跟踪共同估计是共同跟踪的前提。只有这样，在跟踪时（例如每日立会上）人们才会关怀别人任务的实际状况，在遇到困难时（往往是发生了超过当年筹划意料之外的事情），人们会更理解任务为什么发生延期，且更容易激发热情去协助任务负责人。在一种采用师徒制度和松结对编程的团队，共同跟踪活动不限于每日立会，而是会渗入到平常开发活动中。6. 团队绩效即觉得若某个工作没有完毕，责任属于整个团队而不是具体负责人。这样既可以避免有任务没人接，也可以避免有人把

17、着任务不放。在较大的团队里边由于有从众心理，往往很难让一种人在心理上承认自己应为此外9个人中的一种没有完毕任务而负有责任。但当把她们切提成小组时，状况会有所改观。特别是师徒制度下师傅的团队责任感会很强。7. 可完毕的任务若任务总是无始无终（例如“开发可重用库”）或很难有原则判断与否完毕（例如“需求分析”），则很难估算和跟踪，也无法形成同行压力。8. 开放空间既涉及物理上的开放空间即人们可以观测到每个人在做什么，也涉及逻辑上的开放空间即人们可以观测到别人任务的进度。匿名性被心理学分析为引起违规的重要诱因，例如群体事件中的蒙面者更加胆大妄为。跨职能团队、共同估算、开放空间等均起到破除个体匿名性的作

18、用。在开放空间和个人空间之间有由来已久的纷争，仁者见仁智者见智。但是笔者放弃了所有拥有独立办公室的机会，坚持坐在团队的中间乃至正中央。由于工作并非永远令人兴奋、感觉顺畅，我非常紧张自己会放弃自律而有所松懈。那时候产生的所有负面效果的第一种受害者是我，而不是公司或其她人。上述内容在很大限度上已经替代个体考核管理了团队中的个体，协助她们提高绩效，但如何最后考核她们的绩效（正如前言，工资和奖金毕竟是发放到个人账户上的），后来会有博文再议。若团队的个体绩效已经与团队的整体绩效对齐，那么她们一起去做什么呢？那就是我们的下一种话题：为团队设定外部目的。敏捷开发绩效管理之四：为团队设立外部绩效目的（目的管理

19、，外向型绩效）近来在看德鲁克的书，发现其中很明确地写着“公司的绩效只存在于外部，而公司内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有诸多“外向型”思维，例如：关注客户价值，觉得可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目的管理接轨。外向性思维可以避免部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。“内向型”绩效及其导向进度：“各阶段准时完毕率”会导致分析和设计人员草草结束工作，而将大量不拟定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。质量：“千行代码缺陷率”会导致开发人员在诸多“与否是缺陷”问题上与测试人员

20、争执不下，此外某些次要的如使用不便、不直观等问题则被长期搁置。成本：“与筹划相比的人员超支率”会导致项目经理很不乐意接受变更，虽然是那些显然能给客户带来巨大价值的。功能：“需求规格中需求的完毕比例”会导致开发组思维局限于当年编写需求规格时期的结识，而不能在整个漫长的开发过程中不断精化需求。此外尚有某些更可怕的数据，例如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有困惑性）“每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“公司内部只有成本”的理念指出，无论是文档，代码，可运营软件乃至最后产品，若尚未被销售，都只是成本的一部分。多数采用内向型绩效的公司和团队，其绩效成果都不好。究其

21、因素，单个部门/工种/个人各自追求自己的绩效，并不会导致整个项目外部绩效的提高（这称为“合成谬误”）。某些内向型绩效甚至是互斥的，处在零和状态。例如测试团队人均发现的缺陷数（测试团队的绩效）与开发人员人均缺陷数（是开发团队的负绩效）并存，则两个团队无论如何都无法同步提高绩效，导致她们永远无法像一种团队同样互相协助。若你的公司有这样的绩效，则研发人员与测试人员打架就不用奇怪了。其她多数内向性绩效，都存在潜在的互斥关系。例如前面提到的个阶段准时完毕率即内部存在互斥，而“需求规格中需求的完毕比例”必与“客户需求响应率”互斥。外向型绩效下面是某些潜在的“外向型”绩效，由于之前提过不同公司乃至产品的外向

22、型绩效差别很大，请灵活运用。产品研发型进度：“与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。“响应分销商需求的时间”适合渠道比较强势的状况。这些外向型绩效应当作用在整个团队上，换言之不管哪个环节导致了进度差，都一起得究竟的绩效。从而促使整个团队一起思考如何提高绩效。需求和设计人员为了能让开发人员提前动工，可以采用分段写需求和设计的措施，把最影响架构又最不会发生变化的部分先写出来，让开发人员提前动工干活；而开发人员也也许会采用同样的方略，阶段式地发布产品，让测试人员可以提前测试，避免最后缺陷太多导致产品延期；而需求和设计人员又回过头来用开发的进度和测试的缺陷率，来判断产品应当消减功能

23、换取上市时间，还是增长更多功能以换取竞争力。可见一种为外部目的奋斗的团队，会很容易地团结起来，共同思考提高绩效的最佳方略。质量：“每月待解决质量问题数”征询过的一家ERP公司的实际数据（但她们尚未用这个数据考核），此数据一般符合瑞利分布，因此可预测将来的质量问题数量。“每月终端顾客投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。“每月分销商投诉数”适合渠道比较强势的状况。“每月论坛缺陷提出数”适合我在的一家公司使用BBS免费解决缺陷。用最后顾客提出的抱怨作为外部质量目的的方略，不是说人们不用测试了，把缺陷留给顾客。而是：用我们测试了但仍漏给客户让其发现的缺陷，来修订我们对缺陷的结识，修订

24、发现缺陷的措施。有诸多产品，收到的客户有关易用性的抱怨，远远多于对功能和常规缺陷的抱怨，就应当将“易用性差”作为核心的质量问题，进而作为质量重点。我在下载一款总体评价4星半的Android短信软件时，发现近期的评价诸多都是“越来越难用了”“没用的功能越来越多”甚至“更新太频繁了（给了1星）”等等，近来的某些评分平均估计会下降到4星如下。这些抱怨应当当作质量管理的最后考核原则，由于下载者无疑会根据这些评价来决定与否安装软件，而不是看那些“千行缺陷率”“测试人员发现缺陷数”。成本：“产品实际投入产出”适合很长的战线。试想如果是手机研发，应当在开发阶段就做好测试、维护、重刷系统等接口，此外应当优化性

25、能以选择低端硬件，否则整个产品很难保障赚钱。并且还会发生若软件做得好（但软件的研发成本要上升），则可以节省某些硬件资源或减免某些专用硬件的状况。这时候若要分别考核软件部门和硬件部门，就很难实现了。需求：“每月待解决需求数”征询过的一家ERP公司的实际数据，如果产品试销售过程中此数据很大并且消退很慢（符合瑞利分布），则表白产品与客户的需求不符。估计也能呈现某些易用性方面的因素。“客户尖叫度（Customer Screaming Rate）”苹果成功的标志性绩效指标，不谈需求，由于她要超越需求。要学习这个很难，但要理解并体现其精神。“软件与硬件需求匹配度”适合消费电子，例如若硬件与软件研发平行，则

26、最后交付产品中交付的软件和硬件应当匹配，而不能“18个功能中，硬件完毕了12个，软件完毕了13个，但其中6个不重叠（就是说这些功能交付不了）”，这样软硬件部门才会共同配合。某手机厂商很擅长上一条，她们一年的200个项目中，只有3个延期，就是较好地运用了功能排序-软硬件对齐的措施，牺牲次要功能保证上市时间。项目开发型产品做的多，项目做的少，不敢多说，请各位补充吧！为团队设立外部绩效目的的目的，是对齐团队的不同角色、工序、人员的目的，从而互相协助提高共同的绩效。外部目的多数可以被客户、顾客或市场明确感知，其提高几乎意味着带来收入的增长。如果想在测试人员发现Bug的时候发奖金但却发现账上没有钱，那就

27、改到客户很少抱怨的时候发吧，那时候账上肯定有钱。 注：这是一篇旧文，因符合本系列的内容，在进行了很大改动后重新编辑发布在这里。敏捷开发绩效管理之五：敏捷开发生产率（上）（故事点估算）度量敏捷开发的生产率始终是个难题，确切说度量任何开发措施的生产率都是一种难题，但它事实上有答案，这个答案是本文的重要内容。度量敏捷生产率的目的真正难以回答的是度量生产率的目的是什么？诸多人都觉得是考核绩效，发奖金。根据上一篇文章的内容我们可以懂得，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目赚钱，应当为团队设立外部目的，否则很也许得到一种生产率很高，但是事实上很烂产品质量上或易用性上很

28、差，抑或其她想象不到但一定遇到的因素。这是我们说为什么用外部目的而非内部目的考核团队的因素。或许又有人说：“开发得快不快是团队的事情，产品好不好则是产品负责人的事情。”这样也不对，相称于我们在自组织之后，当我们享有勇气，尊重，沟通这些敏捷的特质之后，我们居然得到了一种只关怀自己的开发速度，而置客户价值和公司利益于不顾的团队。“受鼓励的个体”只被自己小团队的绩效所鼓励，并不爱也不关怀自己的产品，这绝对不是敏捷开发的初衷。度量生产率的目的不是绩效考核，而是是但愿提高生产率绩效。将度量成果进行横向和纵向比较，可以分析导致生产率差别的因素，并进而提高生产率绩效。 微观度量措施-故事点故事点估算措施“每

29、月完毕的人天数”这个措施不说了，用尺子量尺子，肯定不行的。但是通过记录每月的实际投入天数，可以优化人员运用率，并间接提高生产率。 “每月完毕的故事点”这个是比较好的措施。所谓故事点法，就是提前选择某些人们都熟知的、以往做过的、典型的故事，例如：1. 对单个表进行增删改查2. 对父子表的增删改查3. 为一种已经存在的数据表增长一种复杂报表4. 修改一种中档难度的BUG（事实上这些故事应当是具体的，而不是像上面例子中同样看起来更像是“分类”）然后人拿出当年的历史记录，将当时所投入的人天数称为“故事点数”（也有别的做法但这个最简朴）。例如“对单个表进行增删改查”当年用了4天，那么原则故事点就是4。当

30、下次估算时，人们又发既有一种故事也是“对单个表的增删改查”，于是就先选定基数为4，再讨论这次与上次比，究竟复杂多少。如果一致觉得也许复杂20%，那么故事点就是5。如果人们的生产率不变，那么这个故事应当5天完毕，但是如果成果却是4天就完毕了，则表白人们的生产率提高了。固然不是一种一种故事度量，而是把整个迭代内的故事点加起来度量。通过纵向比较故事点，可以懂得人们与否比此前的生产率提高了。横向比较故事点比较有难度，由于每个团队乃至项目都会选定自己特有的原则故事，并且很难阐明这个团队和那个团队的原则故事的转换关系。故事点的局限性在推广故事点这件事情上笔者有所保存，建议尝试但需注意风险，必要时知难而退。

31、在笔者遇到的这样多做敏捷的公司和人里边，还没有见到有人提到她们的故事点应用是成功的。因素在于找到人们都熟知的、以往做过的、典型的故事很难，而让所有人记住它们当年的具体状况以便后来对比修订就更难。笔者去做征询的一家公司有她们的故事点模板（她们并不做敏捷开发，但却使用完全类似的措施），一共有17种原则故事，已经记录了25个项目的故事点数据和实际工作量数据，每个项目从4个故事到上百的故事不等，她们但愿笔者能帮她们计算一下“17个原则故事分别相应多少人天”。终于遇到了又有原则故事又有历史数据的状况，这比所有一穷二白想使用故事点的公司可乐观多了。这是一种所谓“线性规划”的问题，波及“最小二乘法”“超越方

32、程”这些玄乎的名词，但却在Excel表里有这个功能，但是是10分钟的事情并不费力，真正费力的是解释其成果：求解的答案是某些原则故事是负数，也就是说如果把这几种故事当作负数看待，那么以往发生的25个项目的预测成果与实际成果最符合。再换一种直白的解释：用这17种故事预测工作量不准。或许有人会说她们的17种故事选得不好，或她们的水平很差。怎么说呢，她们是一家1000多人的电信公司，专职做过程管理的人就有5人，还认真地记录了这样多数据，恐怕当年选定故事的过程也是通过思考的。倘若她们都难以建立其故事点，一般的10人团队想自己做一套恐怕更难。回过头来观测她们公司的失败因素，是在为新的故事找到相应的原则故事

33、后，没有根据其差别进行调节，而是机械地选择了原则故事的故事点，导致误差很大。在采用故事点的时候应当注意。但她们考虑到某些故事的回归成果居然是负数，虽然“进行调节”成果也会是血淋淋的，甚至可以说基本扔到了原则故事从头估算，最后放弃了故事点，采用了此外一种措施，就是下篇文章提到的“功能点估算”。笔者之前的一篇文章有故事点估算措施的更详尽的简介，但角度不同：敏捷估算：故事点与直接估算天数的差别故事点为我们提供了一种比较客观度量敏捷生产率的措施，但其局限性限制了其应用。下一篇文章将简介此外一种广泛应使用的措施：功能点估算法。敏捷开发绩效管理之六：敏捷开发生产率（中）（功能点分析，FPA，简化的功能点）

34、直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚初期，面临与客户有关的报价问题，或高层领导要记录公司绩效并想进行项目乃至行业间的比较，这两种措施都很难使用。敏捷开发内部之因此没有进化出来能做项目间比较、行业间比较、用于初期报价的估算措施，是由于敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故事点，在老板眼中更接近生产率绩效。这时候就需要功能点估算。功能点估算由来功能点估算是此外一种世界的事情。每100个懂敏捷的人中，也许才有1个懂CMMI；而懂CMMI的人中，也许才有100个懂功能点，而100个懂功能点的人中，也只有1个人懂敏捷这就是三个世界，但每个世界都和敏捷

35、世界同样热闹，同样有可操作的措施，只是互相不通信而已成果是，每个世界都不懂得别人已经早就解决了自己冥思苦想的问题。用功能点度量软件的目的，是在初期获知软件开发的工作量，进而推算开发成本。 由于这个目的，使得它事实上是与开发工作量的有关性也最强（远远超过Delphi/代码行/故事点/用例点多种国家的政府使用此估算采购软件，中国大概2年就后采用），并且居然和顾客故事尚有较好的相应关系。功能点自身很复杂，人们可以在网上查到某些资料，这里不多说了。原则功能点分析特别复杂，有一次有一种欧美发包商来到中国，问“我们目前已有100多页文档，谁看过之后懂得这个项目要多少钱才干开发出来，以及为什么，我们就把这个

36、项目给她。”笔者介入了此事，也懂得原则功能点能解决这个问题，但是却不能在给定的时间内完毕（只有2天的时间解决此问题，而用功能点至少需要1015天）国外ISBSG也转发度量Guru Capers Jones的邮件称“只有很少数的项目采用了功能点估算，由于成本太高”。这件事情促使笔者尝试找简朴的功能点估计措施，直到后来在此外一种世界发既有人早就解决了大概了那就是NESMA的简化功能点，如果不嫌麻烦请参阅（点击左边 Advanced 下面的 Early&Fast FPA）。但是建议直接看下面。下面的概念作了很大的调节以便于用有限的文字理解，如果有懂FPA的读者看出破绽不要奇怪（本人是正规做FPA培训

37、和研究的）。什么是简化的功能点估算在我们的开发工作中一共有两类东西要开发，一种是数据，一种是操作。所谓数据，就是例如要编写一种CRM，其中有“顾客、角色、权限”这三种东西，就是要管理的数据，这里权且记下顾客有“3个数据”要管理。所谓操作，就是对顾客，应当有增、删、改、查、加入角色这些称之为操作，这里权且记下对顾客，顾客会做“5个操作”。倘若角色和权限没有操作（虽然这是不也许的），那么在NESMA简化措施中由于每个数据是7点，而每个操作是4点左右，那么就可以算出来一共有：3 7 + 5 4 = 21 + 20 = 41点。ISBSG/IFPUG涉及中国的CSBSG等均有不同行业/不同类型软件的生

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

39、板在酒桌上刚从客户那记下来的），就猜出有多少个操作？并且还不漏掉？增删改查好猜，“加入角色”就不好猜了。怎么办？请看下文。敏捷开发绩效管理之七：敏捷开发生产率（下）（简化功能点分析，NESMA，两级简化）功能点估算第一级简化上次说到只用数据+操作就能精确计算规模，听起来够简朴了，但其实还不够。谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？并且还不漏掉？增删改查好猜，“加入角色”就不好猜了。NESMA早就遇到过这个问题了，她们这样解决：通过记录发现每个数据差不多有7个操作，因此刚刚我们找出了3个数据，那么：3个 （数据7 + 操作47个操作） =

40、3 35 = 105，嘿，把角色和权限的操作问题也给解决了，不用猜了。如果有几种数据要管理也不懂得怎么办？那也太粗糙了吧，再去细化一下吧（别细化报表上有几种按钮，按了按钮后的逻辑是什么那个和规模无关；只确认是不是数据）。这样准吗？来自课后的10个数据表白，基于这种功能点作出的工作量估算与实际项目数据相比，最大误差在正负50%左右（本人手里没有具体数据因此没分析，应当取P50就是中值的误差比较好，也许在30%左右）。虽然听起来误差大得乍舌，但是在手里只有2张纸的时候，已经很精确了。某政府部门的规定是到400%以内都可以接受，由于她们在一种项目的招标中，4个供应商报价最大差别是12倍。总结一下这一

41、级别的简化措施就是：每个内部数据35点。此外如果是外部接口数据（例如要取LDAP），那么每个外部接口数据15点。第一级简化适合项目合同期/项目初始筹划的初期估算。第二级简化如果项目已经完毕了，不用猜了，就可以数究竟有几种操作，就不用猜每个数据有7个了。但是，到软件界面上面数显的很不专业，如果我们的史诗故事是基于数据写的，顾客故事是基于操作写的，数史诗故事+顾客故事不就得了？例如图中这个：图中就是刚刚提到的顾客/角色/权限的局部，一共3个数据（小课本是史诗故事），外加19个操作（蓝色的是顾客故事，其中两个“新建+查看”分别代表两个，要2），加起来是 3 7 + 19 * 4 = 21 + 76

42、= 97，已经很接近105个了如果考虑到这个软件还没有编完，我们第一级简化还是蛮准的嘛（归功于NESMA的长期努力）。完毕这些功能需要 105 9 = 945 小时 = 118人天。如果我们有一种迭代，正好要完毕这些功能并将其部署上线，那么就按118天计算吧（如果只编写出来不测试，大概是70%的工作量）。固然这不是说任何一种人都花相似的时间，而是基于目前业界收集上来的数据，团队人均耗费这样多。个体的生产率差别可达5倍，但团队却都差不了太多。此外单个故事的精度也很差，例如如果某人正好编过某功能，也许一小会就完毕了。但是如果诸多人编写诸多故事，大数定理睬起作用。总结一下这级别的简化措施就是：每个内

43、部文献按7点（每个外部接口按5点），每个操作按4点，加起来就是功能点。这个级别的简化适合每个迭代拟定工作量；还可以在项目完毕后，总体计算开发效率作为绩效管理的根据（算是回到绩效管理了）。遗留问题正如前言，诸多敏捷世界的新鲜事，在别的世界早就不是新鲜事了（固然别的世界也有她们的新鲜事），提出和解决下面这些问题的诸多前辈都已经去世了。本文只是指出有这样一种措施，并非这种措施的操作手册，这种措施还是需要培训的（有现成的）。1. 就这样简朴？不是，简化的功能点大概需要一成天的培训，后续估算（推导工作量/工期/成本）还需要一成天。里边有诸多细节。复杂的功能点大概需要23天培训，此外一般5天左右的指引，如

44、果要CFPS证书尚有一种3天左右的考前指引。2. “每个顾客操作 = 一种顾客故事？那修Bug怎么办？做小的改动怎么办？提高性能怎么办？”可以记录成不同类型的故事，但是就别计算功能点了。图中三个绿色箭头，就是三个对原有故事的“增强”，其特点就是无法描述为完整的顾客操作。她们不计数，但是在记录时已经被平摊到计数的故事里边了。我自己实践的时候发现，有些故事为了开发以便，极有也许涉及两个操作（如上面的“角色首页”涉及新建和查询两个操作），建议可以当作一种故事，怎么舒服怎么来不要太生硬，但是加个记号懂得是2个操作，避免数错。3. 每个数据都是/才干是史诗故事吗？不一定，我有一种史诗故事叫做“性能优化”

45、，它就不是，也不计算它。4. 每个动词都是操作？不一定。简朴而言就是只有”主语是顾客“的动词才是操作。”。临时还没有遇到有些Backlog Item不是顾客操作但是很想当成顾客故事的状况，如果有，可以在史诗故事/顾客故事上设立一种字段，如果是才计数。5. 非功能性需求怎么办？最早提出来也最早被解决的问题，原则功能点的非功能性调节因子是1970左右（天啊）提出的有点老了多数都不合用了；个人最喜欢的是韩国原则中的调节因子，大体可以理解为一般的乘1，科学计算之类的乘1.3左右，运营计费乘1.5左右，生死攸关的乘2左右。非功能性调节因子一般涉及规模因子、领域因子（韩国原则涉及8大类约50小类）、质量因

46、子（韩国原则涉及4个质量因子，每个三个级别）、开发语言因子这几种。有时候不会觉得她们考虑不周，反而是多虑了6. 准吗？不准。由于这种措施虽然很准，但是那个”9小时/功能点”是业界数据，最佳用自己的数据重新回归一下。本人正在回归自己的，可惜只有一种项目在做，因此不得不每个迭代都当作项目来看待。一般稍微大点的公司有一年时间积累20个（子）项目数据就可以了。7. 有前程吗？有。芬兰，澳大利亚，韩国，日本的政府采购均采用这种措施计算价格。中国的国标估计在来年出台，即政府采购项目均将使用这种措施报价（或指引报价）。8. 有的项目好坏可不是光看开发的功能多少，还要看创意和是的，用这种措施度量绩效的目的，是

47、为了提高开发绩效，加快开发速度，而不是计算工资奖金或评价项目好坏。在之四里边已经提到，必须在赚来钱的时候才干发奖金，它是由外部目的驱动的。在产品开发中，往往收入与功能多少的关系不很直接甚至完全没有关系，但在某些直接由功能点报价的政府项目、外包项目里边，这个可以直接作为外部目的考核。敏捷开发绩效管理系列之八：阿米巴经营之前言每次敏捷开发培训课上，最备受关注的问题可以说是团队管理和绩效管理。“敏捷开发注重团队合伙”“敏捷开发不考核个人”“敏捷开发放权”“敏捷开发对人的积极性规定高”这些新话题可以说对一般程序员而言是非常陌生的，由于一般的程序员，基本上是距离客户最远的人。前面有市场、销售、售前，背面

48、有测试、技术支持，因此最有理由远离“尘世纷扰”，只需遵循指令照章办事。一旦程序员们被“放权”“积极”考虑“客户价值”并与队友们“团队合伙”并且“不被考核”，反而不知所措。阿米巴经营就是解决这个问题的。本文会通过对阿米巴经营与软件开发管理及敏捷开发之间的关系，配合本人在一家公司管理市场/销售/实行团队时做的绩效管理改革（当年的营业额同比增长200%），分析软件行业实行阿米巴经营的某些潜在措施。前言：何为阿米巴经营阿米巴经营简朴说就是把公司分解成众多独立工作的小组，而每个成员都具有经营意识和行为。对常年做开发的程序员而言，阿米巴经营整体还是不太好理解的。下面结合软件开发业的特点，及敏捷开发中有关的

49、术语，做某些简介。阿米巴经营有5个大目的，她们是：1. 全员参与经营这是一种典型的唤醒沉睡员工的思路。什么是沉睡员工？百度近来的狼性与小资的消息可以说做了一种完美解释：李彦宏将狼性文化定义为敏锐的嗅觉、不屈不挠奋不顾身的攻打精神，群体奋斗。她同步表达将裁减小资，她将小资定义为有良好背景，流利英语，稳定的收入，信奉工作只是人生的一部分，不思进取，追求个人生活的舒服才是所有的人。“要让所有员工更明确如果想找一种稳定工作不求有功但求无过的混日子，请目前就离开，否则我们这一艘大船就要被拖垮。”软件公司整体上有两大类人与“经营”距离甚远，一种是行政人员（HR、财务、文秘），此外一种是技术人员（开发，测试

50、，美术，技术支持）；而经营感最强的则是业务人员（市场，销售，售前，产品经理），固然尚有公司老板。如果管理不当，很容易导致经营感若的人员变成“小资”。2. 以核算进行目的管理有些岗位是非常难以核算的，例如行政人员。技术人员也不是太容易进行核算，别看守理指标一大堆（进度，质量，成本），但是要具体拿出一种来做绩效考核，还真的很难。那么应当怎么做呢？答案是：用外部目的对内部人员进行核算。例如如果用内部目的度量开发人员，开发人员会告诉你说：“我们的生产率就是生产代码（或更高档一点，功能点），因此要想提高生产率，就多招聘某些人吧”。而对外部目的而言，生产率是赚钱的速度，也就是人均产值，面对这个目的，开发人

51、员要重新思考：“客户买我们产品的目的是什么，哪些功能值钱，哪些不值钱；能不能用更少的代码完毕这些功能以提高生产率？”注意如果用内部目的，代码少生产率反而低。3. 透明管理一想到透明管理，做软件的第一感觉就是软件度量，其实还否则。公司，无论是哪种类型的公司，第一种需要透明化的东西，就是营收数据：究竟赚了多少钱，哪些部门哪些产品哪些人赚的；究竟花了多少钱，哪些部门哪些产品哪些人花的。如果这些都不透明，简朴度量某些代码行、缺陷率，无益于公司整体的发展。固然有人会说：“我们就是一种一般的开发人员，能度量清晰自己的代码、缺陷就已经不错了，哪有闲心和能力去管理部门和产品？”如果刚刚真的有这种想法，恭喜，你

52、已经成为一种没有狼性的小资了。敏捷开发中的透明化管理多数都是一线数据的透明化，固然因素不是“目光短浅”，而是敏捷开发本来要解决的就是此类问题。但产品经理及产品总监应当具有透明管理的意识，即要意识到自己所管理的产品是一种一方面有收益，此外一方面有投入的循环过程。本来那种不管人力研发成本、甚至不管产品销售状况而只管产品需求的产品管理措施，将不久过时。4. 公司的上下整合有无遇到过这些状况：销售部门需要一种重要的功能才干打动一大类新的客户，所需的时间也不是非常多，但去找开发人员的时候，开发人员都很忙；过了N年M月，新版本一次一次发布，都没有那个重要的功能，而新的客户也因此没有被打动；而新版本发布之后

53、，并没有更多的客户被其中新增的功能所打动；问她们为什么不开发那个销售部门急需的功能时，人们说都很忙这是典型的整合问题，简朴说是销售和开发两个部门的横向整合问题，但从本源上，是老板-销售 与 老板-开发 这两条上下整合线出了问题。换言之，公司的大老板必须懂得自己公司究竟近来在做什么，并让所有部门协同来完毕这个工作。敏捷开发中的产品版本规划与此有关；而产品线规划（敏捷开发中没有提到），与此的关系更大。5. 培养领导人诸多时候，公司的多数人都在避免自己成为一种可以被替代的人，相反，所有人都但愿自己变成独当一面的人，因此自己的位置也就安全了。这是典型的小资思维。但此外某些人则在做相反的事情：她们在培养

54、自己的接班人，并但愿把自己的工作分出去，以便自己可以在更高的位置接手更重要的事情。这个就是典型的狼性思维。诸多人会问：“你培养好了接班人，不仅没有更高的位置也没有接手更重要的事情，反而由于不需要了而被开掉了，怎么办？”这样想的人，多半没有做过这件事情，或者误觉得自己做了这件事情（后来会有文章详述）。敏捷开发中的团队协作，特别是松结对编程及139团队，其主旨就是但愿能培养人的可替代性。特别对团队领导或高手而言，应当意识到有人能替代自己的工作开始是技术上的，之后是管理上的是一件能扩大自己下属团队的最佳措施，也是另下属团队能独立思考自主运营的最佳措施。阿米巴经营在国内尚处在探讨阶段，IT公司更是如此

55、。但是如果人们据说过“内部创业”，或对目前游戏团队的运营模式有所理解，不难想象其操作原理。但是要说到可分享的经验，尚为时过早。之后的文章，将通过这5点进行更进一步的探讨，找到某些思路。敏捷开发绩效管理之九：阿米巴经营之软件团队经营什么（上）若正在为长期没有得到职务提高而感到困惑，下面的内容也许会有所协助。由于越向上的职位越不像一种打工者，而是像一种公司的经营者。何为经营对一种开发团队而言，大体需要“经营”如下四种重要内容：产品，团队，技术，过程。固然仔细分析，也许尚有更多相对次要的内容。对于一般开发人员而言，不太好理解“经营”的含义，然而经营意识的缺少，正好是研发管理中最大的问题之一。曾经有一

56、种与员工一起培训的部门经理，在第一天培训（讲顾客故事，需求管理，顾客建模，版本规划等）最后拍案而起说：“研发团队不关怀市场经营，这个就是我们目前最缺少的！”。具体缺少什么呢？我们来看看一种开发团队的两种职责描述，就能发现问题。这是一种很正常的描述：1. 产品：收集、描述和分析产品需求。2. 团队：筹划并分派人员完毕任务。3. 技术：保证产品的技术先进性与质量。4. 过程：建立和维护项目管理制度。这些都是中规中矩的管理概念，甚至可以说，如果能按上述条目完毕管理，已经属于比较好的了。但在阿米巴式经营，或者说百度提到的“狼性”文化中，这些还不够。因此整体上可以看出，做这四件事情的人，显然是“被雇来”

57、按照“既定制度”管理产品、团队、技术和过程的。固然这里边有一种先有鸡还是先有蛋的过程：“如果我们本来就被雇来奉命行事的，又怎么也许不奉命行事呢？”这正是阿米巴经营要解决的问题。其实诸多时候领导都但愿放权，但当看到所有人对“做什么”都不关怀，而只是盯着“怎么做”，领导就退缩了。经营什么经营产品经营产品就是要真正把产品当作自己要做的东西，而不是别人雇自己来做的东西。要经营的内容，大体涉及：1. 基于产品的商业筹划（时间上的，偏重营收分析）2. 客户群定义（空间上的）3. 产品版本规划（基于时间及客户群的综合分析）实际开发中比较容易忽视的是1和2，典型的状况涉及：1. 开发人员只盯着发版筹划，却不关

58、怀发版的产品的销售状况和客户反馈2. 开发人员不断开发功能，却不懂得产品也许卖给谁，甚至连顾客是谁均有点模糊（在我培训课程中有一种沙盘演习环节，此状况屡屡浮现！）如果陷入了这两种状况，就要思考与否忘掉了积极经营产品。尚有某些比较复杂的后来或许有机会会讲到（确切说，目前还没有足够的能力写出来），例如：产品线规划，即不同产品的搭配，以在原客户群中产生附加值或占领更大的市场。经营团队精英团队就是要把自己的部门、小组当作自己的小公司同样经营。涉及：1. 思考合理的人数和知识体系2. 思考下属员工的职业生涯规划3. 理解和优化团队的投入产出比“投入产出比”是一种很重要的属性，就是要理解自己团队在公司中的

59、位置，并运用营收数据来指引团队的发展。举个例子：曾经有一次我们的团队营业额达到了上一年的3倍多一点，而人们的收入也平均增长了30%左右（这个是估计的），但人们仍然觉得心里不平衡：由于3倍和30%还是有很大差别的。但随后的营收分析揭示了一点：其实虽然我们在营业额暴增之后，每年仍然净亏损150万元左右。有了这个数据，团队就冷静多了，也有了新的目的。这不是说要用这种措施“避免给下属加薪”，而是说无源之水是不长期的，要令团队懂得、思考和改善自己所处的经营状态。对开发团队而言，也许没有直接可以考量的营收指标，但是此外某些指标一般也是一笔糊涂账：团队的生产率？质量？成长性？别说具体的数值，也许连合理的定义

60、措施团队都较少去思考。这些都是缺少经营感的体现。固然要做到精英团队很难！但这正是需要做的因素之一，由于一旦做成，别人很难复制。（待续）敏捷开发绩效管理之十：阿米巴经营之软件团队经营什么（中）经营技术经营技术是说，不要只是把做产品/项目的过程当作完毕任务，而是要当作为提高自己能力的过程和公司积累技术资产的过程。这听起来很容易，但做起来有难度，例如这几种问题：1. 团队与否有一种可复用的技术库？（DLL，类，函数，多种层面的）2. 团队与否有一种机制令得这些库被充足运用？（一种可度量指标就是代码行/功能点，越低越充足）一般而言若不进行有效管理，20人团队的代码冗余率也许在95%左右，也就是95%左

61、右的代码是多余的。在的一次技术改造中，一种19万行，13人9年的产品，被改造为1.3万行，1人1.5年的相似产品（更核心的是缺陷少了，这次改造的直接动因就是本来产品的缺陷众多并且隐藏很深）。这并不是个例：这家公司是纳斯达克上市的上千人的电信软件公司，其开发和管理强于一般的中小公司，后者的技术水平也许更差。但由于普遍而言人们使用别人代码的比例很低（我们常常感觉到用过别人的东西，但若自己数数，又会发现但是就几百行代码而已），因此人数越多可压缩的比例越高；再加上由于多数人连自己的复用做的也不好，因此在未完善管理的状况下，对代码进行大规模压缩的潜力一般都接近在2人数倍以上。注意这个例子中，较少的代码不

62、仅有更高的生产率，质量也随之提高，甚至更加明显。类似这种规模和周期的软件及团队，都应当刻意地在开始就不要只以完毕目前任务为唯一目的，而开始架构和积累整个技术架构。“若刚开始的时候老板不给充足的时间怎么办？”一则我历来没有见过老板指着我们的可复用库说：“不要编写这个，直接给我垒代码”；二则及时被予以足够的时间，多数团队也没有形成这样的可复用库；三则可复用库的生效速度是不久的，若前三个月投入复用的时间还没有赚回来，那么多半做错了考虑到这些，多数时候缺少对技术的经营，其实是我们软件人员自己的问题。经营过程过程就是人们做事的措施，说大某些，就是“公司文化”。文化是很容易被谈论又很容易被忽视的东西。诸多底层的程序员能看到远在天边的公司文化，但却看不清晰自己面前的编码文化。在的一种团队里边（就是我第一次感受松结对编程与139团队的那个团队），刚开始只有5个人，人们不需要专业的测试人员而仰赖高手协助新手查看代码和自己自主测试来保障质量；一年后来，当团队扩张到25个人的时候，这个老式仍然存在此时我们的专业测试人员只有2