Как заставить команду разработчиков использовать TDD и CI?

Подавать пример. Вы не можете заставить людей делать то, во что они не верят, особенно в вашей роли. Но если вы работаете так, как считаете правильным, и если вы незаметно показываете результаты, то в конечном итоге вы должны склонить людей на свою сторону. Никого не заставляйте, просто работайте так, как считаете правильным, отмечайте свои положительные результаты, а если им интересно, то показывайте еще.

Я впервые осознал мощь TDD, когда один из членов моей команды настоял на том, чтобы использовать его для своей работы. Я думал, что он зря тратит время, но я достаточно доверял ему, чтобы позволить ему работать так, как он считает нужным. Затем однажды он показал мне десятки ошибок, которые он нашел в нашем программном обеспечении и незаметно исправил. Он нашел их, потому что хотел проверить поведение кода, с которым работал, написать для него тесты и найти дыры. В тот момент он не преобразовал всю команду, но он преобразовал меня. Я уверен, что он делал это и для других людей... просто тихо.

Кстати, посмотрите это видео от Дэна Норта и, в частности, рассказ №3 «Тренер». http://www.infoq.com/presentations/interactions-career

По моему опыту, это многолетний процесс. Разработчики, которые не практикуют «Качественное встраивание» в своем ежедневном процессе, будут рассматривать это как дополнительную работу. Скорее программируют...

Качественная сборка

Бережливые производственные компании будут в максимально возможной степени использовать качество в своих процессах. Внедряя качество в свой процесс, вы предотвращаете ненужные доработки и брак. Это означает, что ваши машины способны обнаруживать неисправности (дзидока), а ваши приспособления защищены от ошибок, чтобы избежать неправильной сборки (пока-ёкэ).

Приверженность руководства

С моей точки зрения, это должно быть видением руководства, они должны сообщить этим командам, что именно этого от них и ждут.

Имейте в виду, что автоматизированное тестирование требует дополнительных усилий в краткосрочной перспективе, но в то же время является очень гибким и экономичным в долгосрочной перспективе. Время разработчиков будет распределено примерно на 33 % требований, 33 % на программирование и 33 % на автоматическое тестирование. Это замедлит работу команды, и это может стать проблемой, если руководство не будет в этом заинтересовано.

• Объясните, почему это хорошая практика
• Дайте команде время поэкспериментировать с ним, написав и запустив автоматические тесты.
• Ставьте перед собой реалистичные цели по увеличению охвата кода за каждый релиз/цикл.

Ориентированный на результат подход

Я менеджер программы разработки программного обеспечения, который испытал на себе многие преимущества разработки через тестирование и непрерывной интеграции. Но некоторые из команд разработчиков, с которыми я работаю, не следуют этим практикам. Я не обязан указывать им, как выполнять свою работу, но как я могу побудить их принять эти методы, не выходя за рамки моей роли?

Хотя вы, возможно, не в состоянии диктовать хорошие методы работы, вполне вероятно, что вы в состоянии применять подход, ориентированный на результат. Вообще говоря, TDD и CI — это методы, которые предназначены для снижения количества дефектов, и это должно быть вашим фокусом.

Например, вы можете нарисовать круговую диаграмму, показывающую, сколько времени уходит на исправление ошибок, а не на разработку новых функций с нуля. Делая уровень дефектов видимой стоимостью для разработчиков (которые обычно предпочитают работу над новыми функциями исправлению ошибок), вы создаете стимул для разработчиков проверять и адаптировать свой рабочий процесс.

Это не вопрос «привлечения людей к ответственности». Скорее, цель состоит в том, чтобы создать причинно-следственную связь, которая поможет разработчикам увидеть естественные последствия их текущих методов разработки. Это может быть все, что необходимо, чтобы вызвать перемены.

Обратите внимание, что в конце концов вас, вероятно , не должно волновать, пишут ли они программное обеспечение, используя TDD и CI, или пишут код на каменных табличках, используя клинопись. Что вас действительно волнует, так это качество программного обеспечения и эффективность доставки, и вы определенно должны поддерживать разумные цели для обоих этих аспектов. Затем команда разработчиков решает, хотят ли они делать что-то простым или сложным путем; вы можете давать указания, если они его возьмут, но вы должны позволить некоторым людям учиться на собственных ошибках.

Сосредоточьтесь на ощутимых результатах (например, количестве дефектов или сроках выполнения функций). Установите разумные цели для ваших проектов. Бросьте вызов своим командам, чтобы улучшить их процессы или цепочки инструментов, когда они не оправдывают разумных ожиданий. Вы не можете защитить людей от самих себя, но вы можете стимулировать их профессиональный рост, особенно если вы предоставляете время, деньги и оборудование, необходимые для реального изменения процесса.