Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

целый спектр практик под флагом аджайл. Вы наверняка слышали о наиболее популярных из них, таких как скрам, канбан и экстремальное программирование. Даже сами эти практики реализуются по-разному и с разной степенью приверженности «правилам». За последние 20 лет методология аджайл распространилась по всему миру. В опросе 2019 г. «Состояние аджайл» 97 % респондентов заявили, что их организации практикуют методы аджайл. Независимо от конкретной реализации все они преследуют одну и ту же цель: создание эффективного ПО. Рассмотрим более детально эту методологию.

Основы аджайл

В основе методологии аджайл лежит гибкость (кто бы сомневался!) – способность быстро и легко двигаться, быстро менять направление и реагировать на изменение исходных данных. Авторы манифеста аджайл видят проблему в практике предварительного планирования, отталкиваясь от неверных предположений, и в отсутствии координации действий владельцев бизнеса и разработчиков. Устраняя эти два ключевых недостатка, методология аджайл позволяет сделать процесс создания ПО более гибким. Хотя существует множество путей реализации методологии аджайл, все они сводятся к трем основным идеям: предвидение изменений, разделение работы на части и поддержание тесного сотрудничества между бизнесом и разработчиками.

Предвидение изменений

Первая идея – это предвидение изменений в технических требованиях, поэтому вместо того, чтобы удивляться их появлению и расстраиваться из-за этого, нужно создать систему, которая ожидает изменения. Аджайл позволяет сделать это несколькими способами. Во-первых, это ограничение объема незавершенной работы. Если у вас сотня заданий, которые выполнены на 10 %, то вероятность появления изменений и прерывания хотя бы одного из потоков работы велика. Однако если сосредоточиться на выполнении одного задания на 100 %, то вам вряд ли придется бросать завершенную работу. Аджайл ограничивает объем незавершенной работы, разбивая ее на короткие спринты, часто продолжительностью не более двух недель, с целью поставки работоспособного продукта в конце каждого цикла. Это не означает, что проект выполняется за две недели, но какая-то его часть становится работоспособной в конце каждого спринта, а не остается незавершенной в течение длительного времени.

Короткие циклы обеспечивают высокую адаптируемость. При появлении изменений их можно учесть в будущем спринте, поскольку команда не привязана ни к чему, кроме текущего спринта. Большинство спринт-команд проводят ежедневные летучки, на которых можно обсудить изменения и скорректировать планы на день. Подобное очень тесное сотрудничество с участием одной небольшой команды и менеджера по продукту облегчает работу с изменениями. Вместо того, чтобы перекладывать работу на других и защищаться от меняющихся требований, здесь происходит обратное. У команды единое понимание задания, и поэтому она чаще поддерживает изменения, а не сопротивляется им. Это цельный процесс, выстроенный с прицелом на гибкость, т. е. на внесение изменений.

Разделение работы на части по ходу дела

Вторая идея заключается в разбивке работы по мере ее выполнения на управляемые, предсказуемые и реализуемые единицы. В отличие от каскадного метода, где работа распределяется по строкам календарного графика (иногда растянутым на годы) до ее начала на основании неполного набора допущений, методология аджайл предполагает создание управляемых единиц работы, которые реализуются быстро и только в пределах текущего спринта. Такой процесс позволяет сделать каждый элемент работы предсказуемым по объему и времени, придавая высокую степень уверенности в его выполнении. Само по себе это необязательно обеспечивает уверенность в выполнении большого многолетнего проекта, но позволяет строить большой проект на основе множества небольших интервалов с высоким уровнем уверенности. Это может показаться не таким уж и хорошим выходом, но он лучше, чем альтернатива – создание большого рискованного проекта на основе множества более мелких рискованных проектов.

Если вам нужно пробежать милю, позаботьтесь о том, чтобы каждый шаг был выполнен хорошо. Важно, чтобы результатом каждого спринта было работоспособное ПО. Именно поэтому многие команды внедряют практику «демоспринта» – демонстрацию в последний день спринта результатов своей работы, создавая культурное подкрепление этого ключевого принципа методологии аджайл. Демоверсии позволяют показать умение разбивать работу на части и выполнять ее в спринте. При отсутствии работоспособного ПО они и не могут его продемонстрировать, что создает стимул для улучшения ситуации в следующих спринтах.

Как вы понимаете, точная оценка объема работы, необходимой для реализации функциональности в ПО, – это искусство, которое мы пытаемся превратить в науку с помощью аджайл-практики. И это – командная работа. Вновь сформированная команда нередко не очень хорошо умеет точно предсказывать свою производительность. Ее знание кодовой базы (если это существующий проект) или проблемной области (если это новый проект) часто неполное, поэтому в оценку объема работы, необходимой для реализации задания, вкрадываются ошибки. Но со временем, по мере роста знаний о кодовой базе и проблемной области, точность оценки повышается.

Команды часто используют такой абстрактный показатель, как «пункты истории», чтобы оценивать и постоянно улучшать предсказуемость и результативность своих спринтов. Он характеризует объем работы по реализации заданной функциональности, а также какого результата команда может достичь в спринте. По мере повышения точности прогнозирования объема работы и производительности в пунктах истории предсказуемость работы команды растет. Как только команды определят свой базовый уровень, они могут сосредоточиться на получении большего числа пунктов истории в спринте и, таким образом, повышать эффективность и производительность. Учтите, что пункты истории являются абстрактным показателем – они не основаны на каком-либо жестком количественном измерении, таком как строки написанного кода, и поэтому не могут использоваться для сравнения с другими компаниями или командами. (Кстати, строки написанного кода – это ужасный показатель, о котором вы никогда не должны заботиться, ведь «меньше – это больше», когда дело доходит до хорошего кода.) Все, что вас должно интересовать как стороннего наблюдателя, – это обеспечивают ли пункты истории более высокую предсказуемость и производительность команде. Не заморачивайтесь вопросом, почему оценка одной команды 100 пунктов, а другой – только 50. Если они не откалибровали свое определение пунктов, что делается редко, то это небо и земля. Вам нужно смотреть на то, становится ли со временем каждая команда более продуктивной с точки зрения пунктов истории. Если год назад они набирали в среднем 100 пунктов за спринт, а сейчас – 150, то, значит, они стали на 50 % эффективнее. Лучшие команды делают более предсказуемую и качественную работу, а подсчет пунктов истории дает лидерам возможность оценивать прогресс своих команд.

Еще одно преимущество разделения работы на части и получения готового фрагмента кода