陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》

这是敏捷开发与中医理论系列的第二篇。（之一，之二）由来中国古代的很多技术或艺术，都是没有学校教授的，譬如中医，戏曲，民间艺术，食品，酿酒……但却不乏流传千古的名家和作品，唯一问题就是流传缓慢，传内不传外，传男不传女……。现在终于有了大学，流传速度应该加快了，但是呢？上次路过中国X

本文是“松结对编程”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）估算是经久不衰的管理话题，大致分为两种流派。第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以

本文是“松结对编程”系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况

这是敏捷开发绩效管理的第四篇。（之一，之二，之三，之四，之五，之六，之七） 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交

这是敏捷开发绩效管理的第三篇。（之一，之二，之三，之四，之五，之六，之七） 如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬——大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要打造一个

这是敏捷开发绩效管理的第五篇。（之一，之二，之三，之四，之五，之六，之七） 度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。 度量敏捷生产率的目的真正难以回答的是度量生产率的目的是什么？很多人都认为是考核绩效，发奖金。根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目

这是敏捷开发绩效管理的第六篇。（之一，之二，之三，之四，之五，之六，之七） 直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故

这是敏捷开发绩效管理的第二篇。（之一，之二，之三，之四，之五，之六，之七）团队管理是个由来已久的话题，各式各样的管理理论和方法层出不穷。笔者因为工作原因在过去16年里与100多家企业的团队或团队领导者有较为深入的交流，看到了听到了想到了很多相关的内容，下面做一个总结。不过受个人经历所限，这不是一个客观的全面的总结，而是带有本人的角度和主张，仅供参考。 中医治病的原理中医和西医看待疾病的角度差别很大

这是敏捷开发绩效管理的第一篇。（之一，之二，之三，之四，之五，之六，之七）“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发

这是敏捷开发绩效管理的第七篇。（之一，之二，之三，之四，之五，之六，之七） 续前文…… 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7

本文使用三个例子，来说明如何灵活使用不同类型的度量数据，来表征生产率在短期、长期、内部、外部的实际情况。

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 第二个月从图形到Word测试经理正在审视第一个迭代的测试用例——因为历史原因，他们还没有形成真正的开发+测试的混合团队，独立的测试团队还只能在每个迭代后期单独执行

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 第一个月从用例到用户故事，从用户故事到代码在敏捷计划会上——是的，他们采用敏捷开发，确切说是Scrum——产品经理正在给开发人员讲解需求。他并不是空手来的，而是带

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 第三个月​结项度量第三个月月底，项目成功交付。看惯了文山会海，高层领导希望这个小项目做一个简短的总结。结果他看到了下面的表格：功能点耗时率是指完成每个功能点需要5

QUML作为UML、功能点分析FPA、敏捷开发三种管理方法的集大成者，可以被应用于不同的场景。以下的图书各自侧重于一个方面，供不同领域的读者选择。《QUML：量化需求分析与建模》本书从需求分析与建模的角度，介绍QUML的结构、规则、使用方法，是QUML的基本图书。全书通过对一个电商网站的实例分析，分层次地介绍了QUML的结构、用途、规则和最佳实践；书中还概要地对如何将UML应用于早期估算、产品版本

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 本章讲解如何将非常模糊的高层需求，也就是愿景，表达为一个清晰、简单、确定的模型。基于这种简单的模型进行开发，要比基于大段似是而非的文字更容易得到最终想要的结果。什

本文是“松结对编程”系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？新人的真正问题在于无心办错事和好心办错事。无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。好心办错事包括想做一个

本文是“松结对编程”系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）团队中常见的一种情况计划、估算、设计的时候大家还在一起，但编程的时候就会分开。分开看似是安全的，但是却充满隐患。2001年，一位招聘考试前三名（一共120员工）的程序员的两个月的成果被彻底放弃重写，原因是里边包含3000多个常数，而且很难修改（码流参数），重写的人座位距离他只有

本文件做通知，下载链接/版本记录/讨论请前往主贴：http://blog.youkuaiyun.com/cheny_com/article/details/6616794  更新时间：2011-09-12 16:18更新内容：新增两页“敏捷绩效管理”。另有一些页面已经做好，但更接近“松结对编

作者：陈勇来源：blog.youkuaiyun.com/cheny_com    合成谬误由萨缪尔森提出：倘若每个人都基于自身作出最佳选择，所有人选择的合成结果极有可能是大家的公共福利受到伤害。    合成谬误的一个典型的例子就是公地悲剧（tragedy of the commons ，哈定

本文长期更新，请常来看看。 •    序言–  从代码行到故事点敏捷估算：故事点与直接估算天数的差异 –  下一步？•    敏捷团队绩效管理–  谁来管理团队中的个体？同行压力（兼谈敏捷团队，绩效管理，自组织团队）目标管理（百度百科）–  敏捷团队的目标–  从团队外部认识团队

作者：陈勇来源：blog.youkuaiyun.com/cheny_com 在网上能找到不少彼得定律的文章，不过由于彼得定律的提出的时间很早，因此论述在IT公司中影响的内容很少，本文结合一下IT公司的特殊情况略加说明。彼得定律彼得定律大意为：在一个等级制度中，所有人都将被最终提拔到一个无法胜

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 定义简单看，139团队就是1个项目经理，3个小组长，9个开发人员，小组长管理各自管理3个左右开发人员。139团队从管理上缩减了团队规模，可以被视同只有1个项目经理和3个小组长，细节交由小组长处理。这样就方便在大型团队

（原文载于教堂墓地的一块墓碑上，但主人不详）When I was young and free and my imagination had no limits, I dreamed of changing the world. As i grew older and wiser

作者：陈勇出处：blog.youkuaiyun.com/cheny_com谦虚一词在古今中外的差异和变化都很大，古、中似乎更谦虚一些，人们用“哪里哪里”“不敢不敢”“我还差得远”来应对别人的表扬，而今、外则喜欢“谢谢”欣然接受，甚至用“我能！”来向世界表达自己的能力。那么到底什么是谦虚呢？或

平衡计分卡方法可以认为是一种很好的同时关注企业生存与发展的绩效管理方法，但是应用起来却很难。本书很好地解释了如何动态地应用平衡计分卡方法。 本书中文版在China-pub长期脱销，但在免费的Google Book有一个相对而言非常完整的英文版本，70%以上的页面均可预览。 如果没

本书是德鲁克历年作品的精简摘编版本，目的是为了解决“德鲁克的书这么多”，到底应该从哪里看起的问题。可以作为中等快餐作品来阅读。本书分为三个部分：管理篇，个人篇，社会篇。本人是从“个人篇”开始读的，另外两篇还不太适合理解。整体文风比较严肃，从文学上讲有点枯燥。不过内容非常真枪实弹，

这是敏捷生态系统系列的第四篇（之一，之二，之三，之四，之五）。一半内容属于需求管理生态，一半内容属于计划跟踪生态。在实际开发环境中，产品负责人常常和开发组存在潜在的利益对立。前者往往希望在更短的时间开发出更多的功能，而后者的绩效则多数来自于计划按时率/缺陷率这些会因“更短-更多”而下降的数据，于是两者的隔阂从此开始。敏捷开发中的计划跟踪生态II大致如此（黑体字即图片中的元素）：☺ 产品负责人（PO

本文是敏捷开发产品管理系列的第三篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）上周在培训做“用户故事的用户建模”练习的时候，就有人提出一个疑问：这么短的时间里边，能定义好用户群和用户群分类吗？答案是：不能。用户群的规划是产品概念期就应该完成的工作，它是一个产品管理工作，而非需求管理工作。用户

这是敏捷开发般若敏捷系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）除了上篇开头中提到的四个问题（“拥抱客户价值，拥抱变化”，开发与测试的融合，团队合作，协作重于流程），其实敏捷开发中还有很多实践，都是从模糊利益和绩效界限的角度出发得到的，比如持续集成和自动化测试，两者甚至模糊了长期和短期利益的边界。依然如前文所说，这里指的不是敏捷开发发明了两者，而是说敏捷开发将两者当作根本

本文是“松结对编程”系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）松结对编程是小型团队的实践，大约运行在1个师傅+1～3个徒弟的尺度上，当面临更大尺度的时候，就需要大型团队模型。这里推荐139团队模型，因为它不但可以让松结对编程运转顺利，还解决了大团队沟通、绩效考核、师傅的出路等问题。139团队的整体情况相当复杂，将另有系列博文描述，这里只描

本文是“松结对编程”系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）松结对和紧结对不一样，两个人不是总坐在一起随时发现问题解决问题，而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个：一是看结果是否符合需求（做什么），而是看代码是否存在问题（怎么做），后者就是代码检查。代码检查（也称代码审查Code Inspection）是一种由来已久

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 角色-业务图（RB图）下面是QUML中使用的方法，称之为“角色-业务图”（Role-Bussness Diagram，简称RB图）。通过分析角色和主要业务，表达愿