关键点

1. 技术教练可以帮助开发者改变他们的日常习惯和工作方法，以更好的支持敏捷模式和开发运维。


2. 很少的团队可以成功的运用TDD。开发者从TDD练习到实践，都需要一些支持与帮助。


3. 与有经验的练习者一起工作去学习TDD是非常有效的，尤其是结合常规的实际训练课程。


4. “Samman”是一种技术教练的方法。它有两个主要组成部分：团队协作和学习时间。


5. 技术教练太少了，像Samman这样具体的方法可以帮助开发者开始训练。




对于敏捷模式和开发运维，一个成功的因素是开发者改变他们的工作方式并且使用Test-Driven Development（TDD）。它不是只发生于本次，更常见的是发生变化时。在本文中，我会讲一些我尝试过的，确实有用的做法。我会解释“Samman”，也就是我与开发者使用的教练法。


为什么TDD重要


如果一个团队正在构建软件产品，那么大家写代码的方式就尤为重要。好的技能实践意味着团队可以用更少的时间更高质量的构建新功能。这意味着满足时间节点和可靠的发布。熟练的开发者想为团队贡献高质量代码，有效的开发实践和健康的文化。在另一方面，团队也正在与糟糕的代码质量作斗争，不解决它最终将导致不能定期发布新功能或者效率低下。那对于任何团队来说都是坏的表现。




有一个备受推崇的调研向我们表明了影响。Forsgren写的Accelerate，阐述了对软件开发团队多年的研究而得出的值得关注的发现。他们研究了非常多的因素，发现了一些在商业成功案例中做出重要贡献的因素。他们还特别指出了持续发布的实践。这个术语包含了一些技术和组织的实践，包括TDD。








这就意味着可以说，使用TDD会带来成功的软件业务，但是这无疑是蓝图中的重要一环。团队生产高质量代码，完成高度自动化的测试，频繁集成，做持续的小的设计上的改进。不是每个团队或者软件开发者能够把它做的很好。








我作为技术辅导时，遇到了许多程序员习惯了长的交付周期，大概每周去集成改变。他们对于特殊的功能在当前需要做的变化上，几乎不去改进设计。这些团队只做了其他使用了TDD团队的一小部分的工作。TDD和高质量的代码库，在团队协作上有巨大的推进作用，能够更好的让开发者之间合作。








哪些是组织正在做的事情？




Accelerate调研告诉我们，在好的组织与表现差的团队之间有着巨大的差异。在数字化的新世界里，DevOps和业务敏捷，许多组织需要提升软件开发组织能力。我确实遇到了一些经理和架构师以及技术leads会让他们的开发团队去使用更加有效的实践方式。








最近我做了一场大概300人参与的ACCU 2021 研讨会，关于他们他们已经做了哪些学习的事情。（显然，这些是会议参与者，所以有一项活动我没有列举）。最受欢迎的选择依次递减：





1. 代码review


2. 线上按需培训视频


3. 导师课程辅导，每次2-5天


4. 结对编程


5. Hackathons


6. 实践社群




然后我通过对他们成功的学习TDD的调研，有一个附加选项“我没有学过TDD”。这就是最受欢迎的选项，非常不幸，通过追踪结对编程和线上颠簸视频课程得出结论。








这证实了我的观点，TDD学起来没那么简单；学习TDD最好的方式是从了解它的人那里学习，需要在你熟练的运用它之前付出努力和重复的做。hackathon和代码review不怎么管用；学一项类似TDD这样的技能不只是还没发生事情的一部分。甚至讲师带领的培训课程也不容易成功 - 对一种新的工作方式来说时间太短、重复太少。




与那些了解TDD的人结对编程是我见过的少有的有用的方式之一。然而没有几个团队中有人愿意做结对编程。如果人们有积极性并且能坚持下去，带有大量的实践练习的线上的培训课程也是有效的。如果只有少量人学习的话，对你的团队帮助不大。








我自己的经验




在2005年，我发现Coding Dojo论坛来教授和学习TDD，并且在帮助我同事掌握TDD上取得了一些进展。我在2011年写了第一本书“Coding Dojo 白皮书”。Coding Dojos是一个能让人们学到TDD基本概念的非常棒的方式，然后开始改变开发文化。然而，在一些年之后，我意识到它并没有那么成功，尤其是在代码质量差、TDD比较难的团队中。在Coding Dojo中成功的练习和在他们回到办公室后的所面对的现实中存在着巨大的差距。








下一项尝试 - Samman方法




在2018年，我从Llewellyn Falco处收到了一个极好的邀请，要去一对一的培训他。我在美国花了两周时间作为他的客户，看他正在做的事情看起来似乎可行。他用的同一种group code Kata sessions，我用coding dojos和实操整个团队的会话，在生产代码上。这种结合看起来能够解决问题。








回到家，我从此次旅行中获得了灵感并且在咨询中改变了方向。后面的三年中，我发现有4、5个团队希望让我尝试去做这个新方式的技术培训。我也招募了更多的人和我用同一种方式共同工作，我们开发方法。不久后，我想分享这些有效的技术。








我决定这种培训风格需要一个新的名字，以区分它和其它的方式，帮助人们发现它。“Samman”是一个瑞典语意思是“together”的意思。它看似对一种包含许多工作的方法非常合适在一个“ensemble” - 一个法语单词，也是“together”的意思。我在2021年1月发行了新书“Technical Agile Coaching with the Samman method”。








Samman方法是什么呢？




Samman是一种方法，它可以帮助人们想要提升软件构件的方式。尤其需要关注技术实践和人们如何去编码。Samman教练将他们的时间分配在一些软件开发结对上，这种方法主要有两个部分：





1. 学习时间


2. 一起工作




在学习时间，教练使用练习和有用的学习技术去教授理论和实践的技能，比如TDD。在一起的环节，整个团队与教练一起合作，在他们常用的生产库上应用敏捷开发技术。（一些人也许知道一起工作的另一个名字：Mob Programming）








学习时间 - 像一个短暂的，频繁的Coding Dojo




我确定你在学习一项新的技能上有经验了。也许你已经学会了一个乐器，一门外语，一种新的舞蹈风格，一项新运动。如果你已经成功了，我希望你有一些教授或者培训的心得体会，就跟相当多时间的专注练习一样。最好的学习经验经常会包括一个友善的小组、一个有激情的老师和有趣的病符合当前等级的实操练习。那就是学习时间的精髓。








我受Sharon Bowman所使用的教授方式启发。她卖的最好的书“Training from the Back of the Room”描述了“4C”教学模型。每一个学习时间有四部分结构组成：





1. 沟通


2. 概念


3. 具体实践


4. 总结




前面一章，大家回顾了学习新技能。那是一种“沟通”活动。为了学习新东西，你需要将它融合到你已有的知识之中。它给学习者一个机会去回顾已有的知识，在你要学习下一部分之前回忆起它们，“概念”。








在幻灯片前讨论让人理解的新概念。也许不总是那么奏效。你想要满足他们的好奇心，让他们主动的参与自己的学习中。大脑依靠多样性、运动和社交来寻找自我。我已经尽量精简了幻灯片的数量了。








如果我想使你们了解的概念是TDD的一部分，我会关于这项技术做一个简短的demo。如果它是一个设计模式或者测试能力的问题，我可能会给参与者一些代码去review。一个新的编码技术比如参数化测试，我会让他们通过网络搜索代码片段或者设计建议。








“具体实践”意思是写点代码做练习。这经常是学习时间的最长的部分 - 大约30-45分钟的时间，跟团队的所有人一起做或者分成2到3人的小组做。你不能写很多的代码，所以你需要准备一个起点和清晰的指令，所以人们可以开始直接学习“概念”。








我已经在coding dojos中使用了很多年的code katas，现在我仍在学习时间使用他们，几乎没有改动。我提供的新的练习倾向于更小并且注重于一项特殊的技术。我经常会用相同的形式去教授一些东西，在一个代码库中有一些分支，这些分支有着不同的起点。 Supermarket Receipt 是一个很好的例子。我用它来教重构和验收测试的各个方面。








在学习时间的最后，我们经常花几分钟时间做一下课程“总结”。它可以帮助人们记住用他们自己的话记录的内容，或者对另一个人讲述他们学到了什么。最后，我鼓励大家后面再自己单独做一下练习。练习的越多，就会越熟练，想到达一定的级别，你只需要花时间。








执行一个任务




所有聪明的大脑会在同一间事情上工作，同一时间，同一空间，同一个电脑 - 我们称他为“Mob Programming”。 - Woody Zuill








这段引用自“Mob Programming - a Whole Team Approach”，Woody Zuill 和 Kevin Meadows。我起初是跟Zuill与其它跟他相似的人那里学习技术。随后的几年中，我更喜欢用其它的词来形容他。我经常说“ensemble”。我喜欢这个词，它意思是友好合作的人们，像一个乐队。技术的本质是相同的。








就像音乐家们在演奏之前需要一起练习一样，程序员需要学习在一个大团队里如何更好的去合作。在一个组里，有不同的角色，需要不同的技能。作为领导者的第一个挑战是口头表达代码和设计。。你需要说“定义一个新变量”或者”串联返回语句”，当你以前只是将它打出来，但没想过它叫什么。当你已经学会了一些新词，你就会想到更高层的抽象，然后开放设计讨论。最终整个团队都被加进来去做开发工作，分享知识，开发大家都引以为豪的代码。








我曾多次注意到以下团队中的设置：团队中的某个人知道如何做。团队内的人去做这件事。很快团队里的所有人都知道如何去做这件事。这是经常的事 - 人们从其它人那里学习，知识和技能很快的就扩散开来。这是我作为技术教练的关键。作为团队的一员给了我巨大的力量！如果我加入了一个团队，我可以很自然的给团队推广我所知道的东西，如果有需要的话。








当我给一个团队做教练时，我经常建议他们使用Test-Driven Development。当我们讨论要做什么时，我会让他们列一个测试清单。当有些人开始实现代码时，我让他们先写测试用例。如果我们需要重构，我会让他们小步快跑。如果对于某个点，他们不知道怎么做，我可以做指导，告诉他们如何去做。我会短时间的承担这个角色 - 能够改变方向即可。当一些人有信息接手的时候，我就会再次退出。








对于教练来说，好的结果是在与团队一起工作时，你也可以不断的学到新知识。与如此多不同的人一起工作，你会学会新的工具，框架，设计思维；当你教授不同的团队并且推广你学到的知识时，会最终使整个组织受益。








在课程中，团队选择一项他们经常做的任务。通过教练的帮助，团队学会应用敏捷开发技术。








当人们第一次学习团队工作时，每天2小时足够了。这就是为什么Samman方法能够让教练和不止一个团队一起工作。你在早上可以教授一个团队（2个小时用于团队，1个小时用于学习），在下午再教授另一个团队。如果你，你可以同时给三个团队上课，然后共同使用学习时间。不得不说，那有点压力。








我既做线下也做线上的教学。我认为两种方式都挺好，都有利弊。当你再现场，你能够读他们的身体语言，当团队中其他人继续工作的时候，可以在旁边安静的谈话。当你远程时，每个人可以清晰的看到屏幕上的代码，每个人也都有一个舒适的座椅，键盘，显示器。人们也会容易的去查找文档，或者代码的其它部分，因为每个人有自己的机器，也可以看到分享的屏幕。








我发现，在十天半的训练之后，团队和教练都会从休息中受益；在开始下一个10天的训练之前，休息几天或者几周比较好。团队有一些时间可以不用教练工作，他们被迫找出什么是他们真正了解的，什么是当教练回来时，需要教练帮助的。教练也有时间去计划新的学习时间，或者跟其它人做一对一的培训。他们可能为以后的课程模块引入新的团队。








观察结果




在一个10天半的的教练周期之后，我观察到大多数团队可以掌握不需要教练就可以达到的点。这是一个团队学习的技能 - 当使用这项团队协作技能有用的时候票，他们可以决定继续进行。我听说过有些团队紧接着选择在较大的设计变动上做集成，还有当新团队成员加入时。有些甚至用它作为日常工作的一部分。








其它我观察到的主要的结果，在一两个教练周期后，是态度上的变化。在发布培训调查后，他们都比较有共识的点如下：





1. 更喜欢写单元测试


2. 更喜欢安全的提高设计和重构


3. 更喜欢可读性设计，可持续的测试用例


4. 更喜欢小步快跑，经常的提交代码


5. 提升团队协作




目前为止，我还没有与任何采用TDD很成功的大型的组织一起工作过。我看到一些团队采用非常常规的团队协作方式，开始写许多单元测试。我见过一些例子中的最显著的变化是团队内的一个成员已经是高级的水平，并且对TDD有了一定了解。训练使他们能够让他团队内的其他人开始那些之前知识口头讨论过的实际练习。








Samman训练适合你吗？




我相信世界上需要更多的技术教练。非常多的团队在困难的代码中挣扎，他们缺少能够更好的进行下去的敏捷技能。许多开发者和技术leader也许有这些技能，但是将他们更快更广的推广开来还需要费些功夫。Samman是一个具体的方法，它可以将有效的开发实践带到需要它的团队和组织中去。