随笔分类 - 绩效管理
摘要：这是敏捷开发般若敏捷系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）除了上篇开头中提到的四个问题（“拥抱客户价值，拥抱变化”，开发与测试的融合，团队合作，协作重于流程），其实敏捷开发中还有很多实践，都是从模糊利益和绩效界限的角度出发得到的，比如持续集成和自动化测试，两者甚至模糊了长期和短期利益的边界。依然如前文所说，这里指的不是敏捷开发发明了两者，而是说敏捷开发将两者当作根本大法来对待。无轮回观的享乐主义在无信仰而人口众多的国家，很容易滋生享乐主义。人们因而很难理解有信仰的国家，为什么会有人把巨额资产裸捐，而保持过着简朴的生活，以换取“天堂的生活”或“来生的幸福”。这种情
阅读全文
摘要：本文是敏捷开发产品管理系列的第三篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）上周在培训做“用户故事的用户建模”练习的时候，就有人提出一个疑问：这么短的时间里边，能定义好用户群和用户群分类吗？答案是：不能。用户群的规划是产品概念期就应该完成的工作，它是一个产品管理工作，而非需求管理工作。用户群定位这里仅就自己所从事的互联网行业提出一些简单看法。这些看法与本人在做的产品密切相关，因此在别处可能会不适用，仅作参考。我们整体把用户分为人气用户和付费用户两种。这个与互联网通行的分类方法很接近，相
阅读全文
摘要：本文件做通知，下载链接/版本记录/讨论请前往主贴：http://blog.csdn.net/cheny_com/article/details/6616794更新时间：2011-09-12 16:18更新内容：新增两页“敏捷绩效管理”。另有一些页面已经做好，但更接近“松结对编程”的内容，将在下一发布日期发布。下一发布日期为2011-10-31。
阅读全文
摘要：这是敏捷开发绩效管理的第七篇。（之一，之二，之三，之四，之五，之六，之七） 续前文……功能点估算第一级简化上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7个操作，所以刚才咱们找出了3个数据，那么：3个 × （数据7 + 操作4×7个操作） = 3 × 35 = 105，嘿，把角色和权限的操作问题也给解决了，不用猜了。如果有几
阅读全文
摘要：这是敏捷开发绩效管理的第六篇。（之一，之二，之三，之四，之五，之六，之七） 直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故事点，在老板眼中更接近生产率绩效。这时候就需要功能点估算。 功能点估算由来功能点估算是另外一个世界的事情。每100个懂敏捷的人中，可能才有1个懂CMMI；而懂CMMI的人中，可能才有100个懂功能点，
阅读全文
摘要：这是敏捷开发绩效管理的第五篇。（之一，之二，之三，之四，之五，之六，之七）度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。度量敏捷生产率的目的真正难以回答的是度量生产率的目的是什么？很多人都认为是考核绩效，发奖金。根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目盈利，应该为团队设立外部目标，否则很可能得到一个生产率很高，但是实际上很烂产品——质量上或易用性上很差，抑或其他想象不到但一定遇到的原因。这是我们说为什么用外部目标而非内部目标考核团队的原因。或许又有人说
阅读全文
摘要：这是敏捷开发绩效管理的第四篇。（之一，之二，之三，之四，之五，之六，之七）最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。“内向型”绩效及其导向进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。质量：“千行代
阅读全文
摘要：这是敏捷开发绩效管理的第三篇。（之一，之二，之三，之四，之五，之六，之七）如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬——大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一个共进退的团队。本文的部分内容在之前的若干博文中提到过，因符合本系列的内容，在此处从另外一个角度加以说明。领导压力领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或企业非常
阅读全文
摘要：这是敏捷开发绩效管理的第二篇。（之一，之二，之三，之四，之五，之六，之七）团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。笔者因为工作原因在过去16年里与100多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。中医治病的原理中医和西医看待疾病的角度差别很大。中医受到当年条件所限，并不知道致病的原因是细菌、病毒还是其他什么。由于没有显而易见的敌人，中医采取的策略是扶正去邪，就是让让人体自身加强，从而自然地消灭”邪气“。比如中耳炎，西医的解释是：“多由感冒引
阅读全文
摘要：这是敏捷开发绩效管理的第一篇。（之一，之二，之三，之四，之五，之六，之七）“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”，而是“如何利用敏捷开发提高绩效”。何为绩效管理绩效管理常常被片面理解为绩效考核，即如何确定个人的绩效，如何提工资和发奖金的问题。实际上绩效管理还包含制定绩效目标，制定绩效计划，制定
阅读全文
摘要：这是敏捷生态系统系列的第四篇（之一，之二，之三，之四，之五）。一半内容属于需求管理生态，一半内容属于计划跟踪生态。在实际开发环境中，产品负责人常常和开发组存在潜在的利益对立。前者往往希望在更短的时间开发出更多的功能，而后者的绩效则多数来自于计划按时率/缺陷率这些会因“更短-更多”而下降的数据，于是两者的隔阂从此开始。敏捷开发中的计划跟踪生态II大致如此（黑体字即图片中的元素）：☺ 产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。☺ 产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。☺ 团队的权利在于开发人员自己估算
阅读全文
摘要：本文是“松结对编程”系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八）松结对编程是小型团队的实践，大约运行在1个师傅+1～3个徒弟的尺度上，当面临更大尺度的时候，就需要大型团队模型。这里推荐139团队模型，因为它不但可以让松结对编程运转顺利，还解决了大团队沟通、绩效考核、师傅的出路等问题。139团队的整体情况相当复杂，将另有系列博文描述，这里只描述与“松结对编程”相关的内容，以保证本系列博文的完整性。基本概念139团队就是1个项目经理，3个师傅，9个徒弟的简称，当然实际上未必正好凑够13个人，也未必正好每个师傅都有3个徒弟。在第一篇里边已经提到过三个层级的工作关系，下面是一些深入
阅读全文
摘要：本文是“松结对编程”系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八）松结对和紧结对不一样，两个人不是总坐在一起随时发现问题解决问题，而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个：一是看结果是否符合需求（做什么），而是看代码是否存在问题（怎么做），后者就是代码检查。代码检查（也称代码审查Code Inspection）是一种由来已久但是很神秘的东西，最初引入是在一些生命攸关、重大财产相关的软件开发中，典型的就是SSOS（美国航天飞机的软件），其每段代码都交由6个人审阅，方可入库。成果就是在1989年之前（之后笔者没有数据），SSOS在太空中失效次数只有一次。笔者亲身
阅读全文
摘要：本文是“松结对编程”系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八）团队中常见的一种情况计划、估算、设计的时候大家还在一起，但编程的时候就会分开。分开看似是安全的，但是却充满隐患。2001年，一位招聘考试前三名（一共120员工）的程序员的两个月的成果被彻底放弃重写，原因是里边包含3000多个常数，而且很难修改（码流参数），重写的人座位距离他只有4米，重写也只花费了2周；2002年，一位月薪7000（那时候北京房价才3000多）的程序员编写了一个月的4000多行代码，在一个下午被重写为50多行，座位距离他只有5米的项目经理疑惑加惊讶地问：“你真的没学过c++ template？”
阅读全文
摘要：本文是“松结对编程”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八）估算是经久不衰的管理话题，大致分为两种流派。第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以不怕。第二种是自我管理派（偏敏捷），就是由具体开发的人员自己说开发工作量，领导和他人不干预。尽管“自组织”了，但是领导深以为这种方法留下了偷懒的种子，而队员也觉得某人的估算很不靠谱（太长或太短），到底怎么办呢？共同估算吧。--------
阅读全文
摘要：本文是“松结对编程”系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八）新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？新人的真正问题在于无心办错事和好心办错事。无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。好心办错事包括想做一个比领导想想的更好的功能、过度思考了可复用性可维护性等。这两个问题笔者都经历过（作为新人和老人），“避免”是最好的方法，而不是事后改正，这就需要在设计阶段和计划阶段从技术、管理两个方面来提前预防。----------------------
阅读全文
摘要：本文是“松结对编程”系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八）传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况。二是来自基层的，两人若有高低，高手肯定觉得还不如我一个人干的快；两人若旗鼓相当，难免产生争执。其实在我们身边一直有一种方法很像结对编程：“师徒制度”，就是每个新人来到公司，都指派一个师傅带着，在技术与业务方面提供指导。他们既不用一台电脑
阅读全文
摘要：本书是德鲁克历年作品的精简摘编版本，目的是为了解决“德鲁克的书这么多”，到底应该从哪里看起的问题。可以作为中等快餐作品来阅读。本书分为三个部分：管理篇，个人篇，社会篇。本人是从“个人篇”开始读的，另外两篇还不太适合理解。整体文风比较严肃，从文学上讲有点枯燥。不过内容非常真枪实弹，很难想象是很多年前的见识（注意在前言里边有关于哪段内容来自哪年的哪本书），感觉甚至预言了当前手机厂商Nxx的衰落。购书点击这里：http://product.china-pub.com/192880点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
阅读全文
摘要：作者：陈勇来源：blog.csdn.net/cheny_com 合成谬误由萨缪尔森提出：倘若每个人都基于自身作出最佳选择，所有人选择的合成结果极有可能是大家的公共福利受到伤害。 合成谬误的一个典型的例子就是公地悲剧（tragedy of the commons ，哈定提出），即若有一片公共草地允许所有人自由放牧，则每个人都会尝试略微增加自己的羊群数量，直至草地被耗尽为荒地。小至混乱的购票窗口、踩踏事件，大至银行挤兑、股票抛售，远至古代皇子们的勾心斗角，近至中国乳业的衰落，都能看到合成谬误的影子。 为了解决合成谬误问题，一般需要引入高于各个独立个体的公共管理才能解决。比如排号机可以解决排队问题，
阅读全文
浙公网安备 33010602011771号