技术指导实践指南

关键要点

• 技术指导需要经过仔细的设计和规划。
• 有一系列可以通过逻辑和渐进的方式进行指导的主题。
• 与主题相对应的一系列练习。
• 你可能需要在其中充当教练的常见场景以及如何处理它们的建议。
• 关于会话格式以及如何使用指导会话的建议。

关于我

在过去的 4 到 5 年中，我一直担任软件开发教练，帮助组织改进他们的技术实践。

我也是偶然中发现自己正在承担教练的角色。一开始，我有点惊慌失措，因为之前从未做过这样的事情。我曾经组织过 TDD 和软件设计方面的活动会议，但从未按照某种逻辑顺序来组织它们。

我的第一个挑战是选择活动主题。

有哪些主题？

经过几次迭代，我开始专注于 XP 实践，特别是 TDD、结对编程、重构和简单设计。

随着经验的增长，我能够将这些练习分解为更细粒度的主题。

我的目标是找到尽可能平滑的路径，避免出现大的学习跳跃。另一个目标是找到具有编程语言无关性的主题。由于我工作的大多数组织都使用面向对象范式，所以一些主题偏向了面向对象。以下是我目前的主题分类：

• 结对编程
• 驾驶员和领航员
• 乒乓和爆米花
• 象棋时钟
• 番茄工作法
• 结对轮换

结对编程备忘单

• TDD
• 经典TDD
• 从外到内（Mockist）TDD
• 测试替身

• 转换优先级前提

• 重构
• IDE 生产力
• 重构味道

• 重构遗留代码

• 简单设计
• 对象健美操
• 代码的味道
• 简单设计四要素
• SOLID 原则

应该按照怎样的顺序进行？

多年来，我一直按照一定的主题顺序开展实验，并根据得到的反馈做出调整，现在已经不需要再做出任何重大的调整了。

这并不意味着我总是严格地按照这个顺序进行。我发现，在某些情况下，对顺序进行即时调整是有好处的。有时候，人们需要了解面向对象概念，有时候又需要用到设计模式，还有一些是关于领域驱动设计的。

我努力尝试找出一个不会造成学习大跳跃的顺序，同时又能避免添加不会在后续“模块”中使用的教材。

因此，测试替身被排到了比较靠后的位置，而这个项目之前通常排在最前面。

以下是我目前的主题顺序：

1. 面向对象的基础（可选的前导会话）。
2. 结对编程。
3. 经典 TDD。
4. 转换优先级前提。
5. 对象健美操。
6. 重构技术。
7. 代码的味道。
8. 遗留代码。
9. 简单设计四要素。
10. SOLID 原则。
11. 测试替身。
12. 从外到内 TDD。
13. 设计模式（可选）。
14. 领域驱动设计介绍（可选）。

在确定了主题顺序后，下一个目标就是为人们制定练习内容。练习是至关重要的。信息本身并不是很有用，学会应用知识等于掌握了知识，而刻意练习是成功的关键。

需要多长时间？

“重复造就了我们。因此，卓越不是一种行为，而是一种习惯。”——亚里士多德

在我执教的早期阶段，我尝试让人们结对完成他们的工作。我发现人们对这种方式感到沮丧，因为他们会跟不上速度，而且并非所有任务都适合使用结对的工作方式。

为了解决这种挫败感，我试图采用常用的代码 kata。这样做效果更好，但由于在工作区域结对，经常被打断是个大问题。我的解决方案是带他们到一个安静的远离办公桌的地方，并和我一起练习。

后来，我尝试与一对开发人员合作，而不是进行一对一指导。我发现这种方式的效果更好，可能是因为人们可以相互学习，而不仅仅是从教练那里学习。后来，我尝试混合不同团队的人来创建结对。我试着看看这种方式是否会改善团队之间的沟通，结果比预期更好。

我过去曾经使用过很多种练习，有些可行，有些不可行。在下面的表格中，我提出了一些在实践中可行的项目。

结对编程	没有（在后续的所有练习中使用结对编程技术）	1
经典 TDD	FizzBuzz、闰年、Fibonacci 数列、字符串计算器	2
转换优先级前提	罗马数字、质因数、保龄球	2
对象健美操	TicTacToe、生命周期游戏	2
重构技术	重构高尔夫、网球游戏	1
代码的味道	我使用了自己设计的练习，计划在适当的时候公开	1
遗留代码	镶金玫瑰、冷知识	2
简单设计四要素	火星车（从外部开始你的测试）	2
SOLID 原则	我使用了自己设计的练习，计划在适当的时候公开	1
测试替身	字符复制程序	1
从外到内 TDD	银行、购物车	2
设计模式（可选）	使用命令模式、策略模式和状态模式来重构火星车	2
领域驱动设计（可选）	讨论他们的银行和购物车方案	1

我只在有多余的时间并且我认为结对的人已经做好准备的情况下才会使用可选的会话。至于序言，我只会在有必要的时候才使用它。

在与另一位教练讨论时，他向我介绍了 Bloom 分类学。这是一种用在教学中的模型，根据复杂程度设定学习目标。

这个模型定义了六个级别的目标：记住、理解、应用、分析、评估、创造。我将这个模型应用于技术实践，并且为确定人们至少可以达到应用级别。

我总是停留在某个主题，直到人们感觉可以应用特定的练习。仅仅记住和理解一种做法是不够的。我试着让人们不断突破学习等级，只有他们能够应用学到的东西时才算真正学会了。

场景

在我担任教练的工作中，我需要面临一系列挑战。在本节中，我将介绍最常见的场景以及我是如何处理它们的。

场景一——“我不需要学习 / 改进实践”

我通常会从高级的开发者那里听到这句话。如果他们认为自己还没有准备好参加教练课程，我不会推他们。指导应该是一种拉而不是推。我选择和渴望学习并与我合作的人一起工作。随着时间的推移，他们开始传播他们所学到的东西，不那么渴望参与的人也开始变得积极起来。这个策略对我来说非常有效。

场景二——“我想要新的信息，不要让我练习”

我非常坚信，不通过实践获得的信息是没有价值的。如果有人专注于信息但却拒绝练习，我就不再继续。不过我从来没有真正做得这么极端。在某些时候，人们会意识到刻意练习的重要性。有时我会质问他们，他们究竟可以用新信息来做些什么。另一个办法是开始练习并让他们逐渐找到兴趣所在。

场景三——“我不想结对”

这通常是因为害怕暴露一个人的弱点。作为一名教练，我需要想办法克服他们的恐惧。我要让他们相信这里是一个安全的学习环境。通常，我会故意犯一些愚蠢的错误或暴露我对某个主题的无知，让其他人在暴露他们的技术弱点时感到不那么拘谨。

作为教练，我也想办法创建小组。我尝试避免结对的人力量分配不均，所以我通常从不同的团队中选择成员进行结对，并尝试让具有同等经验水平的人进行结对。我发现与陌生人结对更容易。

场景四——“我如何衡量指导是否成功？”

我对这个问题的通常回答是：你如何衡量质量？这完全是主观的。

即使在短期内无法衡量，在中期仍然会起到一定作用：

1. 完成课程的人与职位晋升之间存在关联 ;
2. 团队中的噪音水平增加 ;
3. 在完成课程之后，团队讨论的数量、长度和重点都在增加 ;
4. 讨论更侧重于设计，而不是新技术、产品和玩具 ;
5. 人们开始关心和分享得更多。

场景五——“我想了解这些做法，但我不会写代码”

有一些人对学习这些实践很感兴趣，但他们不是软件工程师，或者很久以前写过代码但忘得差不多了。在这种情况下，我自己进行练习，确保他们能够逐步理解我正在做的事情。到最后，有些人可以开始参与练习，也有些人没有参与进来，但是所有人都对教学内容有了更深入的理解。

在添加新内容之前和之后进行相同的练习

这种技术有奇迹般的效果。我要求结对人员在没有我的帮助的情况下自己做练习，我只负责澄清要求，并且告诉他们我不会查看结果。

在第一次迭代之后，我引入新的内容，并让结对的人进行相同的练习。如果他们觉得有难度，我就会向他们提供帮助。最后，我建议他们比较两个版本的练习。

放手

作为一名教练，我努力实现退出策略，让我指导的人不再需要我。

随着课程的进展，我提供的帮助越来越少，但我总是在场，以避免错误变成坏习惯。我让人们犯错，然后提出建议。

在刚开始的课程中，我充当反馈循环。在以后的课程中，人们应该自己形成内部的反馈循环。

在最后，我通常让他们自己来，在练习时不提供任何帮助。我只在练习完成后提供反馈，通常是向他们问题。

形式

我曾经用过几种形式：

• 运行几天小组课堂（从未超过 20 人）。
• 我发现这种形式最具挑战性。
  • 很难避免来自小组外的打扰。
  • 为团队中每个人找到合适的时间和地点是很困难的。
  • 提供相同级别的个性化反馈并不容易。
• 如果我能克服这些障碍，这可能是最有效的行式。
• 在小组中进行结对，每对一周进行两次 90 分钟的练习。
• 将小组分成两对，每周练习 120 分钟。

总结

在本节中，我将为软件教练提供一些一般性的建议：

• 人们应该掌握更多的个体 XP 实践（TDD、重构、结对编程、简单设计）。
• 确保他们至少在达到 Bloom 分类标准的应用水平之前花时间在练习上。
  • 避免仅仅在知识层面进行指导。
• 理想情况下，使用结对。
  • 这样可以练习结对编程并促进分享。
• 变通。如果使用小组的形式，则可以稍微变通下规则。
• 不断努力创造一个非常安全的学习环境。
• 考虑使用拉模型而不是推模型。
• 向人们解释学的目标是什么，并让他们专注于这些目标。
• 确保不要让人依赖你。随着课程的进展，给予他们越来越多的空间。
• 作为教练，你需要承担三种角色。通常按以下顺序进行：
  1. 老师。在刚开始时，你大部分时间都在教学，填补知识方面的空白。
  2. 导师。随着课程的进行，你将担任导师的角色，仅在需要时提供建议。
  3. 教练。放手让人们自己去练习，尝试在适当的时候提问，但不提供解决方案。
• 多年来，我发现缺乏最多的是软件设计技能。
• 没有良好的设计技能，所有的实践和准则都没有意义。
  • 简单设计是 XP 中最模糊的实践。
  • 花大量时间在软件设计工作上。
  • 为设计问题提供反馈，讨论替代方案……
  • 鼓励人们理解各个点之间的关联
    • 对象健美操 -> 代码的味道。
    • 代码的味道 -> 简单设计四要素。
    • 简单设计四要素 -> SOLID 原则。
• 人们应该在其敏捷开发 / 文化中包含所有其他 XP 实践。
• 团队不应该停止 XP 实践。
• 他们是怎样找出要构建的内容的（需求）？
• 他们在宏观设计（架构）中使用了哪些实践？
• 他们是怎样进行团队活动的（SCRUM/ 看板）？
• 他们是怎样发布软件的（DevOps 文化）？
• 放轻松，有耐心。
• 祝好运。

我正在写一本更深入的关于敏捷技术实践的书。可以在 Twitter 上关注我，以便了解该书的进展情况（@pedromsantos）。

关于作者

Pedro Santos 在软件开发方面拥有超过 25 年的经验。近年来，他一直专注于教育和激励其他开发人员。他花了数百个小时做结对练习、指导开发人员。他曾与开发人员合作过编程基础知识、面向对象设计、重构遗留代码、测试实践、架构决策和职业发展选择。

查看英文原文： Coaching Technical Practices