Наладьте работу своих сотрудников с помощью Agile

По данным исследования компании Digital.ai, в 2021 году 86% команд разработчиков программного обеспечения используют Agile-методики. Также, по данным ежегодного отчёта Scrumtrek, 33% финансовых компаний активно пробуют приёмы Аджайл-технологии. В этой статье мы расскажем, что же это такое и почему популярно.

Что такое Аджайл простыми словами

Agile часто называют методологией планирования рабочих процессов. Это неверно. Понятие «методологии» подразумевает некую совокупность приёмов. Agile не даёт никаких точных алгоритмов действий. Agile ― это философия гибкого подхода к созданию продукта. Основная идея подхода в постоянном совершенствовании продукта и активном получении фидбека от заказчиков и клиентов. Поговорим об этой философии подробнее.

Как появился Agile и какие ценности он продвигает

Agile родился в головах IT-специалистов. К 2000-м годам программирование начало активно развиваться. Система создания ПО обросла огромной документацией и длинным путём к созданию готового продукта. Стало ясно, что в индустрии нужно что-то менять. Нужны качественно новые практики организации рабочих процессов. С конца 90-х годов программисты со всего мира делились своими идеями. Уже в то время родилась теория экстремального программирования, о которой мы ещё поговорим подробнее. Но знаковой оказалась встреча в 2001 году, которая и положила начало новой философии.

11-13 февраля 2001 года группа программистов в очередной раз решила собраться для обсуждения проблем. Местом встречи они выбрали горнолыжный курорт Snowbird в горах Уосатч в штате Юта. Они собрались не только покататься на лыжах, отдохнуть, но и общими усилиями найти решения проблем в организации процесса разработки ПО. Из 20 приглашённых приехало 17 специалистов. В результате этой встречи родились не просто идеи нового подхода к программированию, а целый манифест. Тогда же участники и назвали его Agile.

Agile-манифест

Философия Agile, отражённая в манифесте, состоит из 4-х ценностей и 12-ти принципов.

Ценности:

  1. Взаимодействие с людьми важнее рабочих процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее, чем согласование контракта.
  4. Быстрая реакция на изменения важнее первоначального плана.

Создатели манифеста не говорят о том, что нужно отказаться от контрактов и документации. Речь о том, что эти вопросы должны отойти на второй план. Главное ― продукт, его полезность и актуальность.

Принципы:

  1. В приоритете удовлетворение потребностей клиента за счёт поставки ценного ПО.
  2. Требования всегда можно изменить, даже если продукт находится на последней стадии разработки.
  3. Готовый продукт нужно постоянно обновлять.
  4. На протяжении всего проекта разработчики и представители бизнеса должны работать вместе.
  5. Чтобы работа была сделана качественно, сотрудники должны находиться в приятной атмосфере и мотивированы на работу.
  6. Только личное общение способствует эффективной коммуникации.
  7. Показателем прогресса является готовое ПО.
  8. Инвесторы, разработчики и пользователи должны быть в постоянном рабочем ритме. То есть процесс разработки должен иметь устойчивый цикл.
  9. Разработчики должны уделять особое внимание совершенствованию проектирования. Это повышает гибкость проекта.
  10. Простота рабочих процессов является основой. Никакой лишней работы.
  11. Лучшие решения рождаются у самоорганизующихся команд.
  12. Чтобы работа была эффективнее, нужно постоянно анализировать работу и её корректировать.

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

Принцип Agile и его методики

Итак, для чего нужен Agile? В рамках философии Agile появились конкретные методики, которые должны были помочь компаниям улучшить свои рабочие процессы. В список методик для управления продуктами вошли:

  1. Экстремальное программирование (XP).
  2. Kanban.
  3. Scrum.
  4. Бережливое производство (Lean).

Теперь по порядку рассмотрим каждую из этих методик.

Экстремальное программирование, или Extreme Programming

Эта методика появилась раньше манифеста Agile (1990-х годах), но отлично вписалась в концепцию. XP предназначена только для разработки ПО. Оно не может быть использовано в другом бизнесе или бытовых задачах. Главная цель методики ― сделать рабочий продукт быстро. В начале планирования итерации решается вопрос, какой функционал должно приобрести ПО в итоге. На этом планировании обязательно присутствует заказчик. Именно он должен согласовать цель итерации.

Внутри этой методологии есть 12 практик, которые позволяют ускорить программирование. Для примера в XP рекомендуют использовать парное программирование, рефакторинг (оптимизация кода), коллективное владение кодом.

Kanban

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

Scrum

Весь рабочий процесс состоит из коротких итераций ― спринтов. Спринты обычно длятся 1-4 недели. В начале каждого спринта проходит планирование задач. Команды должны быть маленькие не более 10 человек. В команду входят:

  • Product Owner (владелец продукта). Общается с заказчиками и потребителями, планирует задачи.
  • Scrum Master. Анализирует выполненные задачи и ищет способы улучшить процесс работы. Также проводит собрания и решает проблемы в команде.
  • Development Team (команда специалистов). Это вся остальная команда, которая выполняет задачи по созданию продукта. Состоит из специалистов различного профиля.

Для Scrum характерны некоторые специфические правила и мероприятия.

  • Backlog. По сути, это список задач, которые ранжируются по приоритету. Все запланированные задачи команда должна успеть выполнить до конца спринта.
  • Sprint Planning Meeting (планирование спринта). Это собрание, которое проходит в начале спринта. На нём команда просматривает задачи и анализирует, сколько она успеет сделать за итерацию, какие задачи стоит разбить на ещё более мелкие.
  • Daily Scrum meeting (ежедневное собрание). Ежедневное собрание на 15 минут, где каждый член команды отвечает на 3 вопроса:

    • Что я сделал вчера?
    • Что я планирую сделать сегодня?
    • Что мне мешает?
  • Retrospective meeting (ретроспектива). Проводится в конце спринта. На нём обсуждаются результаты выполненных задач, а также каждый член команды делится своим мнением об итерации. На основе высказанного вносятся правки в дальнейшие спринты.

В общем, Scrum продвигает идею небольших забегов. Цель каждого забега ― создать продукт или модернизировать его.

Бережливое производство, или Lean

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

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

Положительные и отрицательные стороны

Гибкий подход к разработке рабочего процесса приводит к некоторым очевидным преимуществам:

  1. Продукты быстрее выходят на рынок. За счёт того, что на рынок выпускается более или менее готовый продукт и только потом дорабатывается, прибыль приходит раньше.
  2. Высокое качество продукта. Из-за постоянно доработки по итогу качество продукта намного выше, чем когда версия продукта выпускается единожды.
  3. Прозрачность работы. Так как и сотрудники, и заказчики, и пользователи постоянно взаимодействуют, весь процесс создания продукта становится прозрачным.
  4. Увеличение прибыли. Так как продукт постоянно совершенствуется, в дальнейшем есть возможность легитимно повышать цену.

Несмотря на продвинутость и всеобщее признание подхода, у Agile есть и недостатки:

  1. Мало предсказуемости. В самом начале проекта трудно понять, сколько времени и ресурсов вы в итоге потратите на разработку продукта. Если команда только переходит к гибкому подходу, это может посеять страх среди сотрудников. Не все готовы оперативно исправлять ошибки и внедрять идеи в продукт.
  2. Много коммуникации. Не все готовы на постоянное и тесное сотрудничество. Чтобы разработчики быстро могли приступить к обновлениям и доработкам, заказчик должен быть доступен 24/7, ревьюить идеи и работу на каждом этапе. Это занимает много времени, и далеко не каждый к этому готов.
  3. Есть риск переделывания работы. В любой момент заказчик или пользователь может в корне изменить свои желания и по правилам Agile нужно будет всё переделывать.
  4. Снижение качества продукта для ускорения выпуска. Пытаясь успеть как можно раньше выпустить продукт, разработчики часто выводят в свет откровенно сырой продукт, который потом собирает негатив от пользователей.

Каким компаниям подходит Agile-подход

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

Для небольших проектов, например, создание рекламного баннера, скорее всего, внедрение сложных технологий не потребуется. Есть ТЗ и понятные этапы работы. Разве что можно создать доску, если проектов несколько. Такой подход добавит наглядности. Однако необходимости внедрения методологий Agile нет.

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

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

Этапы внедрения Agile

  1. Выберите метод. Подробно изучите каждый метод и определите, какой поможет именно вашей команде.
  2. Расскажите всей команде об Agile. Каждый сотрудник должен знать, в чём заключается суть концепции. Проведите обучение всей команды. Если есть возможность, пригласите сторонних специалистов, у которых есть опыт по внедрению Аджаил.
  3. Организуйте процесс. Даже если все сотрудники будут разбираться в Agile-философии, всё равно нужен человек, который возьмёт на себя ответственность организовать процесс. Скорее всего, вам понадобится создать рабочие доски. Это может делать Scrum-мастер или руководитель отдела.
  4. После первых нескольких итераций проанализируйте эффективность налаженной системы. У вас вряд ли с первого раза получится создать идеальную систему. Первое время придётся постоянно перестраивать процессы.

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