Термины и общий смысл
В начале разберемся с терминологией.
Гибкая методология разработки (Agile) — это общий термин для множества подходов разработки, которые основаны на манифесте Agile.
SCRUM — это один из таких подходов. Еще, к примеру, есть Kanban, о котором вы, скорее всего, тоже слышали.
Манифест, на котором базируется Agile, придумали в 2001 году. Он состоит из 4 ценностей и 12 принципов. Не будем его копировать полностью в данный материал, его можно прочитать, например, в википедии. Основная суть: выдаем промежуточный результат, пригодный для работы, как можно быстрее, итерациями. Документация и контракты на разработку во вторую очередь. Важнее внести изменения в продукт, если это нужно заказчику. Требования к команде: безусловно высококлассные профессионалы, которые способны самоорганизоваться, и которым не нужен дополнительный контроль.
В манифесте нет ни слова про принципы формирования бюджета проекта.
Принципы формирования стоимости работ по Scrum
Мы будем сравнивать Scrum с классическим подходом.
Напомним, классический подход — это, чаще всего, поэтапная работа над реализацией технического задания.
Что означает данное изображение?
Scope — это объем работ. В случае классического подхода вы обращаетесь к команде разработчиков с объемом задач, которые необходимо реализовать (Scope). В ответ вы получаете цену и сроки.
В Agile же наоборот. На предложенный вами бюджет и сроки команда разработчиков сообщает, какой объем задач получится реализовать. Сложно для понимания, но чаще всего это бывает так: вы говорите, что необходимо реализовать, в ответ команда говорит вам, что "1 месяц работы нашей команды стоит ХХХ рублей, за этот срок мы обычно реализовываем следующий объем задач".
Кому подходит Scrum?
Мы считаем, что Scrum подходит в случае, если вам непрерывно нужно улучшать продукт. Специалисты, которые будут задействованы на проекте, могут находиться как у вас в штате, так и в организации, которая окажет вам такие услуги. Но платить вы будете ежемесячно за команду. В методологии Scrum все специалисты, задействованные на проекте, должны заниматься только (!) вашим проектом.
Напротив, в случае классического подхода, если для проекта понадобился на короткий срок какой-то редкий специалист, то его не обязательно переводить на full-time работу над проектом. Он может обслуживать потребности нескольких проектов.
Простой опросник применимости Scrum
У вас есть техническое задание на весь продукт или вы считаете, что задание можно подготовить совместно с исполнителем?
- Да — скорее всего, классический подход;
- Нет — возможно, Scrum.
Вам необходимо зафиксировать стоимость и сроки разработки?
- Да — скорее всего, классический или гибридный подход;
- Нет — возможно, Scrum.
Вы хотите нанять специалистов в штат и заниматься гибким развитием продукта?
- Да — скорее всего, Scrum;
- Нет — возможно, классический подход.
Плюсы и минусы Scrum и классического подхода
| Методология | Плюсы | Минусы |
|---|---|---|
| Классический подход | Централизованный контроль. Управление сроками и рисками. Управление по отклонениям | Бюрократизация и избыточный формализм. Потеря актуальности детальных планов.Невовлеченность команды в дела проекта. |
| Scrum | Высокая вовлеченность команды. Децентрализованное принятие решений. Быстрые итерации и учет обратной связи | Слабое управление сроками и рисками. Потеря контроля для сложных проектов. Низкая эффективность для временных команд и мультипроектного режима работы. |
Исследование: почему не взлетает чистый Agile?
В Канаде в 2021 году провели исследование: были опрошены 296 респондентов, которые описали 477 проектов из разных индустрий. Из этого числа 52% оказались гибридными, 33% классическими и 15% Agile.
Причины, почему не взлетает чистый Agile:
- Требования правительства и регуляторов (как вы думаете, как отнесется счетная палата РФ к госконтракту, который будет выполняться по методике Agile?);
- Требования надежности и безопасности;
- Требования к оформлению документации;
- Установленные границы по срокам и бюджету;
- Управление большими комплексными проектами (что бы это не значило).
Что советуем мы?
Если вам необходимо получить продукт в прогнозируемые сроки с гарантированным бюджетом, и вы представляете, какой функционал вам нужен, то разработку минимальной жизнеспособной версии продукта (MVP) стоит вести классическим подходом.
Первым этапом работы будет аналитика, написание технического задания и прототипирование системы. Эту работу выполняет команда разработчиков совместно с заказчиком.
Следующий этап — это оценка точной стоимости разработки и непосредственно работа по заданию. К примеру, мы для разработки применяем методику контрольных точек, о которой расскажем в одной из следующих статей. Да, минусом является то, что в процессе разработки нет достаточной гибкости в подходе, и любые изменения задания необходимо дополнительно согласовывать.
Когда MVP будет разработан, то, скорее всего, у вас появятся идеи по поводу развития проекта. Можно использовать:
- Классический подход с этапом аналитики и техническим заданием под каждый объем задач. 80% наших клиентов выбирают этот способ.
- Гибридные методологии разработки, которые основаны на классическом подходе, но с некоторыми принципами гибких методик. Например: частая поставка готового продукта, активное вовлечение заказчика, минимум согласований и документов, и другие. Порядка 20% наших клиентов выбирают подход Time&Materials для развития своих проектов.
- Scrum. Но в этом случае заказчик должен полностью доверять команде разработки, либо собирать команду в своем штате.
Для подготовки статьи использовался собственный опыт и материалы с курса "Управление проектами" Павла Алферова ( https://www.alferov.expert/ )