Category: PM 项目管理

迭代经理是什么角色?(下)【译】

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

7.6 迭代经理与迭代

迭代经理也有与迭代相关的职责。迭代经理与客户、团队一起工作,对每次迭代做出计划,包括:

  • 帮助客户排列优先级
  • 整理协调团队成员的建议
  • 计划团队的交付能力

迭代经理指导、鼓励和激发团队的士气。迭代经理通过健康检查来保持团队的坦诚。这些检查不是用来确保团队符合敏捷的所有方面,而是看团队能从敏捷提供的哪些技术中受益。

迭代经理肩上最后一个与迭代相关的职责是会议促进(facilitation)。迭代经理主持和引导计划会议,包括迭代计划会议和发布计划会议。适当的促进迭代计划会议和发布计划会议可以指引团队走上成功。测量指标、进行中的各项事宜,以及其他不像计划那么顺利的事情,都必须公开坦诚地进行讨论。

在发布计划会议上,迭代经理展现出他们的洞察力,与客户对下一个发布需要交付的高层次功能特性做出计划。一旦计划得到认可,而且客户认同计划可能改变,迭代经理帮助团队进行高层次的工作量评估(例如,故事的点数),让客户知道下一个发布里面会交付哪些东西。

在迭代计划会议上面,迭代经理常常要防止团队成员签署超出他们交付能力范围的工作。同时,通过复审测量指标,迭代经理帮助团队成员“掌控”他们的手段,改进最后的会议结果。

最后,迭代经理负责推动回顾会议,这样团队能“快速发现做得不对的地方”,找出需要在下次迭代里面进行改进的地方。迭代经理需要引导团队的讨论,使其关注于本次迭代里做得好、以及做得不好的地方,不时提醒成员重点是如何改进做得不好的事情。这能营造出一个负责任的氛围,也能让团队成员提升自己。

7.7 迭代经理和项目

正如本文讨论,迭代经理承担了一系列项目相关的职责,但有时他们也会被要求负责团队文化建设。在让商业客户满意的同时,迭代经理促进形成满意、愉悦、高效和受尊重的团队成员。Fred George说,“作为次要目标,我期望看到因为迭代经理的工作,团队成员在项目结束的时候变得更为优秀。团队内充满信任,持续提高技能——这是迭代经理的工作。”

迭代经理致力于创造一个专业和敢于承担责任的氛围。这样的氛围体现在恰当的行为和习惯上,如下所示:

  • 对自己、他人和客户互相尊重。
  • 庆祝成功。
  • 失败乃成功之母。

迭代经理争取把团队拧成一根绳,所有的成员同舟共济。

7.8 结论

构建一台“润滑良好”的交付“机器”,持续地补充新的故事,调整机器:这构成了一份全职的工作。沟通清晰、实用主义至上以及处理变更的能力属于不同的技能,需要挖掘和培养。2000年之后,ThoughtWorks培训了很多迭代经理,派到客户现场,提高和巩固了敏捷项目的成功。迭代经理留下了可复用的流程,可以用以改进敏捷团队,完成设定故事范围的项目和改进团队文化。

这带来了愉快的、高效的团队成员。每日沟通、消除不和谐、保持客户对项目最新进展的了解,可以花上开发人员整天的时间,导致几乎没有时间编写代码。如果敏捷团队里面不存在迭代经理,团队很可能会失败。团队只需要关注手头的任务(或者故事),把这些杂事留给迭代经理。

--完成--

迭代经理是什么角色?(中)【译】

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

7.3 迭代经理不做什么

迭代经理(IM)并不是项目经理(PM)。与项目经理不同,迭代经理需要在工作第一线,与团队成员一起面对每日的工作活动。如果你是迭代经理,就把项目预算、资源管理、承诺、以及大层面上的问题留给项目经理。只关注团队!

此外,迭代经理只是一名项目成员,而不是人力经理或者资源经理。迭代经理不负责给团队成员写年度总结。这可能会影响他们的中心任务,即保持一个中立的态度——既维护团队的权利,又保持团队关注于对客户优先级最高的功能。团队成员不应该绞尽脑汁以求给迭代经理留下好印象,而应该是在需要帮助的时候要求迭代经理给予帮助。

迭代经理也不是客户。通常由团队中的商务分析师或者架构师扮演客户,这取决于故事的性质,或者真实客户的可获性。但是,迭代经理不应该扮演客户,如果他们作为客户来下决定,就无法帮助团队恰如其分地解决问题。

最后,迭代经理不保证技术的完整性,也不保证对标准的遵守,抑或提供技术基础支持(例如,对构建、部署或者数据库的支持)。项目的实现活动,比如协调多个项目、协调部署或者演示,通常是技术负责人或者首席商务分析师来处理。

7.4 迭代经理与团队

虽然没有明确规定,但是迭代经理要承担一些日常职责。下面列举了其中一些:

  • 收集花在故事开发上的时间
  • 使交付过程中的瓶颈显现出来
  • 向客户汇报团队状态
  • 解决在每日站立会议上提出的问题、阻塞和障碍
  • 控制所有流向团队的工作,管理工作的分派以保持一个可持续的速度

收集单个故事的实际所花时间可以得到很多测量指标。收集这些时间,和其他不同的数据点比较,有助于迭代经理提高团队的产出。首先,比较迭代内已完成故事的实际所花时间和故事的点数,迭代经理就可以知道团队有多少时间花在真正的交付故事上面,又有多少花在团队会议和其他活动上面。其次,比较项目已完成故事的实际所花时间和团队计划的项目时间,迭代经理就可以明白团队的产能,以及团队对于项目的可用度。最后,比较已完成故事的实际所花时间和故事的预估时间,可以得到故事评估的准确度。上述所有的测量指标在不同的环境下都很有用,迭代经理用它们来帮助团队形成一个稳定的交付速度。

稳定的交付速度是计算未来迭代团队产能的基础。有了团队在每次迭代里面经过充分测试的产出物和每位团队成员的计划可用率,迭代经理可以基于实际的已验证的数据来规划团队的产能。产能是不受团队支配的,也不会因为明确的交付时间就自动达到。产能是预先计划的,这样团队成员才能自我管理好。如果交付速度与业务需求不同步,可以调整其他的项目杠杆,但仍然需要使用实际的产出物来预测将来的产能。

很多测量指标和精心地排列故事墙能识别出项目的瓶颈。假设一个故事预估的工作量是一天,但在经过三天开发以后,却还摆放在故事墙的开发栏里面:这说明遇到了瓶颈需要团队一起讨论。Fred George创造了一种成功的测量指标,就是手指图。这种图表使用了堆积图,每块区域分别代表了迭代周期中的一个阶段。每天更新故事的状态,团队可以观察到图上每个区域的增长,以及交付周期中故事的流转。当图上的所有区域成比例地增长时,这些区域就能形成手指的形状。当图上某块区域与其他相比不成比例时(比如说“等待开发”区域比“开发”区域宽),团队能发现瓶颈的存在。此时,团队可以讨论如何消除瓶颈以使团队的交付速度回复稳定。

在每日站立会议上面,迭代经理排除掉不必要的干扰,保持团队成员使用正确的方式:过去24小时做了什么,接下来的24个小时准备做什么,遇到了什么障碍。迭代经理留心倾听每人的任务项和当天需要排除的障碍,这样团队成员可以完成故事。如果有人在每日站立会议上霸占时间,谈论标准汇报内容之外的东西,迭代经理需要带领团队重新回到关注点上面。通常的做法是建议那人在站立会议之后做一个较大的问题解答。

7.5 迭代经理与客户

正如前面讨论的,测量标准可以帮助迭代经理判断团队可持续的速度。这允许团队定期做出承诺,并最终兑现。但是,为了团队成员能维持承诺,迭代经理必须保持客户在迭代阶段不去更改故事。迭代经理要像守门人,帮助客户对即将来临的工作排列优先级,而不是经常更改优先级使得团队无所适从。

作为守门人,迭代经理保护团队不受分心之扰,也防卫客户不经意间影响团队的生产率。在迭代之外,客户可以而且应该不断地更改优先级。直到迭代开始之前,所有影响决定的因素都是可以改动的,而且要经常介绍新的信息。

项目中即时决定的概念并不是一个全新的概念。由丰田知识工程发展而成的精益开发系统在多方案同步进行的开发工程方面已经有多年的成功经验。多方案同步进行的开发工程被描述成“很谨慎地延迟决定,直到必须做出决定;努力维持各种可能的选项,尽可能延迟决定至开发团队收集到足够的决策支持信息,而不是为了所谓的果断而快速排除其他选项,从而更快地达到最优方案。”

--未完待续--

迭代经理是什么角色?(上)【译】

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

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

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

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

7.1 什么是迭代经理?

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

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

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

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

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

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

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

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

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

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

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

--未完待续--