В основе методологии аджайл лежит гибкость (кто бы сомневался!) – способность быстро и легко двигаться, быстро менять направление и реагировать на изменение исходных данных. Авторы манифеста аджайл видят проблему в практике предварительного планирования, отталкиваясь от неверных предположений, и в отсутствии координации действий владельцев бизнеса и разработчиков. Устраняя эти два ключевых недостатка, методология аджайл позволяет сделать процесс создания ПО более гибким. Хотя существует множество путей реализации методологии аджайл, все они сводятся к трем основным идеям: предвидение изменений, разделение работы на части и поддержание тесного сотрудничества между бизнесом и разработчиками.
Первая идея – это предвидение изменений в технических требованиях, поэтому вместо того, чтобы удивляться их появлению и расстраиваться из-за этого, нужно создать систему, которая ожидает изменения. Аджайл позволяет сделать это несколькими способами. Во-первых, это ограничение объема незавершенной работы. Если у вас сотня заданий, которые выполнены на 10 %, то вероятность появления изменений и прерывания хотя бы одного из потоков работы велика. Однако если сосредоточиться на выполнении одного задания на 100 %, то вам вряд ли придется бросать завершенную работу. Аджайл ограничивает объем незавершенной работы, разбивая ее на короткие спринты, часто продолжительностью не более двух недель, с целью поставки работоспособного продукта в конце каждого цикла. Это не означает, что проект выполняется за две недели, но какая-то его часть становится работоспособной в конце каждого спринта, а не остается незавершенной в течение длительного времени.
Короткие циклы обеспечивают высокую адаптируемость. При появлении изменений их можно учесть в будущем спринте, поскольку команда не привязана ни к чему, кроме текущего спринта. Большинство спринт-команд проводят ежедневные летучки, на которых можно обсудить изменения и скорректировать планы на день. Подобное очень тесное сотрудничество с участием одной небольшой команды и менеджера по продукту облегчает работу с изменениями. Вместо того, чтобы перекладывать работу на других и защищаться от меняющихся требований, здесь происходит обратное. У команды единое понимание задания, и поэтому она чаще поддерживает изменения, а не сопротивляется им. Это цельный процесс, выстроенный с прицелом на гибкость, т. е. на внесение изменений.
Вторая идея заключается в разбивке работы по мере ее выполнения на управляемые, предсказуемые и реализуемые единицы. В отличие от каскадного метода, где работа распределяется по строкам календарного графика (иногда растянутым на годы) до ее начала на основании неполного набора допущений, методология аджайл предполагает создание управляемых единиц работы, которые реализуются быстро и только в пределах текущего спринта. Такой процесс позволяет сделать каждый элемент работы предсказуемым по объему и времени, придавая высокую степень уверенности в его выполнении. Само по себе это необязательно обеспечивает уверенность в выполнении большого многолетнего проекта, но позволяет строить большой проект на основе множества небольших интервалов с высоким уровнем уверенности. Это может показаться не таким уж и хорошим выходом, но он лучше, чем альтернатива – создание большого рискованного проекта на основе множества более мелких рискованных проектов.
Если вам нужно пробежать милю, позаботьтесь о том, чтобы каждый шаг был выполнен хорошо. Важно, чтобы результатом каждого спринта было работоспособное ПО. Именно поэтому многие команды внедряют практику «демоспринта» – демонстрацию в последний день спринта результатов своей работы, создавая культурное подкрепление этого ключевого принципа методологии аджайл. Демоверсии позволяют показать умение разбивать работу на части и выполнять ее в спринте. При отсутствии работоспособного ПО они и не могут его продемонстрировать, что создает стимул для улучшения ситуации в следующих спринтах.
Как вы понимаете, точная оценка объема работы, необходимой для реализации функциональности в ПО, – это искусство, которое мы пытаемся превратить в науку с помощью аджайл-практики. И это – командная работа. Вновь сформированная команда нередко не очень хорошо умеет точно предсказывать свою производительность. Ее знание кодовой базы (если это существующий проект) или проблемной области (если это новый проект) часто неполное, поэтому в оценку объема работы, необходимой для реализации задания, вкрадываются ошибки. Но со временем, по мере роста знаний о кодовой базе и проблемной области, точность оценки повышается.
Команды часто используют такой абстрактный показатель, как «пункты истории», чтобы оценивать и постоянно улучшать предсказуемость и результативность своих спринтов. Он характеризует объем работы по реализации заданной функциональности, а также какого результата команда может достичь в спринте. По мере повышения точности прогнозирования объема работы и производительности в пунктах истории предсказуемость работы команды растет. Как только команды определят свой базовый уровень, они могут сосредоточиться на получении большего числа пунктов истории в спринте и, таким образом, повышать эффективность и производительность. Учтите, что пункты истории являются абстрактным показателем – они не основаны на каком-либо жестком количественном измерении, таком как строки написанного кода, и поэтому не могут использоваться для сравнения с другими компаниями или командами. (Кстати, строки написанного кода – это ужасный показатель, о котором вы никогда не должны заботиться, ведь «меньше – это больше», когда дело доходит до хорошего кода.) Все, что вас должно интересовать как стороннего наблюдателя, – это обеспечивают ли пункты истории более высокую предсказуемость и производительность команде. Не заморачивайтесь вопросом, почему оценка одной команды 100 пунктов, а другой – только 50. Если они не откалибровали свое определение пунктов, что делается редко, то это небо и земля. Вам нужно смотреть на то, становится ли со временем каждая команда более продуктивной с точки зрения пунктов истории. Если год назад они набирали в среднем 100 пунктов за спринт, а сейчас – 150, то, значит, они стали на 50 % эффективнее. Лучшие команды делают более предсказуемую и качественную работу, а подсчет пунктов истории дает лидерам возможность оценивать прогресс своих команд.
Еще одно преимущество разделения работы на части и получения готового фрагмента кода в каждом спринте заключается в том, что вы попутно создаете дополнительную ценность для клиентов. Представьте, что вы выполнили 10 % проекта, но отправляете эту часть только в конце. Вы, таким образом, держите 10 % функций в заложниках, пока не будут выполнены остальные 90 % проекта. Но, разделяя работу и часто отправляя результат, вы можете сразу представить эти 10 % функций клиентам.
Аджайл-команды обычно разбивают сложные задачи на части, создавая бэклог заданий, подлежащих выполнению. Если инженеры занимаются реализацией бэклога заданий текущего спринта, то задача менеджера по продукту состоит в подготовке бэклога заданий следующего спринта, устраняя неясности и неопределенности. За пределами следующего спринта существует море заданий на разных стадиях определения, но по мере выполнения спринтов они становятся все более и более ясными. Самое главное, это не является недостатком аджайл. Принимайте решения как можно ближе к моменту их реализации, чтобы получить как можно больше информации. Подобный метод уменьшает объем ненужной работы.
В большинстве аджайл-команд есть две роли: владелец продукта и команда разработчиков. В скрам добавляется еще и третья роль: скрам-мастер. Задача владельца продукта состоит в понимании и защите клиента, а также в подготовке «пользовательских историй», описывающих потребности пользователя. Пользовательские истории – это инструмент взаимодействия владельца продукта и команды разработчиков. Конечно, это может смахивать на перекладывание работы на других, но в хорошо функционирующей аджайл-команде владелец продукта тесно сотрудничает с разработчиками в процессе подготовки и постепенного улучшения пользовательских историй.
Смотрите на пользовательские истории как на описание работы, подлежащей выполнению с точки зрения клиента. Этим они отличаются от технических требований к продукту прошлых лет, которые больше концентрировались на том, что должна выполнять программа, а не на том, что нужно клиенту. Разница может показаться несущественной, но она важна. В хорошо функционирующей аджайл-команде создание пользовательской истории и ее обсуждение сконцентрированы больше на клиенте, а не на ПО.
Плохая пользовательская история описывает большую сложную систему, а хорошая – ограничена по объему. Это повышает предсказуемость и снижает возможность неверных интерпретаций или появления открытых вопросов. Вместе с тем хорошая пользовательская история содержит сквозное описание того, что собирается делать клиент, так что разработчик может прочувствовать и понять проблему клиента. Это позволяет разработчику принимать правильные решения и использовать свою интуицию, а не просто «делать то, что приказано».
Владелец продукта, как и следовало ожидать, – обычно менеджер по продукту. Он должен не ограждать команду разработчиков от клиентов, а помогать членам команды понять потребности клиента. Владелец продукта служит связующим звеном и поддерживает диалог между клиентами и командой. Хороший владелец продукта умеет правильно резюмировать проблему клиента, подлежащую решению, и, таким образом, представляет широкий круг клиентов.
Владелец продукта управляет бэклогом работ команды. Бэклог представляет собой очередность будущих заданий, которые постоянно уточняются владельцем продукта с целью создания максимальной потребительской ценности в каждом спринте и работы над пользовательскими историями с высокой степенью осуществимости и полезности для клиента. Если в пользовательской истории все еще много неопределенности в потребностях клиента или осуществимости, то владелец продукта должен сделать все, чтобы найти ответы на незакрытые вопросы. Эту часть процесса называют «причесывание бэклога», она является одной из важнейших обязанностей владельца продукта. В каждом спринте, если команда разработчиков сосредоточена в основном на выполнении требований пользовательских историй для данного спринта, то владелец продукта занимается уточнением набора пользовательских историй для следующего спринта. Хотя формирование бэклога лежит в основном на владельце продукта, наполнение историй техническими деталями происходит в тесном сотрудничестве с разработчиками и совершенно непохоже на перекладывание работы на других.
Если все это кажется сложным, то так оно и есть. К работе необходимо привлечь аджайл-коуча, который поможет команде внедрить хорошую аджайл-гигиену, в частности расчет пунктов истории и причесывание бэклога. Если команде с трудом удается представлять работоспособное ПО в каждом спринте, то коуч должен помочь команде определить, в чем проблема – в определении объема, в низкой производительности, в плохом сотрудничестве, в расплывчатости пользовательских историй или во всем вышеперечисленном. Если аджайл-коуч покажется роскошью, то он может работать сразу с несколькими командами. Я не буду детализировать роль коуча, скажу только, что она похожа на роль любого другого коуча – когда нужно помочь команде чему-то научиться, хороший коуч может быть бесценным.