敏捷体系中，有许多种不同的开发方法。各类敏捷开发方法中，较成体系的有 XP、FDD，只说明管理框架的有 Scrum，只说明建模的有敏捷建模，具体的技术实践包括 TDD 测试驱动开发、持续集成、结对工作、快速迭代等等。敏捷涉及面非常广泛，不同的人当然有一些不同的理解和解释。也许由于敏捷开发方法首先发端于程序员，不 少的理解可能来自于程序员。本文试图来整理当前主要的让管理层害怕的敏捷理解，而不论这个理解是否正确。本文所指管理层是指团队以上的管理者们，不包括项 目经理和项目团队领导。
第 1 个：敏捷团队不需要管理层的指导
自组织团队是敏捷方法主要的实践之一。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其 实比较难。团队的形成必须经历几个时期。在经历了初期的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规 矩，而且这些规矩是不言而喻的。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工 作效率非常高。（参考文献 1）
在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。总之， 自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则， 一旦出现问题，团队成员之间就会出现信任危机。
敏捷开发小组是以小组为整体来工作的，也安排了一些承担特定任务的角色。比如在 Scrum 中有一个角色是产品所有者（Product Owner）。产品所有者的主要职责包括：确认小组所有成员都在追求一个共同的项目前景，确定功能的优先级以便总是在处理最具有价值的功能，以及作出决定 使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。
因此，管理层在敏捷中仍然具备指挥权。如果管理层当前的管理风格是面面俱到，事无巨细的命令和控制，那么引入敏捷时，需要作出变化，转而抓大放小，转向高层次的指导，采用服务型管理方式。总之，敏捷团队仍然需要管理层的指导，但不需要过于细节的、命令式的指导。
第 2 个：敏捷团队会采用屏蔽手段
Scott Ambler 在极限编程的 Yahoo Group（eXtreme Programming yahoogroup）里面提出了敏捷中的“屏蔽”，他说道：
“这就是那种被我称之为‘屏蔽’的很好的例子，你按要求写文档，参加会议，并做出很关注的样子……这样别人看起来你好像是在按照所谓的‘官方流程’在走。”（参考文献 3）
彻底点说，为了团队的敏捷实践，有人弄虚作假，装模做样。在管理层与敏捷团队之间就被屏蔽了。对管理层而言，这是很难容忍的。
在 Scott Ambler 发起的讨论中，已经有人指出敏捷团队不应该屏蔽管理层。
笔者认为：在实际中这是可能存在的。部分敏捷团队为了避免管理层的“干扰”，或者认为与管理层沟通也没有好结果，不愿意与管理层坦诚沟通，采取了屏 蔽手段。作为管理层，需要注意倾听，需要开诚布公，在前期就注意敏捷团队有没有抱怨管理层不合理的要求；发现屏蔽存在时，不能草率的责备敏捷团队，需要与 团队一起分析原因，最终的原因有可能就是原有规章不合理的要求。
第 3 个：不能评价敏捷团队成员的个人绩效
有人这样说：“敏捷提倡对每个人的信任，以及团队成员的平等地位，所以不需要对每个人做绩效考评，因为这么做除了引起团队成员的分歧，对于个人的激励没有太多的正面作用。”
Christophe 在其《Death by appraisal》（参考文献 4）文中说道：“对于大多数团队，每个人的成就是和团队其他成员混合在一起的。在协助的背景下强调或评价个人绩效，试图单独拉出个人绩效是无效的。个人技 能只是绩效整体表现中较小的部分。对于个人绩效，管理的质量、环境、组织文化是更主要的因素。大多数的评价和评级模式忽略了这些因素。”
在 2004 年一月的 Better Software Megazine 中，Mary Poppendieck 有一篇关于在敏捷团队里面绩效管理的文章（参考文献 5）。在这文章中，团队所有成员得到了相同的评价。不过，这篇文章中的场景是设计的，不是真实的，没有调查，没有数据。
敏捷社区中以上这样的说法可不少，存在于个人文章、论坛帖子中。Scrum 中说 Scrum Master 不要评价团队成员，没有说其他人可不可以评价团队中个人绩效。现在听说敏捷界已经有了一些实际的例子表明不评价个人，组织、团队和个人都得到满意的结果。 这些例子中，其组织结构、文化、背景其实并不具备代表性。
现有的大量人力资源管理（HR）方法是围绕着个人绩效评价来展开的。如果不评价个人绩效，那么如何管理，可能不少管理者无法回答这个问题。
这也许是敏捷开发方法的悖论。
而实际上目前还没有哪个体系的敏捷方法在正式的文字中宣称“不能对敏捷团队中个人进行绩效考核”。之所以口口相传，最大可能原因是敏捷方法被程序员类技术人员（包括敏捷的最早先行者们）率先采纳接受并倡导，在目前敏捷界，这样的群体发出了较大的声音。
职场的事实是“对个人的评价在组织中不可避免”。其中最无法避免的个人评价是如何挑选员工晋升？满足条件就能晋升？满足条件本身的判断就是判断个 人，晋升的机会永远是少的、但又是必然有的，而且在时机充满了不确定性：有时是有人突然离职，有时是业务扩充。其次是优秀员工评选、加薪等等。
所以刚开始采用敏捷，个人绩效考核方面完全可以基于组织自身的历史来处理，没有必要在敏捷引入开始时就一定要想办法调整个人绩效考核办法。随着敏捷 实践的开展，基于组织的发展实际，寻求更好的个人绩效评价办法。不排除达到“不进行个人绩效考核而各方共赢”的效果。所以管理层不必因为此而害怕敏捷。
第 4 个：不能横向比较敏捷团队的绩效
“敏捷团队就是不要绩效考评，至少不要传统意义上的绩效考评。从 scrum 到 XP，几乎所有的敏捷大牛都对这个问题有明确阐述。”— 摘自于网络。
敏捷开发最常用的两个规模表达方式是：1、故事点；2、理想工作人天。IFPUG 的 FP、长度单位米等等是绝对的单位。每个 FP，每米都是一样的。但故事点不是绝对单位，是一个相对单位。A 团队的故事点与 B 团队的故事点是不一样的，是不可以比较的。理想工作人天更加是据于特定团队的判断，较之于故事点，是一个更加主观的判断。所以据于这两种规模表达得到的速 度 (velocity）或利用率（capacity）都是不可以比较的。因此，敏捷团队是不能简单比较的。
基于故事点和理想工作人天的速度 (velocity）或利用率（capacity）确实是无法比较团队绩效的。但是有别的办法，参考文献 6《PAS-我们的 Scrum 迭代会议演示评审系统》给出了一个例子。其它考察团队整体的老方法同样适用于敏捷团队绩效考核，比如用户反馈调查（用户反馈调查的可能带来误差，这是用户 反馈调查本身的问题，不是敏捷团队绩效考核的问题）。因此敏捷团队的横向比较是有办法的。
敏捷团队的横向比较也是有必要的。在组织内营造积极的竞争氛围是有利的，这早已被证明，也被大量的组织采用。对于敏捷团队，正因为团队不能简单地显 示可比的开发效率，管理层难免会有疑问：他们这个迭代计划的工作是否充实，哪些用户故事真的需要这么多工作量吗？所以敏捷团队的横向比较机制能够让敏捷团 队向更好的结果努力，管理层也会打消团队磨洋工的疑虑。
第 5 个：固定报价的项目不适于采用敏捷
在《为什么有些公司敏捷实施不成功？》（参考文献 7）一文中，作者 Christopher Goldsbury 首先建议：“不要试图在固定报价或基于项目划拨经费的情况下尝试实施敏捷。取而代之，作为经理，你应该评估你的公司是否能够支持敏捷实践以及一支人员配备 齐全的开发团队。如果能，那么你应该实施敏捷……它能运作良好；如果不能……那么你最好明智地坚持使用传统项目管理实践。”
在《敏捷并非奢侈品》（参考文献 8）一文中，作者黄维勇认为软件公司根据自身的特征和环境去实施敏捷是稳妥的做法，如果你是固定报价合同类型的公司，那么在项目中引入敏捷，一开始可能会 遇到问题，以及从成本花费上看会有所增长，但是当你渡过这段时期之后敏捷所能带给你的优势会超过你最初的投入，那种固定报价合同类型类型公司实施敏捷将会 失败的预言并不准确，但是我们应该看到相比于产品开发类型公司它面临的问题会更为严峻。
笔者认为敏捷完全可以适用于固定报价的项目。对于这种项目最难的是合同商讨时总价与项目范围的匹配，项目还没有开始，不知道如何，就需要确定总价。 需要资深人员的判断和过程中的良好沟通。这个问题不是敏捷独有的，传统方法也是如此。第 2 个大困难是固定报价项目的团队能力，这也是传统方法和敏捷方法一样面对的问题，如果没有成熟的团队能力，那么利用传统方法较之于敏捷方法冒着一样的失败风 险。采用敏捷，可以比传统方法更快地向用户交付价值，可以更快地用运行着的软件来和用户沟通。即使失败，也能尽早的发现，更早地获得调整或退出的时机，以 避免损失的扩大；而传统瀑布型生命周期遭遇失败时，已经发生的投入将形成较大的损失。
第 6 个：项目经理在敏捷团队中消失了
在 Scrum 的条文中 Scrum 团队没有项目经理，有 Scrum Master 和 Product owner。但是 Scrum 不能代表敏捷的全部，虽然现在 Scrum 采用占了多数。
每个敏捷项目都有项目经理吗？
Michele Sliger 认为，这个问题要看具体情况。Scrum 开发有 Scrum Master，这算不算项目经理呢？XP 开发有 XP 教练，这算不算 PM 呢？在 Michele 做过顾问的大型企业中，虽然这些企业大都选择使用 XP、 Scrum 或是精益敏捷开发方法，但他们的人事簿上都有 PM 一职。职位还是“项目经理”，只是作用可能并不一样。（参考文献 9）
在实践中，就算是遵照 Scrum，项目仍然可以有项目经理。在敏捷引入时，一般来说组织原来就安排了项目经理，项目经理也许有几年的项目管理经验，也经过了诸如 PMP 等培训。而在 Scrum 团队中项目经理处境尴尬，如果秉承 Scrum 的理论，项目经理就受到巨大的束缚，很多 PMP 中的手段无法使用，不管发钱，不管派发任务。现实中，项目经理可不会死扣 Scrum 的理论，绝大多数项目经理仍然按照项目经理的方法论来开展项目。在引入 Scrum 时，死扣 Scrum 理论几乎是不可行的。
那么是不是说引入 Scrum 后，再来取消项目经理，安排牧羊犬式的 Scrum Master，并来倡导并建设自组织的团队？
笔者认为未必有这个必要，因为：1、继承项目经理制度，Scrum Master 可以就是项目经理，Scrum Master 是带领 Scrum 成功的领头羊；2、完全的团队自我管理在职场（以劳动换取报酬）是不可行的。（参考文献 10）
总之，项目经理制度已经很成熟了，引入敏捷时（哪怕是引入 Scrum）没有必要撤销项目经理。
第 7 个：敏捷做法留下的文档很少，后续工作难于跟进
有些人认为敏捷不需要文档，甚至不支持任何形式的文档化。这个观点在敏捷宣言中就已经被驳斥了。宣言的最后一句明确说明：“也就是說，虽然右侧条目有其价值，但我们更重视左侧条目。”而其中的“详尽的文档”位于右侧，“可用的软件”位于左侧。
但是用中文来检索“敏捷宣言”，得到的中文网页竟然有不少是缺少最后一句话翻译的。真是怀疑这是有人故意为之，因为宣言本来就很短。宣言明确要求“此宣言可以任何形式自由复制，但须附上连同此声明在內之完整內容。”
在《敏捷方法需要文档吗？》（参考文献 11）一文中较详细说明了敏捷的文档。
但纵然对宣言理解没有问题，那么这个敏捷的文档到底如何 Just enough？Just enough 的对比是什么呢？
大而化之，可以将文档的“Just enough”归纳到两种不同的极端需要：
1，通过文档，只要了解明天加入这个团队所要知道的内容就行了，不在文档中的内容，团队老成员会通过诸如结对、协作等等方式告诉新人；
2，通过文档，可以处理当前项目结束后的维护，或者是后续跟进项目。
管理层和敏捷团队自身可以考察团队的稳定性，项目所处阶段来判断需要什么样的文档。如果团队成员离职率高，文档需要就大，如果项目处于晚期阶段，那么要考虑项目结束后团队去向，如果团队会解散，那么文档需求显然，如果团队会留下，那么文档还是可以少些。
因此这个问题是可以处理的。
另外对于敏捷开发方法常用的需求表达方式：User Story。一位敏捷界的资深人士阐述了如下的 user story 写法要求：User story 由以下三点组成：
用来制定计划和作为提醒的一段书面描述
用来充实 story 的细节的谈话
测试用例，用来表达和记录细节并且能够在 story 实现的时候对进行验证
特别留意下上述的第 2、第 3 点。如果按照这个 3 点要求，估计写一个用户故事可是需要不少字，这样就会留下足够详细的文字，而且也许并不比传统的需求规格书（SRS）的字数少。（参考文献 12，参考文献 13）
第 8 个：引入敏捷需要改造组织文化
Greg Smith 在一篇文章《Creating an Agile Environment》（参考文献 14、参考文献 15，内容源自他即将出版的新书《Becoming Agile》）中提出观点认为：“要全面深入并务实地过渡到敏捷模式，关注文化变化的重要性不亚于对流程改变的关注。在众多讲述各种敏捷方法论（尤其是极 限编程和 Scrum）的好文章中都明确指出，真正的敏捷来源于团队在正确的价值观、原则、态度和行为上达成一致的能力。但它们都没有强调整个组织的转化”。
Smith 认为，这将意味着在公司的文化方面：过渡到敏捷模式不仅仅是改变流程，它还需要文化方面的转变。对于大多数的公司来说，改变文化是最困难的。我认为这是事实，原因如下：
公司现行的流程无论成功与否，都让人觉得舒服；
许多人仍然相信需求变更的原因是管理不好。他们无法想像一个拥抱改变的流程是什么样；
大部分经理都被训练去控制，而不是授予开发团队交付及掌控项目的权力。他们认为那样的话，既不直观也不合乎逻辑；
保住“乌纱帽”。在大型企业里，所有人都专注于管理和监控项目，而事实上，对于敏捷团队却不那么需要。
介 绍这篇英文时，中译者加上了标题：“创建适于敏捷的组织文化”。这样的提法很容易理解为“引入敏捷方法，需要改造组织文化”，而且以上文章确实在说“要全 面深入并务实地过渡到敏捷模式，关注文化变化的重要性不亚于对流程改变的关注。过渡到敏捷模式不仅仅是改变流程，它还需要文化方面的转变”。
笔者认为“创建适于敏捷的组织文化”的提法可能带来误解，原因如下：
1、轻重颠倒
组织文化（对于企业而言，就是企业文化）对于敏捷而言，是一个体量更大的话题，涉及的方方面面远大于敏捷开发。组织文化是组织经过多年积淀而来的， 它的形态包括了成文的部分，还有不成文的部分。敏捷开发的引入未必能够对组织文化有如此重要的影响力，失败了例子已经有不少，更不能说为了引入敏捷，要来 改造组织文化。
2、先后颠倒
通过《Creating an Agile Environment》一文的上半部分，可以看到敏捷的引入多半要改变一些什么。首先应是引入敏捷开发方法，在这些个方法发生作用的过程中，相应的管理 方式、文档方式、团队组织等等在渐渐的变化，这系列的变化在潜移默化中的改变着组织文化。
总之，引入敏捷时并不需要在组织文化上刻意改变迎合，如果敏捷引入是有效的，组织文化会随着敏捷推进自然的向好发展，但是绝不会突变。
总结
通过以上的分析可以看到，对于敏捷是没有必要害怕的。希望阅读本文的管理者，尤其是高层管理者，打消引入敏捷的疑虑或恐惧。
参考资料
文中所引用的参考文献：
《敏捷开发思想之自组织》，张逸。
《敏捷开发之 12 条敏捷原则》，周金根。
《敏捷实践中的屏蔽：有用吗？危险吗？这样做道德吗？》，作者 Geoffrey Wiseman，译者 郑柯。
《Death by appraisal》，Christophe。
《unjust deserts》，Mary Poppendieck。
《PAS-我们的 Scrum 迭代会议演示评审系统》，欧阳丹。
《为什么有些公司敏捷实施不成功？》，作者 Christopher Goldsbury，译者刘洋。
《敏捷并非奢侈品——项目型公司也可以敏捷》，作者 黄维勇。
《如何当好敏捷项目的经理》，袁发明
《Scrum Master: 牧羊犬 or 领头羊？》，张克强。
《敏捷方法需要文档吗？》，作者 Geoffrey Wiseman，译者 乔梁 ）。
《User Story 在敏捷开发过程中的应用》，苏小补丁。
《User Stories Applied: For Agile Software Development》，Mike Cohn。
《创建适于敏捷的组织文化》，作者 Mike Bria，译者 徐毅。
《Creating an Agile Environment》，Greg Smith。
关于作者
张克强
系统分析师，Certified Scrum Master，2002年毕业于清华大学。现在是宝信软件过程改进首席咨询师，负责领导咨询团队把业界最佳实践和自身有效实践应用到宝信的各个研发单元 中，并组织和协调各单元的过程改进评估和审核。在软件工程方面拥有8年经验，他的经历主要在组织的过程改进、质量保证和测试方面，帮助组织按 CMM/CMMI模型进行改进，并通过了CMM4、CMM5、CMMI5的评估，从2007年起宝信软件引入了以Scrum为主体的敏捷开发方法，在软件 质量和开发效率方面都获得了明显的改善。他也曾担任水木软件工程版版主。
他的博客地址是：http://hi.baidu.com/hespr
