OOPAA

（节选自本人翻译中的《ThoughtWorks Anthology》一书的第7章“What Is an Iteration Manager Anyway?”）

第7章 迭代经理是什么角色？

行业日新月异，敏捷、迭代式和迭代这些热门词已是“飞入寻常百姓家”，一个定义模糊的新角色——迭代经理，也浮出水面。这是新一代的项目经理么？抑或是美其名的团队带头人？又或者是管理上的一个新阶层？谁会被冠以这个“经理”头衔？

本文将着重阐述迭代经理作为软件团队成员的工作内容和价值。我们将分析迭代经理的职责范围，同时讨论作为一个不可或缺的角色，迭代经理在面对组织和文化挑战的情况下，如何维持一个健康的工作环境。

7.1 什么是迭代经理？

通常在大型的敏捷团队里面，项目经理不可能同时关注项目团队每次迭代的成功，和整个项目最终的成功。2000年，有一个项目团队困扰于甄选高优先级的工作，最终的解决办法是选出一个人以一个稳定的节奏给交付团队提供持续的高优先级的功能“流”：这就是迭代经理（IM）的雏形。

在迭代式开发的世界里，总是需要有人对项目团队提供支持，促进与业务客户的日常交流，使整个团队保持关注于高优先级的工作。ThoughtWorks的高级架构师Fred George把迭代经理描述成“面向内部的管理角色。迭代经理负责保证故事在团队中流动的顺畅，这涉及到合理分配任务、在技能需求改变的时候建议更换团队成员。”

7.2 怎样成为一个好的迭代经理？

迭代经理可以来自不同的能力背景——可以是技术能力（加上很强的人际能力！），也可以是分析能力（加上很强的人际能力！），甚至他们也可以从业务专家或者行政专家（加上很强的人际能力！）里面产生。他们必须拥有前瞻思考、乐观进取的态度和拥抱变化的才能。每天，这些面向内部的推动者使用他们的才能协助交付团队使之逐步完善。

比如，一旦明确了迭代的工作量，迭代经理就需要在迭代的整个过程中跟踪团队的进展，从实际出发，积极地在团队内部贯彻流程的改进。想象一下在站立会议上面，迭代经理听到开发人员说他已经在一个故事上面工作了三天，而这个故事原本估计是一天的工作量。因为要对每个团队成员的日常活动和迭代的进度负责，迭代经理需要去挖掘这个被低估故事的细节。如果迭代经理不能很快判断故事的真实状态，立即与客户就迭代计划的潜在变更进行沟通，团队就有可能面临承诺失信的风险。迭代经理可以从询问如下问题开始：

• 开发人员弄清楚了故事的范围吗？
• 故事任务在最初的评估之后是否发生了变化？如果发生了，是如何变化的？
• 开发人员是否需要业务分析人员或者客户的帮助，以更好地理解故事所要求的完成结果？
• 开发人员是否需要向技术负责人寻求帮助？
• 是否有什么事情阻碍了开发人员完成故事（换句话说，是否存在硬件、软件，甚至基础设施的问题）？
• 是否开发人员又被分派了另外一个项目，或者参加了太多琐碎的会议导致无法完成故事？

上述问题只是一个例子，说明为了保持团队按照预定的进度前进，向客户汇报项目的每日状态，迭代经理可能要承担的工作。每天，迭代经理都必须倾听团队的需要并且响应。其主要职责就是培养一台润滑良好的“机器”，能依据要求的质量在项目范围内交付功能。

迭代经理应该在技术熟练度和业务知识之间达到一个平衡。Mary和Tom Poppendieck写到敏捷领袖应该“同时对客户和技术都具有深刻的理解，这样才能赢得开发团队的尊重。”良好的沟通技巧是必须的。迭代经理的职责之一就是维护开发团队与客户，以及与管理阶层之间的关系。

同时，迭代经理必须推动、坚持和保障团队成员的权利。对于很多敏捷团队，这些权利来自于开发人员的“权利法案” ，经过了整个团队的同意。通常迭代经理都需要协助团队以确保这些权利得到了坚持。

通常这都是以在团队内部以及团队之间加强交流的方式出现。大部分的开发人员都不习惯于直接与客户交流，或者对故事的完成程度给出直接的判断。迭代经理通常需要提供数据、图表和图形的示例来推动开放的交流。

迭代经理也必须维护客户的权利。每次这样的诱惑——团队成员不按照优先级高低的顺序进行开发——稍微露出端倪，迭代经理就要作为客户代理人出现。还记得么，客户有权利只为那些符合他们所期望的优先级顺序的工作买单？整个过程自始至终，迭代经理都必须保持一个中立的态度。

－－未完待续－－