《敏捷教练-如何打造优秀的敏捷团队》读书笔记
本书通过真实的例子，介绍如何辅导团队平稳度过整个敏捷转型生命期，如何打造一个自立、自觉的敏捷团队。针对敏捷实践的工作机理和如何激发团队的成长有深入的思考，可帮助读者了解如何高效召开各种敏捷会议，及如何指导团队建立良好的工作流程和工作习惯。总结了在敏捷转型过程中教练和团队可能面对的障碍及应对方案，很多都是我们实际敏捷推广过程中遇到过的问题，对于刚开始推行敏捷转型的敏捷教练、团队还是很有指导意义的。
后面几章是讲具体的敏捷实践，在很多书籍都有介绍过，就没有仔细去看了。
第一章教练的职责
1.1敏捷教练的职责
1.2教练角色
• 给出建议，让团队自己决策而不是由你指定方向
• 以团队外援的身份履行教练角色，优势在于能够和团队亲历问题，而不是旁观。团队知道你是从亲身体验的角度看问题时，会把你视为自己人。
• 敏捷教练并不需要知道所有的答案，有时候没有答案反而更好，非专家定位有助于你和问题保持必要的距离，还能从局外人的角度看待问题，帮助团队整体优化。
• 可以引导讨论，也可以引入组织内外其他敏捷团队尝试的经验。
• 团队境况越来越好的时候，教练应该功成身退，让团队自我教导，自己想办法找答案。
1.3几个重要的习惯
• 以身作则：从自己做起，让团队看到真实的例子
• 平衡心态：别让团队的反应乱了阵脚
• 循序渐进：耐心，逐步改进
• 谨言慎行：注意言辞，说话要基于团队的立场
• 边走边学：尝试，反思，从错误中学习
1.4教导前应澄清的问题
1.5PrOpER教导循环
• 问题：选择一个问题着手解决，观察团队的工作方式，哪些方面需要改进？
• 选项：考虑可选方案，哪些能推动项目向好的方向发展，列出至少三个选项。
• 试验：选择其中一个进行阐释
• 检验：检查结果，是否有所改善？是否有经验教训？
1.6考虑可选方案的方式
• 暴露问题：让团队看到问题
• 公开讨论问题：和团队讨论这个问题
• 静观其变：搁置问题，如果情况变得更糟糕，团队也许自己会发现问题
• 暗度陈仓：说服团队内或团队之外的其他人认识到问题
• 根因分析：寻找问题的根本原因
• 教育团队：提供更多信息帮助团队找到解决办法
• 予人权责：将此职责转交给团队或某个团队成员
• 在受阻时，可以想象其他教练面临同样的情形时所采取的措施。
1.7腌黄瓜现象
• 黄瓜在盐水灌里泡久了，会变成腌黄瓜。
• 如果我们跟同一个团队，甚至同一家公司长达几个月之久，会失去我们的新鲜视角。我们会看不出以前一眼就能察觉出来的问题，思想逐渐大众化，“我们这里就这样做事”。
• 如果发现自己正在变成腌菜，试着向外人解释你所面对的团队流程及挑战。解释过程中，也许能再度发现流程中的问题、隐藏的假设以及“房间里的大象”。
• 房间里的大象：指那些触目惊心地存在却被明目张胆地忽略甚至否定的事实或者感受。
1.8敏捷拦路石
• 当团队碰上严重障碍无法走向敏捷时，建议先移除障碍，再启动敏捷。不然人们会将失败归咎于敏捷。
• 比如正在进行组织结构调整，人们会更关注如何保住自己的工作，而无暇顾及敏捷。
第二章 与人合作
2.1倾听
• 先倾听再提建议：
– 倾听最难的在于克制自己的冲动，例如过早给出建议，或者把话题转到自己的相似经历。
– 你也许对所发生的事情有不同的看法，但在查清事实真相之前，先花时间听完对方的说法。
– 谈话顺利，可以要求澄清问题，以便不带偏见地理清事情的来龙去脉，并体现出你的意图在于澄清事实，而非对他们的行为进行盘问或批评。
– 参与集体会议时，如果你发现他们误解了一些东西，比如：“我们已经敏捷了，所以不需要写版本发布文档”，此时可以暂停会议检查团队对这一点的理解。
– 大家说什么词，你就用什么词，不要把你的理解强加于人，大胆问他们并确认是否已准确理解他们的要点。
• 言外之意：
– 寻求支持，还是找认同感，还是希望你帮助解决他所描述的问题
– 设身处地为他人着想，想象他们对现状的感受
• 维系信任关系：
– 结束谈话时，总结听到的关键点，并和对方确认，你是否理解他们的需要？
– 讲话者和你分享信息总是有原因的，但如果谈话后不继续跟进，他们可能会再也不会这样做了。问题暴露出来后，需要深入调查后再承诺，不要勉强自己立即做出承诺。
– 不要泄密，确认谈话内容是需要保密，还是可以和团队分享他们的担忧。
• 背景倾听
– 引导会议的时候，关注每一位发言者，等他们说完后再要求澄清。可以复述他们所讲的内容，这有助于你检验自己的理解。
• 给予反馈
– 谈谈从你的视角看到的数据，给出你曾经耳闻目睹的具体实例，而不是你的诠释。
2.2化解矛盾
• 有时团队会遇到一些冲突，教练可能会被卷入其中，如果发现团队内潜藏的矛盾，就多花点时间听听团队内有哪些看法，了解它的来龙去脉。
• 在扮演仲裁者角色时，不能偏袒任何一方，聆听各自对问题的描述，并用自己的话复述问题，表明你理解他们说的内容。接下来剥离个体原因，从团队的角度重新描述问题，告诉大家你发现一些环境因子对局势是有影响的。比如团队承受着交付压力，导致大家都工作到很晚。或者画画因果图，查明有哪些影响力。
• 团队内部化解纷争，有助于停止各自为政的行为。通过聆听，了解团队面临的问题，建立互信。
• 给反馈时，要区分所见所闻跟感受。讲观察结果时，要用实际的例子，而不是泛泛的建议。先讲述耳闻目睹的例子，再问问他们的见解，接着大家一起讨论下次如何应对类似的情况。
• 如爆发冲突，确保冲突各方都有机会陈述各自的观点。
2.3达成共识
• 引入新实践的时候有助于搞清楚是否所有团队成员都买你的帐。
• 梯度级别投票，将赞同的级别分成从力挺到力阻。
• 共识很重要，因为在有人不认同某措施的时候，他们不大可能全身心的投入。有时候你得做出决定，即使没有达成共识，也值得去做。通过一段时间的变更，团队在回顾会议上重新评估其成效。但如果梯度级别显示有很多反对声音，就得努力寻找所有人都能接受的方案。
• 相反的有同意阶梯，即在大家同意做某一件事的前提下，针对具体细节做投票。
第三章 领导变革
3.1引入变革
• 身为敏捷教练，你的工作有时是引入新的敏捷实践，有时则是帮助团队优化工作流程。不管是哪种，都需要领导团队实现变革。这并不是告诉大家该做什么这么简单。人们需要先知道为什么要这么做，才能全身心投入其中。
• 不能太快推动团队实现变革，开始变革前，团队需要时间讨论一下，认识到自己现在需要做哪些调整。
• 授人以渔
– 仅仅说服团队必须变革还不够，还需要告诉他们怎么起步。假设你给某团队的建议是写单元测试，说这可以帮助减少缺陷泄露，你会发现所有人都点头赞同，但就是不真正动手写测试。千万不要惊讶，他们需要再支持以实现变革。
– 有以下办法可以试试
• 教育团队：安排内训课，帮助大家学习如何写单元测试
• 演示：和开发人员结对，亲自示范如何写单元测试
• 公示：帮助团队达成共识，每天都写一定数量的单元测试；在团队白板上追踪目标的进展。
• 兜售问题
– 不要急着发表自己的观点，先准备好可以驱动变革的问题兜售出去。团队如果不改变，最可能的结果是什么，要把这幅景象清晰的描绘出来。让大家都明白，“不变”是有问题的。
– 变革的确需要花更多的时间、金钱，可能还会有很多困难。跟大家解释，为什么你还认为变革是个好主意，带来的收益大于付出。
– 例如：先走查，而后才迁入代码，这意味着实现用户故事需要更长时间，但这同样意味着，从长远看代码更容易维护。
– 如果能找到支撑观点的证据，兜售问题就更有说服力。上述例子，如果能分享一些代码在发布前被频繁退回返工的数据给大家看，再提出预测就会很有效。但不要批评团队当前的工作方式，教练的关注点是流程改进，不是个体绩效。
– 在理想情况下，你会发现大把的问题和改进机会，但是如果一个不漏的数落所有问题，就会给人留下负面印象，人们很快就不会再听你的。
– 如果要人们接受你的领导，可以“从小的变化开始，每次只做一件事，和团队集中精力解决它，其他的稍后慢慢来”。
3.2提问
• 向别人提问的行为表明你尊重他们的意见，而且对他们的回答感兴趣。尽量采用有启发性的问题，比如：
– 要让这个缺陷不再出现，我们能做什么？
– 我们怎样才能做到按时发货？
• 使用“为什么”这类问题要格外小心，这听起来像是批评，虽然你并无此意。比如：“你为什么要那样做？”听起来就像指责，而“你有试过…做吗？”听起来友好一些。也尽量不要使用“你们”这种字眼，让人感觉居高临下。
• 问什么
– 求助型问题：不要在团队会议上问，那是一般的做法，要选择一对一的时间问他们。
– 思考型问题：通过思考型问题引导团队思考。比如：
• 这个问题你考虑多久了？
• 针对这件事情所做的考虑，你自己满意吗？
• 你有哪些见解？
3.3鼓励学习
• 鼓励团队在计划里留出一些时间，例如，如果团队想要试试测试驱动开发这样的新实践，他们需要有时间事先学一学怎么做，而后才开始实施。
• 不要让团队对你产生依赖，把你作为他们唯一的敏捷知识来源，要鼓励他们自己主动学习相关知识。
• 安排时间让组织里的其他人分析他们的敏捷经验，这能为你的同事创造机会，展示他所学的东西。
3.4引导会议
• 为团队引进新实践时，需要展示具体做法。例如回顾会，主动请缨引导会议，向团队展示具体做法。在会议进行时，把遵循的流程解释给团队听，让他们学习如何自主引导这些会议。
• 下次会议前，协助会议的引导者规划会议议程，而后在会议中退居次席。但也要实时发表评论，向团队展示你的思考过程。
• 总结要点：结束会议时，把所有要点记录在白板上之前，复述你的理解，检查并确认自己真的理解了这些要点。
后面几章都是讲具体的敏捷实践，在很多书籍都有介绍过，就没有仔细去看了。