这是敏捷开发绩效管理的第一篇。（之一，之二，之三，之四，之五，之六，之七）
“敏捷开发绩效管理”本身是个伪命题，因为敏捷开发本身不想涉及绩效管理，这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的：更高的交付保障，更高的生产率，更高的质量……这和人们选择C++（而不是C）的原因还是很接近的：都是为了更高的绩效。在下面的所有文章中，“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”，而是“如何利用敏捷开发提高绩效”。
绩效管理常常被片面理解为绩效考核，即如何确定个人的绩效，如何提工资和发奖金的问题。实际上绩效管理还包含制定绩效目标，制定绩效计划，制定配套的制度推动绩效等等，当然也包括最后的绩效考核，以最终达到绩效持续提升的目的。
上述内容在本系列中都有考虑，并根据笔者以往的经验和经历给出一些实际的案例供研讨使用。
从一个经典问题看绩效管理的出发点
绩效管理不是敏捷开发的要求——如果能理解敏捷开发也不是瀑布模型的要求，敏捷开发爱好者们或许就会释然了——绩效管理是企业管理的要求，是企业为了持续提升自己的绩效而采取的措施。
从这个角度我们来看一个由来已久的问题：“敏捷开发是否考核个人？”很多人会脱口而出：“敏捷开发不考核个人。”但是如果再问“企业管理要求必须考核个人怎么办？毕竟工资和奖金不是发到团队总账户上的”估计再下去的回答，就只能说是闪烁其辞了。
其实这也是一个伪命题，所以才导致很难回答。下面一点点分析。
企业绩效管理的目的不是为了考核个人，而是为了提升企业绩效，所以尝试考核个人的企业实际上在“利用考核个人提升企业绩效”（尽管提升个人绩效会提升企业绩效，但勿入此牛角，因为前面有个尖）。因此这个问题从原始出发点来看，应该是：“企业是否应该通过考核个人来提升绩效？”，那么答案就是：“敏捷开发有比考核个人更能提升绩效的方法”。不是因为用了敏捷开发就不能考核个人，而是选择了敏捷开发，就意味着已经选择了比考核个人更有效的提升绩效的方法，因此没有必要让企业管理和敏捷开发较劲，它们打不起来的。
不过这个或者这些更有效的方法是什么呢？这就是本系列博文的主要内容。
本系列博文将较多涉及团队级别的绩效管理，内容包括团队管理的策略，个体管理，团队的外部目标设定，如何分解到个人，不同团队绩效管理的差异，非物质激励等。
另外一个高级话题则是产品级别的绩效管理，包括产品发布计划，产品版本计划，产品线管理，产品负责人及产品负责人团队，不同产品类型的搭配等等。但这个话题以另外一个主线组织会更顺畅：敏捷开发产品管理，因此会形成另外一个系列，但其核心内容仍是“如何通过敏捷开发管理产品提高绩效”，如果您觉得本系列所涉及的范围太窄，敬请关注
