Scrum для заказчика: почему вам, скорее всего, не подойдет гибкий подход в разработке IT-продукта

В начале разберемся с терминологией.

Гибкая методология разработки (Agile) — это общий термин для множества подходов разработки, которые основаны на манифесте Agile.

SCRUM — это один из таких подходов. Еще, к примеру, есть Kanban, о котором вы, скорее всего, тоже слышали.

Манифест, на котором базируется Agile, придумали в 2001 году. Он состоит из 4 ценностей и 12 принципов. Не будем его копировать полностью в данный материал, его можно прочитать, например, в википедии. Основная суть: выдаем промежуточный результат, пригодный для работы, как можно быстрее, итерациями. Документация и контракты на разработку во вторую очередь. Важнее внести изменения в продукт, если это нужно заказчику. Требования к команде: безусловно высококлассные профессионалы, которые способны самоорганизоваться, и которым не нужен дополнительный контроль.

В манифесте нет ни слова про принципы формирования бюджета проекта.

Мы будем сравнивать Scrum с классическим подходом.

Напомним, классический подход — это, чаще всего, поэтапная работа над реализацией технического задания.

Что означает данное изображение?

Scope — это объем работ. В случае классического подхода вы обращаетесь к команде разработчиков с объемом задач, которые необходимо реализовать (Scope). В ответ вы получаете цену и сроки.

В Agile же наоборот. На предложенный вами бюджет и сроки команда разработчиков сообщает, какой объем задач получится реализовать. Сложно для понимания, но чаще всего это бывает так: вы говорите, что необходимо реализовать, в ответ команда говорит вам, что "1 месяц работы нашей команды стоит ХХХ рублей, за этот срок мы обычно реализовываем следующий объем задач".

Мы считаем, что Scrum подходит в случае, если вам непрерывно нужно улучшать продукт. Специалисты, которые будут задействованы на проекте, могут находиться как у вас в штате, так и в организации, которая окажет вам такие услуги. Но платить вы будете ежемесячно за команду. В методологии Scrum все специалисты, задействованные на проекте, должны заниматься только (!) вашим проектом.

Напротив, в случае классического подхода, если для проекта понадобился на короткий срок какой-то редкий специалист, то его не обязательно переводить на full-time работу над проектом. Он может обслуживать потребности нескольких проектов.

У вас есть техническое задание на весь продукт или вы считаете, что задание можно подготовить совместно с исполнителем?

• Да — скорее всего, классический подход;
  
• Нет — возможно, Scrum.

Вам необходимо зафиксировать стоимость и сроки разработки?

• Да — скорее всего, классический или гибридный подход;
  
• Нет — возможно, Scrum.

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

• Да — скорее всего, Scrum;
  
• Нет — возможно, классический подход.
  

В Канаде в 2021 году провели исследование: были опрошены 296 респондентов, которые описали 477 проектов из разных индустрий. Из этого числа 52% оказались гибридными, 33% классическими и 15% Agile.

Причины, почему не взлетает чистый Agile:

• Требования правительства и регуляторов (как вы думаете, как отнесется счетная палата РФ к госконтракту, который будет выполняться по методике Agile?);
  
• Требования надежности и безопасности;
  
• Требования к оформлению документации;
  
• Установленные границы по срокам и бюджету;
  
• Управление большими комплексными проектами (что бы это не значило).
  

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

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

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

Когда MVP будет разработан, то, скорее всего, у вас появятся идеи по поводу развития проекта. Можно использовать:

• Классический подход с этапом аналитики и техническим заданием под каждый объем задач. 80% наших клиентов выбирают этот способ.
  
• Гибридные методологии разработки, которые основаны на классическом подходе, но с некоторыми принципами гибких методик. Например: частая поставка готового продукта, активное вовлечение заказчика, минимум согласований и документов, и другие. Порядка 20% наших клиентов выбирают подход Time&Materials для развития своих проектов.
  
• Scrum. Но в этом случае заказчик должен полностью доверять команде разработки, либо собирать команду в своем штате.