【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

敏捷回顾活动“最高指导原则”答疑解惑

  • 2008-02-27
  • 本文字数:8163 字

    阅读完需:约 27 分钟

设想邀请几位善于思考的聪明才智之士一起坐下来,一边喝茶一边讨论“最高指导原则”(Prime Directive)——敏捷回顾活动的基础。如果你还不了解敏捷回顾,那我可以向你推荐 Norm Kerth 关于项目回顾的书籍或Esther Derby 和Diana Larsen 关于敏捷回顾的书。其他类似过程包括项目结束后的复查,团队在某项活动完成后回头进行的“死后检查(postmortem)”(我怎么就这么讨厌这种说法呢?)。最高指导原则,遵循Norm 书中实践的人都会实践它,而且它也是敏捷回顾活动的核心——贡献知识——的先决条件。很多刚刚参加回顾活动以及努力理解最高指导原则的人们提出了类似下面谈话中的问题。这也是我们从这些用心思考的人们的言谈中学习和了解的好机会。

***

Philippe 是挑起话题的人。感谢你,Philippe!

Philippe:

“最高指导原则” 是这样说的:

无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。

真是如此吗?在我作为开发人员和咨询师的职业生涯中,就曾遇到过破坏分子和令人讨厌的人。大多数情况下,我尽量不与他们正面接触,总是尽量避开或是不与他们一起工作。

仅在口头上说“我坚信”对我来说无法接受,我曾经解雇过一个人(在我整个的职业生涯中),因为他不能胜任分配的工作;更确切地说,他能力上没有问题,但是对项目一点儿都不上心。所以我不轻易“相信”,而是从事实出发。从人的本性来看,我觉得“最高指导原则”太天真了。我可以完全相信与我一起工作的人,但是他们要能证明不会辜负我的信任。

Linda:

我当时也花费了很长时间才完全理解“最高指导原则”的真实意图。在我参与过的回顾活动中,有很多片段让我产生了同样的挣扎。回顾的目的是学习,它不是绩效评审活动。然而,谈论团队成员的人品如何,不能让参与者真正了解回顾的“目的”。必须要列出像“最高指导原则”和其他一些类似的条件才能达到目的。

“最高指导原则”的重点不是现实,而是在于信任,在于为了回顾活动的成功而坚持的想法,在于为了最大化知识的产出而将思考的重点暂时从“人”移开。这是一个“游戏”——“让我们假装”——而不是要检视工作场所和其中的人。

我知道当我要求别人“签字”遵守“最高指导原则”时,他们也有你同样的想法,这很正常。他们只要假装那么一小会儿就可以了,但这就足以让他们把对别人的评判放在一边,从而使团队学到新东西了。

“哄骗”自己的大脑来进行某些必要的行动——有时你必须这么做;发现这一点是挺让人吃惊的。不过我们的脑子经常可以接受类似的瞒哄。

很多人在一次回顾活动之后会来找我并道出许多类似你讲过的话,不过接下来他们会说:“不过我已经‘签字’遵守了‘最高指导原则’而且完成了一次回顾活动,我想‘最高指导原则’应该是没有问题的。”对此我从来都是不置评论,只轻轻点头表示赞同。

Eugene:

作为有过类似经历的人,我知道:即使是最有能力而且抱有最好意图的人,有时候也会对团队合作造成不良影响。我同意 Philippe 说的,与他们一起工作会让人经常有挫折感。而且我也不愿意与这样的人共事。但关键在于他们的本意根本不想产生不良影响。他们会尽一切努力来挽救管理不善的项目。从这个角度来看,“最高指导原则”是完全正确的。它甚至还提出了“考虑到……他们的技术水平和能力”这样的前提,要知道团队合作技能与纯技术的技能同样重要。

由于这些人要么就是坚持己见的专家,要么就是非正式的带头人,甚至二者兼备,我们作为经理应该做到这样两点:首先在构建团队时注意要减少“内部抵抗”,其次要针对不同级别、不同个性,以及我们与他们之间的不同关系来“销售”我们的团队运作方式。这就是我们打造具备凝聚力团队的方式。我坚信:我们永远不应期待或希望每个人都能唯领导马首是瞻。我们永远不会拥有完美的团队成员。我们必须学习如何与团队中不同类型的人打交道,并将他们打造为具有凝聚力的团队。即使是一个成熟的经理,想做到这些也是不容易的。有时我们可以称心如意,有时不行;而且可以在团队的士气和产出结果中看到差距所在。我想说,对一个经理来讲,这是他最困难、但也是最重要的、应不断“自省”的任务。

牢记这一点,我就觉得开展以遵守“最高指导原则”为基础的回顾活动就极其重要了。要想创造促进成功回顾活动的气氛,这是唯一的方式;而且也为我们进一步提升团队凝聚力提供了新的机会。

我不同意 Philippe 说的“我可以完全相信与我一起工作的人,但是他们要能证明不会辜负我的信任……”。二者非此即彼,不可兼得。要么我们给人十分的信任,如果他们不能好好表现(可以自己定义“好好表现”的含义)就给他扣分;要么我们从一开始就不信任他们,他们必须证明自己的价值。我曾见过这两种方式的实际应用,而且坚决支持第一种。而且,我认为第二种方式比较适合麦当劳(不知道,没在那儿打过工),但对 IT 公司肯定不行。我解读他的话是要说,应该不时评估是否应完全相信一个人;这一点我完全同意。

Philippe****:

我明白“最高指导原则”的意图所在,不过是“坚信”二字让我觉得迷惑。你现在是这样说的:“为了能够举行一次健康而有效的回顾活动,我们要假设佯装(你的原话)每个人都已尽己所能……”

如果我知道 Linda 根本就是在混日子,比如她说生病了,却被 Whistler 看到她在滑雪;比如与其他同事对抗;比如不能按时提交代码,而且埋怨是别人造成了她的延迟;你不会想让我带着“她已经尽力了”的想法开始回顾吧?你是说我们所见到的就是 Linda 所能尽力做到的,是么? 而且我们不能在会议中质疑她为什么不能尽力而为?

我想重写这条指导原则如下:无论我们发现了什么,根据每个人目前所知,他们的技术水平和能力,可用的资源以及目前的状况,我们要假定每个人都已经尽己所能。

但为什么 Linda 的绩效不能在回顾会议上评估呢?为什么我们要在三个小时内用美妙的比喻和华丽的语言来总结?要知道每个人都清楚真正的问题何在啊(也许 Linda 还不知道)。

Linda:

做绩效评估不是回顾活动的目标。一个组织当然总是要做绩效评估,不过,有些回顾活动中发现的东西也许有助于必须要做绩效评估的人。

但是

当团队成员开始彼此埋怨或者怪罪团队之外的人之时,回顾就很难再继续下去了。很多时候,很难说清楚为什么过去的绩效不理想。我想是因为当将其作为回顾活动的一部分时,参与者会有意识或者无意识地保护自己,因此不会讲述事实或者隐藏某些会让他们难堪的事情。

如果团队曾经有过不成功的学习经历,那就麻烦了。我曾经以为不断挑刺是一种“心智工程师化(engineering mentality)”[见译注 1],现在我认识到这其实是人类的一种特质。事情总会不断恶化,特别是在项目“失败”的时候,要想在这种背景下学习需要付出相当的努力。我想我们在日常生活中也是这样做的。

在任何语言中,措辞是非常重要的。“考虑到……在竭尽所能”是什么意思?我想你可能认为这是在说某人的表现没有达到期望值,而不是在指责团队成员没有全力以赴。当然,凭良心说,把某个已经尽力的人解雇掉,这种状况也有可能发生。

最后,我觉得你们可以按照自己的理解和喜好随意改写“最高指导原则”或者回顾活动的任何内容:-)!

很多时候,人们挣扎于解决从未讨论过的问题。没有人可以避免被别人指责工作没有做好的状况——我就遇到过。这并不是说人们就没有尽力。判断一个人是否全力以赴,可能根本就无法做到。而评价别人的表现就要容易得多,虽然我很高兴不必涉身其中:-)。

Linda,继续说道:

鉴于过去多次推行回顾活动的经验,我认识到回顾活动并不经常发生,但却是进行改变的好时机。个人与团队的变化我都见到过,而且有时是以令人讶异、意料不到的方式发生的。人们只有同意遵循“最高指导原则”并采用流程中其他一些环节,这些变化才有可能发生。我记得多次见过形势向好的方向发生转变的回顾活动。我可不愿意因为固执地认为我们“了解”其他人,从而丧失掉变化的机会。

不按“最高指导原则”办事,就可能导致形势陷入僵局。这太容易了——只要保持对过往彼此之间互动关系的固执判断即可——我自己就经常这样做。

Owen:

我想再次重申 Linda 的一些观点。“最高指导原则”的目的就是有意要让我们暂时停止对别人的不信任。就像 Linda 说的,让我们假装在接下来的两个小时里(或者是在回顾的持续之间之内),我们相信房间内每一个人都已经以最大的善意、尽自己最大努力贡献了自己最大的能力。当然,这样有点幼稚,不过不妨将其看做对心态的挑战。让我们放下怀疑和对他人的评判,试着让他们与我们一起进行回顾和学习,试着找出如何能够让一个人全力以赴。这是很富有挑战性的,因为与我们内心的想法完全相反。

Philippe 举了那个本应工作却去滑冰的员工的例子。我们能不能假设她虽去滑雪但是仍然有尽力工作,而不是假定她有怠工的嫌疑。这会让我们用一种积极的角度来看待她的动机。也许她是在与一个重要的客户滑雪,也许她刚因癌症去世的兄弟是个滑雪爱好者,而滑雪是她应对悲痛的方式。

归根结底,别人的动机是无法得知的——至少我们应该跟其他人共同验证。“最高指导原则”就是要让我们认识到:我们的观察是主观的,而且会被自己的偏见所影响;而且在挑战我们能否抛弃偏见——至少在回顾活动中应该这样。如果可以做到,我们也许能够学到一些东西。

Eugene:

说得太对了!还记得 20 还是 30 年前发行的 Yourdon 关于结构化设计的那本书吗?[译注 2] 他讲了一个故事,其中提到一个家伙在某个工作日中离开了办公室,回来时拎着一桶油漆,一句话不说就把办公室的门漆成绿色的了,然后又离开了整整一天。显然,他在办公室里面花了 36 个小时试图解决一个 bug(不过没有成功)。 Owen:

我花了相当一段时间来理解“最高指导原则”。阅读 Norm 的书,初步印象让我觉得“最高指导原则”像是一条咒语。我在刚开始推进回顾活动时试过几次,但是没产生什么魔力效果。所以当时就放弃了。Yahoo restrospective 讨论组上的讨论是促使我理解的关键。我现在试着在回顾活动中引入“最高指导原则”,但是仅仅把它大声诵读出来是没有用的。在回顾活动正式开始之前,应该与其他参与回顾的人一起讨论它。如果要做迭代回顾的话,这是一个很棒的“迭代原点”回顾活动的话题:),是回顾的“元回顾”。

Michael:

最近我加入了一家新公司,他们要我主持一个不太成功的项目的回顾活动。该项目曾经三次推迟发布日期,结果被中止了,因为公司认为不能再拖延下去了。大家都能想象得到,这种事情对于业务部门和开发部门之间信任关系的破坏非常严重。我对于回顾活动的目标,不只要让大家学习哪些环节可以做得更好,还要重建信任关系。要想达到目的,使用“最高指导原则”是唯一的方式。

Diana:

“最高指导原则”最让我困惑的不是有人在评判他人,而是有人这样说:

我自己有时没有尽力,是因为我觉得很懒或是拖拖拉拉或其他原因。所以我会假定别人也会因为这样卑劣的原因而没有全力以赴。我愿意因为懈怠承担责任,那别人也应该接受谴责。把这些事情都找出来然后公开化,我们都可以从中学习并获益。只有这样,我们才能收集到解决问题需要的全部信息,而且遭到羞辱的遭遇会让大家将来不再犯类似的错误。

聪明人对于他们本人和自己的意愿有着很高的期待和要求,但这会影响对于自己和他人的同情和理解,不能去体会别人的感受。我个人并不认同用羞辱来防止某些事情。激励者不应该让别人或自己感觉到羞耻。

Mary:

在流行“全面质量管理”(Total Quality Management,简称 TQM)的日子里,戴明与朱兰 [译注 3] 都注意到:当工人犯错误时,有 80-85% 都是由于系统出了问题,而不是个人原因。我也注意到这一点。每个个体都一定会有觉得疲倦或懒散的时候。但是不允许工人感到劳累或懒散的系统并不是好系统。举例来说,组装电脑时,需要向其中插入各种连接线,接头上都有类似与卡子的突出,这样就不会上下颠倒或是插反方向。我想起来以前的 PC 很容易把 IDE 线接错,我就犯过好几次。我不会责怪我自己,而是要怪那个没法区分的插头。

同样,我认为大部分的软件缺陷不是程序员的错误,而是系统的问题,比如没有提供适当的测试,从而不能马上发现缺陷。开发人员也会像工人一样感到疲劳和懈怠。系统应该知道这是理所当然的,并提供相应的补偿机制。不应该指望每个开发人员都能在 100% 的时间内做到 100% 的投入。这太不现实了。我们设计的系统应该能让人保留他们的自我。

另一个观察到的现象是,团队可能缺少真正做好工作的动力。我的经验告诉我,通常 80—85% 的时间都是这样的,其原因是对系统产生受挫感,或者缺少合适的工具或专家,或者由于无法直接与客户接触从而不知道真正应该做的是什么,或者对工作的衡量标准或者管理层的期望反而阻碍他们做正确的事情(非常常见的、导致表现不佳的原因)。我觉得,当人们没有尽力时,应该看看在管理方面有哪些因素对激励起到了反作用,看看是否缺少足够的专业知识,局部性优化工作衡量标准或期望值,或是其他妨碍人们尽力工作的障碍。

我不会假定每个人都已经全力以赴,但我会认为如果他们没有这样,深层次原因要从系统或者管理方面去发掘,而不是从个人身上找。当然并非永远如此。是有一些坏家伙,而且不管是什么原因,应该解决掉表现不佳的问题。然而,当系统有问题时,试图提升个人的表现没太大用处。因此,要解决问题的话,不应该先去责备某个人,而是要发现暗藏于系统之中的深层次原因。

Esther:

我习惯于这样引入“最高指导原则”。我会说:“是我个人的价值观让我今天站在这里。这并不容易,有时看到一些特别郁闷的问题,我还得提醒自己。今天我不是建议你们也采纳我的价值观,不过出于纯粹的实用主义角度考虑,如果对别人没有意见,你就更容易影响他们;如果你觉得别人很愚蠢,那就不可能从给他们身上学到东西了。”接下来我会问大家能否仅仅在回顾中,而不是永远,放下自己的个人意见。

Linda:

即使参与回顾的人很多,我也会举手示意,或者来回走几步,或者以其他方式来表示我在观察大家。这不会用多长时间,而且是一种影响别人的策略——比如与别人进行目光交流,让每个人都能说出“是的”。这样就能让大家更加投入。通常我不会去做任何“提醒”的动作,参与回顾的人之中总是有人会去做的——一般是正在学着推动回顾活动的人——而且此人更了解其他人,并可以通过他人和组织可以接受的语言来提醒大家。

Norm:

“最高指导原则”是我在回顾推动者事业的后期才制定出来的。直到我需要去教授别人如何引领回顾活动,我才发现有必要把“最高指导原则”明确叙述出来。不过其中蕴含的一些理念早在我参与第一次回顾活动时就已经有了,剩余的思想直到今天也已经深植于我的内心。

我十几岁的时候参加过帆船比赛。有一次比赛天气状况非常恶劣,我的一个朋友因帆船倾覆,溺水而亡。那些我非常尊敬的顶级水手们展开了一次无畏的复查活动,检查比赛的每个方面,检查每个人的行动,检查每个决策。不是为了别的,而是要让整个帆船社区知道如何避免另一次的死亡事件。因为这些水手们勇敢地一再讲述那个惨痛的故事,我们的领导者明确说明我们不能去评判别人的行动。不会有替罪羊,也没有人会受谴责。负疚感不应该总伴随着我们,而且也不会有什么惩罚,因为我们已经够难受了。

这是一个通过向大家反复讲述一个故事,以达到学习目的的极好例子。打那之后过去三十多年了,可我每一次踏上甲板都会想起从中学习的教训。

当开始制定我自己的课程时,我认识到不能这样说“不会发生鸡蛋里挑骨头的事情,也不会有对个人的评判,等等”,因为如果这样说,反而会让大家关注这些概念。实际上,我需要找到一种信息来替代这些东西。首先想到的是“我们假定每个人都已经全力以赴”。但是“假定”这个词汇看起来没有说服力,所以就改成了“我们理解并坚信:每个人对自己的工作都已全力以赴”。

我认为对于推动者最重要的是,要理解“最高指导原则”背后的含义。有了这个作为基础,就可以用我们的创造力来帮助有需要的组织提升他们。我想 Esther 对“最高指导原则”的阐述有必要成为我们职责的一部分,并成为我们的文化。

Ainsley:

要记得对自己应用“最高指导原则”。在我的个人回顾研讨会(Personal Retrospective Workshop)中,大家谈论了认识自己和个人经验的方式对我们个人如何产生巨大的影响。不管是对别人还是我自己,我都会将“最高指导原则”作为自我评估的上下文。后续产生了一些很精彩的讨论,很多人都注意到他们对别人会比对自己更加宽容,而且这对他们的工作也产生了影响。

Linda:

与诸位的这次谈话真的很不错。我在 yahoo 讨论组上发现了下面这段有趣的文字,感谢把它分享出来的人:

一位电视访谈节目主持人与 Richard Feynman 博士讨论了挑战者号航天飞机爆炸事故: 主持人:可是我们听到你们的委员会主席 Rogers 说:“我们在此不是为了责怪任何人。” 为什么?为什么没有人要被责怪? Feynman 博士:我不知道该责怪谁,而且这样做也没什么好处。真正的问题是:我们怎么样从中吸取经验教训…… MacNeil/Lehree 新闻时间,1986 年 6 月 9 日。

致谢

感谢下面这些通过不同方式参与讨论的人:Steve Adolph,Paul Culling,Esther Derby,Geoff Hewson,Norm Kerth,Philippe Kruchten,Diana Larsen,Jaswinder Madhur,Ainsley Nies,Eugene Nizker,Mary Poppendieck,Owen Rogers 和 Michael Vax。

作者简介

Linda Rising 在亚利桑那州立大学获得了基于对象设计方法领域的博士学位,她的背景还包括:在大学中授课,在电信、航空电子和战略武器系统等行业的工作经验。在模式、回顾活动、敏捷开发方法和流程变更等方面,是国际闻名的主持者。Linda 是《Fearless Change: Patterns for Introducing New Ideas》一书的作者,与Mary Lynn Manns 共同编写,而且是《Design Patterns in Communications Software》《The Pattern Almanac 2000》《The Patterns Handbook》等书的编辑。


InfoQ 上关于本话题的更多内容: Interview: Linda Rising on Collaboration, Bonobos and the Brain

译注 1:心智工程师化(engineering mentality)。1952 年,哈耶克以有力的证据证明了工程师化心态的特质。他认为工程师化心态的形成是教育的结果。这种教育未能让他们认识到,社会中无意识的行为和互相作用,对于形成和影响身边的人和世界起着非常重要的作用。相反,这种教育告诉他们,社会中各种流程的“理性”精密控制起到了关键作用。这会让工程师们一方面难于应对社会和政治领域中令人迷惑的因果关系,以及从而带来的妥协与慎重的思维方式;另一方面,他们会倾向于认为社会应该像一架运转良好的机器那样运作。

弗里德里希·冯·哈耶克(Friedrich von Hayek,1899-1992),20 世纪最伟大的经济学家之一,1974 年诺贝尔经济学奖获得者。主要著作包括《通往奴役之路》、《个人主义与经济秩序》、《货币的非国家化》、《致命的自负》、《自由秩序原理》、和《法、立法与自由》等。 延伸阅读有关“心智工程师化”内容,请查看 Clive Thompson 的博客文章:论文解释了为什么“心智工程师化”会制造出恐怖分子

译注2:可能是指1979 年由Prensent Hall 出版的《Structured Design》,作者Edward Yourdon。

译注3:戴明,本名William Edwards Deming。戴明博士是世界著名的质量管理专家,他对世界质量管理发展做出的卓越贡献享誉全球。作为质量管理的先驱者,戴明学说对国际质量管理理论和方法始终产生着异常重要的影响。戴明学说简洁易明,其主要观点“十四要点”成为本世纪全面质量管理(TQM)的重要理论基础。并首先提出PDCA 循环。

朱兰,本名Joseph H.Juran。朱兰博士是世界著名的质量管理专家,生于1904 年,他所倡导的质量管理理念和方法始终影响着世界以及世界质量管理的发展。他的"质量计划、质量控制和质量改进"被称为"朱兰三部曲"。他最早把帕累特原理引入质量管理。《管理突破》(Management Breakthrough)及《质量计划》(Quality Planning)二书是他的经典之著。由朱兰博士主编的《质量控制手册》(Quality Control Handbook)被称为当今世界质量控制科学的名著。为奠定全面质量(TQM)的理论基础和基本方法做出了卓越的贡献。 <strong><strong><strong> 查看英文原文:</strong><a href="http://www.infoq.com/articles/retrospective-prime-directive">Questioning the Retrospective Prime Directive</a> </strong></strong>

2008-02-27 01:491815
用户头像

发布了 479 篇内容, 共 151.8 次阅读, 收获喜欢 47 次。

关注

评论

发布
暂无评论
发现更多内容

利用树形结构辅助实现去重算法

卓丁

算法 algorithm tree Deduplication

从 Node 到 Deno

寇云

node.js deno

ziliqa生态打造区块链技术实体应用新标杆

极客编

ARTS 打卡 WEEK1

编程之心

ARTS 打卡计划

Cassandra集群架构及算法剖析

老任物联网杂谈

大数据 分布式 Cassandra 时序数据库

Spring事务@Transactional底层原理

公众号:好奇心森林

spring 事务 hiber

DDD 中的那些模式 — CQRS

Joshua

领域驱动设计 DDD 事件驱动 CQRS Event Driven

20200518-20200524朋友圈思考汇总

罗小布

日常思考

ARTS打卡第一周

Tom

绿宝这条宝藏街,夜宵也太太太太太好吃了吧!

极客编

ARTS打卡第一周

落曦

最优组合问题-贪心算法

公众号:好奇心森林

python实现·十大排序算法之归并排序(Merge Sort)

南风以南

Python 排序算法 归并排序

ARTS第一周

困到清醒

ARTS 打卡计划 起跑

程序员的晚餐 | 5 月 24 日 咖喱鸡块

清远

美食

Rust 遇上 C/C++ (一):数组操作

Coding Fatty

c c++ rust 编程语言

列个清单-《清单革命》

Jack Hong

理解这八大优势,才算精通单元测试

禅道项目管理

测试 单元测试

在线文档的开发难度与突破

葡萄城技术团队

分布式协同 SpreadJS 在线文档

思考:如何打造一个优秀的研发体系?

菜根老谭

研发管理 研发效能 研发体系

坚持ARTS(week-1)

王钰淇

ARTS 打卡计划

Refcard,近300份技术大咖总结的cheat sheet

KAMI

学习 开发 分享 作弊卡

别在发愁写页面了,强烈推荐几款傻瓜式扒网站神器!!

公众号:V5codings

人工智能学习心得--人工智能分类

岛乾坤

AI

回“疫”录(24):开始了就不算晚

小天同学

疫情 个人成长 回忆录 个人感想 日常思考

Implement Stack using Queues

onee

LeetCode

JUC整理笔记二之聊聊volatile

JFound

手把手透析C语言堆内存申请malloc及扩容realloc

卓丁

c 堆内存管理 heap memory malloc realloc

学会推销自己

一尘观世界

创业 程序员 外包 销售 接项目

重学 Java 设计模式:实战抽象工厂模式

小傅哥

设计模式 小傅哥 重构 代码质量 代码坏味道

从零到部署:用 Vue 和 Express 实现迷你全栈电商应用(二)

图雀社区

node.js vue.js Vue

敏捷回顾活动“最高指导原则”答疑解惑_研发效能_Linda Rising_InfoQ精选文章