[最佳实践]敏捷回顾活动“最高指导原则”
只有做好敏捷回顾，才能不断地改进，实现正反馈，如何做呢？不妨看看国外大师们。。。。
敏捷回顾活动“最高指导原则”的辩论
设想邀请几位善于思考的聪明才智之士一起坐下来，一边喝茶一边讨论“最高指导原则”（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》等书的编辑。
[最佳实践]敏捷回顾活动“最高指导原则”相关推荐
- 基于云平台的41种可复用的架构最佳实践 ｜ 赠书活动
点击上方"程序猿技术大咖",关注并选择"设为星标" 回复"加群"获取入群讨论资格! 感谢大家对公众号"程序猿技术大咖"的 ...
- 印第安人的灵魂——敏捷回顾
印第安人在赶了3天路后,会停下来小憩一天,因为他要等着自己的灵魂跟上来.敏捷开发在经历了一次迭代或者冲刺(Sprint)后,也需要休整,以等待团队的灵魂跟上来,这一过程被称之为"敏捷回顾(A ...
- 互联网企业保持高绩效的秘密——敏捷回顾
图片来源:https://vitalitychicago.com/wp-content/uploads/2018/06/norm-kert-quote3.jpg 大家可能都知道我们所处的时代是一个VU ...
- 将 DTS 用于业务智能解决方案的最佳实践
摘自:http://www.microsoft.com/china/MSDN/library/archives/library/dnSQL2k/html/SQL_busintbpwithDTS.asp ...
- dubbo 无法访问消费端_Dubbo最佳实践，我整理了以下9点
Dubbo服务化,在当前互联网后端开发中,大部分都使用了Dubbo.截止目前github dubbo上,star也将近3万,使用dubbo的公司数量也很可观,Dubbo确实也是一个比较不错的服务化框架 ...
- 深入理解java虚拟机 - jvm高级特性与最佳实践(第三版)_JVM虚拟机面试指南：年薪30W以上高薪岗位需求的JVM，你必须要懂！...
JVM的重要性 很多人对于为什么要学JVM这个问题,他们的答案都是:因为面试.无论什么级别的Java从业者,JVM都是进阶时必须迈过的坎.不管是工作还是面试中,JVM都是必考题.如果不懂JVM的话,薪 ...
- 生产环境使用HBase，你必须知道的最佳实践
来源 | 阿丸笔记 封图| CSDN 下载于视觉中国 前面,我们已经打下了很多关于HBase的理论基础,今天,我们主要聊聊在实际开发使用HBase中,需要关注的一些最佳实践经验. Schema设计七大 ...
- hbase中为何不能向表中插入数据_生产环境使用HBase，你必须知道的最佳实践 | 百万人学AI...
叮咚-你被福利砸中了!现在起,「2020 AI开发者万人大会」299门票免费送!进入报名页面[2020 AI 开发者万人大会(线上直播门票)-IT培训直播-CSDN学院],点击"立即报名&q ...
- Hadoop-Impala优化十大指导原则和最佳实践
1.1 Hadoop-Impala优化十大指导原则和最佳实践 以下是性能准则和最佳做法.您可以使用在规划过程中实验,和hadoop集群一起进行impala的性能调整.所有这些信息也可在文档的其他地方 ...
最新文章
- 提高C++性能的编程技术笔记：内联+测试代码
- python不支持prelu_python实现并绘制 sigmoid函数，tanh函数，ReLU函数，PReLU函数
- 成功解决ValueError: Dimension 1 in both shapes must be equal, for ‘Assign_8‘ (op: ‘Assign‘) with input s
- 15 款Python编辑器的优缺点，别再问我“选什么编辑器”啦！
- android 输入模糊匹配_Android 模糊搜索rawquery bind or column index out of range:
- 我心中的MySQL DBA
- JAVA取钱多线程实验_JAVA多线程----用--取钱问题2
- 如何自定义一个datatable
- 数据结构与算法-java笔记一 更新中
- 微信/qq消息-定时自动循环发送
- 中学生怎样学计算机编程6,中学生学电脑编程有什么好处
- 黑盒测试与白盒测试的区别与方法
- nmds与mds的区别_PCA、PCoA、NMDS、CCA、RDA傻傻分不清楚
- 使用任意波形（或函数）发生器产生想要的任意信号
- 求两个数最小公倍数的7种方法
- IE不兼容HTML5、CSS3解决方法
- c语言.jpg图片转成数组_怎么转换图片成PDF格式？
- Java 项目的命名规范
- 涉密计算机外送维修,涉密计算机及涉密介质维修
- kafka listeners 和 advertised.listeners 的区别及应用