Tag: PM

敏捷,把纪律留下(上)

(本文发表于《程序员》2009年第6期,转载请注明。


在软件行业,大部分经理们都希望自己率领的团队能像军队一样具有铁的纪律性。在一次敏捷培训中,我们与众多来自国内软件公司的项目经理们讨论了敏捷,以及他们现在各自的开发方法和问题。闲谈中,一位学员冒出一句,开发团队应该像军队,不仅要整体阵法严密,而且每个兵都要纪律分明。这次培训主要是介绍敏捷的技术实践,比如测试驱动开发、持续集成、用户故事等,该学员认为这些敏捷实践不仅可以提高员工的技战术,还可以塑造团队成员的纪律性。如果这些敏捷实践在日常开发中都能落在实处,势必将提高团队成员的战斗素养战术素养。一言以蔽之,相较于其他软件开发模式,敏捷方法对团队成员的纪律性提出了更高的要求,鼓励团队成员成长为项目经理心中的合格军人

其实,抛开敏捷方法,哪一种软件开发方法又何尝不强调团队成员的纪律性?计划驱动的传统型开发方法给软件过程制定了严格的计划书和检验标准,希望能提高团队的纪律性。它们的出发点是对的,但因为缺少了具体的技术实践导致计划书并不能匹配团队的真实状态;检验标准大多是着眼于与最终交付软件无关的中间文档,这些都使得成员在工作中对项目开发的约束力感受不深。比如,很多项目里面的规范说明书、WBS表和甘特图都画得非常详细,但大多数时候这些东西与项目真实情况的落差太大,很难指导督促成员的日常开发工作。而且,这些文档与需要交付的软件产品的关联性不强,也很难能让成员和其他人通过这些文档建立对软件交付的信心。长期看到团队的表现与计划的不相符,项目经理们往往会感叹团队的纪律性不行。那么,为什么说敏捷方法能相对一定有效地提升团队成员的纪律性呢?我们先来看看纪律的定义。

纪律

一般来说,纪律有三种基本涵义:1.纪律是指惩罚;2.纪律是指通过施加外部约束达到纠正行为目的的手段;3.纪律是指对自身行为起作用的内在约束力。这三层意思概括了纪律的基本内涵,同时也反映出良好纪律的形成过程是一个由外在的强迫纪律逐步过渡到内在自律的过程。从纪律的含义来看,达到自律是最终的目标,也是施加外部约束的目的所在。通过奖惩来达到一定的纪律性,比如程序员开发过程中的bug率等等,这是生活中最常见的一种形式。这种方法因为检查的结果与具体生产过程差得太远,而且评判标准还是比较粗放,所以应该是最低级的方式。施加外部约束,比如检查列表,指导产品的具体生产,可以评判成员的各个环节是否符合标准,应该算中级方式。只有自律,真正让成员把纪律的观念贯穿在生产的每个环节,主动改进,从而改善生产。而这,也是纪律性的高级方式。

对比这个标准,我们可以看到:计划驱动型的软件方法学强调更多的是奖惩,也涉及到一些外部约束(代码复审等),这也是为什么它们在培养团队成员纪律性上难度比较大。而敏捷方法,通过强调承诺,强调每个成员都是理性人的事实,借助于成员的自律性来达到严明的纪律性。国内有一家业内非常有名的技术网站InfoQ,四月份在北京举行的QCon
Beijing
就是由InfoQ主办。除了有限的几位全职员工,大部分的中文编辑都是社区的活跃分子,他们走到一起,通过之间的承诺和信任维持着日常工作,也给全国技术爱好者传播国内外的业界最新新闻和技术。撇开具体项目团队而言,这就是敏捷团队最好的写照。但是,我们也应该看到,InfoQ类型的团队是可遇不可求的。现实中,大部分的开发团队还是良莠不齐,项目经理们很难去完全授权给手下的员工。为什么敏捷方法又能有效地提升成员纪律性呢?答案在于敏捷方法不仅仅强调承诺,也包含了丰富的技术实践:不仅给个人带来更短更频繁的反馈,也给团队和组织带来了多层次较全面的反馈。而反馈的频繁程度,则是外部约束发挥作用的重要基础,也即提升纪律性的重要手段。

戴明环(PDCA

我们来看看被认为是组织或团队改进或解决质量问题的基本准则的戴明环。戴明环(PDCA)是由美国质量管理博士戴明在20世纪50年代提出,PDCA是英语单词Plan(计划)、Do(执行)、Check(检查)和Action(行动)的第一个字母,PDCA循环按照计划-执行-检查-行动的顺序进行,并且循环不止地进行下去,是一个立体多层级的螺旋式的演化过程。PDCA循环最开始是用在质量管理领域,但实际上它是有效进行任何一项工作的合乎逻辑的工作程序,是放之四海而皆准的指导性原则。下面我们就用它来说明外部约束对纪律养成是如何影响。

PDCA循环里面的Action是一个循环的关键,对Check的结果进行处理,成功的经验加以肯定并适当推广、标准化;失败的教训加以总结,未解决的问题放到下一个PDCA循环里,但它必须以上一环节的Check结果为基础。如果Check不到位,不能具体到实际工作,Action的正确性和出发依据就很值得商榷。软件开发是一个以不确定性为主要特征,强调知识的活动。为了采取的Action具有较高的正确几率,更需要强调开发过程的Check比较频繁、具体,不断给团队提出直接的反馈,这样才能减少不断累积的不确定性最后带来成不可控制的后果。如此来看,短而频繁的反馈对外来约束真正施加到个人的效果是非常重要的。

PDCA循环还有一个特点是多层级性:各层级质量管理都有一个PDCA循环,形成一个大环套小环,一环扣一环,互相制约,互为补充的有机整体。软件开发通常会把个人、团队和组织都牵扯进来:个人完成功能的开发,团队完成软件的开发,组织负责完成客户需求的完成。传统的软件开发方法更多的是强调团队、组织层级的计划、图表等文档,关注于团队与组织层级的反馈。对于真正创造产品质量的日常开发环节,则缺少必要的检查和反馈。与之相反,支撑敏捷方法的敏捷实践,就从个人-团队-组织的几个层面都提供了相应的反馈:低层次的反馈,为上一层次的反馈提供了依据,同时也作为上一层次反馈的落实和具体。


--未完待续--

 

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

(节选自本人翻译中的《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写到敏捷领袖应该“同时对客户和技术都具有深刻的理解,这样才能赢得开发团队的尊重。”良好的沟通技巧是必须的。迭代经理的职责之一就是维护开发团队与客户,以及与管理阶层之间的关系。

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

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

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

--未完待续--