skip to main content

Что такое методологии разработки и Agile

js

Кратко 🔗

Компаниям важно быстро проверять гипотезы — отбрасывать неверные и развивать валидные. Процесс разработки программ постоянно изменяется, чтобы лучше соответствовать этим требованиям. Сейчас очень популярны гибкие (agile) методологии. Они концентрируются на человеческом отношении, результате и быстрой доставке ценности конечным пользователям. Главные ценности:

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

Классический подход 🔗

До распространения гибких методологий, типичный процесс разработки программы выглядел всегда примерно одинаково. Заказчик составлял всеобъемлющее техническое задание для команды разработки — сотни и тысячи страниц текста — которое описывало финальный результат в мельчайших подробностях. Команда называла срок, когда все будет готово (обычно годы) и начинала работу.

Этот процесс, по сути, был калькой с процессов других областей — строительства, создания электроники, производства. Но у него было несколько серьезных проблем:

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

Принципиальное устройство классического подхода

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

В феврале 2001 года 17 независимых экспертов в области управления разработкой опубликовали «Манифест гибкой разработки программного обеспечения». Основные принципы, описанные в документе:

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

Это положило начало бурному развитию гибких методологий. Сейчас почти все IT-компании придерживаются принципов гибкой разработки программ.

Методологии 🔗

Agile (читается «эджайл») — набор принципов и ценностей, описанных в манифесте. На основе этих принципов создано много разных фреймворков и систем, два самых популярных — SCRUM и Kanban.

SCRUM 🔗

SCRUM (читается «скрам») — один из самых популярных гибких методов управлениям проектами. Впервые он был описан в 1986 году, но стал широко применяться только в начале 2000-х.

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

После груминга команда совместными усилиями планирует итерацию разработки продукта с жестко заданной длительностью (обычно от 1 до 4 недель), в которую попадают задачи из бэклога с наивысшим приоритетом. Такие итерации называют спринтами.

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

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

Многие команды считают SCRUM излишне нагружённым и модифицируют его под свои нужды — берут одни концепции и отказываются от других. Другие наоборот, следуют всем правилам и часто нанимают (или обучают) специального человека, который следит за соблюдением всех правил — SCRUM мастера.

Kanban 🔗

Канбан появился сильно раньше, чем другие гибкие методологии. Его придумали в Toyota в 1960-х годах и изначально применяли к производству автомобилей. С начала 2000-х канбан перекочевал в индустрию разработки программ и применяется многими командами.

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

Пример канбан-доски

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

Использование канбана позволяет легко искать «бутылочные горлышки» в процессе разработки — если задачи скапливаются на этапе «Готово к разработке», значит это и есть узкое место всей команды. С другой стороны, канбан обеспечивает прозрачность прогресса проекта для всей команды.

Не серебряная пуля 🔗

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

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

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