Что такое Agile

Agile (англ. – проворный) – это семейство «гибких» подходов к разработке программного обеспечения.

Опубликовано
Аджайл Гибкие методологии Методология разработки ПО

Многим до сих пор непонятно это слово . Давайте разберёмся и поймём, что это не страшно, а даже классно и полезно.

Эджайл – не методология!

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

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

Достаточно точно водопадный подход описывает метафора автономной подводной лодки, которая уходит в плавание в Северный Ледовитый океан. Внутрь загрузили команду, продукты, всё необходимое, отдано боевое задание. Всё готово, инструктаж проведён, люки задраены, и лодка ушла под лёд на 3 месяца. И она там что-то делает-выполняет безо всякой связи с внешним миром. Через 90 дней экипаж прибывает обратно и отчитывается о проделанной работе.

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

Нам проще и быстрее понять, что нужно сделать по-другому.

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

Мы привыкли мыслить водопадными проектами.

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

Концепция Эджайл предлагает: «Давайте не тянуть до последнего, чтобы увидеть результат, а будем действовать разумно. Разобьём всю длину проекта на недельные интервалы, будем создавать план работы на будущий отрезок, выполнять поставленные задачи и смотреть, что получилось. А потом принимать решение, куда двигаться дальше».

Совсем не обязательно в конце одной маленькой итерации отдавать клиенту что-то работающее. Смысл в получении обратной связи. Можем показать просто упаковку без продукта внутри. За счёт отклика клиента появится множество возможных вариантов что-то исправить. И за те же деньги заказчик получит результат в разы лучше, чем при классическом способе работы. Он останется крайне доволен соотношением «стоимость-качество», а вы заслужите репутацию достойной фирмы.

Поговорим о некоторых тонкостях внутри Agile

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

Вот кейс на примере реальной жизни. Промышленной IT-компании нужно было создать интернет-магазин сопутствующих товаров, а они никогда такого не делали. Каким бы был ваш первый шаг?

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

Стоит также упомянуть структурную составляющую проекта.

В традиционной команде есть руководитель проекта, который за него отвечает. У него есть исполнители, которым нужно раздать задачи: что и в каком объёме сделать. Но не существует управленцев, которые могут создать идеальный план, который будет точь-в-точь совпадать с реальностью.

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

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

У команды должен быть тот, кто её вдохновляет, направляет к цели и говорит, куда и зачем они идут. В Agile-сообществе он часто называется Product Owner (владелец продукта). С ним "люди-руки" становятся "людьми-головами". И для них владелец создаёт такие условия, в которых они могут договариваться. Никто в Эджайле не отменяет бюджеты проекта, его сроки. Пусть люди ежедневно встречаются по 10 раз и решают, кому и чем лучше заняться сейчас, чтобы был максимальный результат.

У эджайл-команды чаще возникают неорганизационные вопросы.

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

Представьте, что нужно внедрить SAP (автоматизацию бизнес-процессов) и получить на выходе какую-то бизнес-ценность: уменьшить количество ошибок или операций.

Как мы привыкли поступать?

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

Как применить эджайл в этом случае?

Очень просто! Есть огромное количество бизнес-процессов, которые можно автоматизировать. Мы даём подрядчику недельный план, в котором указываем, что наиболее важно в данный момент. Если процесс нельзя автоматизировать за неделю целиком, то мы попросим показать маленькую его часть. Чтобы мы могли пригласить конечных пользователей этой системы, а они могли сказать, подходит им это или нет.

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

Как быть, если не хватает бюджета на единовременный контракт?

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

Почему это сложно сделать в крупной компании?

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

Например, мы эджайл-команда. Мы понимаем, что получим согласование на разработку продукта через 2 недели. Тогда пытаемся командно придумать, как получить одобрение быстрее. Как правило, есть возможность ускорить реализацию за счёт личных взаимоотношений. Поверьте, это возможно сделать и в Сбербанке, и в Газпроме – компаниях с очень сильной бюрократией. "Люди-руки" получат ответ только через 2 недели, поэтому они не могут конкурировать в эффективности с "людьми-головами".

Как же переходить на новый подход?

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

В Сбербанке было так: Герман Греф однажды пришёл в офис и прокричал «Всем эджайл!». Идея отличная, только люди были к ней не готовы. Поэтому процесс её внедрения сильно растянулся и сейчас почти не двигается. Лучше, когда есть пилотные команды внутри организации. Они начинают работать по-другому и заражают этим методом всех остальных.

Но есть и обратная сторона. Корпоративная культура ест эджайл-процессы на завтрак, как говорится в поговорке. Поэтому нужна сильная поддержка менеджмента.

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

Эджайл – история про здравый смысл, а не про регламентированность.

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

Самый большой минус Эджайла

Удалённость, она мешает коммуникациям. «Но мы же живём в мире быстрого и безлимитного интернета!» - можете возразить вы. Опираясь на наш опыт, заявляем - это всё равно хуже. Причём удалённость даже в масштабе двух этажей и соседних комнат уже снижает эффективность. Если люди находятся далеко от вас, то они становятся странными и неясными для нас, даже если это друзья-сотрудники из другого филиала. Появляется недопонимание. А когда они сидят рядом с нами - они часть нашей команды, мы видим их деятельность, они "свои".

Подведём итог

Эджайл-философия подходит вашей компании, если:

  • над проектом работает опытная, высококвалифицированная команда
  • вы работаете над стартапом
  • нужно быстро получить рабочую версию продукта
  • заказчик выступает в качестве партнёра, а не инвестора
  • продукт разрабатывается в сфере, подверженной постоянным изменениям

И не подходит, если:

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

Главный пункт здесь – бюджет. Нам кажется, что мы тратим чуть больше денег, чем при классическом подходе. Но это лишь кажется, поверьте. На деле же мы получаем продукт, который нас удовлетворяет на 120%. И в итоге мы даже экономим!

open_in_new Кратко: что такое Agile
YouTube Имми Йалиан
open_in_new Что скрывает Agile
YouTube Дмитрий Лобасев
group 3 equalizer 5