& & 指导和辅导是能有效激发敏捷团队成长的重要实践之一。教练帮助团队学习敏捷实践，帮助人们从&敏捷似乎是我们应该做的事情&转变成&我们正在实践敏捷开发，定期成功交付商业价值&。& & 有越来越多的报道称，敏捷实施在最初的成功之后，继而却是失败的结果。组织里面第一个实施敏捷的团队通常表现都不错。这样的团队往往是由组织内表现最好的人员组建而成，而且配备经验丰富的敏捷教练来帮助团队学习新的技能。通常接下来实施敏捷的其他团队却不会这么成功，而且，屡次失败也导致组织内的敏捷无以为继。& & 关于这个典型现象有一些解释，在文献中往往是归咎于上级组织的文化或后来团队犯下的错误。这些原因可归纳如下：该组织的文化与敏捷文化中的透明性、自组织性、以及一线人员取代管理阶层做决定的特点背道而驰。随着敏捷团队最初的成功成为过去，政治因素开始接手，组织中有些人对敏捷团队的成功感到恐惧，有些人因为觉得失去控制权而恼怒不已，这样的人就开始攻击破坏日渐兴起的敏捷活动。& & 来自最早敏捷团队的成员被冠以&专家&的名头，团队被拆分，每个团队成员都被分派到其他团队中，人们把这些成员看作种子，希望在新团队里面扮演教练，传播敏捷。不幸的是，这些团队成员只有自己的经验，而且在新的团队里面（很可能）会面对迥异的环境。因此，如果他们试图把在特定环境下的体验运用到其他环境，自然无法达到显著结果。& & 上面的理由在很多情况下都是合理的，但它也把责任完全推到某个人身上，而没有考虑原来的敏捷教练，因为那些人现在已经出局了。另外，对于不是敏捷教练的人们来说，第一点理由让他们觉得敏捷教练们也太过自负了。但是，是否有其他的原因导致公司为发展而做的努力付诸东流？是否有可能发生这样的情况：原来的敏捷教练在第一个项目结束之后，没能正确地让团队为将来的成功做好准备？& & 我相信，目前敏捷教练&&特别是外部教练（比如本文作者）&&一直以来的工作方式存在问题。事实上，我认为我们是问题的一部分。让我解释一下：一般来说，我们在传授技能方面做得很好。比如，指导团队按照&启动&、&演示&和&回顾&这三部曲进行迭代，还有教授测试驱动开发。我们中有些人甚至可以很好地指导团队成为伪自组织型团队，他们通过苏格拉底问答的方式来指导团队，然后退后让团队自己犯错并从中学习。& & 我们甚至可以使用多种方式，把敏捷开发价值观很好地传授给团队。如果我们与团队共事足够长的时间，价值就会从勤快的、纪律严明的实践应用中呈现出来。& & 我们就像是团队的安全网，他们不能脱离我们独自行动，这是我们中许多人做得不够的地方。& & 鉴于现在的合同结算模式，外部敏捷教练可能与团队在工作时间内一直呆在一起，这样团队会倾向于依赖她。或者，即使她只是定期地（比如每个月有一个礼拜）出现在团队中，她仍然会呆上一段较长的时间。团队在困难问题上会依赖于她：请她帮助&说服&他人相信引入敏捷的价值；请她阻止异常情况悄悄签入，还要防止返回到以前做事的老路上去， 她的咨询费用也很昂贵。在首次获得显著成功之后，她就不怎么在团队中出现了。当她离开之后，事情变得不妙，最终推行敏捷的计划就会前功尽弃，人们对敏捷价值的看法也从惊叹不已滑落到&不像以前那么差嘛&。& & 这个问题我是见了一次又一次。我曾经身为这种类型的教练，那时我不会与团队共事&足够长的时间&，在离开团队之前，其他人都是肩并肩，而我却是退居二线：对此，我深感内疚。但是这还不够。我认为：作为敏捷教练，我们应该扪心自问；如果出现了问题，请停止指责我们客户（即便有正当的理由），我们应该把问题揽过来解决。& & 查看英文原文：Opinion: Agile Coaches Frequently a Source of Adoption Problems& & 本文来自：q.com/cn/news/2009/07/agile-coach-failures
声明：该文章系网友上传分享，此内容仅代表网友个人经验或观点，不代表本网站立场和观点；若未进行原创声明，则表明该文章系转载自互联网；若该文章内容涉嫌侵权，请及时向
上一篇：下一篇：
相关经验教程
论文写作技巧《敏捷教练——如何打造优秀的敏捷团队（Agile Coaching）》阅读随笔
核心提示：市面上讲怎么做敏捷教练的书有2本，1本是这本，还有1本叫CoachingAgile Teams（早前Ethan总在KM中给过一本供借阅）。这本书名为敏捷教练，但其实"敏捷教练"和ScrumMaster并不...
市面上讲怎么做敏捷教练的书有2本，1本是这本，还有1本叫CoachingAgile Teams（早前Ethan总在KM中给过一本供借阅）。这本书名为敏捷教练，但其实 敏捷教练 和ScrumMaster并不是截然区分的2个帽子， AgileCoaching 是每一个ScrumMaster都应该掌握的方法，因此这本书中的几乎所有内容，都适用于ScrumMaster。书里干货还是挺多的，不过和预期略有点不太一样，原本有点以为会讲些怎么coaching人（如具体的，怎么培养SM），不过这本书主要篇幅是在讲怎么coaching具体的敏捷过程和实践。
我学到的东西：
核心的Coaching模型就是PrOpER了。觉得起这个名字的水平……还要大小写跳过字母的。。。不如加个什么W的，变成POWER得了。PrOpER就是Problem -& Option -& Experiment -&Review，这个思维倒是挺好的，有点leanstartup的意思，首先要界定问题，然后考虑备选方案（可列出多个选项），然后just do it，再总结经验教训、回顾改进。
作为教练，是不能自己卷起袖子深陷于项目任务的。就像足球教练，需要站在场外而不是站在场上，这样有更理想的角度，更能全神贯注于全局状态、改进过程、提升团队合作。
房间里的大象 理论：教练不能浸泡在一个团队中太久，否则像黄瓜在盐水罐里浸泡的下场一样，不管是否情愿，都会变成腌黄瓜。房间里的大象就是说，有些问题触目惊心的存在、却被明目张胆的忽略掉了，原因就是 不识庐山真面目，只缘身在此山中 啊。缓解的办法就是多点和外面交流，把团队的状态告诉团队外的人、或者邀请团对外的人参与团队活动，就会得到不一样的反馈。
教练要化解团队矛盾，基本原则是要询问他们的感受和需求（来自《非暴力沟通》一书），有4个步骤的基本套路：观察（ 当你……的时候 ——描述观察）、感觉（ 你是否感觉到…… ——揣测情绪）、需求（ 因为你需要…… ——揣测需求）、请求（ 你想让我/他/他们做……吗 ——建议行动）
理想情况下，教练总是会发现大把的问题和改进机会。不要着急，心急吃不了热豆腐，像KentBeck说的一样， 从小的变化开始，每次只做一件事，其他的稍后慢慢来 ，专注于一个问题和团队一起解决。
在变革遇到阻力时，可以提议：尝试一下，权当做试验。团队会评估试验成功与否，这回引导团队关注其好处，考虑如何度量改进效果。这里面有一个天大的秘密：一旦团队决定冒险，把改变当作试验来尝试，团队成员就会习惯于新的工作方式，再退回来的实际概率很小！
对于激发团队自己思考问题（而不是教练思考问题），可以问的问题，带有 思考 （包括同义词，如想、考虑、见解…）这个词的问题就是好问题。例如：这个问题你考虑多久了？你有哪些见解？针对这件事情目前的考虑，你觉得有遗漏吗？等
对于客户（或Scrum里的PO）的角色，在大型的项目中，只有一个人担当客户肯定是不够的，需要有一个客户团队。一种合理的解决方法，就是近客户（near-customer）和远客户（far-customer）组合，近客户负责跟团队一起明确需求的细节，远客户负责业务优先级的决策。近客户和开发团队坐在一起，而远客户和运营、市场团队坐在一起。近客户就是BA/SA，远客户就是真正的产品经理。
每日站会：严格的站会规则（几点开、谁能说话、三段论）适合于初始引入的Scrum团队，但要注意不要变成应付式的 照章办事 、扼杀团队内部的自组织。不要本末倒置，我们更乐意听到热烈的讨论、每个人的都很投入、发挥出创造力，这是我们希望达到的状态。
用户故事：有些人把用户故事当作新的需求文档来使用，这就完全错过了用户故事的要义，用户故事的要义就在于问问题——3C
客户测试：不要也不应该期待客户写出边界测试/异常处理测试，这是IT人员份内的事情，用户只会也应该专注于软件交付的业务价值是否符合他的预期
这本书对看板的解释，我觉得是我看过的定义得最好的，如下这段话： 软件开发中的看板系统专注于实现工作的可视化，呈现价值流中的不同转化阶段，并限制每一点的在制品数量。团队因而可以发现系统中存在的瓶颈和约束，并借此持续改善系统，提高生产力，改善绩效。
慎用电子化的敏捷管理软件。如果项目或敏捷流程本身有问题，引入电子工具未必能解决问题，而且这类软件更易于掩盖问题，并促成糟糕的沟通实践。对于同时使用物理工具和电子工具的团队，建议只需在迭代的一头一尾使用电子工具，前面记录下故事的标题（及必要的信息）及估算值，后面记录故事的实现状态、团队的速率。中间任务级的信息，没有记录的必要。
重构：重构就像在家里整理东西，如果我每次去超市购物回来，都把东西随手一丢、也不收拾，我的房子很快就会变成一个烂摊子，房间里堆得满满当当，家里变得寸步难行。我啥也找不到，最终我可能要重新买这些东西。我可能会打碎一些东西，因为它被其他东西遮住了。所以，重构就是让代码一直有条理、不紊乱，对于居家，它就是最基本的持家之道。
回顾会：就是50%的时间回顾过去，50%的时间展望未来。回顾过去有3招：彩色时间线、情绪曲线、美术馆。敏捷（10）
Agile（10）
敏捷就是团队在一起工作、生成出优秀软件。作为一个敏捷教练，你可以帮助你的团队小步快跑到敏捷中去释放他们全部的潜能。
这本书就是关于如何使团队从敏捷中受益的。它关注于实际的建议、注意事项、技术，使得教练团队能否提高有效力。对于任何想要在敏捷开发中培训团队的人都适合不管你是开发负责人、技术专家或者你只是开发人员。
敏捷教练的艺术在于理解敏捷软件开发所遇到的问题、价值，以及这两者是如何结合的。作为一个敏捷教练，你不需要知道所有的答案，需要花费很多时间和很多经验才能找到最好的方法。我们所一起工作的团队遇到过很多的问题，我们从一起工作的团队中学习。
这本书将讨论从制定计划到部署软件的整个敏捷开发的每一个步骤。我们不得不去探索更多的敏捷方法中的实践，包含计划的和技术的，因为他们结合在一起工作会让系统更稳固。然而，经验告诉我们，最难的部分不是敏捷方法，而是如何教导别人采纳他们。这就是这本书的内容。
Generic Agile（一般的敏捷）
大多数团队使用的框架方法混合，所以在这本书中，把这些都叫做敏捷
敏捷过程中最简单的生命周期如图。这个图标明团队是周期地交付软件。每一次周期都以基于用户故事的的计划作为开始，以演示和回顾作为结束。团队在共用空间内一起工作，以围绕看板进行的站立晨会作为一天工作的开始。软件使用和来开发。一些团队以一周为周期，然而有些团队以一个月为一个周期
作为敏捷教练，我们努力在多职能团队和投资者之间建立一个有益的沟通。我们使用属于“客户”作为投资者代表，他和团队一起工作（相当于），但是不对团队的角色负责，基于我们的经验，这是两个不同的组织。
生命周期图标明敏捷实践是组合在一起的。但是不用从顶部开始执行敏捷。你的团队可以从生命周期中的任何实践开始，然后逐渐的把其他实践加入。
The Aim of This Book（本书的目标）
引导就是和人一起工作。这些人在工程和团队中工作，这些团队在一个组织中。每个人、工程、团队、组织是不同的，所以我们不能确切地规定你所遇到的问题如何来解决
作者建议：展示而不是告诉
我认为，不进入到敏捷实践中纯粹地谈论敏捷引导，是不可能的。这是作为敏捷教练的一个主要事情之一。你要亲自到敏捷团队中去帮助他们揭开敏捷神秘的面纱、解除混乱、使困难变得容易。
想象一个这样的场景，如果你看到一个人用锤子在敲钉子，但是他使用锤子柄来敲。你提供的帮助是给他展示如何使用锤子，你使得情况好转，你是用锤子头来敲钉子。现在，他们知道怎么使用锤子，工作变得容易了，他们很高兴使用锤子因为他们知道如何工作了。
我经常遇到一些团队，他们尽力在使用敏捷实践，但是他们做的相当奇怪，而且存在时间浪费。我展示给他们如何不同的做这件事情，而不是告诉他们如何来做。他们选择是否要使用我展示给他们看的那个方法。
我们给了一般的可以遵循的指导原则，也给了你可能遇到的情况下的不同选择。
我们不能给你永远奏效的规则，因为两种问题不会完全一样。根据这个团队的情况，可能会给喝其他团队相反的建议。例如：我们一般推荐开发负责人参加每日站会，但是我们也多次建议他们不参加。一些主要原因就是团队规模、团队压力、团队成员的经验。
通过这本书，我们共享在不同的环境中的故事，还有一些注意事项，如果你恰好遇到了我们描述的情形你可以使用这些注意事项。你需要决定是否在你的团队中使用我们的建议。
对于一个有效的敏捷教练连说，时间和经验是很必要的。阅读这本书将增加你的知识。他讲帮助你避免引导陷阱、对于提高引导技能提供注意事项。对于你和团队一起学习，它将给你灵感和主意。
How to Read This Book（如何阅读这本书）
每一个章节都是相对独立的。可以深入读也可以顺序读这本书。以讨论一般的引导规则为开始，然后进入到如何运用他们去引导特定的敏捷实践。在每一个章节的末尾，要画一些时间去回顾，反馈你如何在你的团队中运用你学习到的内容。
在引导敏捷团队中，我们遇到过很多不得不克服的障碍。在每一张的末尾，我们将共享这些案例，并且给出清除障碍的建议。这些不意味着是一个详尽的清单，但是我们希望当你遇到问题时，这些建议可以给你灵感。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：6174次
排名：千里之外
译文：11篇
(1)(1)(5)(5)&&&&敏捷教练：如何打造优秀的敏捷团队
钻石会员自营订单满49元（含）免运费
其他会员自营订单满59元（含）免运费
不足金额订单收取运费5元起
邀请好友参加吧
版 次：1页 数：219字 数：242000印刷时间：日开 本：16开纸 张：胶版纸印 次：1包 装：平装是否套装：国际标准书号ISBN：4所属分类：&&&
本商品暂无详情。