Чистый Agile. Основы гибкости Мартин Роберт
Рефакторинг — это метод улучшения структуры кода без изменения его поведения, определенного тестами. Другими словами, мы вносим изменения в имена, классы, функции и выражения, не проваливая никаких тестов. Мы улучшаем структуру программы без воздействия на ее выполнение.
Конечно же, эта дисциплина тесно связана с разработкой через тестирование. Чтобы без опасений перепроектировать код, нужен тестовый набор, который с высокой степенью вероятности укажет нам на то, что мы ничего не испортим.
Изменения, выполненные во время рефакторинга, разнятся от простых косметических до глубокой правки структуры. Такие изменения могут представлять собой просто изменения в названиях или сложную замену операторов switch на полиморфные отправки. Большие функции будут разбиты на те, что поменьше, с более удачными названиями. Списки аргументов будут изменены на объекты. Классы с большим количеством методов будут разделены на множество мелких классов. Функции будут перемещены из одного класса в другой. Из классов будут выделены подклассы или внутренние классы. Зависимости будут инвертированы, а модули перемещены через границы архитектуры.
И пока все это происходит, наша программа непременно проходит тесты.
Красный/зеленый/рефакторинг
Ход рефакторинга естественным образом связан с тремя правилами разработки через тестирование приемом «красный/зеленый/рефакторинг» (рис. 5.1).
Рис. 5.1. Цикл «красный/зеленый/рефакторинг»
1. Сначала мы создаем тест, который не получается пройти.
2. Потом пишем код и проходим тест.
3. Затем подчищаем код.
4. Далее возвращаемся к шагу 1.
Написание рабочего кода и написание чистого кода — это две разные вещи. Делать одновременно то и другое необычайно сложно, так как это совершенно разная деятельность.
Довольно тяжело написать рабочий код, не говоря уже о соблюдении его чистоты. Поэтому мы сначала ориентируемся на написание рабочего кода, что бы там ни происходило в головах нашего сумрачного гения. Затем, когда все заработало, мы устраняем беспорядок, который натворили.
Это дает понять, что рефакторинг кода — процесс непрерывный, и его не проводят по плану. Мы не плодим беспорядок несколько дней кряду, чтобы потом долго его подчищать. Мы лучше создадим легкий беспорядок и через минуту-две все исправим.
Слово «рефакторинг» никогда не должно появляться в графике работ. Это не тот род деятельности, который можно провести по плану. Мы не выделяем времени на рефакторинг кода. Рефакторинг — это часть нашей ежеминутной, ежечасной рутины при написании ПО.
Большой рефакторинг
Иногда требования меняются так, что вы осознаете: дизайн и архитектура программы не совсем подходят. Тогда вы решаете внести значительные изменения в структуру программы. Такие изменения вносят в цикле «красный/зеленый/рефакторинг». Мы не создаем программы специально для того, чтобы вносить изменения в структуру. Мы не выделяем времени в графике работ на такой глубокий рефакторинг кода. Маленькими порциями мы переносим код, продолжая добавлять новые функции за время обычного цикла Agile.
Такое изменение в структуру программы можно вносить несколько дней, недель или даже месяцев. Все это время программа проходит все необходимые тесты и готова к развертыванию, даже если изменение структуры не полностью завершено.
Простота проектирования
Метод «простота проектирования» — одна из целей рефакторинга. Простота проектирования — метод, предполагающий написание только необходимого кода, чтобы сохранять простоту структуры, его небольшой размер и наибольшую выразительность.
Правила простого проектирования Кента Бека.
1. Пройти все тесты.
2. Проявить намерение.
3. Удалить дубликаты.
4. Сократить количество элементов.
Номера пунктов означают порядок действий, в котором эти правила выполняются, и их приоритет.
Пункт 1 говорит сам за себя. Код должен пройти все тесты. Он должен работать.
В пункте 2 указано, что после того как код заработал, ему нужно придать выразительность. Он должен явно отражать намерения программиста. Код нужно писать так, чтобы он легко читался и содержал достаточно сведений. Как раз сейчас мы проводим косметический рефакторинг кода, в течение которого вносим много простых изменений. Нужно также разделить большие функции на мелкие, дав им более простые и понятные названия.
В пункте 3 говорится, что после того как код получился в высшей мере описательным и выразительным, мы старательно выискиваем и удаляем все дубликаты. Не нужно, чтобы в коде повторялось одно и то же. Во время такой деятельности проводить рефакторинг, как правило, сложнее. Иногда удалить дубликаты так же просто, как перенести дублирующийся код в функцию и вызвать его из разных мест. В других случаях требуются решения интереснее, например паттерны проектирования[54]: метод шаблонов, стратегия, декоратор или посетитель.
В пункте 4 говорится о том, что как только мы удалили все дубликаты, нужно стремиться уменьшить количество структурных элементов, например классов, функций, переменных и так далее.
Цель метода «простота проектирования» — поддерживать наиболее возможную легковесность кода.
Легковесность
При проектировании программа может получиться как достаточно простой, так и необычайно сложной. Чем сложнее структура, тем больше умственная нагрузка на программиста. Эта умственная нагрузка — вес структуры программы. Чем больше вес программы, тем больше времени и усилий будет затрачено программистами на изучение и управление этой программой.
Таким же образом сложность требований также варьируется от небольших до огромных. Чем сложнее требования, тем больше времени и сил понадобится, чтобы изучить эту программу и управлять ею.
Однако обе причины не являются дополняющими. Сложные требования можно упростить за счет усложнения структуры программы. Часто предпочтительнее найти компромисс. Программу можно упростить, подобрав подходящую конструкцию под заданный набор функций.
Уравновешивание сложности конструкций и функций является целью «простоты проектирования». Применяя этот метод, программисты постоянно перепроектируют структуру кода, чтобы сохранялось равновесие между требованиями и достижением наиболее высокой производительности.
Парное программирование
Метод парного программирования за годы своего существования оброс противоречиями и кривотолками. Многие отрицательно воспринимают мысль о том, что два (и больше) человека могут плодотворно работать над одной и той же задачей.
Во-первых, работа в паре не обязательна. Никого нельзя к ней принуждать. Во-вторых, работа в паре не обязательно постоянна. Существует много веских причин, почему иногда лучше писать код в одиночестве. Желательно, чтобы доля программистов, работающих в паре, в команде была 50 % или около того. Но это не так важно. Она может быть лишь 30 %, а может и все 80 %. Право выбора принадлежит членам команды.
Что такое парное программирование?
Парное программирование — это совместная работа двух программистов над одной задачей. Напарники могут работать на одной машине, с одним монитором, клавиатурой и мышью. Или они могут работать на двух машинах по сети, пока могут видеть один и тот же код и обращаться с ним. Последнее прекрасно можно осуществить с помощью систем доступа к рабочему столу. Такое ПО позволяет напарникам находиться далеко друг от друга, если у них хорошая пропускная способность и голосовая связь.
Программисты, работающие в паре, выполняют разную работу. Один будто водитель, а другой — штурман. У водителя в руках инструменты — клавиатура и мышь. Штурман же внимательно всматривается в монитор и дает советы. Другой вариант: один программист пишет тест, а второй добивается его прохождения, после чего пишет ответный тест первому программисту. Иногда этот метод называют «пинг-понг».
Но чаще всего никакого разделения нет. Программисты просто сидят за одной машиной и занимаются одним и тем же и по очереди используют клавиатуру и мышь.
Пары не назначаются. Они выбирают друг друга в зависимости от желания совместной работы над одной задачей. Менеджеры не должны вмешиваться со своими расписаниями или матрицами.
Чаще всего напарники быстро меняют партнера. Сессия парного программирования может длиться день, но чаще всего они длятся от силы час-два. Даже работа в паре в течение лишь четверти-получаса может принести пользу.
Истории не распределяются по парам. За истории отвечают отдельные программисты, а не оба напарника. Продолжительность выполнения истории длится, как правило, гораздо дольше, чем работа с одним напарником.
В неделю каждый программист будет тратить около половины своего времени на выполнение своих собственных задач, привлекая к помощи некоторых других программистов. Оставшуюся половину времени, проводимого в паре, он потратит на помощь другим программистам с их заданиями.
Опытным программистам следует стараться как можно чаще работать в паре с младшими. Младшим программистам нужно просить помощи чаще у опытных, чем у других младших. Программисты со специализацией должны тратить значительное количество времени, работая в паре с программистами над задачами вне своей специализации. Цель состоит в том, чтобы распространять знания и обмениваться ими, а не накапливать их в одиночку.
Зачем работать в паре?
Работая в паре, мы укрепляем командный дух. Члены команды не изолируются друг от друга, а ежесекундно сотрудничают. Когда член команды не может работать, другие закрывают образовавшуюся брешь и двигаются к цели.
Работа в паре — однозначно лучший способ обмениваться знаниями в команде и избегать сокрытия информации отдельными членами. Это лучший способ организовать команду так, чтобы в ней не было незаменимых сотрудников.
Многие команды сообщали, что парное программирование сокращает количество ошибок и улучшает качество проектирования. Это верно в большинстве случаев. Как правило, во время работы над задачей лучше, если на нее смотрит не одна пара глаз. Действительно, во многих командах перешли от разбора кода к работе в парах.
Парное программирование как анализ кода
Парное программирование представляет собой вид анализа кода (Code Review), но имеет значительное преимущество. Работая в паре, программисты пишут код в соавторстве. Они видят уже написанный код и, как само собой разумеющееся, проводят его анализ с целью создания нового кода. Таким образом анализ кода — это не просто статическая проверка, которая проводится, чтобы убедиться в том, что код соответствует нормам, принятым в команде. Скорее это динамический обзор текущего состояния кода с прицелом на то, каким код должен быть в ближайшем будущем.
А каковы издержки?
Сложно измерить издержки, возникающие при парном программировании. Прямая издержка — это то, что над одной задачей работает два человека. Очевидно, что на решение задачи не затрачивается двойного усилия, но, вероятно, какие-то издержки все же есть. В разных исследованиях установлено, что издержки составляют примерно 15 %. Другими словами, потребуется 115 программистов, работающих в паре, чтобы выполнить работу 100 программистов, работающих индивидуально (без анализа кода).
Если считать упрощенно, получается, что в команде, где в паре работают половину от всего времени, потери в производительности составят менее 8 %. С другой стороны, работа в паре снимает необходимость анализа кода, и тогда нет никакой потери производительности.
Затем рассмотрим преимущества — обмен знаниями, взаимное обучение и глубокое взаимодействие. Эти преимущества невозможно просчитать, но они также весьма важны.
По моему опыту и опыту многих других, программирование в паре, если оно происходит непринужденно и по желанию самих программистов, приносит довольно много пользы всей команде.
Только два?
Слово «пара» подразумевает, что в сессии парного программирования работают только два программиста. Хотя чаще всего это так, это не строгое правило. Иногда для решения задачи может собраться группа из трех, четырех или большего количества программистов (опять же на усмотрение программистов). Это явление иногда называют «совместное программирование»[55].
Менеджеры
Программисты часто опасаются, что менеджеры не одобрят работу в парах или даже потребуют разойтись и не заниматься ерундой, чтобы не тратить драгоценное время. Я с таким не встречался. За все полвека, что я занимаюсь написанием кода, я никогда не видел, чтобы менеджеры вмешивались. В большинстве случаев, по моему опыту, они только рады видеть, что программисты сотрудничают, работая вместе. Это создает впечатление, что работа кипит.
Если же вы менеджер, который хочет разогнать программистов, работающих в паре, опасаясь, что такая работа неэффективна, то отбросьте свои опасения и дайте программистам возможность решить самим. В конце концов, они профессионалы. А если вы программист и ваш менеджер требует прекратить работу в паре, напомните ему, что специалист здесь вы, поэтому только вы, а не менеджер, отвечаете за то, как будет вестись работа.
И наконец, никогда в жизни не просите разрешения на работу в паре. На проведение тестирования. На рефакторинг. И прочее.
Вы профессионал. Вам решать.
Заключение
Технические методы Agile — наиболее важная составляющая всей методологии. Любая попытка применить Agile без технических методов обречена на провал. Причина проста: Agile — действенный механизм при работе в большой спешке, образующей большой беспорядок. Без использования технических методов, позволяющих поддерживать высокий уровень качества кода, команда начнет стремительно и неумолимо утопать в бесконечной пучине низкой производительности.
Глава 6. Внедрение Agile
Когда я впервые услышал об экстремальном программировании, то подумал: «Что может быть проще? Просто соблюдать простые правила и применять методы. Вот и все».
Но судя по тому, сколько организаций безуспешно пытается внедрить Agile, реализация Agile сопровождается огромными сложностями. Возможно, причина всего этого в том, что во многих компаниях принимают за Agile что-то, что им не является.
Ценности Agile
Еще давно Кент Бек сформулировал четыре ценности Agile. Это смелость, взаимодействие, обратная связь и простота.
Смелость
Первая из ценностей — это смелость, или, по-другому, разумная степень принятия рисков. Члены команды, работающей по Agile, в первую очередь сосредоточены на качестве и возможностях, а не на каких-то политических мотивах. Они понимают, что лучший способ вести проект по разработке ПО в течение долгого срока — проявлять некоторую напористость.
Есть разница между смелостью и безрассудством. Чтобы развернуть наименее достаточный набор функций, нужна смелость. Смелость нужна и для того, чтобы поддерживать высокое качество кода и добросовестно применять методы. При этом безрассудно развертывать программу с неустойчивой структурой или такую, в качестве которой вы не до конца уверены. Безрассудно идти в ногу с графиком, принося в жертву качество.
Верить в то, что качество и дисциплина повышают скорость — смело, поскольку это убеждение будут постоянно оспаривать влиятельные, но наивные спешащие коллеги.
Взаимодействие
Мы ценим прямое и частое взаимодействие, которое воздвигает мосты между людьми. Члены Agile-команды хотят общения друг с другом. Программисты, клиенты, тестировщики и руководители не против находиться рядом друг с другом, часто общаться, и не только на встречах. Не только через электронную почту, сообщения и заметки. Они ценят личные непринужденные разговоры тет-а-тет.
Так команда становится сплоченной. Это происходит в быстром хаотичном потоке легкого и частого взаимодействия. Рождается огненная буря, несущая озарение, зажигающая лампочки в головах людей. Когда вся команда в сборе, а ее члены находятся рядом и постоянно общаются, то происходят чудеса.
Обратная связь
Методы Agile, которые мы изучили, все как один направлены на отдачу быстрой обратной связи ребятам, принимающим важные решения. Игра в планирование, рефакторинг кода, разработка через тестирование, непрерывная интеграция, небольшие и частые релизы, коллективное владение, одна команда и другие методы повышают частоту обратной связи и количество передаваемых сведений. Они позволяют нам своевременно понять, что что-то идет не так, чтобы внести исправления. Они дают важные уроки того, что все решения, принятые ранее, влекут за собой последствия. Команды, применяющие Agile, успешны за счет обратной связи.
Именно обратная связь помогает команде работать столь плодотворно и приводит проект к благоприятному исходу.
Простота
Следующая ценность Agile — это простота, другими словами, честность. Часто говорят, что каждую проблему в разработке можно решить, добавив еще один слой неясности. Но такие ценности, как храбрость, взаимодействие и обратная связь, существуют для того, чтобы свести количество проблем к минимуму.
Таким образом, неясность можно свести к минимуму. Решения могут быть простыми.
Это касается ПО, но также относится и к команде. Пассивная агрессия — это неясность и уклончивость. Когда вы видите проблему, но молча перекладываете ее решение на кого-то другого, вы ведете себя нечестно. Когда вы соглашаетесь с требованиями менеджера или клиента, зная о губительности последствий, вы нечестны.
Простота — это честность. Честность при написании кода и честность во взаимоотношениях и поведении. При написании кода в некотором количестве неясности есть необходимость. Неясность — это механизм, посредством которого мы снижаем сложность взаимозависимости. При работе в команде в неясности куда меньше необходимости. Большую часть времени нужно быть честным, насколько это возможно.
Сохраняйте простоту кода. Не усложняйте отношения в команде.
Методологический бестиарий
В огромном количестве существующих методик Agile легко запутаться. Я понимаю, что их тьма-тьмущая, но не обращайте на это внимания. В конце концов, независимо от того, на какие методики падет ваш выбор, вы будете подстраивать и отлаживать модель разработки под свои нужды. Таким образом, начни вы с экстремального программирования, Scrum или других 5328 методик, относящихся к Agile, вы придете к одному и тому же.
Настоятельный совет, который я могу вам дать, — это полностью перенять жизненный цикл, главным образом, технические методы. Огромное количество команд переняли лишь внешнее кольцо, определяющее взаимоотношения с клиентами, и угодили в ловушку, которую Мартин Фаулер назвал «дряблый Scrum»[56]. Признаки этой болезни: производительность медленно падает с высокого уровня в начале проекта до крайне низкого, когда проект подходит к концу. Причиной такой потери в производительности является искажение и ухудшение качества самого кода.
Оказывается, что методы взаимодействия с клиентами, предлагаемые Agile, — очень действенный способ создать огромный беспорядок. Кроме того, если вы не позаботитесь о чистоте структуры, которую выстраиваете, беспорядок будет замедлять ход работ.
Итак, выбирайте одну из методик или вообще не выбирайте. Убедитесь, что вы учитываете все дисциплины жизненного цикла. Согласуйте с командой. И вперед. Помните, что смелость, взаимодействие, обратная связь и простота позволяют с постоянством отлаживать дисциплины и методы. Не просите разрешений. Не бойтесь сделать неправильно. Просто выполняйте свою работу наперекор возникающим проблемам и настойчиво ведите проект к лучшему.
Преобразование
Переход от других методологий и моделей к Agile ведет к изменению ценностей. Ценности при использовании Agile включают в себя принятие рисков, быструю обратную связь, а также глубокое и многостороннее взаимодействие между членами коллектива, которое стирает границы внутри команды, в том числе между начальниками и подчиненными. Они также нацелены на ясное и честное поведение, а не распределение ролей и поиски крайнего. Эти ценности прямо противоположны ценностям крупных организаций, которые вкладывают значительные средства в менеджеров среднего звена, ценности которых — безопасность, преемственность, административное управление и выполнение плана.
Разве возможно перевести такую организацию на Agile? Честно говоря, это не то, в чем я достигал больших успехов, у других я подобных успехов также не наблюдал. Я видел, как затрачивалось много усилий и средств, но чтобы организация действительно осуществила переход, я видел редко. Уклад ценностей слишком отличается от тех, которых придерживаются менеджеры среднего звена, чтобы их принять.
То, что я видел, — это переход команд и отдельных специалистов, потому что команды и одиночные программисты часто следуют ценностям, которыми руководствуется Agile.
Как ни странно, руководители тоже часто разделяют ценности, присущие Agile, например: принятие рисков, ясность и взаимодействие. В том числе по этой причине они пытаются осуществить переход в своих организациях.
Дело как раз в менеджерах среднего звена. Этих ребят взяли на работу не для того, чтобы принимать риски или вносить ясность, но для того, чтобы передавать ответственность при минимальном взаимодействии. Эта проблема остро стоит во многих компаниях. Руководство и работники в организациях разделяют мировоззрение, свойственное Agile, но среднее звено мыслит наоборот. Я ни разу не видел, чтобы менеджеры среднего звена стояли в основе изменений. И вправду, с чего бы? Сопротивление таким изменениям — это их работа.
Чтобы донести свою мысль, расскажу вам несколько историй.
Саботаж
Еще тогда, в 2000 году, я участвовал в переходе одной организации на Agile. Мы заручились поддержкой начальства и программистов. Переход сулил большие надежды. Возникли сложности с техническими руководителями и архитекторами. Эти ребята, неправильно оценив положение дел, подумали, что их значимостью стали пренебрегать.
Значимость архитекторов, технических руководителей проектов и многих других в команде, работающей по Agile, отличается, но никак не преуменьшена. К сожалению, ребята не понимали этого, возможно, и по нашей вине. Может, мы не донесли до них то, насколько они были значимы для команды, или они просто не хотели учиться новым навыкам, которые бы им пригодились.
Как бы то ни было, они тайком строили план саботажа, чтобы не допустить перехода на Agile. Не буду вдаваться в подробности этого плана. Только скажу, что как-то раз их застукали за этим и немедленно выперли с работы.
Мне бы очень хотелось сказать вам о том, что после этого переход на Agile стал продвигаться семимильными шагами и закончился большим успехом. Но, увы, не могу.
Волчонок
У нас отлично получилось перевести на Agile одно из подразделений компании куда крупнее. Оно переняло опыт экстремального программирования и проделало за эти годы такую работу, что удостоилось статьи в журнале Computer world. Собственно, за этот успех вице-президент по инженерно-техническому обеспечению, руководивший этим переходом, получил повышение.
Его заменил новый вице-президент. И, подобно возмужавшему волчонку, которому посчастливилось возглавить стаю, он занялся тем, что уничтожил все наследие своего предшественника. Это коснулось и Agile. Он полностью отказался от него и вернул команде старую модель разработки, которая отличалась не в лучшую сторону.
Это привело к тому, что многие члены команды стали искать новое место работы, чего, я полагаю, и добивался новый вице-президент.
Плакса
Последнюю историю мне рассказали. Я не присутствовал в самый важный момент. Мне рассказали мои сотрудники, работавшие в то время.
В 2003 году моя компания переводила на Agile одну известную брокерскую фирму. Все шло замечательно. Велась подготовка руководителей высшего и среднего звена, а также разработчиков. Они готовились вместе. Ничего не предвещало беды.
Потом пришла пора подвести итоги. Руководство и разработчики собрались в большой аудитории. Целью было оценить ход и успешность перехода на Agile. Начальство задало вопрос: «Как обстоят дела?»
С разных сторон послышались ответы: «Все отлично!»
Потом повисло гробовое молчание, которое резко прервалось всхлипами, доносящимися сзади. Кто-то заплакал. И тогда эмоциональный подъем обрушился, и аудитория погрузилась в уныние. Вдохновения как не бывало. «Это так сложно, — донеслось до собравшихся. — Мы это просто не тянем».
После этого начальство свернуло переход.
Мораль
Мораль всех этих историй: ожидайте любых странностей.
Притворяйтесь
Может ли команда, применяющая Agile, работать в организации, где есть сильное среднее звено, которое против этой методологии? Я видел, как время от времени это происходило. Некоторые команды разработчиков спокойно руководствуются Agile во время выполнения своей работы и в то же время выполняют строгие условия, навязанные менеджерами среднего звена. Покуда менеджеры среднего звена довольны соблюдением правил и нормативов, они оставляют разработчиков в покое, не вмешиваясь в их работу.
Это как раз то, о чем говорили Буч и Парнас: «Притворяйтесь!»[57] Команда работает по Agile, не объявляя об этом, и в то же время делает все для того, чтобы менеджеры среднего звена оставались довольными. Вместо того чтобы бороться с ветряными мельницами, такие команды используют Agile на низком уровне, преподнося его так, что для менеджеров среднего звена он выглядит безопасным и совместимым с их ценностями.
Например, менеджеры хотят получить документ об анализе, проведенном на ранней стадии проекта. Команда, применяющая Agile, пишет большое количество первичного кода программы по всем канонам Agile, затем выпускает документ об анализе, запланировав череду историй по производству документации. Менеджеры получают необходимый им документ.
В этом есть смысл, поскольку первые несколько итераций написания кода в значительной мере ориентированы на анализ требований. То, что анализ выполнен благодаря непосредственно написанию самого кода, менеджерам среднего звена знать необязательно. Их не должно это волновать.
К сожалению, мне доводилось видеть компании, где такой дурдом, что если, не дай бог, среднее звено учует, что «что-то не так», оно прибегнет к различным уловкам, чтобы от Agile не осталось и следа. Это позор, потому что такие команды в действительности дают менеджерам все необходимое.
Успех в небольших организациях
Я видел, как некоторые средние по размеру компании переходили на Agile. В таких компаниях тонкая прослойка менеджеров среднего звена — это сотрудники, которые получили свои должности, поднимаясь с низов. У них сохранился образ мышления людей, готовых к прямому взаимодействию и принятию рисков.
То, что мелкие компании полностью переходят на Agile, отнюдь не редкость. Там нет менеджеров среднего звена, а ценности боссов и разработчиков совпадают.
Успешный переход отдельных специалистов
Наконец, в некоторых компаниях ценности Agile перенимают только отдельные сотрудники. Те, кто переходит на Agile индивидуально, чувствуют себя некомфортно в компании или команде, которые не собираются этого делать. Разница в ценностях обычно приводит к некоторому разделению. В лучшем случае люди, которые осуществляют переход, объединятся, чтобы сформировать новые гибкие команды, которым удастся скрыться от менеджеров среднего звена. Если это не получается, они, скорее всего, будут искать (и найдут ведь!) работу в другой компании, которая разделяет их ценности.
За последние двадцать лет мы видели, как в отрасли меняются ценности. Образуются новые компании, которые принимают ценности Agile, и программисты, которые хотят работать по методологии Agile, группируются в таких компаниях.
Создание Agile-организаций
Можно ли создать крупную организацию, где смогут успешно работать команды, использующие Agile? Несомненно! Только обратите внимание, я сказал «создать», а не «перевести».
Когда IBM решила выпустить персональный компьютер, руководство компании понимало, что ценности организации не позволяют быстро внедрить нововведения и принять необходимые риски. Поэтому она создала организацию с другой системой ценностей[58].
Было ли такое в мире разработки ПО? Было ли такое, что крупные организации создавали более мелкие, чтобы писать ПО с помощью Agile? На моей памяти были намеки на это, но не могу привести ни одного яркого примера.
Конечно, мы видели множество новых компаний, принимавших Agile. Также можно вспомнить много компаний, консультировавших по Agile более крупные компании, которые не применяли Agile в целом, но хотели выполнить отдельные проекты с большей скоростью и надежностью.
А вот мой прогноз. В конечном итоге мы увидим, как крупные компании будут создавать новые подразделения, которые будут заниматься написанием программ с применением Agile. Также консалтинговые компании, занимающиеся Agile, будут все чаще оказывать услуги крупным организациям, которым не удалось перевести на Agile своих разработчиков.
Коучинг
Нужен ли команде, работающей по Agile, коуч? Вообще — нет. Но если хорошо подумать, то иногда нужен.
Прежде всего, следует видеть грань между тренером и коучем. Agile-тренер обучает команду, как организовать себя, применяя Agile.
Часто они не работают в самой компании или работают в ней, но сами не являются членами команды. Их цель — прививать ценности Agile и обучать дисциплинам Agile. Их работа не должна длиться долго. Команде, состоящей из десятка разработчиков, понадобится одна-две недели тренингов.
Agile-тренер может говорить и делать что угодно, но всему остальному, чему нужно, разработчики научатся сами.
В начале перехода команды на Agile тренер может временно выступать в роли коуча, но продолжительность такого коучинга невелика. Это бремя должен на себя взять кто-то из членов команды, и чем скорее, тем лучше.
Как правило, коучи и тренеры — разные люди. Коучи — это члены команды, чья задача — обеспечивать соблюдение методологии внутри команды. Когда разработка кипит, у программистов может возникнуть соблазн сойти с колеи. Они ненароком могут перестать работать в паре, выполнять рефакторинг кода или обращать внимание на сбои, возникающие при непрерывной сборке. Коуч наблюдает за тем, чтобы такого не было, и при случае указывает команде на их огрехи. Коуч выступает в качестве совести команды, постоянно ей напоминая о данных себе обещаниях и о ценностях, которые те согласились соблюдать.
Эта роль по мере необходимости обычно переходит от одного члена команды к другому согласно неофициальному графику. Команда, уже стабильно сработавшаяся, не нуждается в коуче. С другой стороны, команда в напряженной обстановке, будь то из-за графика работ, проблем во взаимодействии с клиентами или внутри команды, может принять решение назначить кого-либо коучем на время.
Коуч не менеджер. Он не отвечает за распределение средств или график работ. Коуч не руководит командой и не представляет интересы команды перед менеджерами. Коуч также не является посредником между клиентами и разработчиками. Коуч выполняет свои функции исключительно внутри команды. Никто из менеджеров или клиентов не знает, кто является коучем и есть ли он вообще.
Скрам-мастер
В Scrum такой коуч называется мастером. Изобретение этого понятия и череда событий, последовавших за ним, были одновременно и лучшим, и худшим, что когда-либо случалось в сообществе Agile. Программы сертификации привлекли большое количество менеджеров проекта. Такой приток поспособствовал распространению Agile в самом начале, но в итоге он привел к тому, что функции коуча приравняли к тому, чем занимается менеджер проекта.
В наше время слишком часто происходит так, что скрам-мастера никакие не коучи, а обычные менеджеры проекта, которые выполняют соответствующую работу. К несчастью, название должности и наличие сертификата способствуют их непомерному влиянию на команду, применяющую Agile.
Сертификация
Вся существующая сертификация по Agile смехотворна и нелепа. Нельзя относиться к такой «сертификации» всерьез. Обучение во время программ сертификации часто полезно, однако оно не должно сводиться к определенной роли и должно быть рассчитано на всех членов команды.
Например, от «сертификата» скрам-мастера никакого толка нет. Сертификаты значат не больше, чем то, что кому-то некуда было девать деньги и он в лучшем случае прошел двухдневные курсы. Лицо, выдающее сертификат, не гарантирует, что новоиспеченный мастер будет хорош в роли коуча. Бессмысленность наличия такого сертификата в том, что он наделяет «сертифицированного скрам-мастера» чем-то особенным, а это не имеет ничего общего с коучингом в команде. Чтобы стать коучем в команде, не нужно никаких обучений.
Нет ничего плохого в прохождении самого обучения, необходимого для сертификации. Просто обучать только одного человека отдельной роли в команде глупо. Каждый член команды, применяющей Agile, должен понимать ценности и методы Agile. И если один член команды подготовлен, значит, нужно подготовить и всех.
Настоящая сертификация
А как на самом должна выглядеть программа сертификации по Agile? Это должен быть семестровый курс, который сочетал бы обучение работе по Agile и небольшой учебный проект по гибкой методологии разработки. На этих курсах будет система оценок и высокие планки прохождения заданий. Тот, кто выдает сертификаты, должен гарантировать, что ученики усвоили ценности Agile и показали высокий уровень мастерства в применении методов Agile.
Agile в крупных масштабах
Движение Agile появилось в конце 1980-х. Его быстро признали способом организовать небольшую команду, размером от 4 до 12 разработчиков. Эти числа были нестрогими и редко озвучивались, однако все понимали, что Agile (или как мы его там называли до 2001-го) не подходит для гигантских команд из тысяч разработчиков. Это не та задача, над решением которой мы бились. Тем не менее вопрос подняли почти сразу. А что насчет больших команд? Что, если применить Agile в крупном масштабе?
Долгие годы люди искали ответ на этот вопрос. В самом начале авторы Scrum предложили метод Scrum-of-Scrums. Позже мы стали наблюдать появление некоторых фирменных подходов вроде SAFe[59] и LeSS[60]. На эту тему написано несколько книг.
Я уверен, что в этих подходах нет ничего плохого. Я уверен, что эти книги замечательны. Но я не пробовал этих методов и не читал книг. Вы можете подумать, что я какой-то пустомеля, что высказываюсь на тему, которую не изучил. Может, вы и правы. Однако у меня есть своя точка зрения.
Agile создан для малых и средних команд. Точка. Он хорошо работает для таких команд. Agile никогда не предназначался для больших команд.
Почему мы не пробовали решить проблему больших команд? Да потому что проблема больших команд решается огромным количеством специалистов вот уже больше пяти тысяч лет. Эта проблема больших команд — проблема культур и цивилизаций. И если в какой-то мере судить о нашей нынешней цивилизации, эту проблему решили достаточно неплохо.
Как построили пирамиды в Египте? Надо было решить проблему больших команд. Как получилось победить во Второй мировой войне? Надо было решить проблему больших команд. Как удалось отправить человека в космос и благополучно вернуть его на Землю? Надо было решить проблему больших команд.
Но такие большие проекты — не единственные достижения больших команд, не правда ли? Как получилось развернуть телефонную сеть, построить автомагистраль, создать интернет, произвести мобильные телефоны или автомобили? Это все сотворили большие команды.
Инфраструктура и средства обороны нашей обширной, охватывающей весь земной шар цивилизации — прямое свидетельство того, что мы уже решили проблему организации больших команд.
Большие команды — проблема уже решенная.
Та проблема, которую все еще не решили тогда, в конце 1980-х, когда зарождалось движение Agile — это проблема организации работы малых команд разработчиков. Мы не знали, как эффективно организовать относительно малую группу программистов так, чтобы была максимальная отдача. И эту проблему решил Agile.
Важно понимать, что Agile создали для решения проблемы организации небольшой команды разработчиков, а не просто небольшой команды. Проблему небольших команд решили еще в древние времена военные и производственные организации по всему миру. Римляне бы не покорили Европу, если бы не смогли решить проблему организации небольших отрядов.
Agile — это набор дисциплин, с помощью которых мы организуем небольшие команды разработчиков ПО. Зачем нам нужен отдельный способ для организации разработчиков? Потому что программное обеспечение особенно.
На него похожи только несколько областей знаний. Соотношения «вложение/выгода» и «риск/вознаграждение» в разработке ПО отличаются от тех, что имеются в других видах деятельности. Разработка похожа на строительство, за исключением того что не строится ничего осязаемого. Разработка похожа на математику, за исключением того что ничего нельзя доказать. Разработка похожа на естествознание своей эмпиричностью, но при этом не открывается никаких законов природы. Разработка похожа на бухгалтерское дело, за исключением того что она описывает поведение, упорядоченное по времени, а не факты о числах.
Разработка ПО действительно не похожа ни на что другое. Поэтому для того, чтобы организовать небольшую команду разработчиков, нужен набор особых дисциплин, которые подстроены под уникальность разработки.
Посмотрите на дисциплины и методы, о которых мы говорили на страницах этой книги. Обратите внимание, что они все до единого, почти без исключения, подстроены и отлажены под уникальные стороны разработки. Присмотритесь к методам, начиная от очевидных вроде разработки через тестирование и рефакторинга до более неоднозначных вроде игры в планирование.
Суть в том, что Agile создан для сферы разработки ПО. В частности, речь идет о небольших командах программистов. Мне неприятно, когда меня спрашивают, как внедрить Agile в сферу производства аппаратного обеспечения, строительства или в другой процесс. Я всегда отвечаю, что не знаю, потому что Agile существует для сферы разработки ПО.
А что, если масштабировать Agile? Думаю, ничего не выйдет. Организовать большие команды можно, разбив их на несколько мелких. Agile решает проблему небольших команд разработчиков. Проблема организации небольших команд в большие уже решена. Поэтому мой ответ на вопрос о применении Agile в крупном масштабе таков: просто распределите ваших разработчиков по небольшим командам, которые будут работать по Agile, а потом применяйте обычные способы управления и научно-исследовательские методы, чтобы руководить этими командами. Не нужно никаких особых правил.
Теперь мне могут задать еще один вопрос. Если разработка ПО в небольших командах настолько уникальна, что пришлось изобрести Agile, почему такая уникальность не относится к организации маленьких команд разработчиков в большие? Разве не существует чего-то уникального в области разработки ПО, что выходит за пределы организации небольших команд разработчиков и влияет на организацию больших?
Сомневаюсь, потому что проблема больших команд, которую мы решили более пяти тысяч лет назад, — это вопрос слаженного сотрудничества самых разных команд. Команды, работающие по Agile, — лишь один вид несметного числа команд, которые нужно скоординировать для создания чего-то большего. Координация команд различных назначений — уже решенная проблема. Я не вижу никаких признаков того, что уникальность команд разработчиков плохо влияет на их включение в более крупные объединения.
Так что, опять-таки с моей точки зрения, не существует никакого Agile для применения в крупном масштабе. Agile — необходимое нововведение для организации небольших команд разработчиков ПО. Но будучи уже организованными, такие команды можно встроить в структуры, которые в крупных организациях применяются уже тысячелетиями.
Это не та тема, которую я усердно исследовал. Все, что вы только что прочитали, лишь мое мнение, я могу оказаться неправ. Возможно, я просто старый ворчун, который посылает всех желающих применить Agile в крупных масштабах идти развлекаться в свой двор. Время лучший судья. Но теперь вы знаете, в чем я точно уверен.
Инструменты Agile
Авторы Тим Оттингер и Джефф Лангр,
16 апреля 2019 года[61]
Мастера осваивают свои инструменты. Столяры овладевают молотком, метром, пилой, долотом, рубанком и уровнем. Все эти инструменты недороги и отлично подходят мастеру в начале его трудового пути. По мере роста своих потребностей столяр учится пользоваться инструментами посерьезнее (которые, как правило, и дороже): дрелью, гвоздезабивным пистолетом, токарным и фрезерным станком, САПР, ЧПУ и много чем еще.
Однако мастера столярного дела не расстаются с ручным инструментом, который отлично подходит для работы. Используя только ручной инструмент, умелый мастер может выполнить работу качественнее и иногда даже быстрее, чем приводным инструментом. Как следствие, толковый столяр осваивает ручной инструмент, прежде чем перейти к более совершенным. Столяры изучают предел возможностей ручного инструмента, и поэтому у них есть понимание, когда нужно прибегнуть к приводному.
Вне зависимости от того, какой инструмент используется, ручной или приводной, столяр всегда стремится овладеть каждым инструментом из своего арсенала. Такое мастерство позволяет ему сосредоточиться непосредственно на ремесле, например на изготовлении изящной мебели высокого качества, а не на инструменте. Без должного овладения инструмент — плохой помощник, а при неумелом применении может даже нанести вред как изделию, так и незадачливому работнику.
Средства разработки
Разработчикам ПО в начале работы требуется освоить целый ряд инструментов:
• Хотя бы один язык программирования, а чаще больше.
• Интегрированную среду разработки или текстовый редактор, подходящий программисту (vim, Emacs и т. д.).
• Различные форматы данных (JSON, XML, YAML и т. д.) и языки разметки (в том числе HTML).
• Командную строку и скрипты для взаимодействия с операционной системой.
• Системы управления версиями (Git. Тут без вариантов).
• Средства для непрерывной интеграции и сборки (Jenkins, TeamCity, GoCD и т. д.).
• Средства развертывания и управления сервером (Docker, Kubernetes, Ansible, Chef, Puppet и т. д.).
• Средства коммуникации (электронная почта, Slack, английский язык).
• Инструменты тестирования (фреймворки для модульного тестирования, Cucumber, Selenium и т. д.).
Все эти инструменты необходимы для создания ПО. Без них на сегодняшний день невозможно ничего сделать. В некотором смысле, это «набор ручных инструментов» разработчика.
Чтобы освоить многие из этих инструментов и использовать их с отдачей, придется попотеть. Тем временем положение дел постоянно меняется, поэтому мастерски овладеть тем или иным инструментом становится все большим испытанием. Грамотный разработчик ищет пути наименьшего сопротивления и наибольшую пользу от применяемых инструментов, выбирая те, которые при затраченных усилиях дают большую отдачу.
Что делает инструмент эффективным?
Набор инструментов стремительно меняется, потому что мы постоянно узнаем более действенные способы достигать своих целей. За последние несколько десятков лет мы видели широкое разнообразие систем управления версиями: PVCS, Clear Case, Microsoft Visual Source Safe, Star Team, Perforce, CVS, Subversion, Mercurial и прочие. Все они страдали от каких-то недостатков: слишком нестабильные, слишком проприетарные или закрытые, слишком медленные, слишком въедливые, слишком жуткие или сложные. В итоге победил тот, который преодолел большинство ограничений, — Git.
Одна из сильных сторон Git в том, что он дает уверенность, что исходный код будет в сохранности. Если вы уже давно работаете, то наверняка использовали какие-то из перечисленных систем и, вероятно, время от времени нервничали. Требуется соединение с сервером в реальном времени, иначе ваша работа под угрозой. Репозиторий CVS время от времени повреждал файлы, после чего приходилось устраивать пляски с бубном в надежде восстановить данные. Сервер репозитория иногда падал, даже при наличии резервной копии, и можно было прождать пол рабочего дня. Некоторые проприетарные системы также страдали повреждением данных в репозиториях. Вы висите на телефоне часами, разговаривая с поддержкой, при этом отстегивая деньги на сторону за возможность привести их в порядок. При использовании Subversion вы опасались вести много веток, потому что чем больше файлов находилось в репозитории, тем дольше переключались ветки (иногда это занимало несколько минут).
Хороший инструмент должен быть удобен в использовании, а не заставлять вас содрогаться при одном лишь его виде. Git быстрый, он дает возможность вносить изменения в код локально, а не только на сервере, позволяет работать из локального репозитория без соединения по сети; он отлично поддерживает работу в нескольких репозиториях и нескольких ветках, а еще искусно выполняет слияние версий.
Читать бесплатно другие книги:
