Posted on 2009-06-13 16:31
mingj 阅读(4035)
评论(0) 编辑 收藏 所属分类:
agile 敏捷 、
PM 项目管理
(节选自本人翻译中的《ThoughtWorks Anthology》一书的第7章“What Is an Iteration Manager Anyway?”)
7.3 迭代经理不做什么
迭代经理(IM)并不是项目经理(PM)。与项目经理不同,迭代经理需要在工作第一线,与团队成员一起面对每日的工作活动。如果你是迭代经理,就把项目预算、资源管理、承诺、以及大层面上的问题留给项目经理。只关注团队!
此外,迭代经理只是一名项目成员,而不是人力经理或者资源经理。迭代经理不负责给团队成员写年度总结。这可能会影响他们的中心任务,即保持一个中立的态度——既维护团队的权利,又保持团队关注于对客户优先级最高的功能。团队成员不应该绞尽脑汁以求给迭代经理留下好印象,而应该是在需要帮助的时候要求迭代经理给予帮助。
迭代经理也不是客户。通常由团队中的商务分析师或者架构师扮演客户,这取决于故事的性质,或者真实客户的可获性。但是,迭代经理不应该扮演客户,如果他们作为客户来下决定,就无法帮助团队恰如其分地解决问题。
最后,迭代经理不保证技术的完整性,也不保证对标准的遵守,抑或提供技术基础支持(例如,对构建、部署或者数据库的支持)。项目的实现活动,比如协调多个项目、协调部署或者演示,通常是技术负责人或者首席商务分析师来处理。
7.4 迭代经理与团队
虽然没有明确规定,但是迭代经理要承担一些日常职责。下面列举了其中一些:
- 收集花在故事开发上的时间
- 使交付过程中的瓶颈显现出来
- 向客户汇报团队状态
- 解决在每日站立会议上提出的问题、阻塞和障碍
- 控制所有流向团队的工作,管理工作的分派以保持一个可持续的速度
收集单个故事的实际所花时间可以得到很多测量指标。收集这些时间,和其他不同的数据点比较,有助于迭代经理提高团队的产出。首先,比较迭代内已完成故事的实际所花时间和故事的点数,迭代经理就可以知道团队有多少时间花在真正的交付故事上面,又有多少花在团队会议和其他活动上面。其次,比较项目已完成故事的实际所花时间和团队计划的项目时间,迭代经理就可以明白团队的产能,以及团队对于项目的可用度。最后,比较已完成故事的实际所花时间和故事的预估时间,可以得到故事评估的准确度。上述所有的测量指标在不同的环境下都很有用,迭代经理用它们来帮助团队形成一个稳定的交付速度。
稳定的交付速度是计算未来迭代团队产能的基础。有了团队在每次迭代里面经过充分测试的产出物和每位团队成员的计划可用率,迭代经理可以基于实际的已验证的数据来规划团队的产能。产能是不受团队支配的,也不会因为明确的交付时间就自动达到。产能是预先计划的,这样团队成员才能自我管理好。如果交付速度与业务需求不同步,可以调整其他的项目杠杆,但仍然需要使用实际的产出物来预测将来的产能。
很多测量指标和精心地排列故事墙能识别出项目的瓶颈。假设一个故事预估的工作量是一天,但在经过三天开发以后,却还摆放在故事墙的开发栏里面:这说明遇到了瓶颈需要团队一起讨论。Fred George创造了一种成功的测量指标,就是手指图。这种图表使用了堆积图,每块区域分别代表了迭代周期中的一个阶段。每天更新故事的状态,团队可以观察到图上每个区域的增长,以及交付周期中故事的流转。当图上的所有区域成比例地增长时,这些区域就能形成手指的形状。当图上某块区域与其他相比不成比例时(比如说“等待开发”区域比“开发”区域宽),团队能发现瓶颈的存在。此时,团队可以讨论如何消除瓶颈以使团队的交付速度回复稳定。
在每日站立会议上面,迭代经理排除掉不必要的干扰,保持团队成员使用正确的方式:过去24小时做了什么,接下来的24个小时准备做什么,遇到了什么障碍。迭代经理留心倾听每人的任务项和当天需要排除的障碍,这样团队成员可以完成故事。如果有人在每日站立会议上霸占时间,谈论标准汇报内容之外的东西,迭代经理需要带领团队重新回到关注点上面。通常的做法是建议那人在站立会议之后做一个较大的问题解答。
7.5 迭代经理与客户
正如前面讨论的,测量标准可以帮助迭代经理判断团队可持续的速度。这允许团队定期做出承诺,并最终兑现。但是,为了团队成员能维持承诺,迭代经理必须保持客户在迭代阶段不去更改故事。迭代经理要像守门人,帮助客户对即将来临的工作排列优先级,而不是经常更改优先级使得团队无所适从。
作为守门人,迭代经理保护团队不受分心之扰,也防卫客户不经意间影响团队的生产率。在迭代之外,客户可以而且应该不断地更改优先级。直到迭代开始之前,所有影响决定的因素都是可以改动的,而且要经常介绍新的信息。
项目中即时决定的概念并不是一个全新的概念。由丰田知识工程发展而成的精益开发系统在多方案同步进行的开发工程方面已经有多年的成功经验。多方案同步进行的开发工程被描述成“很谨慎地延迟决定,直到必须做出决定;努力维持各种可能的选项,尽可能延迟决定至开发团队收集到足够的决策支持信息,而不是为了所谓的果断而快速排除其他选项,从而更快地达到最优方案。”
--未完待续--