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

这是敏捷开发与中医理论系列的第一篇。。（之一，之二）最近一个世交的中医朋友到梁冬的正安药坊上班，也去实地参观了一下。因为之前的一些经历和最近的几天的交流，一点点悟到一些中医理论与软件研发管理的共同之处，写在这里成一系列。这里的很多内容来自于与这位朋友沟通所得，并与之前更早听《冬吴

总目录问题系列：之一，之二，之三，之四，之五，之六，之七，之八之前提到过，正确的答案一定简单，怎么连问问题都需要简单呢？这也是最近的感悟。佛经《金刚经》上有一段文字：（须菩提问世尊）“善男子，善女人，发阿耨多罗三藐三菩提心，应云何住，云何降伏其心？”大致意思就是问善男信女们，如果想学佛，应该基于怎样的出发点，怎样稳定心态。如果30天前我有机会问这个问题，多半会这样问（现在不会了）：“我吧觉得天天搞

总目录：之一，之二，之三，之四，之五，之六，之七，之八 这是2011年7月的一次QQ群对话记录，做了匿名化处理，并重新调整了顺序，以便于阅读。对话的开始，是有人提到他们公司的产品部门和开发部门正在打架，后者希望能有写好的或者至少是靠谱的产品定位和功能文档，而前者则认为根本不存在这种文档，肯定是想到哪里做到哪里；而后者又认为没有这种文档，一是不知道做什么，二是返工肯定太多。总之是两个部门为一个先有鸡

总目录：之一，之二，之三，之四，之五，之六，之七，之八 是否见过这种场景：一堆人在会议室，谈论一个亟待搞定的客户：“这个客户可难缠了……”“可不是，我给你说……”“对对，我也是有亲身体会的，比如……”“别提了，上一次……”又如一堆人在会议室，讨论一个新的市场方向：“这个新方向不好开拓，……”“咱们刚开始，你看人家IBM……”“别提IBM了，就光一个XX就够我们受的……”“咱们一无案例，二无资金，三

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

这是敏捷开发般若敏捷系列的第九篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）经常听到有人提到敏捷开发与“本能反应”非常近似，比如凡事都需“看着办”，比如“不拘泥于形式”，比如“直击代码，不写无用的文档”等等。那么敏捷开发与本能反应之间的差别是什么呢？简单地说，敏捷开发就是无我状态的本能反应。无我，无人（无我，无人，无众生）按理说，本能反应是最接近最佳路径的，一线人员，工作现场，当下的

本文是敏捷外包工程系列的第三篇。（之一，之二，之三，之四） 下面的很多外包场景以国内的外包为例，因为往往这些项目更加严苛。外包合同常常是固定价格固定工期固定需求（一般称为定额合同），这个时候“拥抱变化”的敏捷感觉意义不大，那么敏捷开发是否就无用武之地了呢？其实不然。下面的一些用法，是利用敏捷开发来促进这种固定合同的达成。在提出这种“如果……，不但……，而且……，那又怎么办呢？”的限制性问题时，不能

本文是敏捷外包工程系列的第一篇。（之一，之二，之三，之四）本系列是中科院研究生院《软件工程硕士-外包方向》的《敏捷外包工程》课程的课外扩展阅读材料（本人是此课程讲师）。同时也适合软件外包公司在本公司推行敏捷开发时参考。 定义这里的“外包”指广义的外包，包含了传统的欧美外包、对日外包，也包含国内以销售合同驱动的项目型外包，如政府、银行、电信项目。由于整体上外包工程属于管理活动，除了需求开发部分会借鉴

本文是“松结对编程”系列的第八篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。） 好像微软自己也有一个无纸下载处，但是手册不在身边没搜到，这里补充一个下载链接。 无需积分，但需要注册优快云帐号。http://download.youkuaiyun.com/detail/cheny_com/3678487  ppt无法单独阅读，请参考以下相关的系列博客：松结对编程的起

本文是“松结对编程”系列的第七篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。） 刚刚参加完MPD 2011深圳站，在演讲中间及后来媒体采访，被问到了一些问题，也给出了答案，这里做一总结。 我自问自答到一半，才发现这里边的很多问题的答案，都用到了火星人谚语系列之一：有问题的地方无答案、火星人谚语系列之三：正确的答案一定简单。如果您觉得答案和自己的情况不完全

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

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

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

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

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

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

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

本文是项目经理的商务指南系列中的第三篇。（之一：序言及项目本质，之二：认识责任，之三：认识客户，之四：认识谈判，之五：认识项目进展，之六：认识回款，之七：将项目推向不败之地）被动而弱小的客户客户常常被认为是主动的一方，可以蛮横，强硬地与乙方谈判，但事实其实不是这样。多数甲方的信息中心，尽管也签署过若干项目，但每种软件，却都只有一次机会立项；这和我们乙方能同时给多个甲方开发相同的软件比，信息不可谓不

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

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

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

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

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

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

最近有一篇“为什么Scrum不行”的文章很热，本来路过打酱油的时候看到过，但是后来在另外一个网站的敏捷诊室里边被要求评价一下，所以顺便转发到这里。为了不让大家再去找原文，原文发在这里（好像是由一篇外文翻译的？没找到原始出处）：因为本人经常站在Agile的风口浪尖，所以我有必要也来

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

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

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

作者：梁斌原文： http://blog.sina.com.cn/s/blog_593af2a70100w0iv.html 今天看到微博上@hellodba发的一个帖子：“内部晋升越来越困难，但是外部来的大P越来越多，所以很多人都选择跳槽”，之后我从三个方面简要的进行了回答：“外

前几天参加敏捷大会，最大的收获乃是听到腾讯副总裁的这番回答，对这个问题有了重新的认识（或者说重新陷入迷惑，也行）。腾讯一直以来被认为是抄袭专家，创业杀手，甚至有“gouridetengxun”说法，马化腾自己也有“喜欢慢人半步”的言论，所以似乎一切都已经有定论。那天底下一位观众问

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

本文是项目经理的商务指南系列中的第四篇。（之一：序言及项目本质，之二：认识责任，之三：认识客户，之四：认识谈判，之五：认识项目进展，之六：认识回款，之七：将项目推向不败之地）谈判是一件让大门不出二门不迈的项目经理很头疼的事情，谈判的技巧很多，要完全掌握不是一天两天的事情，但也不难。随便搜索“谈判技巧”，都可以找到一大堆，本文不再详述。本文主要涉及如何向正确的谈判心态迈出第一步的问题，剩下的问题，自

本文是项目经理的商务指南系列中的第一篇。（之一：序言及项目本质，之二：认识责任，之三：认识客户，之四：认识谈判，之五：认识项目进展，之六：认识回款，之七：将项目推向不败之地）编程语言的逐渐高层化导致了需求分析与架构设计的逐渐合并，敏捷开发等更加扁平的开发方法论导致了项目团队将直接与客户的业务流程以及业务人员打交道。在这种变革中，项目经理将越来越需要掌握一些商务知识，而不是固守原来课本上对进度、质量

这是IT职场人生系列的第二十四篇。（序言，专栏目录）程序员的收入是广受关注的问题，很多人从业3～5年之后就会遇到这个收入瓶颈。尽管物价不断上涨，程序员尤其是初、中级程序员的收入不升反降。即使上次在某个文章中看到有中国第一程序员之称的某位，月薪也只有3万，尽管这个数字已经很高了，但这个“中国第一”，也只有众多小型软件企业总监级别的收入而已。为什么这么高水平的技术人员在公司中的位置仍然显得与日俱降？本