Представление новых тем для коллег

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

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

Я попробую это в следующий раз. Я просто хочу вывести этот проект за дверь.

У меня такое чувство, потому что большинство из того, что они видели, - просто демонстрации типа лекций, и у них нет практического опыта. Что я могу сделать, чтобы подтолкнуть их? Я не хочу «заставлять» их писать код, если они этого не хотят, потому что это может показаться «домашней работой» и может оставить у них плохое впечатление.

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

Есть ли какие-нибудь забавные или интересные упражнения (сольные или командные), которые позволяют им иметь больше практического опыта в этих темах? Я надеюсь найти что-то, что вызвало бы достаточный интерес, чтобы они могли запланировать час своего дня для работы над чем-то интересным или достаточно интересным, чтобы они могли проводить расследование в свое время.

Чтобы «доказать» и, следовательно, действительно внедрить идею в чью-то голову, теории (разговора) никогда не бывает достаточно.

Вы должны использовать эту практику в своем собственном коде и заставить их «обнаружить», что это решает проблемы хорошим способом.

Это означает, что ваши практики должны быть эффективными, и вы должны сделать это очевидным.

Таким образом, чтение вашего кода вдохновит их, поскольку они «увидят его в действии».

Не думайте, что достаточно просто рассказать, как это работает.

Если судить по своему опыту, если они не хотят применять то, чему вы пытаетесь их научить, это означает, что им все равно. Вы, вероятно, тратите свое время, пытаясь представить им темы, потому что, если они понимают реальную пользу этих тем, они захотят применить их, а не оправдываться, почему они не могут.

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

Грустно, но верно. Может быть, ваша ситуация иная, но я сталкивался с этим пару раз в прошлом, и в конце концов было совершенно очевидно, что никто, кроме меня, не интересовался этими темами; В конечном итоге я принял решение уйти и попытаться найти сотрудников, которым все равно; те люди, которые либо не нуждаются во мне, чтобы вводить темы (потому что они уже знают / используют их), либо стремятся принять их, вместо того, чтобы сказать, как они не могут этого сделать.

Я видел много «лучших практик», которые перестали нравиться и больше никогда не привыкли. Существует много типов проектов, и такие методы подходят не для всех проектов. Убедитесь, что продаваемый материал действительно поможет.

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

Если вы можете мотивировать своих коллег принять участие, вы можете организовать Coding Dojos . Это проблемы программирования, когда участники сознательно сосредотачиваются на совершенствовании практики. Возможно, участие в тест-додзё, например, приведет ваших коллег к тому, чтобы увидеть преимущества TDD.

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

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

Лучшая практика на реальном производственном коде. Katas - хорошее введение, но по моему опыту, не держите то же самое "Эврика!" Моменты, как видя это сделано по-настоящему .

Тем не менее, вы указали, что сроки «не позволяют экспериментировать». Это действительно простое исправление. Вы уже занимаетесь тем, чему пытаетесь научить, поэтому оставьте открытое приглашение для совместной работы с вами, пока вы реализуете потрясающую новую функцию X. Пусть они сядут за клавиатуру и будут печатать, пока вы " вождение заднего сиденья ". Это позволит им нарастить мышечную память и уверенность в себе.

Удачи в ваших начинаниях.