Парное программирование
Метод парного программирования за годы своего существования оброс противоречиями и кривотолками. Многие отрицательно воспринимают мысль о том, что два (и больше) человека могут плодотворно работать над одной и той же задачей.
Во-первых, работа в паре не обязательна. Никого нельзя к ней принуждать. Во-вторых, работа в паре не обязательно постоянна. Существует много веских причин, почему иногда лучше писать код в одиночестве. Желательно, чтобы доля программистов, работающих в паре, в команде была 50 % или около того. Но это не так важно. Она может быть лишь 30 %, а может и все 80 %. Право выбора принадлежит членам команды.
Что такое парное программирование?
Парное программирование — это совместная работа двух программистов над одной задачей. Напарники могут работать на одной машине, с одним монитором, клавиатурой и мышью. Или они могут работать на двух машинах по сети, пока могут видеть один и тот же код и обращаться с ним. Последнее прекрасно можно осуществить с помощью систем доступа к рабочему столу. Такое ПО позволяет напарникам находиться далеко друг от друга, если у них хорошая пропускная способность и голосовая связь.
Программисты, работающие в паре, выполняют разную работу. Один будто водитель, а другой — штурман. У водителя в руках инструменты — клавиатура и мышь. Штурман же внимательно всматривается в монитор и дает советы. Другой вариант: один программист пишет тест, а второй добивается его прохождения, после чего пишет ответный тест первому программисту. Иногда этот метод называют «пинг-понг».
Но чаще всего никакого разделения нет. Программисты просто сидят за одной машиной и занимаются одним и тем же и по очереди используют клавиатуру и мышь.
Пары не назначаются. Они выбирают друг друга в зависимости от желания совместной работы над одной задачей. Менеджеры не должны вмешиваться со своими расписаниями или матрицами.
Чаще всего напарники быстро меняют партнера. Сессия парного программирования может длиться день, но чаще всего они длятся от силы час-два. Даже работа в паре в течение лишь четверти-получаса может принести пользу.
Истории не распределяются по парам. За истории отвечают отдельные программисты, а не оба напарника. Продолжительность выполнения истории длится, как правило, гораздо дольше, чем работа с одним напарником.
В неделю каждый программист будет тратить около половины своего времени на выполнение своих собственных задач, привлекая к помощи некоторых других программистов. Оставшуюся половину времени, проводимого в паре, он потратит на помощь другим программистам с их заданиями.
Опытным программистам следует стараться как можно чаще работать в паре с младшими. Младшим программистам нужно просить помощи чаще у опытных, чем у других младших. Программисты со специализацией должны тратить значительное количество времени, работая в паре с программистами над задачами вне своей специализации. Цель состоит в том, чтобы распространять знания и обмениваться ими, а не накапливать их в одиночку.
Зачем работать в паре?
Работая в паре, мы укрепляем командный дух. Члены команды не изолируются друг от друга, а ежесекундно сотрудничают. Когда член команды не может работать, другие закрывают образовавшуюся брешь и двигаются к цели.
Работа в паре — однозначно лучший способ обмениваться знаниями в команде и избегать сокрытия информации отдельными членами. Это лучший способ организовать команду так, чтобы в ней не было незаменимых сотрудников.
Многие команды сообщали, что парное программирование сокращает количество ошибок и улучшает качество проектирования. Это верно в большинстве случаев. Как правило, во время работы над задачей лучше, если на нее смотрит не одна пара глаз. Действительно, во многих командах перешли от разбора кода к работе в парах.
Парное программирование как анализ кода
Парное программирование представляет собой вид анализа кода (Code Review), но имеет значительное преимущество. Работая в паре, программисты пишут код в соавторстве. Они видят уже написанный код и, как само собой разумеющееся, проводят его анализ с целью создания нового кода. Таким образом анализ кода — это не просто статическая проверка, которая проводится, чтобы убедиться в том, что код соответствует нормам, принятым в команде. Скорее это динамический обзор текущего состояния кода с прицелом на то, каким код должен быть в ближайшем будущем.
А каковы издержки?
Сложно измерить издержки, возникающие при парном программировании. Прямая издержка — это то, что над одной задачей работает два человека. Очевидно, что на решение задачи не затрачивается двойного усилия, но, вероятно, какие-то издержки все же есть. В разных исследованиях установлено, что издержки составляют примерно 15 %. Другими словами, потребуется 115 программистов, работающих в паре, чтобы выполнить работу 100 программистов, работающих индивидуально (без анализа кода).
Если считать упрощенно, получается, что в команде, где в паре работают половину от всего времени, потери в производительности составят менее 8 %. С другой стороны, работа в паре снимает необходимость анализа кода, и тогда нет никакой потери производительности.
Затем рассмотрим преимущества — обмен знаниями, взаимное обучение и глубокое взаимодействие. Эти преимущества невозможно просчитать, но они также весьма важны.
По моему опыту и опыту многих других, программирование в паре, если оно происходит непринужденно и по желанию самих программистов, приносит довольно много пользы всей команде.
Только два?
Слово «пара» подразумевает, что в сессии парного программирования работают только два программиста. Хотя чаще всего это так, это не строгое правило. Иногда для решения задачи может собраться группа из трех, четырех или большего количества программистов (опять же на усмотрение программистов). Это явление иногда называют «совместное программирование»[55].
Менеджеры
Программисты часто опасаются, что менеджеры не одобрят работу в парах или даже потребуют разойтись и не заниматься ерундой, чтобы не тратить драгоценное время. Я с таким не встречался. За все полвека, что я занимаюсь написанием кода, я никогда не видел, чтобы менеджеры вмешивались. В большинстве случаев, по моему опыту, они только рады видеть, что программисты сотрудничают, работая вместе. Это создает впечатление, что работа кипит.
Если же вы менеджер, который хочет разогнать программистов, работающих в паре, опасаясь, что такая работа неэффективна, то отбросьте свои опасения и дайте программистам возможность решить самим. В конце концов, они профессионалы. А если вы программист и ваш менеджер требует прекратить работу в паре, напомните ему, что специалист здесь вы, поэтому только вы, а не менеджер, отвечаете за то, как будет вестись работа.
И наконец, никогда в жизни не просите разрешения на работу в паре. На проведение тестирования. На рефакторинг. И прочее.
Вы профессионал. Вам решать.
Заключение
Технические методы Agile — наиболее важная составляющая всей методологии. Любая попытка применить Agile без технических методов обречена на провал. Причина проста: Agile — действенный механизм при работе в большой спешке, образующей большой беспорядок. Без использования технических методов, позволяющих поддерживать высокий уровень качества кода, команда начнет стремительно и неумолимо утопать в бесконечной пучине низкой производительности.
Глава 6. Внедрение Agile
Когда я впервые услышал об экстремальном программировании, то подумал: «Что может быть проще? Просто соблюдать простые правила и применять методы. Вот и все».
Но судя по тому, сколько организаций безуспешно пытается внедрить Agile, реализация Agile сопровождается огромными сложностями. Возможно, причина всего этого в том, что во многих компаниях принимают за Agile что-то, что им не является.
Ценности Agile
Еще давно Кент Бек сформулировал четыре ценности Agile. Это смелость, взаимодействие, обратная связь и простота.
Смелость
Первая из ценностей — это смелость, или, по-другому, разумная степень принятия рисков. Члены команды, работающей по Agile, в первую очередь сосредоточены на качестве и возможностях, а не на каких-то политических мотивах. Они понимают, что лучший способ вести проект по разработке ПО в течение долгого срока — проявлять некоторую напористость.
Есть разница между смелостью и безрассудством. Чтобы развернуть наименее достаточный набор функций, нужна смелость. Смелость нужна и для того, чтобы поддерживать высокое качество кода и добросовестно применять методы. При этом безрассудно развертывать программу с неустойчивой структурой или такую, в качестве которой вы не до конца уверены. Безрассудно идти в ногу с графиком, принося в жертву качество.
Верить в то, что качество и дисциплина повышают скорость — смело, поскольку это убеждение будут постоянно оспаривать влиятельные, но наивные спешащие коллеги.
Взаимодействие
Мы ценим прямое и частое взаимодействие, которое воздвигает мосты между людьми. Члены Agile-команды хотят общения друг с другом. Программисты, клиенты, тестировщики и руководители не против находиться рядом друг с другом, часто общаться, и не только на встречах. Не только через электронную почту, сообщения и заметки. Они ценят личные непринужденные разговоры тет-а-тет.
Так команда становится сплоченной. Это происходит в быстром хаотичном потоке легкого и частого взаимодействия. Рождается огненная буря, несущая озарение, зажигающая лампочки в головах людей. Когда вся команда в сборе, а ее члены находятся рядом и постоянно общаются, то происходят чудеса.
Обратная связь
Методы Agile, которые мы изучили, все как один направлены на отдачу быстрой обратной связи ребятам, принимающим важные решения.