Привет. Меня зовут Вадим Бараненко.
Сотрудничаю с украинским офисом EPAM в качестве архитектора решений.
И в этом материале мне хотелось бы поделиться своими взглядами и опытом по такой интересной теме, как парное программирование (далее ПП).
Впервые я познакомился с ПП около 9 лет назад и практиковал этот подход на разных проектах — частично в харьковском офисе EPAM, частично на площадке заказчика в Англии.
И мне этот опыт показался интересным и полезным.
Первый проект, где я столкнулся с ПП, был для одного из крупнейших ритейлеров Англии.
Клиент использовал гибкие методологии разработки, экстремальное программирование (XP), в частности PP, разработку через тестирование.
В ходе этой работы я заинтересовался практиками продуктивности.
В то же время у EPAM был заказчик, которому нужна была команда с такими навыками.
Поэтому я согласился собрать и отстроить инженерные практики.
Вскоре возникла потребность в еще одной команде, и я перешел туда, чтобы запускать процессы в качестве лида.
Позже он переехал в Англию и начал работать на стороне клиента.
Там у нас была настоящая Agile-команда без лидов, хотя все инженеры были очень опытными.
Работать рука об руку с людьми из разных стран и с разным культурным прошлым было довольно интересной задачей.
В команду вошли инженеры из Нигерии, Индии, Египта, Англии и Украины.
Интересные вещи происходили даже на языковом уровне.
Сейчас я все чаще сталкиваюсь с проектами со значительным объемом работы и конкретными бюджетами.
В таком формате вряд ли можно позволить двум программистам работать над одной задачей.
Однако иногда все же можно использовать ПП.
Итак, три года назад поздно вечером «навалилась» проблема на производстве.
И вместе с ведущим проекта мы сели парой.
Код писался по принципу TDD, чтобы мы ничего не сломали.
И мы еще раз убедились: когда над кодом работают два инженера с разным мышлением, вероятность ошибки существенно снижается.
Простой пример: я увидел пять потенциальных дефектов в коде, и мой партнер увидел такое же количество.
Три дефекта совпали, но в целом мы нашли еще больше недостатков, которые могли привести к ошибкам в производстве.
Почему ПП не очень популярная практика
«Продать» программное обеспечение заказчику довольно сложно.Большинство людей не понимают, почему два инженера должны работать над одной и той же проблемой.
Поверхностные расчеты показывают, что проект потребует в два раза больше времени и денег.
Чтобы согласиться на ПП, клиент должен либо с самого начала иметь положительное отношение к Agile-методологиям, либо пройти трансформацию собственного бизнеса, желая разобраться и разобраться в этих процессах.
Важно, чтобы ИТ-подразделение клиента было готово к гибким технологиям, а клиент сам готов платить за качество.
ПП дает возможность вывести на рынок практически идеальный продукт в спокойные и ожидаемые сроки.
Для сжатых сроков ПП, наверное, не лучшая идея.
Но давайте обо всём по порядку.
Экстремальное программирование (XP) было создано во второй половине 90-х годов и вывело на новый уровень известные в то время подходы к созданию продуктов.
25 лет назад, во времена расцвета водопадной модели разработки, возникали трудности с интеграцией, тестированием, проектированием разных частей продукта и налаживанием коммуникации между разработчиками.
Одной из практик XP, обещавшей быстрый обмен знаниями о системе, проверку кода практически в реальном времени и своевременное создание проекта системы, было парное программирование.
Даже сегодня программное обеспечение позволяет вместе работать над кодом и выпускать значительно меньшие версии.
Это упрощает внесение изменений и повышает качество продукта.
Как организовать ПП: наш вариант
Процесс ПП может быть структурирован по-разному.Существует канонический подход, рекомендованный Кентом Беком (одним из основателей XP): пары инженеров сидят за большим столом с одним монитором, одной мышкой и клавиатурой.
Однако в EPAM мы немного модифицировали этот подход.
Космос
Два программиста сидят за большим столом с одним системным блоком, но двумя мониторами, мышами и клавиатурами.Так, на наш взгляд, работать удобнее.
Стол должен быть прямым.
Сначала мы использовали угловые, но практика показала, что это не очень удобно.
При таком подходе иногда приходилось передвигать мебель, чтобы сидеть рядом и иметь нормальное пространство для общения.
Подобные манипуляции – это лишнее время и суета.
Командная работа
Чтобы выстраивать процессы, у вас должны быть полномочия.Ведь порой сложно объяснить заказчику, руководству и инженерам важность программного обеспечения.
Если клиент и руководство принимают такой подход, но трудности остаются только с командой, стоит потратить время на выстраивание хороших отношений.
Культура должна основываться на взаимопомощи, а не на осуждении.
В ПП один (ведущий) пишет код, другой наблюдает, постигает и корректирует процесс так, чтобы он соответствовал требованиям дизайна.
Такое взаимодействие напоминает сочетание пилота и штурмана в раллийных гонках.
Этот подход требует частой смены ролей, чтобы у каждого была возможность писать и просматривать код, над которым работает его партнер.
Еще один полезный прием — объединение TDD и PP, когда один пишет тест, а второй — реализацию.
Затем запускаем тест и меняем роли.
При таком подходе никому не придется скучать.
Также пары должны постоянно меняться.
Благодаря этому у каждого программиста в команде есть понимание всей системы, а не какой-то одной ее части.
Сначала мы проигнорировали эту рекомендацию.
При планировании спринта они выдавали по одной User Story на пару, но в процессе разработки уже не могли ее разделить.
Позже, когда одна пара заканчивала работу над пользовательской историей, остальные обычно продолжали работать над своей.
Конечно, их тоже нельзя было разлучить.
Уже в Англии я столкнулся с подходом, который, на мой взгляд, работает лучше.
Необходимо, чтобы один программист взялся за задачу, а второй ему помог.
Во-первых, мы решаем психологическую проблему, когда некоторым инженерам комфортно работать с одними людьми, но крайне неудобно с другими.
Во-вторых, мы решаем логистический вопрос, ведь помощнику не нужно переносить свои вещи на новое место для непродолжительной работы.
Поэтому пару следует создавать на один день или задачу.
Инженеры в парах должны смотреть на один и тот же фрагмент кода и общаться друг с другом голосом.
«Штурман» не должен брать управление в свои руки.
Хорошая практика — обратить внимание на недостатки, рассказать и обсудить, что можно было бы сделать по-другому.
Мой опыт показывает, что в парах можно хорошо тренировать юниоров.
Это несколько не соответствует канонам, потому что.
программисты должны быть близки по своему профессиональному уровню.
Но, если подойти к процессу с умом, не отнимать у новичка «баранку» и общаться, вполне может получиться.
Надеюсь, мне удалось объяснить, что ПП может быть полезен в проекте.
Теперь перейдем к плюсам и минусам такого подхода.
Преимущества ПП
Обмен знаниями.Вы сможете быстро обмениваться информацией и не зависеть от одного человека.
Если кто-то из команды уходит в отпуск или на больничный, другие все равно будут иметь полную картину.
Этого можно добиться, регулярно меняя пары.
Качество кода улучшается.
Различные подходы к работе и взгляды на параметры кода могут дать хорошие результаты.
Улучшенный дизайн на разных уровнях продукта.
Если программисты обсудят это перед написанием кода, качество кода во всей системе будет выше.
Конечно, XP учит нас тому, что команда тратит меньше времени на дизайн продукта, чтобы сразу сосредоточиться на коде.
Знаете ли вы, как часто молодые инженеры начинают писать код, как только получают задание? В таких случаях работа в парах помогает больше думать и экономить время на исправлении недочетов.
На мой взгляд, это даже эффективнее, чем два программиста, параллельно работающие над двумя разными задачами.
Более высокая эффективность команды .
Как уже отмечалось, если кто-то будет контролировать работу специалиста, то он сделает это лучше, чем один.
И это не история о так называемых низкоэффективных (т. е.
тех, кто демонстрирует посредственные результаты).
Это базовая психология.
Меньше контроля со стороны менеджеров.
Ведь в ПП члены команды контролируют друг друга.
Общая ответственность за выполнение задачи мотивирует вас работать лучше.
Недостатки ПП
Инженерам психологически сложно начать работать с кем-то в паре.Во-первых, не всем нравится, когда за их работой пристально следят. Итак, когда в 2012 году, будучи Senior-level, я начал работать в парах, я боялся, что могу чего-то не знать, искал ответы на некоторые вопросы в Интернете.
Сейчас я архитектор решений, и практика показала, что люди не могут знать всего и это нормально.
Во-вторых, не все стремятся работать 100% времени.
Хороший результат – шесть продуктивных часов.
Еще немного — и команда может достичь выгорания и исчерпать свои ресурсы.
Чтобы этого избежать, можно реализовать известный метод в парах.
Помидоро : Таким образом инженеры будут работать вместе 20-30 минут, а затем делать 10-минутный перерыв для переключения передач.
Не каждый клиент может легко доказать важность программного обеспечения.
Сложнее всего доказать эффективность такого подхода клиентам, далеким от ИТ-сферы (ведь зачем двум людям работать над тем, что может сделать один?).
А самое простое — для клиентов, проекты которых имеют фиксированные сроки и объёмы работ на определённый период. Такие проекты идут вразрез с некоторыми принципами гибких методологий, поскольку команда лишь частично контролирует процесс, а программное обеспечение позволяет более эффективно решать сложные задачи.
Когда что-то пошло не так с процессами.
Например, лид, Скрам-мастер или другое ответственное лицо упустили кризисную ситуацию.
Скажем, либо правила работы в парах никто сразу не установил, либо за один стол посадили совершенно разных по темпераменту или профессиональному уровню специалистов, либо совсем забыли о необходимости менять пары.
Все это ломает подход к работе в парах.
ПП, плохая репутация проекта распространяется со скоростью света, а привлекать новых инженеров становится все сложнее.
Самые большие проблемы возникают, когда люди не общаются эффективно, не доверяют друг другу и не понимают, почему им следует работать вместе.
Работать удаленно и использовать программное обеспечение практически невозможно.
Есть несколько онлайн-инструментов, но я ими почти никогда не пользовался.
Главное, чего здесь не хватает – живого контакта между людьми.
И минутка стереотипов Бытует мнение, что программисты не очень хорошо ладят с другими людьми.
Говорят, что предпочитают общаться с железом, но в ПП им придется активно взаимодействовать с другими членами команды и постоянно объяснять свои действия.
На самом деле ПП действительно может раздражать и подходит не всем.
Вы наконец решили внедрить ПП.
Что дальше? Начните с пиара Расскажите своей команде, руководству и клиентам, почему вы это делаете, каких сложностей можно избежать при использовании программного обеспечения и как заставить программное обеспечение работать правильно.
Постарайтесь реализовать это не сразу, а постепенно.
Например, когда есть сложные задачи.
Во время планирования позвольте инженерам самостоятельно выбирать задачу и приглашайте коллег присоединиться к работе.
Если в вашей команде есть кто-то с опытом работы с ПП, постарайтесь, чтобы он работал с каждым членом команды по очереди.
Именно это я и сделал, когда настраивал процессы PP и TDD в ряде новых проектов.
По сути, он был наставником и показывал новичкам лучшие практики.
Прежде чем приступить к работе, попытайтесь выявить страхи вашей команды, связанные с внедрением программного обеспечения .
Объясните, что никто не будет никого осуждать за ошибки или несовершенные решения, и будет время выпить кофе.
Акцентируйте внимание на том, что благодаря такой работе вы сможете узнать много нового и понаблюдать за лучшими практиками своих коллег: например, Игорь отлично делает тесты, а Сергей отлично исправляет ошибки.
Опыт каждого члена команды станет богаче благодаря программному обеспечению; это хорошо не только для понимания продукта, но и для самоорганизации.
Конечно, у менеджеров тоже будет преимущество — в паре люди работают эффективнее, потому что валять дурака перед коллегой как-то неловко.
ПП не является панацеей, но может быть полезен для некоторых проектов.
Скажите, вы когда-нибудь работали в парах? Может быть, вы знаете какие-нибудь интересные ресурсы, где можно погрузиться в эту тему? Буду рад общению и обмену опытом в комментариях.
Вот некоторые из моих полезных ссылок:
- Кент Бек Объяснение экстремального программирования: Примите изменения, 2-е издание .
- Роберт Мартин, Чистый программист: Кодекс поведения для профессиональных программистов .
- видео от Роберта Мартина
-
Организация Стран-Экспортеров Нефти (Опек)
19 Oct, 24 -
Работа Как Конкурентный Процесс
19 Oct, 24 -
Ipv6 Для P2P
19 Oct, 24 -
Помни Ты Умрешь!
19 Oct, 24
