Инженерные практики - с чего начать?

Самая первая практика, которую я советую применять инженерам - это совместная разработка, парное или моб-программирование.

Давайте разбираться!

Что это такое?

Про парное программирование Кент Бек (автор экстремального программирования) писал еще в 1999 году. Это когда 2 разработчика сидят за одним компьютером и совместно пишут код, периодически передавая друг другу клавиатуру. О преимуществах и тактике использования этой инженерной практики более подробно можно почитать здесь.

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

Такой подход не обязан ограничиваться разработкой программ, любая нетривиальная работа, когда нужно “об кого-то” подумать, получить совет или научиться что-то делать, лучше выполняется в мобе. Помимо разработки, я лично участвовал в мобе для написания статей, создания сайтов-визиток, подготовке к тренингу и тд.

Зачем?

Лучший способ справиться со сложной (комплексной) работой

Что вы делаете, когда чего-то не знаете? Задаете вопрос тому человеку, который уже решал эту проблему (в том случае, если вы не нашли ответ в гугле 🙂). В моб-программировании с вами товарищ, который подскажет ответ, а если его нет, то всегда лучше подумать вместе, а ещё лучше, подумать и вместе нарисовать решение на доске с маркерами.

Самый быстрый способ разработки

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

Самый лучший способ обучиться

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

Фан 🙂

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

С чего начать работать?

Просто попробуйте - договоритесь с вашими коллегами на первую сессию, возьмите какую-то простую задачу или кату - вам нужно попробовать практику совместной работы, а не изучить алгоритм бинарного поиска 😄

Договоритесь про модель Драйвер/Навигатор/Наблюдатель:

• Драйвер - умное устройство ввода - мечта любого разработчика. Я подумал и код за меня сам написался!
• Навигатор - живет на пару шагов в будущем - даёт инструкции драйверу, что нужно сделать, проводит мгновенное ревью кода, замечает ошибки, в общем-то, делает всю основную работу
• Наблюдатель - активно ничего не делает, молчит, но всё замечает 😉

Определите очередность и частоту смены ролей. Запишите, прямо на бумажке, кто за кем меняется ролью. Это особенно понадобится, если с вами нет человека, который фасилитирует сессию и следит за временем. Временной интервал может быть любым. Начните с 10-15 минут и методом проб, подберите удобный для вас интервал по времени.

Настройте удобное рабочее окружение:

• если вы работает в офисе, забронируйте переговорку с проектором или большим телевизором, сядьте так, чтобы всем был виден экран и вам не нужно было ломать шею или глаза, чтобы видеть происходящее на экране, организуйте место драйвера за клавиатурой
• проследите, что нет торчащих проводов об которые можно споткнуться, когда меняете драйвера
• если работаете удаленно, настройте единое рабочее окружение. Подумайте о том, как вы будете “передавать клавиатуру”, то есть обмениваться незавершенной работой. Это можно делать через:

-комит во временную ветку в git

-используя плагины для совместной работы IDEA и VSCode 

-удаленный контроль в zoom или team viewer

• Позовите опытного коллегу, если у вас в организации уже кто-то практиковал моб-программирование, то позовите его на вашу сессию, он может помочь запустить процесс, как фасилитатор.

На что обратить внимание?

• Доброжелательная атмосфера - если у вас нет привычки совместной работы, то поначалу вам будет некомфортно писать код на глазах других людей, вы будете промахиваться мимо клавиш, не замечать глупые ошибки и опечатки. Это нормально и свойственно для всех! Потому, из роли навигатора будьте терпимее - не нужно шумно вздыхать, закатывать глаза или говорить о драйвере рукожопе. Вы сами будете таким драйвером! Мы работаем вместе, чтобы научиться чему-то новому или чтобы создать что-то крутое. Будьте добры и относитесь с уважением друг к другу 🙂
• Делайте ретроспективы по 5-10 минут, чтобы обсудить, что получилось и что можно улучшить, чтобы в следующий раз, работалось комфортнее и веселее
• Работайте сессиями по 2-4 часа, делайте перерывы.