Развеиваем мифы о методологии аджайл
Мы постоянно открываем более совершенные методы создания программного обеспечения, занимаясь разработкой сами и помогая в этом другим.
В бизнесе и в сфере программного обеспечения (а также в этой книге) мы много говорим об аджайл-подходе или методологии аджайл — способности быстро реагировать на меняющиеся условия. Сегодня очень трудно быть лидером без этого или хотя бы без поверхностного знакомства с принципами аджайл. Скорее всего, ваша команда разработчиков практикует аджайл в той или иной форме. Однако многие руководители бизнеса не знают, как работает аджайл, почему он лучше любой другой известной системы создания ПО и как избежать подводных камней при его использовании.
Вы, вероятно, уже сталкивались с элементами аджайл при работе с техническими командами и наверняка задавались вопросом, что происходит у разработчиков. Возможно, вы слышали от разработчиков, что нельзя заранее сказать, когда продукт будет отправлен заказчику, или какие функции будут у продукта, или когда он получит эти функции. Довольно неприятно, правда? Вы, возможно, предлагали дополнительное финансирование и персонал для конкретного проекта в надежде ускорить его реализацию, но вам говорили, что темп останется прежним, независимо от числа исполнителей, а деньги не приблизят сроки сдачи.
Если вы когда-либо задавались вопросом, что, черт побери, делают разработчики, почему все идет именно так и почему вы иногда получаете эти невероятно разочаровывающие ответы, то вам полезно побольше узнать о том, как работает методология аджайл. Не менее важно понимать, как ею злоупотребляют и доводят до крайностей, которые необязательно помогают делу. В некоторых компаниях аджайл может стать источником разочарования как для руководителей и менеджеров, так и для разработчиков. Создание компании, практикующей аджайл, важно, но для этого руководители должны понимать преимущества и недостатки методологии аджайл, прежде чем слепо принимать ее.
Почему именно аджайл?
В 1980-х и 1990-х гг. результаты разработки программных продуктов были нередко провальными. Даже крупные софтверные компании не справлялись со стремительно растущей сложностью проектов, меняющимися требованиями и большими затратами времени. Эти проблемы преследовали все организации — большие и малые, от стартапов до крупных компаний. Например, опытный программист и предприниматель Митч Капор, создавший в 1980-х гг. программы Lotus 1–2–3 и Lotus Notes, в 2002 г. профинансировал амбициозный проект по созданию системы для совместной работы под названием Project Chandler. Шесть лет спустя после неудачи с поставкой продукта, который лишь отдаленно соответствовал первоначальным целям, проект был закрыт. Даже выдающаяся софтверная компания той эпохи Microsoft с трудом справлялась с гигантскими проектами подобного рода. В 2001 г. Microsoft начала работу над самым амбициозным обновлением своей операционной системы Windows, инициировав проект под кодовым названием Longhorn. На создание этой системы ушло пять лет, на полпути была произведена ее серьезная переоценка, и она появилась в 2006 г. под названием Windows Vista. К моменту ее выхода на рынок разработчики отказались от многих функций и не смогли реализовать те инновации, которые Билл Гейтс и Стив Балмер задумали полдесятилетия назад. Как ни странно, но такие примеры были не исключением, а нормой.
Основная проблема заключалась в том, что большинство софтверных проектов начиналось с тщательного определения технических требований и планирования на месяцы и годы вперед задолго до поставки работоспособного продукта в конце процесса. Вездесущий и ненавистный календарный график работ показывал, как все части проекта будут сливаться воедино с течением времени, чтобы в конце появилось нечто полезное для клиента. Из-за формы графика этот процесс получил название «каскадной» разработки.
Джефф Сазерленд — один из ученых-компьютерщиков, положивших начало методологии аджайл, и активный критик старого метода каскадной разработки. С 1960-х гг. он считался стандартом в софтверной индустрии, но Сазерленд называет его «колоссальной ошибкой», которая «обошлась в сотни миллиардов долларов из-за провальных проектов только в США». По словам Сазерленда, каскадная разработка заканчивается неудачей в 85% случаев в проектах стоимостью более $5 млн. В 2004 г. исследование 250 крупных софтверных проектов показало, что 70% из них страдали от серьезных задержек и перерасхода средств или были прекращены до получения результата.
Австралийская авиакомпания Qantas потратила $200 млн на разработку проекта под руководством IBM и расторгла рассчитанный на 10 лет контракт через четыре года. Но это было только первое ее фиаско. В 2008 г. Qantas отказалась от программного комплекса для управления авиационными запчастями Jetsmart, который обошелся в $40 млн и был настолько плох, что авиаинженеры прозвали его «Тупой самолет» (Dumbjet).
В своей книге «SCRUM: Революционный метод управления проектами» Сазерленд рассказывает историю масштабного правительственного проекта, который был спасен методологиями скрам и аджайл. В 2000 г. ФБР инициировало рассчитанный на пять лет проект Virtual Case File по переводу устаревшей бумажной системы учета в цифровой формат. Исполнители контракта использовали устаревший каскадный метод, и в 2005 г., потратив $170 млн, ФБР пришлось отказаться от проекта и начать все сначала. Исполнение следующего проекта, получившего название Sentinel, с бюджетом $451 млн поручили компании Lockheed Martin. Lockheed также использовала каскадный подход и к 2010 г., за пять лет работы, потратила $405 млн, а сделала только половину. По оценкам компании, ей требовалось еще $350 млн, чтобы закончить работу за шесть‒восемь лет. Однако пара инновационных ИТ-руководителей из аппарата ФБР взяла проект на себя, сократила команду разработчиков с сотен человек до 50, разместила их в подвале штаб-квартиры ФБР и выполнила работу за 20 месяцев и $12 млн. Как? С помощью методологии аджайл.
Методология аджайл решила важную проблему — у разработки ПО не было рабочего процесса, в отличие от многих других технических дисциплин. Когда вы строите небоскреб, геодезист осуществляет съемку местности, архитектор проектирует здание, клиент проверяет проект, а затем архитектор передает его генеральному подрядчику. Подрядчик делит строительство на специализированные этапы и координирует работу. Человечество оттачивало эту модель в течение последних двух сотен лет, и она работает.
При разработке ПО обычным является постоянное изменение требований. Представьте, что вы заканчиваете строительство 50-го этажа небоскреба, а клиент начинает требовать другой фундамент. Такое происходит с программистами все время. Но если любой понимает, во что обойдется снос небоскреба и начало строительства с нуля, то в мире ПО это зачастую не так очевидно. Относительно небольшое изменение в конце разработки может сильно повлиять на некоторые базовые аспекты. Как результат, софтверные проекты часто отклонялись от намеченного курса из-за изменения требований. Но дело в том, что в сфере ПО требования часто не вполне ясны в начале проекта, а тщательно проработанные зависимости и предположения бывают ошибочными. Кроме того, бизнес-потребности изменяются быстрее, чем продвигается софтверный проект.
Помимо прочего, из-за жесткой зависимости между командами замедление работы одной из них нередко тормозит весь проект. А с учетом изменения требований замедление является нормой, а не исключением. Таким образом, даже когда талантливые и исполненные лучших намерений менеджеры проектов предусматривают в планах временной буфер, непредсказуемое каскадное замедление становится неуправляемым. Вот почему миллиарды долларов тратились впустую, у разработчиков и бизнес-руководителей опускались руки, а большинство компаний считали невозможной успешную разработку ПО своими силами.
Решением проблемы могло стать еще более тщательное планирование или запрет на все изменения с началом работ. Однако нашлись головы, которые поняли, что подобный подход — хорошая, но совершенно нереалистичная идея.
В поисках альтернативы в 2001 г. Сазерленд и группа ведущих специалистов по разработке ПО устроили трехдневную встречу. Они разработали одностраничный документ под названием «Манифест аджайл-разработки программного обеспечения», который предлагал более эффективный и реальный подход к создания ПО, повышающий шансы организаций на успешное создание ценности вовремя и в рамках бюджета.
Манифест аджайл-разработки программного обеспечения
Мы постоянно открываем более совершенные методы создания программного обеспечения, занимаясь разработкой сами и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Иными словами, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
Кент Бек
Джеймс Греннинг
Роберт Мартин
Майк Бидл
Джим Хайсмит
Стив Меллор
Ари ван Беннеком
Эндрю Хант
Кен Швабер
Алистер Кокберн
Рон Джеффрис
Джефф Сазерленд
Уорд Каннингем
Джон Керн
Дейв Томас
Мартин Фаулер
Брайан Марик
© 2001, вышеуказанные авторы.
Текст манифеста может свободно копироваться в любой форме, но только полностью, включая это уведомление.
Авторы манифеста аджайл определили четыре направления и 12 принципов, которые подкрепляют эту методологию и действительно являются основой ее многочисленных форм. Вполне возможно, что ваша компания практикует аджайл в том или ином виде, но единого определения методологии аджайл не существует. Появился целый спектр практик под флагом аджайл. Вы наверняка слышали о наиболее популярных из них, таких как скрам, канбан и экстремальное программирование. Даже сами эти практики реализуются по-разному и с разной степенью приверженности «правилам». За последние 20 лет методология аджайл распространилась по всему миру. В опросе 2019 г. «Состояние аджайл» 97% респондентов заявили, что их организации практикуют методы аджайл. Независимо от конкретной реализации все они преследуют одну и ту же цель: создание эффективного ПО. Рассмотрим более детально эту методологию.
Основы аджайл
В основе методологии аджайл лежит гибкость (кто бы сомневался!) — способность быстро и легко двигаться, быстро менять направление и реагировать на изменение исходных данных. Авторы манифеста аджайл видят проблему в практике предварительного планирования, отталкиваясь от неверных предположений, и в отсутствии координации действий владельцев бизнеса и разработчиков. Устраняя эти два ключевых недостатка, методология аджайл позволяет сделать процесс создания ПО более гибким. Хотя существует множество путей реализации методологии аджайл, все они сводятся к трем основным идеям: предвидение изменений, разделение работы на части и поддержание тесного сотрудничества между бизнесом и разработчиками.
Предвидение изменений
Первая идея — это предвидение изменений в технических требованиях, поэтому вместо того, чтобы удивляться их появлению и расстраиваться из-за этого, нужно создать систему, которая ожидает изменения. Аджайл позволяет сделать это несколькими способами. Во-первых, это ограничение объема незавершенной работы. Если у вас сотня заданий, которые выполнены на 10%, то вероятность появления изменений и прерывания хотя бы одного из потоков работы велика. Однако если сосредоточиться на выполнении одного задания на 100%, то вам вряд ли придется бросать завершенную работу. Аджайл ограничивает объем незавершенной работы, разбивая ее на короткие спринты, часто продолжительностью не более двух недель, с целью поставки работоспособного продукта в конце каждого цикла. Это не означает, что проект выполняется за две недели, но какая-то его часть становится работоспособной в конце каждого спринта, а не остается незавершенной в течение длительного времени.
Короткие циклы обеспечивают высокую адаптируемость. При появлении изменений их можно учесть в будущем спринте, поскольку команда не привязана ни к чему, кроме текущего спринта. Большинство спринт-команд проводят ежедневные летучки, на которых можно обсудить изменения и скорректировать планы на день. Подобное очень тесное сотрудничество с участием одной небольшой команды и менеджера по продукту облегчает работу с изменениями. Вместо того, чтобы перекладывать работу на других и защищаться от меняющихся требований, здесь происходит обратное. У команды единое понимание задания, и поэтому она чаще поддерживает изменения, а не сопротивляется им. Это цельный процесс, выстроенный с прицелом на гибкость, т.е. на внесение изменений.
Разделение работы на части по ходу дела
Вторая идея заключается в разбивке работы по мере ее выполнения на управляемые, предсказуемые и реализуемые единицы. В отличие от каскадного метода, где работа распределяется по строкам календарного графика (иногда растянутым на годы) до ее начала на основании неполного набора допущений, методология аджайл предполагает создание управляемых единиц работы, которые реализуются быстро и только в пределах текущего спринта. Такой процесс позволяет сделать каждый элемент работы предсказуемым по объему и времени, придавая высокую степень уверенности в его выполнении. Само по себе это необязательно обеспечивает уверенность в выполнении большого многолетнего проекта, но позволяет строить большой проект на основе множества небольших интервалов с высоким уровнем уверенности. Это может показаться не таким уж и хорошим выходом, но он лучше, чем альтернатива — создание большого рискованного проекта на основе множества более мелких рискованных проектов.
Если вам нужно пробежать милю, позаботьтесь о том, чтобы каждый шаг был выполнен хорошо. Важно, чтобы результатом каждого спринта было работоспособное ПО. Именно поэтому многие команды внедряют практику «демоспринта» — демонстрацию в последний день спринта результатов своей работы, создавая культурное подкрепление этого ключевого принципа методологии аджайл. Демоверсии позволяют показать умение разбивать работу на части и выполнять ее в спринте. При отсутствии работоспособного ПО они и не могут его продемонстрировать, что создает стимул для улучшения ситуации в следующих спринтах.
Как вы понимаете, точная оценка объема работы, необходимой для реализации функциональности в ПО, — это искусство, которое мы пытаемся превратить в науку с помощью аджайл-практики. И это — командная работа. Вновь сформированная команда нередко не очень хорошо умеет точно предсказывать свою производительность. Ее знание кодовой базы (если это существующий проект) или проблемной области (если это новый проект) часто неполное, поэтому в оценку объема работы, необходимой для реализации задания, вкрадываются ошибки. Но со временем, по мере роста знаний о кодовой базе и проблемной области, точность оценки повышается.
Команды часто используют такой абстрактный показатель, как «пункты истории», чтобы оценивать и постоянно улучшать предсказуемость и результативность своих спринтов. Он характеризует объем работы по реализации заданной функциональности, а также какого результата команда может достичь в спринте. По мере повышения точности прогнозирования объема работы и производительности в пунктах истории предсказуемость работы команды растет. Как только команды определят свой базовый уровень, они могут сосредоточиться на получении большего числа пунктов истории в спринте и, таким образом, повышать эффективность и производительность. Учтите, что пункты истории являются абстрактным показателем — они не основаны на каком-либо жестком количественном измерении, таком как строки написанного кода, и поэтому не могут использоваться для сравнения с другими компаниями или командами. (Кстати, строки написанного кода — это ужасный показатель, о котором вы никогда не должны заботиться, ведь «меньше — это больше», когда дело доходит до хорошего кода.) Все, что вас должно интересовать как стороннего наблюдателя, — это обеспечивают ли пункты истории более высокую предсказуемость и производительность команде. Не заморачивайтесь вопросом, почему оценка одной команды 100 пунктов, а другой — только 50. Если они не откалибровали свое определение пунктов, что делается редко, то это небо и земля. Вам нужно смотреть на то, становится ли со временем каждая команда более продуктивной с точки зрения пунктов истории. Если год назад они набирали в среднем 100 пунктов за спринт, а сейчас — 150, то, значит, они стали на 50% эффективнее. Лучшие команды делают более предсказуемую и качественную работу, а подсчет пунктов истории дает лидерам возможность оценивать прогресс своих команд.
Еще одно преимущество разделения работы на части и получения готового фрагмента кода в каждом спринте заключается в том, что вы попутно создаете дополнительную ценность для клиентов. Представьте, что вы выполнили 10% проекта, но отправляете эту часть только в конце. Вы, таким образом, держите 10% функций в заложниках, пока не будут выполнены остальные 90% проекта. Но, разделяя работу и часто отправляя результат, вы можете сразу представить эти 10% функций клиентам.
Аджайл-команды обычно разбивают сложные задачи на части, создавая бэклог заданий, подлежащих выполнению. Если инженеры занимаются реализацией бэклога заданий текущего спринта, то задача менеджера по продукту состоит в подготовке бэклога заданий следующего спринта, устраняя неясности и неопределенности. За пределами следующего спринта существует море заданий на разных стадиях определения, но по мере выполнения спринтов они становятся все более и более ясными. Самое главное, это не является недостатком аджайл. Принимайте решения как можно ближе к моменту их реализации, чтобы получить как можно больше информации. Подобный метод уменьшает объем ненужной работы.
Тесное сотрудничество между бизнесом и разработчиками
В большинстве аджайл-команд есть две роли: владелец продукта и команда разработчиков. В скрам добавляется еще и третья роль: скрам-мастер. Задача владельца продукта состоит в понимании и защите клиента, а также в подготовке «пользовательских историй», описывающих потребности пользователя. Пользовательские истории — это инструмент взаимодействия владельца продукта и команды разработчиков. Конечно, это может смахивать на перекладывание работы на других, но в хорошо функционирующей аджайл-команде владелец продукта тесно сотрудничает с разработчиками в процессе подготовки и постепенного улучшения пользовательских историй.
Смотрите на пользовательские истории как на описание работы, подлежащей выполнению с точки зрения клиента. Этим они отличаются от технических требований к продукту прошлых лет, которые больше концентрировались на том, что должна выполнять программа, а не на том, что нужно клиенту. Разница может показаться несущественной, но она важна. В хорошо функционирующей аджайл-команде создание пользовательской истории и ее обсуждение сконцентрированы больше на клиенте, а не на ПО.
Плохая пользовательская история описывает большую сложную систему, а хорошая — ограничена по объему. Это повышает предсказуемость и снижает возможность неверных интерпретаций или появления открытых вопросов. Вместе с тем хорошая пользовательская история содержит сквозное описание того, что собирается делать клиент, так что разработчик может прочувствовать и понять проблему клиента. Это позволяет разработчику принимать правильные решения и использовать свою интуицию, а не просто «делать то, что приказано».
Владелец продукта, как и следовало ожидать, —обычно менеджер по продукту. Он должен не ограждать команду разработчиков от клиентов, а помогать членам команды понять потребности клиента. Владелец продукта служит связующим звеном и поддерживает диалог между клиентами и командой. Хороший владелец продукта умеет правильно резюмировать проблему клиента, подлежащую решению, и, таким образом, представляет широкий круг клиентов.
Владелец продукта управляет бэклогом работ команды. Бэклог представляет собой очередность будущих заданий, которые постоянно уточняются владельцем продукта с целью создания максимальной потребительской ценности в каждом спринте и работы над пользовательскими историями с высокой степенью осуществимости и полезности для клиента. Если в пользовательской истории все еще много неопределенности в потребностях клиента или осуществимости, то владелец продукта должен сделать все, чтобы найти ответы на незакрытые вопросы. Эту часть процесса называют «причесывание бэклога», она является одной из важнейших обязанностей владельца продукта. В каждом спринте, если команда разработчиков сосредоточена в основном на выполнении требований пользовательских историй для данного спринта, то владелец продукта занимается уточнением набора пользовательских историй для следующего спринта. Хотя формирование бэклога лежит в основном на владельце продукта, наполнение историй техническими деталями происходит в тесном сотрудничестве с разработчиками и совершенно непохоже на перекладывание работы на других.
Если все это кажется сложным, то так оно и есть. К работе необходимо привлечь аджайл-коуча, который поможет команде внедрить хорошую аджайл-гигиену, в частности расчет пунктов истории и причесывание бэклога. Если команде с трудом удается представлять работоспособное ПО в каждом спринте, то коуч должен помочь команде определить, в чем проблема — в определении объема, в низкой производительности, в плохом сотрудничестве, в расплывчатости пользовательских историй или во всем вышеперечисленном. Если аджайл-коуч покажется роскошью, то он может работать сразу с несколькими командами. Я не буду детализировать роль коуча, скажу только, что она похожа на роль любого другого коуча — когда нужно помочь команде чему-то научиться, хороший коуч может быть бесценным.
Слишком много вопросов
Итак, если аджайл — это лучшая методология создания ПО, разработанная к настоящему моменту, то почему до сих пор так много неудовлетворительных результатов? Давайте рассмотрим ряд вопросов, которые могут возникать у руководителей при работе аджайл-команд.
Почему вы не знаете, когда продукт будет поставлен клиентам и с какими функциями?
Первое, что вызывает досаду у руководителей и менеджеров, — это неспособность технических команд придерживаться жестких сроков. На мой взгляд, в разработке ПО есть четыре аспекта: функции, сроки, качество продукта и его определенность. Вообще говоря, вы можете выбрать любые три из них, но вам не удастся получить одновременно все четыре. Вы можете с уверенностью создать набор функций к определенному сроку, но качество продукта может сильно пострадать, поскольку разработчики будут упрощать многое, чтобы уложиться в срок. Вы можете создать продукт к определенному сроку и с предсказуемым качеством, но в реальности вам придется для этого урезать функции продукта. Вы можете с высокой уверенностью получить известный набор функций с хорошим качеством, но не будете знать, сколько времени это займет. Или можно замахнуться на все три аспекта — функции, качество и сроки, что звучит здорово, но, скорее всего, при низкой уверенности.
Если вы, как руководитель, потребуете выполнения всех четырех аспектов, то вам придется угадывать, какой из них — ложный. Или вы можете получить реалистичные отчеты от подчиненных, которые расскажут вам, основываясь на фактах, что произойдет, по их мнению. Если у вас жесткий срок — крупная конференция пользователей или маркетинговая кампания, которую необходимо осуществить любой ценой, — то они скажут, чем следует пожертвовать. Или назовут вероятность выдерживания сроков, что редко бывает точным или внушающим оптимизм. Поэтому, скорее всего, они будут настаивать на соблюдении функциональности, определенности и сроков. На первый взгляд, именно этого и ждут руководители. Жертвой, однако, чаще всего становится качество продукта. Поначалу это может быть неочевидно, но затем выйдет боком, если клиенты примут продукт. Выдерживание срока может помочь завоевать рынок, но клиенты столкнутся с ошибками, проблемами масштабирования, безопасности и т.д. На этом прогресс застопорится, поскольку команде придется исправлять базовые вещи. Это гораздо более неприятно, с учетом того, что у вас появляются недовольные клиенты или неудовлетворенный спрос.
Вот почему многие продукты, созданные по методологии аджайл, начинают свою жизнь с бедным функционалом. Чаще всего функционал продукта не так важен, как быстрое представление идеи клиентам. Таким образом, сроки берут верх над функционалом при соответствующем качестве, надо предполагать. Создание меньшего по объему продукта, но с уверенностью — это путь многих команд, разрабатывающих новый продукт. Если есть ключевой функционал, то к нему всегда можно добавить функции позднее.
Руководителю лучше заняться серьезным обсуждением того, какие параметры необходимо сохранить, а какими можно пожертвовать. В Twilio мы говорим, что качество и доверие — это самое главное. Мы считаем качество драгоценностью, которой никогда нельзя жертвовать. Да, мы совершаем ошибки, но стараемся донести до клиентов мысль о том, что качество для нас не тот аспект, которым можно жертвовать. Как и многие компании, мы проводим большую ежегодную конференцию пользователей (под названием SIGNAL), которая служит нам платформой для анонсирования продуктов, привлечения внимания прессы и информирования клиентов. Поэтому сроком обычно является тот момент, когда маркетинговая команда бронирует помещение для конференции и начинает продавать билеты. Это гарантирует функционал и уверенность. Вообще говоря, неопределенность — скользкая вещь, поэтому функции продукта отдаются на усмотрение команд, с тем чтобы они уложились в срок. Мы измеряем определенность в месяцах до конференции SIGNAL, но, когда остается всего один месяц, она обретает вид однозначного «да» или «нет», и с этого момента функции продукта становятся единственной переменной, которую нужно реализовать в срок. Это хороший компромисс. Как руководители, мы часто зацикливаемся на функциях, однако клиенты редко покупают продукт на основе какой-то функции. Их больше интересует общий функционал, а функции всегда можно добавить позднее. Таким образом, руководители компании и менеджеры по продукту должны заранее определить, какие функции имеют первостепенное значение для принятия продукта клиентами и его конкурентоспособности на рынке, а какие просто было бы неплохо иметь.
Почему на решение проблемы нельзя бросить больше разработчиков?
Обычно руководители рады получить больше ресурсов, поэтому, когда техническим директорам предлагают увеличить численность сотрудников или бюджет для ускорения проекта, их отказ вызывает удивление. Кому не хотелось бы увеличить бюджет и штат? Причина в том, что переброска дополнительных работников на решение проблемы (особенно если проект выполняется, но отстает от графика) вряд ли поможет. На самом деле подобное решение может еще больше задержать работу над проектом. Почему же получается такой парадоксальный результат, особенно в краткосрочной перспективе? Да потому, что подбор исполнителя любой роли требует времени и отвлекает от текущей работы. Время нужно и на то, чтобы новый разработчик вошел в курс дела. Даже если вы наймете его сегодня, он не будет продуктивно работать, пока не ознакомится с кодовой базой и стилем работы команды. Этот процесс обычно занимает несколько месяцев и ничем не отличается от того, что происходит в других отделах. Возьмите отдел продаж — если вы нанимаете нового торгового представителя, ему требуется время, чтобы изучить набор продуктов и начать заключать сделки. Поэтому если вы не дотягиваете до целевых показателей по доходам в текущем квартале, то наем дополнительных торговых представителей прямо сейчас вам не поможет. То же самое и с разработчиками — для повышения производительности нужны предварительные затраты. Но если привлечь разработчиков из другой команды, то эти затраты значительно сократятся. Почему бы не поступить именно так? У ПО есть и другие, уникальные проблемы.
В 1975 г. пионер софтверной индустрии Фредерик Брукс-младший опубликовал сборник эссе о разработке программного обеспечения «Мифический человеко-месяц». Одна из основных идей, давшая название книге, — это «мифический человеко-месяц» (я буду называть его «мифическим разработчико-месяцем»). Ее суть в том, что с увеличением численности разработчиков проекта, который отстает от графика, шансы на срыв сроков только возрастают. С чем связан такой нелогичный результат? Прежде всего со временем на введение новых разработчиков в курс дела. Но еще важнее коммуникационные издержки. Всем новым разработчикам приходится задавать много вопросов о том, как работает разрабатываемый продукт, и эти вопросы отвлекают и сбивают тех, кто давно работает над проектом. В результате прогресс замедляется, и вы отстаете еще больше. Это и есть принцип мифического разработчико-месяца в действии.
Конечно, бывают моменты, когда расширение команды ускоряет прогресс, но середина работы над проектом к их числу не относится. Понятно, что многое изменилось с тех пор, как Брукс опубликовал «Мифический человеко-месяц», но эта концепция в значительной степени осталась верной.
На рисунке показано то, что я наблюдал лично. Я составил формулу для расчета. Она не слишком научна, но, если спросить разработчиков о том, близка ли такая зависимость к истине, думается, они с ней согласятся.
Результаты снижаются, когда число разработчиков увеличивается до 10. Это подчеркивает необходимость сохранения небольших команд, а также объясняет, почему нельзя добавить людей в существующую команду и ожидать большего результата. Если увеличить число разработчиков с 10 до 20, то вы более чем вдвое снизите производительность и получите замедление работы, а не ускорение. А если команда разрастается примерно до 25 человек, то результат становится отрицательным. Я не знаю точно, чем объяснить этот эффект, но мой опыт говорит, что результат именно такой.
Понятно, если вас расстраивает то, что нет возможности привлечь больше работников к устранению проблемы. На бюджет тоже нужно смотреть с позиции руководителя, и он не резиновый. Но в краткосрочной перспективе не выливайте свое раздражение на команду. Это только деморализует уже и без того измотанных людей. Это все равно что злиться на гравитацию. Если ваш парашют не раскрылся, вы можете проклинать гравитацию сколько угодно, но это не поможет.
Однако в более отдаленной перспективе хорошие лидеры могут более эффективно «разделять и побеждать». Разделение проблемной области, кода и работников на более мелкие блоки позволяет создать резерв и добавить больше сотрудников. Вспомните процесс клеточного деления, описанный в главе 8. Не забывайте, что подобные реорганизации требуют времени. Рассчитывайте на то, что увеличение численности разработчиков и бюджета приведет к ускорению прогресса не ранее чем через полгода.
Недавно у меня был разговор с руководителем, рассматривавшим проект, для выполнения которого требовалось три года. Это был важный проект, и руководитель очень сожалел, что они не могли «бросить $100 млн на решение проблемы» и справиться с ней за год — лидеры разработчиков заявили, что прямо сейчас они не в состоянии ускорить проект даже с большим бюджетом. Затем руководитель сказал: «Держу пари, если предложить [название крупной консалтинговой фирмы] $100 млн, они сделают это». Я ответил: «Конечно, их торговый представитель скажет, что они сделают это, когда увидит $100 млн, но им тоже не удастся одолеть задачу». Вот почему крупные консалтинговые проекты никогда не укладываются в сроки и бюджет. Примечательно, что руководитель не стал спорить со мной, надо думать потому, что его опыт подтверждал мое мнение. Иногда принятие трудных решений требует времени. Но я все же предложил этому руководителю обсудить с техническими лидерами, что они могут предпринять сегодня и в ближайшие месяцы для увеличения бюджета через полгода и завершения проекта за полтора года вместо трех лет. Это разумный вопрос, и эффективный технический лидер должен знать, как ответить на него.
Даже в нынешней аджайл-среде работа по-прежнему делится между командами. Чтобы ускорить работу, менеджерам нужно либо добавлять персонал в команду (а это ведет к проблемам, описанным Бруксом), либо перераспределять работу так, чтобы команды могли выполнять ее параллельно. В любом случае это влечет за собой огромный перерасход ресурсов сначала на поиск сбалансированного распределения работы, а потом на встраивание ее частей в кодовую базу. Это классическое «замедление ради ускорения». И наконец, нужно укомплектовать команду и добиться продуктивности. Как бы то ни было, лучше всего просто позволить команде продолжить работу в краткосрочной перспективе, а в это время подумать над реорганизацией структуры команд, которая обеспечит ускорение. Существуют естественные точки остановки, где очень удобно провести переоценку и перераспределение задач (я показывал в главе 8, как клеточное деление позволяет с течением времени разделять и выращивать команды), но это надо делать не в разгар работы над проектом, особенно если намечается отставание от графика.
Ловушки методологии аджайл
Все это хорошо, но методология аджайл не панацея от всех проблем, как ее иногда описывают неофиты. Как и любая система организации, аджайл-подход имеет свои плюсы и минусы. В недавнем разговоре с генеральным директором публичной компании я спросил, как продвигается их аджайл-трансформация, и он ответил: «Сборище лентяев рассказывает нам, как вести бизнес, — и ничего не меняется!» Я чуть не упал со стула. Где же методология аджайл дала сбой?
Вместо высвобождения творческого потенциала разработчиков методология аджайл иногда может подавлять его. В попытке привнести дисциплину и предсказуемость в разработку программного обеспечения первые аджайл-практики обращались к миру материального производства с вопросом: «Как добиться предсказуемости сборочной линии в разработке программного обеспечения?» В результате родился метод организации рабочего процесса канбан, который был буквально заимствован из производственной системы Toyota.
В канбан владелец продукта разбивает недельную работу на небольшие задачи, которые записываются на стикерах и прикрепляются к канбан-доске. Инженеры снимают задания с доски, выполняют работу, перемещают стикеры в колонку «Сделано», и процесс повторяется. Когда неделя заканчивается, они отчитываются о количестве выполненных задач. Разбивка сложных задач на более мелкие необходима, но есть риск, что метод канбан превратит разработчиков в сборщиков на конвейере. Как вы могли понять из прочитанного, я не поклонник такого образа мышления. На сборочной линии автозавода не найти творчества. Автомобили, которые вы производите, не предназначены для решения индивидуальных проблем. Совсем наоборот. Вы хотите, чтобы все автомобили, сходящие со сборочной линии, были одинаковыми. И вам не нужно, чтобы рабочие сборочного конвейера привносили творческие элементы — «Давайте сделаем на этом автомобиле треугольный руль!».
Это подходит для сборки автомобилей, но не для работы творческих людей. Канбан-доски напоминают мне о статье, прочитанной несколько лет назад, — она была интересной, но немного пугающей. В ней рассказывалось о китайской деревне Дафэнь, на которую приходится 60% мирового производства картин маслом, многие из них — это копии работ великих мастеров. Это фабрика изобразительного искусства со «сборочными линиями», выпускающими выполненные вручную копии картин Винсента Ван Гога, Леонардо да Винчи, Энди Уорхола и многих других. Художники работают в бригадах. Каждый мастер идет по проходу между мольбертами и наносит несколько мазков на каждый холст. Следующий добавляет еще один элемент… В Дафэне работают более 8000 художников, и они выпускают от трех до пяти миллионов картин в год. Превращение Моне в деньги — это довольно хитроумный трюк. Но я был потрясен, когда прочитал о Дафэне: меня оскорбляло то, что компании нанимают творческих людей, а затем полностью изгоняют творчество из их работы.
Тем не менее это именно то, что некоторые компании делают с разработчиками. Они нанимают таланты, а затем засовывают их в офисы открытого типа, где они строчат стереотипные программы, вытаскивая билетики с канбан-доски. Мне часто жалуются, что трудно найти отличных разработчиков, а я в ответ говорю, что это и немудрено, если с ними обращаются как с рабочими сборочного конвейера.
Ежедневные летучки — еще один основополагающий элемент методологии аджайл. Каждый день команда начинает с совещания, на котором каждый рассказывает остальным, что он делал вчера и что собирается делать сегодня. Проблема в том, что многие разработчики просто ненавидят совещания — не из-за своей асоциальности, а потому, что совещания отнимают ценное время, которое было бы лучше потратить на написание кода. И, как любые совещания, ежедневные летучки могут быть как хорошо организованными и эффективными, так и безграничной и неконкретной тратой времени.
Мы, как руководители, привыкли к рабочим дням, заполненным встречами, и часто ожидаем, что у всех в компании одинаковый график. Это то, что Пол Грэм, соучредитель Y Combinator, называет «распорядком менеджера», очень эффективным для сотрудников, чья основная работа — это взаимодействие с другими людьми. Деление дня на одночасовые блоки — это метод, который позволяет координировать работу множества людей. Просто добавьте встречу в мой календарь.
Но сделать что-то с нуля обычно невозможно за один час — это требует сосредоточенности и того, что Грэм называет «распорядком создателя». Возможно, вы слышали о потоке — это состояние, когда человек сосредотачивается на проблеме и решает ее максимально креативно. Авторы, художники, музыканты и даже повара говорят о потоке. Это состояние ума, когда все складывается. А еще поток требует постоянной концентрации. Даже одна встреча может разрушить состояние потока. Грэм говорит: «Каждый тип распорядка прекрасно работает сам по себе. Проблемы возникают, когда они сталкиваются. Поскольку большинство влиятельных людей работают по распорядку менеджера, они в состоянии — если захотят — заставить каждого работать аналогичным образом. Но те из них, кто поумнее, сдерживают себя, если знают, что некоторым подчиненным нужны для работы более длинные интервалы времени».
Поэтому неудивительно, что ежедневные летучки могут нарушать поток. Какое соотношение состояния потока и встреч лучше всего подходит вашей организации? Почему бы вам… не спросить своего разработчика?
Многие разработчики хотят свободы, чтобы понимать клиентов, глубоко вникать в бизнес и использовать весь свой потенциал. Но чрезмерно жесткое следование методологии аджайл может убедить разработчиков в том, что их работа вовсе не понимание клиентов или бизнеса, поэтому они ограничиваются той ролью, которую от них ожидает система. Важно не дать менеджерам по продукту и разработчикам попасть в эту ловушку. Если разработчики ограничивают себя, это может в краткосрочной перспективе упростить их жизнь: «Просто говорите мне, что делать». Но довольно скоро они почувствуют неудовлетворенность и начнут искать работу в более подходящем месте. Методология аджайл сама по себе довольно хороша для разработчиков. Но руководители низшего уровня должны позаботиться о том, чтобы разработчики оставались вовлеченными в бизнес и относились к разработке как к совместной работе, а не как к выполнению задач.
Все в меру
Одна из любимых поговорок моего отца — «Все в меру». Большинство вещей в нашей жизни нормальны, пока ты не увлекаешься ими слишком сильно. Алкоголь. Телевизор. Секс. Именно так я подхожу к методологии аджайл при разработке ПО. Вместо того чтобы развертывать полномасштабную реализацию аджайл с коучами, консультантами и кучей жестких правил и процедур, некоторые компании просто берут несколько принципов аджайл, которые имеют смысл, и отбрасывают остальное. «Я уже давно не использую какую-либо формальную методологию», — говорит соучредитель компании Breaker и ее технический директор Лия Калвер (мы упоминали о ней в главе 4). По ее словам, инженеры у нее практикуют быстрые спринты, но не утруждают себя другими элементами аджайл, такими как ежедневные летучки.
В Twilio мы не придерживаемся строго какой-либо определенной формы аджайл и позволяем командам выбирать свой стиль работы — какие-то из них принимают более формальные элементы аджайл, другие — менее формальные. Но мы строго реализуем ряд ключевых идей. Самое строгое правило состоит в том, что небольшие автономные команды — основа прогресса. Мы ограничиваем размер команд 10 сотрудниками. Вместо системы планирования, навязывающей им работу, мы просим их намечать собственные ежеквартальные цели на основе пожеланий клиентов. Когда представления команд о том, что необходимо, отличаются от наиболее важных целей руководства, оно не спускает указания сверху, а начинает дискуссию для разрешения конфликта. Это некоторые из обязательных элементов для всех наших команд разработчиков, число которых приближается к 150.
Когда структура сформирована, мы обычно позволяем командам выбирать свой стиль работы. Большинство (если не все) команд работают в режиме двухнедельных спринтов и стремятся достичь заметного прогресса в конце каждого из них. У одних команд это получается лучше, чем у других. Все они стараются ограничивать объем незавершенной работы, что является целью методов скрам и канбан. Некоторые команды работают в одном помещении, тогда как другие распределены по всей стране или даже по континентам. Однако лучше всего держать команды в пределах четырех или пяти часовых поясов друг от друга, чтобы обеспечить достаточное пересечение рабочего времени. Большинство команд оценивают производительность с помощью пунктов истории. Хотя определение пунктов истории у каждой команды свое, это нормально. Такая практика является частью потока работ многих аджайл-команд, и мне она нравится. Оценка здорового подхода к работе у технической команды не менее важна, чем измерение результативности продавца на закрытых распродажах.
Наши команды находятся на разных этапах реализации методологии «Спросите своего разработчика». В некоторых командах инженеры регулярно обсуждают клиентские аспекты создаваемого продукта. Чаще всего это команды, где разработчиков знакомят с проблемами клиентов, а не только с пользовательскими историями.
Я всегда нахожу время, чтобы пройтись по офисам Twilio и поинтересоваться у инженеров, над чем они работают, — мягко и только если они не очень сосредоточены. Обычно я спрашиваю, какой проблемой клиента они сейчас занимаются. Нередко завязывается обстоятельный разговор о клиенте, но бывает, что в ответ я получаю безразличное пожатие плечами и слышу: «Я не уверен, что это действительно проблема клиента, этим вопросом мне поручил заняться менеджер по продукту». Это признак того, что команды, возможно, слишком далеко зашли в аджайл-разделении труда. В таких случаях полезно поговорить с командой — и с лидерами, которые могут получить более высокую отдачу от своей команды, и с разработчиками, которые довольствуются тем, что «не знают». На мой взгляд, такой подход препятствует карьерному росту и тех, и других.
Если вам интересно, как реализуется методология аджайл и способствует ли она повышению гибкости, поговорите со своими разработчиками и менеджерами по продукту. Вы поймете, как они работают, насколько их работа является гибкой и клиентоориентированной. В частности, постарайтесь понять, насколько эффективна взаимосвязь менеджеров по продукту и технических талантов. Спросите разработчиков, хотят ли они, чтобы менеджеры по продукту были диспетчерами или координаторами взаимодействия с клиентами. Выясните у менеджеров по продукту, смотрят ли они на свою роль так же, как и вы. Вы можете поинтересоваться у команд, дорабатывают ли они рабочие планы на основе единого понимания клиентов или действуют по принципу «разделяй и побеждай»: менеджеры по продукту знают клиентов, а инженеры знают код. Я считаю, что команды, где менеджеры по продукту знают довольно много о коде, а разработчики столь же много о клиентах, делают более совершенные продукты. Позволяют ли спринты каждый раз создавать какой-нибудь полезный продукт? Регулярно ли команды добиваются прогресса? Нет единственно верного способа реализации методологии аджайл, но есть возможность реализовать ее плохо и удалить клиентов из рабочего процесса. Понимание ценности методологии аджайл, а также того, как команды внедряют ее, объясняет, почему вы слышите вроде бы нелогичные и нередко разочаровывающие ответы, когда пытаетесь добиться определенности от своих команд по разработке продуктов.
