Гибкие методологии Agile

Введение в урок

В этом уроке вы узнаете подробнее, что такое гибкие методологии, какие идеи лежат в их основе и для каких проектов они подходят.

Даня

Нашей команде могли бы подойти гибкие методологии?

Артём

Сейчас нет. Мы хотим выпустить веб-приложение через 150 дней и знаем, какие функции нужны в первой версии продукта. Нам удобнее работать по плану, чтобы уложиться в сроки.

Даня

А после запуска веб-приложения?

Артём

Вот после запуска мы сможем работать без плана на длительный срок. У нашей команды не будет жёстких дедлайнов, и мы сосредоточимся на запросах пользователей.

Гибкие методологии разработки (Agile software development) — это совокупность подходов к разработке программного обеспечения, которые основаны на ценностях Манифеста гибкой разработки (Agile Manifesto). В нём также содержатся 12 принципов, дополняющих правила по разработке программного обеспечения.

Наиболее популярные подходы в группе гибких методологий — Scrum и Kanban. Многие компании используют их для организации работы своих команд. Кроме них, к гибким методологиям относятся экстремальное программирование, функционально-ориентированная разработка и другие.

Гибкие методологии пришли в разработку ПО, когда стало понятно, что классические методы управления не подходят для ситуаций, где нужно быстро принимать решения и менять продукт по ходу работы. Гибкость в таких методологиях обеспечивает то, что команда разработки создаёт продукт не целиком, а по частям, фокусируясь только на самом важном.

Agile позволяет команде не планировать разработку сильно наперёд и не требует от неё предсказать, сколько времени займёт та или иная задача. Так участники команды не обещают заказчику то, чего не смогут выполнить, и не делают то, что ему уже не нужно. Agile-манифест описывает не только как вести разработку ПО, но и то, как должна выстраиваться коммуникация в команде, на какие ценности она должна опираться.

Основные ценности, на которых строится любая методология из группы Agile:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

На практике командам, которые работают по принципам гибких методологий, не всегда удаётся следовать заветам Agile. Это скорее идеал, к которому им нужно стремиться. Но важно и не забывать, что методология адаптируется к обстоятельствам, а не обстоятельства подстраиваются под методологию.

Люди и взаимодействие важнее процессов и инструментов

Самое важное в команде — люди, из которых она состоит. Ни хорошие инструменты, ни удачно выстроенные процессы не имеют смысла без людей. Поэтому важно сначала подумать, как участникам команды было бы удобно решать свои рабочие задачи, а потом уже искать подходящие инструменты и процессы — они не должны стать бременем.

Например, вы с друзьями собрались дома для просмотра фильма. Нужно выбрать, что вы будете смотреть. Тут есть несколько вариантов:

Кто-то лично примет решение.
Каждый предложит своё.
Вы воспользуетесь функцией shuffle («перемешать»), которую предлагают многие стриминговые сервисы, — она включит случайный фильм из медиатеки.

Сработать может любой из вариантов, главное — обсудить его с друзьями: возможно, кто-то не захочет участвовать в обсуждении и готов смотреть любой фильм, у кого-то уже есть свои соображения. Как вы придёте к цели, не так важно, главное, чтобы в процессе всем было комфортно.

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

Спрошу у коллег, что делать в такой ситуации, было ли у них такое в команде, и последую их примеру.

Установлю ежедневную встречу с дизайнером, чтобы подробно и регулярно обсуждать с ним правки.

Поделюсь с дизайнером своим беспокойством, обсужу с ним, как можно улучшить совместную работу.

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

Работающий продукт важнее исчерпывающей документации

Одно из важных качеств хорошего продукта — соответствие потребностям пользователей. В командной работе этот фокус нередко теряется, участники сосредотачиваются на выполнении своих обязанностей. Системные аналитики, например, могут сконцентрироваться на подготовке технического задания или документации и забыть про работу над ценностью приложения для пользователя. В этом случае страдают и пользователи, и приложение, поэтому важно искать баланс между подготовкой документации и созданием ценности для пользователя.

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

Представьте, что вы с командой разрабатываете новую функциональность приложения. После релиза пользователи получают дайджест изменений в продукте. Обычно дайджест готовят заранее, чтобы разослать его одновременно с релизом обновления, но в этот раз копирайтер не успел закончить текст. Что будете делать?

Попрошу отложить релиз новой функциональности до тех пор, пока не будет написан дайджест.

Узнаю у копирайтера, сколько времени ему нужно, чтобы закончить работу над дайджестом. Если задержка не будет большой, попрошу выпустить релиз раньше рассылки.

Предположим, копирайтеру нужен ещё день или два. Вы договариваетесь с остальной командой, что выпустите релиз до рассылки дайджеста, который отправите, как только он будет готов. Так вы не отступите от главной цели продукта — решение задач пользователей, закрытие их потребностей — и позволите автору качественно доработать текст.

Попрошу копирайтера работать всю ночь, чтобы успел дописать дайджест.

Сотрудничество с заказчиком важнее согласования условий контракта

Работая в команде, можно достигать бОльших результатов, чем в одиночку. То же справедливо для тандема команды разработки и заказчика. При вовлечении заказчика команда разработки лучше понимает его требования, делает именно то, что нужно, а заказчик всегда знает, как продвигается разработка, и может внести правки. Так работа команды становится более прозрачной и понятной для заказчика, а он, в свою очередь, становится соучастником процесса создания ПО.

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

Вы системный аналитик и взяли в работу крупную задачу. На встрече с заказчиком тот устно описал, что хотел бы получить по итогу её выполнения. Нужно начать формировать требования. Как будете работать?

Отдельно пообщаюсь с заказчиком, чтобы зафиксировать все его требования, предложу составить план регулярных встреч, на которых будем обсуждать, как продвигается разработка, покажу заказчику промежуточные результаты работы, чтобы он мог их оценить и скорректировать, если нужно.

Отдельно пообщаюсь с заказчиком, зафиксирую требования и отправлю их на ревью заказчику, чтобы он подтвердил, что именно эти доработки нужно внести.

Опишу задачу со всеми требованиями, которые были озвучены устно на общей встрече.

В этом случае, скорее всего, всё придётся переделывать. Вы не стали отдельно собирать требования с заказчика, согласовывать их и сразу приступили в работе. Когда задача ушла на этап разработки, заказчик вернулся с вопросами и выяснилось, что вы по-разному поняли одну и ту же задачу. Не стоит надеяться на то, что заказчик разом выдаст вам все требования к продукту, их нужно фиксировать и обсуждать, чтобы ничего не терялось на более поздних этапах.

Готовность к изменениям важнее следования первоначальному плану

Поскольку главная задача продукта — закрыть потребности пользователей, команде необходимо постоянно задаваться вопросами: «Делаем ли мы то, что нужно? Соответствуют ли наш продукт и наши решения текущим потребностям пользователей?»

Благодаря тому, что продукт обновляется по частям, а не сразу, команда разработки получает от пользователей обратную связь и с каждой новой итерацией знает об их потребностях больше, чем в начале работы. Изменения важны для продукта, и нужно готовить себя к ним, ведь мир и обстоятельства меняются. Не заковывайте себя в рамки строгих планов и целей, чтобы продукт не оказался ненужным или нерелевантным потребностям пользователей.

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

Возьму в работу задачу про оповещения преподавателей о новых заказах, не стоит отвлекаться на другие задачи, возможно, проблема не так велика.

Займусь проблемой, о которой сообщают пользователи, — их обращения выглядят серьёзно.

Устрою встречу с командой и заказчиком, поделюсь своими наблюдениями, предложу пересмотреть приоритеты и принять совместное решение о том, что сейчас важнее для продукта.

Обсуждение — важный ключ к решению проблем. Вы введёте в курс дела команду и заказчика и после мозгового штурма совместно найдёте решение, которое позволит и решить проблему пользователей, и закрыть задачу с оповещениями. Например, на почту преподавателей будут приходить не только оповещения о новых заказах, но и сообщения с напоминанием обновить доступные часы в сервисе.

Выберите из перечисленного вариант ответа, который не описывает ценности Agile.

Готовность к изменениям важнее следования первоначальному плану.

Скорость поставки ценности важнее качества реализации.

Всё верно! Нет такой ценности в Agile. Команды, которые используют гибкие методологии в работе, должны стремиться к высокой скорости поставки ценности для пользователей, но не должны пренебрегать качеством, иначе пользователи просто не смогут использовать наш продукт для решения своих задач.

Сотрудничество с заказчиком важнее согласования условий контракта.