敏捷教练-第一章旅行开始

让我们开始成为敏捷教练的旅行。你的任务是帮助团队使用敏捷生产优秀的代码。为了成功，你需要对敏捷的激情和狂热。在你能指导一个团队之前，使用过敏捷也是必须的。

你的第一个问题可能是：一个敏捷教练做什么呢？很快下一个问题就是：我怎样做呢？作为一个敏捷教练，你的成功归结为学校基础的引导技巧和策略，然后帮助你工作的团队去进行改变。

我们在本书的后面，将会深入到如何使用特定的敏捷实践来引导团队，例如TDD和用户故事。在此之前，我们先彻底学习敏捷教练要做什么，如何做这些。然后，我们将为能更好的前进做一些有用的准备工作。

1.1 What Does an Agile Coach Do?（敏捷教练做什么）

你的目标是培养一个高效的敏捷团队，这个团队自己思考，而不是依赖你去使用敏捷规则。展示给别人怎样是敏捷不是足够的。为了坚持使用敏捷，他们需要改变他们如何工作、如何思考。在他们能够有效地作为敏捷团队一员工作时，他们经常需要忘记一些旧习惯。作为一个敏捷教练，你的工作是帮助他们通过崎岖的山路，直到他们自己找到路。

每一个团队都是不同的，有着独一无二的特点和自己项目的挑战。这就意味着你引导一个团队时是依赖于他们对你有什么需求。如果一个团队刚刚使用敏捷，你可能就像一个足球教练，积极地向他们展现敏捷实践是怎么起作用的。对于更有经验的团队，你可能像一个生活教练，聆听然后问能帮助他们提高的问题而不是提供解决方法。

思维导图给你提供了涉及内容的总体概况，我们一起看一下每一个分支，有哪些事情你需要完成。

注意：用眼睛看、用耳朵听，注意到团队是如何工作的，找到潜在的原因

反馈：对于你看到的团队的问题，给出反馈。帮助他们把反馈融入到工作方法中，使得他们能够自己发现问题

引导：寻求方法去促进学习。你可以通过讲故事、进行课程培训来展示怎样做才是敏捷的。

促进：通过完成这些事情，使得有益的交流和合作更敏捷、更容易。

支持：当团队遇到问题时，你要在现场，鼓励他们继续前进，使得他们保持精力

看起来好像很多，但是你不需要一次做所有事情。引导项目一次走一步比狂风暴雨似的改变更好。你将会发现成功的秘密来源于正确的开发态度。

1.1 Developing a Coaching Attitude（培养引导态度）

培养一个积极的态度对于教练是非常必要的。在你让这件事情发生之前，你要相信变化时可能的。当你牢固地站在地上时，你要展示出你能接受新的可能性和主意。团队对你的需求依赖于他们能做什么和他们使这些变化成为事实的勇气。

下面是作为一个敏捷教练需要培养的重要习惯：

l 用案例引导

l 保持平衡

l 设置真实的步伐

l 注意你的语言

l 不断学习

让我们依次看一下每个术语的意思

Lead by Example（用案例引导）

给团队遵循敏捷实践的真实的生活中案例。举个例子，一个重要的敏捷原则是可持续的步伐（而不是一次完成）。所以，确保你在可以感觉到的时间离开办公室，这样来展示你在严格执行这个原则。面对面的交谈，代替使用电子邮件，通过这种方式来展示如何沟通。制定一个敏捷原则清单，这个清单中描述你想要展示什么给他们、如何展示给他们。

自己遵循自己的建议是引导他们的一个强大的方法。当你坚持你的建议时，人们知道你是可以信任的。现在花点时间去思考一下你用什么方法给他们展示实践。

Keep Your Balance（保持平衡）

对于团队来做，拒绝改变是很正常的，作为一个教练，你经常是介绍变化的这个人。预料到每一个变化的反击，不能让团队的反应让你失去平衡。他们可能会恢复到上一次“管理上最大的改变”，当这次的改变不起作用时，他们会立刻痛恨改变。

不要采取批评手段，这个更有可能导致团队反对你。积极坚持，保持你的引导地位不变。采取一些积极的行为，例如找到团队反对的根源，然后找到解决的办法。

Set a Realistic Pace（设置真实的步伐）

忍耐是教练的一个最重要的素质。不要期望团队有立刻的改变，改变需要时间。注意不要在早期他们努力适应敏捷时、存在不切实际的期望，通过找错误给团队增加压力。要记住，团队可能在其他压力下，导致他们不能立刻学习敏捷。冷静下来，不要增加压力。

当团队应用你交给他们的敏捷方法比较慢时，不要跳出来去指责他们。你要负责任，在自身上找原因。你是不是走得太快了？你是不是选择了一个错误开始时间？后退一会儿，和团队外的人聊聊天轻松一下。

忍耐不是自满-不要放弃。你确实是在最终要看到变化，所以继续轻轻地推和坚持下去。你能找到其他方法帮助团队看到慢下来后、学习敏捷技巧的重要性吗？找到一些可以支持团队走出困境、使他们感觉到可以安全试用新方法的方法。

Mind Your Language（注意你的语言）

这可能看起来很奇怪。但是当你作为一个教练时，你不得不注意你的语言。当然，他能让你保持清醒，但是我们推进这个的原因是你需要关心你怎样和团队交流。

你要表现出你是团队的一部分，通过和团队交流时使用“我们”而不是“我、你、他们”这样说：我们需要更新我们的发布燃尽图，而不是说：你需要更新你的发布燃尽图。不同是相当微妙的，但是却很重要，因为你像团队展示，你是和他们一伙的。并不是所有时间你都使用保护语言，当开始个人观点时，很清晰你要使用“我”，例如：我注意到我们的测试一个小时以上才跑一次。

如果你注意到有些事情是独特的，也要说出来。例如：我以前还没有看到有人这么做。或者更有效果的，我一起工作的上个团队在发布之前和他们的客户一起进行检查。把这些信息共享而不是建议或者批评，可以更好地引导团队进行选择。

避免进行彻底的字眼。不要使用“不”“总是”“对的”“错的”，因为这样可能会导致与现在的情形更坏。尽量不要驳斥过去的那些实践是错的或者不对的，这个将造成错觉，人们可能会感觉到这个很丢脸。

不要给人贴上标签，然后讨论成“开发人员”、“项目负责人”，把人分类会给沟通造成困难。尽量使用人的名字。

Learn as You Go（要不断学习）

当事情不像你期望的那样进行时，不要惊慌。花时间去思考一下发生了什么、为什么这个样子。最好的教训来源于从错误中学习。问一下自己，如果你再次面对这个问题，你将怎样做。

尽管这是很诱人的，但是也不要保护团队不去犯错误。项目，给团队空间去犯错误，然后就在那里帮助他们从经历中学习。

你不需要一直和团队一起忙碌工作。花费时间去考虑新的主意，可以和公司外的敏捷社区去交流发生的事情。读书、看博客、听播客，与对敏捷感兴趣的人保持交流。在第14章、207页将讲述关于培养自己的更多的内容。

1.3 Getting Ready to Coach（准备培训）

像运动员教练一样，敏捷教练需要知道如何进行游戏。你需要理解敏捷是怎样活动的，并且在敏捷实践中获取经验。当你有作为敏捷参与者的经验时，你就能更好地评估他是怎么工作的，你能够使用真实的例子来解释你的观点。

使用敏捷的经验不会让你自动地擅长解释敏捷技术。引入一些实践，学习如何解决意料不到的问题。找到一些还没有了解敏捷但是又愿意去听敏捷的人。如果你不能找到这样的人，你的家族都是敏捷专家，甚至你的猫都厌倦了听敏捷，就到当地的敏捷社区中去听其他人是怎么用的。你可以通过听敏捷播客来汲取一些有用的注意事项，一个好的开始是Agile Toolkit

在你和团队一起开始工作之前，要清楚的明白你的作用。敏捷不是结束。你想给这个团队带来哪些帮助？团队和开发负责人对你的期望是什么？花点时间来回答列在下一页方框里的问题。这些能够帮助你更好地被介绍到团队。

Arrange to be Introduced（安排介绍进入团队）

开始旅行的第一步很重要。在你做引导之前，你需要被介绍到团队中。即使你已经认识团队成员，他们需要了解你作为敏捷教练的新角色。

No Formal Introduction（非正式的介绍）

Henry作为一个敏捷教练，来帮助团队使用TDD，但是他没有被当做教练来介绍。他认为开发负责人已经向团队解释了他的角色，但是当他开始给团队提供建议时，他遇到了很多阻力。

在开发人员眼里，Henry是一个新的测试人员，他的工作是为他们写自动化测试用例。他们看起来没有任何原因听从他，把他给他们在过程中的反馈看做是不必要和有障碍的。形势让Henry非常的沮丧，有了这样一个不好的开始，解决问题就很困难，因为团队已经习惯了忽略他。

合适的介绍会增加团队的信任，在他们听从你的建议之前，这个非常重要。他们需要理解你建议他们做什么，这些支持来源于开发负责人。记住，如果他们是敏捷新手，他们可能需要关于敏捷是什么、敏捷的好处的讲解，这些都会使他们明白你的角色和地位。

谁来做介绍取决于你所处的情况：

External coach:（外部教练）

如果你作为一个敏捷专家加入这个团队，那么请你的出资人安排一个介绍。帮助他们做一个很有说服力的介绍，确信他们知道什么样的资历要告诉团队。举个例子，他可能提到你是一个开源工具的贡献者，你是一个多产的博客专家，你在另一个公司进行了一个突破性敏捷项目。这个比就这么说更好：我很高兴见到Allan，他是一个敏捷专家。

Internal coach:（内部教练）

如果你被你的老板安排去做一个项目的教练或者你在组织中支持一个开始做敏捷的项目，那么团队成员需要了解你的新角色。他们需要了解关于敏捷转变的计划。安排一个更高级别的有权威的项目管理者去解释你们组织的敏捷驱动。这些可以使团队从管理者那里获取信息，使得团队能够对你的建议更关注。

Extending your role:（扩展地位）

如果没有人叫你去介绍敏捷，你相信敏捷将给你的团队提供又是，你有权威去扩展你的地位成为一个敏捷教练。你不需要任何人帮助你介绍，但是不要略掉一个介绍。和团队开一个会，介绍你的新地位，回答他们关于转向敏捷的一些初级问题

介绍是两方面的。好的介绍会给你机会了解团队中的人。他们可能担心你隐藏了议程。和他们开诚布公地讨论你作为敏捷教练的动机。通过问他们的期望和担心，向他们展示，你是站在他们那一边的。这个能帮助你确定下次支持他们的时候你可以做哪些事情，然后赢得他们的信任。

你接受完以后，花费一些时间去了解开发人、看他们怎样工作。和团队坐在一起，而不是从远处观察他们。要保持和谐，都在，团队会当你在他们身边时才做的最好。

在他们愿意听从你的领导前，团队要对你的能力和经验建立信心。以他们的兴趣点开始很有帮助，例如开始交互会议来学习敏捷，例如XP游戏和coding dojo。

1.4 How to Start Coaching（如何开始引导）

你可能很急切地想要开始，但是从哪里开始呢？没有合适的地方。最简单的方法是挑选一个然后就去用。如果一开始看不出工作中的问题，那么你可以选择一个敏捷方法。头脑风暴一系列的问题，然后想那些事可以帮助团队提高了。然后基于引导任务按重要性排序，现在你有了一个开始点。

每一个引导阶段，你都可以使用PrOpER环，见图1.1，

问题：选择一个问题去解决。观察团队是怎样工作的，需要提升那些？

选择：考虑你的选择。你将试用那些会把情况变好？至少列出三个选择

尝试：使用一个选择去尝试

检查：检查结果。你提高了吗？即使没有提高，你学到什么了？

我们一起看一个例子：

问题：杰克今天早上站会迟到了。上周也发生这个事情了。你很担心，因为他在构建新的测试环境。他错过了团队提出的现在测试环境中存在的重要问题。

选择：下面是你考虑的几个选择

明知山有虎，偏向虎山行：当杰克到的时候，把他叫住，告诉他站会中他错过的问题。当你们一起浏览这些问题时，告诉他参加整个站会的重要性。

教育整个团队：召开一个会议，教育整个团队如何提升站会效果，这个将帮助杰克理解为什么对于团队中的每一个人参加站会都是重要的

自我管理：你需要一个人帮助你，问杰克是否能帮助你组织明天的站会

等待观望：什么都不坐，看这个团队自己是否能让杰克知道他迟到是个问题

尝试：你选择第一个，去和杰克谈论。在交谈中，你提到，你注意到他错过站会好几次了。他看起来相当吃惊，从他的角度来看，你没有做任何用户故事，所以他不需要在那里。你向他解释你关心的原因：他错过了从伙伴中获取构建测试环境的信息。也解释站会是团队组织的，不是为了客户。建议他和测试人员一起召开一个会，讨论他错过的那些问题。他点头同意明天早上按时参加站会。

检查：检查结果。第二天，杰克准时到了吗？你的交谈让他改变了吗？如果还是个问题，那你要尝试哪个选择呢？

当你试着提出这些选择时，下面是一些考虑的方面“

使问题浮出表面：把问题展示给团队

交流问题：和团队讨论问题

等待观望：不管这个问题，如果变得更坏，团队就会注意到

侧航：把这个问题转述给团队内或者外的其他人

根因分析：找到问题根源

教育团队：给团队提供更多的信息，让他们找到解决方法

指派别人负责：把责任给团队或者团队成员

讨论了你如何使用PrOpER循环，但是它不是个秘密。你可以在团队中公开地使用，非正式场合或者回顾会议

1.5 Maintaining the Pace(保持步伐)

建立一个敏捷团队需要时间，然后很多天看起来好像是没有进展的、肯定会有一些阻碍让你感到要放弃的，所以，如何保持动力继续前进呢？

吉姆进行了一次鼓舞人心的讲话，这次讲话时关于介绍敏捷技术到他的组织中，从他的讲话中找到了一些乐趣：改变我们的组织，组织的改变是超越我们控制得变化的。找到每天可以做的小的事情，这些会让你感到满意。

如果事情进展很慢，不要感到沮丧：尽力每天向前一小步。吉姆发现及时一开始甚至不能改变工作，但是他慢慢地发现是可以发现是可以改变人是如何思考的。团队内心的改变是看不到的，所以看起来他好像没有进步。但是在开始使用敏捷之前（敏捷是组织最终要使用的），解释这个是很必要的一个步骤。

A Shoulder to Cry On（一个哭泣的肩膀）

我第一个作为敏捷教练的大合同，我是一个外部敏捷教练，来带领团队转换到敏捷。开始是很艰难的，我习惯于和已经进行敏捷开发的，并且渴望做更多的人一起工作。但是因为一些原因，这些团队不热情，这个改变比较匆忙，他们不喜欢。

面对这种阻碍，能够帮助引导的就是把它和工作结合在一起。我们很多人是在London的一个星期二敏捷俱乐部认识的。当我遇到团队障碍时，我就去找其他的敏捷教练。他们可能已经解决过类似的问题，这样可以节省我的时间。即使他们没有解决相同问题，对于讨论注意事项和大家谈论也是有帮助的。当进行谈论的时候，可以一起去帮其他人出主意，也可以一起喝茶。

从内部或者外部找其他的教练帮忙，你可以找直接联系过的，也可以从关系网中寻找。

我们发现这个是有用的，如果你遇到困难，去参考其他教练在遇到这种情况是怎么做的。寻找和其他敏捷教练一起工作的机会，你很有可能会看到他们有不同的引导方式。观察他们是怎样处理这种情况的，来增强你的引导技能。不要模仿他们怎么做，这个有可能看起来是不舒服的，要考虑如何能够把他们的技术引进到你的方法中。

Breaking In Your Coach’s Boots

我们发现，要花费很长时间适应敏捷教练这个角色，是给建议而不是在工作中做一个角色。首先，你会发现手头没有工作处理，让团队决定而不是你自己做决定，还是很奇怪的。

在 Becoming a Manager这本书中，Linda跟踪了19个新项目经理第一年的工作。她说明了角色转换是很困难的意见事情。如果你原来是一个技术专家或者开发负责人，现在是一个敏捷教练，你需要花时间去改变你原来的角色，适应新的角色。工作中有这么多变化，我们如何定义自己，改变我们的工作。

你可能愿意转变这个角色，通过开始作为“参与教练”来实现。当你在团队中作为一个参与者时，你可能会直接遇到团队工作中遇到的问题，而不是通过观察。团队知道你遇到的问题来自于第一手经验，他们把你当做同伴。

我们也发现，如果我们做过多的项目中的任务，就没有时间去引导团队了。当我们把敏捷教练当做副业，而不是参与整个项目，我们可以全力去提高流程和团队的工作。你会发现，从教练的角度来看团队，帮助你看到更大的范围，所以你能够帮助团队优化全部。

那么，怎样判断你作为一个敏捷教练的作用呢？

l 回忆，团队是不是比一个月前更好？

l 你对团队有积极影响吗？

l 检查你前面问题的答案（P25页）

Liz Says. . .相信团队

不要期望从敏捷教练的工作中直接获得认可。这是一个支撑的角色，而不是直接交付效益的角色。

好的教练充分信息团队，当你和Frank一起有一个好主意时，如果成功了，那是Frank的主意，如果没有成功，那一起同情一下

另外一个团队已经接受你的引导的信号就是，你听到团队成员基于你原来给出的解释给出其他的建议。引导的喜悦就是当你看到团队自主地使用敏捷后达到了他们的目标。他们没有沉闷地干活，而是经历充沛地、像蜜蜂一样的工作

Moving On

如果一个黄瓜待在坛子中或者海水中太长时间，会发生什么呢？它成了腌菜，不管它是不是希望这样。在Secrets of Consulting这本书中，Jerry警告我们，要小心被腌制。如果我们和一个团队在一起（或者甚至是同一个公司）超过几个月，我们可能失去新鲜的视野。你不能看到一下子就能跳出来的问题。你开始使用相同的思维方式，发现自己是这样说的：周围人都是这样做的

如果你关心你正在被腌制，向团队外的人解释团队的进展和挑战。当你正在解释的时候，你可能看到过程中的问题、隐藏的假设、重大的问题。

当团队比较正常时，注意到你的敏捷教练的工作要结束了。团队成为了自引导，你需要让他们不再依赖你来得到答案。你可以离开了。

1.6 Hurdles

下面是你可能遇到的障碍

No Time to Coach（没时间引导）

如果你项目中的任务比较重，组织中的人是把你看做完成特殊任务的人，那么你就没有时间做敏捷教练了。你不能放弃你期望改变到敏捷教练角色的热情。相反，你要制定一个计划，把你自己从被每个人依赖的地位中解脱出来。慢下来、向别人展示你怎样完成这些关键任务（他们依赖你完成的）

考虑转换到一个不同的团队，通过这个团队你可以获得敏捷经验。然而，如果压力来源于你或者你内部的驱动去做更多的工作，那么休息一下好好看看现在的形式。

No Experience（没有经验）

如果你现在遇到一个问题，这个问题超出了你的经验，要对团队公开，不要欺骗。举个例子，你可能有很多小项目的经验，但是没有和大项目、分布式的项目一起共事过、或者可能你没有编程方面的经验，但是你意识到团队需要自动化测试。

一个敏捷教练不需要知道所有的答案，如果你不是都知道，有时还是更好的。不是一个专家会让你从公平的角度、从外部的角度来看这个问题。

通过促进讨论和通过研究组织内外的其他敏捷团队，来帮助团队解决问题。敏捷会议的经验报告是有用的来源。所有敏捷组织都是去发现其他团队正在做什么的另外一个好地方。如果你认为团队需要专家的帮助，就去找一个专家去指导团队面临的挑战。

Blockers to Agile（敏捷的阻碍者）