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

最近几天没写博客，一方面因为有几次培训和会议占用了时间，另一方面在编写一个免费敏捷教材及宣传材料。最后有几张已经完成的草图。 编写到初衷有两个：1. 希望每次培训课前，大家已经对基本概念有所了解，而不是从头听，这样有限的时间就可以用来解决真正的“敏捷如何应用”的问题而不是“敏捷是

2012-12-25：新增松结对编程4页。预告：下一更新日期：2013-03-01（实际未发布）。致歉：因误以为新版本发布是4.1日，所以错过了发布期。作为普及读物，已经达到70页的上一版本版本已经基本满足需求。下一步计划可能是整合博客中的文章内容，出一本免费电子读物，把博客分门别类放整齐，以方便大家阅读。不过此事工程浩大，会不定期抽时间完成。感谢大家支持。 您可以在非商业场合免费使用（详见文档最

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

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

这是敏捷生态系统系列的第五篇（之一，之二，之三，之四，之五）。本文是2009年刚刚提出敏捷生态系统的时候参与一个MSN讨论组时的对话，当时的想法与现在相比尚缺少系统性，但由于有问有答，也包含了本系列所没有包含的一些信息，仅供参考。删除了部分无关的对话。文章末尾有谷雨霖老师的博客地址，也在CSDN。 “敏捷生态--Srcum敏捷开发”--msn群讨论 2009-08-25 13:52谷雨霖 说:时间

这是敏捷生态系统系列的第一篇（之一，之二，之三，之四，之五）。所谓生态系统，就是指互相依赖方能生存的一系列生物。生态系统常常不是单向依赖的，而是互相依赖互相促进。敏捷开发中的实践也是如此。典型地，当一个实践很难实施时，一定不要认为简单的制度可以保证其实施，而是要思考是什么导致了它的失败。比如每日立会，如果发现大家都不按时开会甚至不开会，马上要做的不是要求大家按时开会+开会迟到给大家买水果+统计每月

这是敏捷生态系统系列的第二篇（之一，之二，之三，之四，之五）。如果说需求管理中尚有一些团队无法控制的因素导致实施困难，计划与跟踪过程总归就没有问题了吧？其实不然，笔者见过领导很放权的全团（很多是因为领导根本管不过来了），但在团队内部仍然存在很大的问题，一般最为突出的，就是每日立会开得毫无生机。这不完全是因为文化差异问题，而是生态系统出了问题。  敏捷开发中的计划跟踪生态大致如此（黑体字即图片中的元

这是敏捷生态系统系列的第三篇（之一，之二，之三，之四，之五）。产品负责人PO与团队的互动一直是一个难题。典型的问题在于：敏捷开发倡导“迭代期内无变更”以换取“团队承诺”，而实际上产品负责人却会不断地来提变更，打乱开发计划了。我们应该怎么办呢？产品负责人说“敏捷就是拥抱变化，我现在来提变化了，你们却关门了。”团队说“如果你总是变，下次我们怎么给你承诺。”敏捷开发中的计划跟踪生态II大致如此（黑体字即

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

2011-10-14：新版本已经发布，新增内容6页，增加目录及《敏捷开发用户故事》系列。此版本就是原定10.31才发布的版本，因下半月要参与一本杂志、一本书的编写，所以提前写好免得惦记。本文仅作通知，下载请访问主贴：http://blog.csdn.net/cheny_com/a

•    谁在管理团队中的个体？•    从领导指令到自组织团队-敏捷生态系统 –  自组织团队的潜在问题 –  敏捷Scrum是怎样解决这些问题的？ –  敏捷生态系统         同行压力（兼谈敏捷团队，绩效管理，自组织团队）        敏捷生态系统：2009敏捷中国大会上的演讲稿–  大团队/强分工下易受影响的生物 •    习惯性分工与事实性分工 •    大型团队：139团队模型

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

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

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

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

本文是敏捷外包工程系列的第二篇。（之一，之二，之三，之四）敏捷开发整体上适合小团队、产品研发（所以才有product owner一称）的环境，而外包软件开发中常常存在的则相反，因此在创建团队的时候要充分认识到这一点。Product Owner产品负责人的人选听到无数次有人说“我们的Product Owner就是客户，因为所有需求都是客户提的”，其实这样做极度危险。Scrum开发理念提出前的环境大致