Archive for

敏捷理念

023 让整个团队都开始实施TDD

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 10 seconds

00:00 / 9:00

Google Play Stitcher

RSS Feed

Share

Link

Embed

如果14到22集里TDD 的IT戏剧一样，一旦你找到了具备测试驱动开发实施能力和可以积极驱动这件事的人选，那么你就占到了起手。我们会回顾Vanilla Pop让他的团队实施TDD的一些步骤，同时也会增加一些我认为很有效的小贴士。 步骤一、寻找火花 寻找一个思维灵活、而且资历也比较高能影响到团队其他人的人选。让他们积极地在样本代码上试验学习TDD，之后在实际工作中开始应用。 另一个策略，是雇佣一个有敏捷软件开发经验的开发者，通常被称为敏捷技术教练或是XP教练。让他参与几次团队的设计冲刺。敏捷教练，比如我自己，有十多二十年使用不同编程语言全栈实施TDD的经验，因此帮助你的团队在几天内改变编程模式，并不是难事。 步骤二、让火花称为火焰积极地研究学习团队工作中所写的代码 教会每个开发者如何结合自己的用户故事来实施TDD。在几轮设计冲刺中进行结对编程，这样你的开发人员就能得到足够的指导，了解如何自己解决最有挑战的微测试问题，就这样让火花燃烧起来。一开始会有些难度，大家也会学习如何删除、改变已有代码，运用新学到的设计模式以便更方便地添加微测试。 减少发布的压力，使每个团队成员都能有时间学到让他们能够产出产品功能的技能。举例来说：让团队决定来做更少的用户故事，这样他们能够为代码提供更多的微测试。另一种方法，是选择一个故事，以结对编程的方式来实施TDD。然后在下几轮的冲刺中，继续这样的方式，直到每个人都能在他们的日常工作中都操练过一些TDD。 40/4挑战，以及永远停留在初级阶段的危险 使用社交化帮助团队操练，讨论微测试在站立期间所取得的成就。 步骤三、投入，让壁炉的火焰更旺获取管理层支持 同他们交流在全部产品代码中使用TDD的愿景。选择两个月后的某时间，让团队讨论使TDD成为主流的产品标准。让产品的微测试工作更加透明 公开每天新增的微测试数量。讨论但不要吹嘘有站立会里有多少交付的微测试。在连续整合服务器的面板显示有关的数据是个好主意。 停止抱怨自动化测试。开发者很快就会开始指责“新事物”减缓了进度，而且看似没有多少好处。每个人都知道学习需要时间。在开始学习这个方法的前两个月，速度减慢是正常、普遍的现象。抱怨正常出现的现象，只会让管理层有所顾虑，担心团队的不安。为了度过这一阶段，我建议关注学习新技能积极的一方面，与组员分享减慢速度后所学到的新事物。之后，速度就会回升，变得更快，但学习的过程必不可少。 在设计冲刺回顾中讨论微测试工作，这样你的组员就会知道他们需要为产出持久的价值负责。利益相关方也要了解到团队的新方法。 步骤四、保障燃料的持续供给 团队工作协议应该把处置未通过的测试作为优先任务。唯一一个更重要的事情，是产品的应用交付。在测试未通过时，有关的人员或者结对小组，应该停下来了处理这个问题。 新增且没有单元测试的代码，应该被删除，就像未通过审阅的代码一样。 对交付应用的代码进行结对编程（定义交付应用代码）。 如果两个月之后，团队对于新代码的使用上还有问题，反思这一情况出现的原因，这种情况只可能因为创建的微测试有问题或者开发者没有按有关的流程执行引发。 期待在开始启动TDD的6个月之后，代码几乎不会出现瑕疵，或是同未采用测试时的旧代码相比错误明显减少。错误追踪系统中的数量走势应当相应地下降。 据我的经验，在历史代码上启用TDD一年之后，错误追踪系统已经用处不大了，只是个支持和开发部门间的工作流程罢了。出现的错误应该少于10个。 下一集，让整个组织实施TDD