If the IT drama of TDD in episodes 14 to 22 is the same, once you find someone who has the ability to implement test-driven development and can actively drive it, then you have a start.We will review some of the steps Vanilla Pop took his team to implement TDD, and will also add some tips that I think are effective.
Step one: look for sparks
* Look for a candidate who is flexible in thinking and has high qualifications that can influence the rest of the team.Let them actively experiment and learn TDD on the sample code, and then start to apply it in actual work.
* Another strategy is to hire a developer with experience in agile software development, usually referred to as an agile technical coach or an XP coach.Let him participate in several team design sprints.Agile coaches, such as myself, have more than ten or twenty years of full-stack implementation of TDD in different programming languages, so it is not difficult to help your team change the programming model within a few days.
Step two, let the spark be called the flame
Actively study the code written in the work of the learning team
* Teach each developer how to implement TDD in combination with their own user stories.Pair programming in a few design sprints so your developers can get enough guidance on how to solve the most challenging micro-testing problems on their own, and just let the spark burn.It will be a little difficult at the beginning, and everyone will also learn how to delete and change existing code, and use newly learned design patterns to add micro-tests more easily.
* Reduce the pressure of release, so that each team member can have time to learn the skills that enable them to produce product features.For example: Let the team decide to do fewer user stories, so they can provide more micro-testing for the code.Another method is to choose a story and implement TDD in pair programming.Then in the next few rounds of sprints, continue this way until everyone can practice some TDD in their daily work.
* 40/4 challenge, and the danger of staying in the initial stage forever
* Use socialization to help the team practice and discuss the achievements of the micro-test during standing.
Step three, put in, make the flame of the fireplace more prosperous
Get management support
* Communicate with them the vision of using TDD in all product codes.Choose some time in two months and let the team discuss making TDD a mainstream product standard.
Make product micro-testing work more transparent
* Publish the number of micro-tests added every day.Discuss but don't brag about how many micro-tests are delivered in the stand-up meeting.It is a good idea to display relevant data on the panel of the continuous integration server.
* 停止抱怨自动化测试。开发者很快就会开始指责“新事物”减缓了进度，而且看似没有多少好处。每个人都知道学习需要时间。在开始学习这个方法的前两个月，速度减慢是正常、普遍的现象。抱怨正常出现的现象，只会让管理层有所顾虑，担心团队的不安。为了度过这一阶段，我建议关注学习新技能积极的一方面，与组员分享减慢速度后所学到的新事物。之后，速度就会回升，变得更快，但学习的过程必不可少。
* 在设计冲刺回顾中讨论微测试工作，这样你的组员就会知道他们需要为产出持久的价值负责。利益相关方也要了解到团队的新方法。
步骤四、保障燃料的持续供给
* 团队工作协议应该把处置未通过的测试作为优先任务。唯一一个更重要的事情，是产品的应用交付。在测试未通过时，有关的人员或者结对小组，应该停下来了处理这个问题。
* 新增且没有单元测试的代码，应该被删除，就像未通过审阅的代码一样。
* 对交付应用的代码进行结对编程（定义交付应用代码）。
* 如果两个月之后，团队对于新代码的使用上还有问题，反思这一情况出现的原因，这种情况只可能因为创建的微测试有问题或者开发者没有按有关的流程执行引发。
* 期待在开始启动TDD的6个月之后，代码几乎不会出现瑕疵，或是同未采用测试时的旧代码相比错误明显减少。错误追踪系统中的数量走势应当相应地下降。
* 据我的经验，在历史代码上启用TDD一年之后，错误追踪系统已经用处不大了，只是个支持和开发部门间的工作流程罢了。出现的错误应该少于10个。
下一集，让整个组织实施TDD
用户评论