SCRUM в России, как и на территории всего бывшего СССР, стал самой популярной методологией разработки ПО не только среди любых «гибких» вариаций и даже среди всех итерационных производственных парадигм. И, действительно, с 2013 года научные исследования консультантов SSC последовательно показывают:

• SCRUM наращивал свою востребованность и с 2017 года явно доминирует среди «гибких» методологий: часть из них (вроде XP) не вызывают энтузиазма в крупных организациях, часть из них (например, KANBAN) вообще не внедрены нигде, кроме как посреди субъективных ощущений отдельных генеральных директоров отдельных web‑студий;

• SCRUM к 2020 году стал основной методологией разработки для лучших российских софтверных вендоров, как для обеспечения критериев качества продукта, так и с точки зрения оптимизации продуктивности и загрузки команд.

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

Безусловно остаются целые области российской IT‑отрасли, в которых инженеры ничего не знают про SCRUM, но будем честны: они ничего не знают и в целом о программной инженерии 20-х годов нашего века, а их программное обеспечение могло быть создано 20 и даже 30 лет назад: ведь это те же самые задачи автоматизации для самолетов, ракет и станков, которые и сами превосходно «помнят» 20-й век. Коммерческая разработка выбрала SCRUM‑методологию и последовательно преодолевает разнообразные сложности этой парадигмы. Одна из регулярно возникающих задач — это необходимость снижать себестоимость команды в «тяжелые» для бизнес‑заказчиков времена.

Вместе с этим, парадигма SCRUM‑разработки ПО эволюционно развивается в высоком темпе: появляются новые методы и подходы к оптимизации трудозатрат в развитии продуктов, к росту продуктивности и вовлеченности инженеров, к повышению разнообразных качественных параметров программных продуктов (UX, LTV, time‑to‑market, т.д.). В данной заметке выделен лишь один подход в сокращению бюджетов проектных команд разработки ПО, а именно: оптимизация ролей в SCRUM‑команде. Мотивы для такой оптимизации обычно противоположены:

• количество сотрудников в проекте превышает обычные представления о SCRUM‑команде в 7–9 человек (нужно раздать роли и\или сократить команду);

• команда не укомплектована полностью: часть ролей необходимо совместить или вообще отказаться от них.

Проведение оптимизации ролей команд необходимо начинать с самого универсального. К счастью, эти общие рекомендации давно разработаны практиками IT‑отрасли. Так, например, рекомендации консультантов SSC, основанные на солидном проектном опыте, могут быть сформулированы следующим образом:

• scrum‑мастер — это не самостоятельная роль, это текущий участник проектной команды, выполняющий ежедневную работу: найдите лидера, который совместит эту роль со своею;

• тимлид, техлид, архитектор — только одна из данных ролей оплачивается бюджетом проекта на 100%. Нужно искать правильную роль или баланс их частичного участия;

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

Прежде всего, забудьте эту книжку десятилетней давности Геоффа Ваттса про служение scrum‑мастера своей команде, потому что мастер — это не проводник в мир «гибких» технологий, не хранитель знаний, ни даже менеджер, который запланирует спринт или проведет дейлик. Это статья в расходах вашего проекта, в редких случаях — ступенька в карьере хорошего инженера до «правильной и полезной» роли. Поэтому сразу определим: лидер одного из направлений в проекте — тимлид, ведущий аналитик, ведущий QA инженер и даже ПМ — могут быть scrum‑мастер безо всяких сложностей. Поэтому определите scrum‑мастера из числа текущих лидеров команды разработки таким образом, чтобы эта роль в проектной команде не несла дополнительных издержек для проекта.

Единственное исключение в практике консультантов SSC можно охарактеризовать следующим кейсом: в коллективе IT‑предприятия (с 25+ лет опыта отрасли) более 80% инженеров не имеют никакого опыта работы в парадигме SCRUM, при этом медиана карьеры в отрасли разработки ПО превышает 13 лет. Сложные трансформационные процессы в таких случаях будут требовать серьезных усилий в области преодоления организационного сопротивления, что делает экономически возможным привлечение отдельно выделенных scrum‑мастеров в проектах разработки. Во всех остальных случаях: scrum‑мастер — это совмещенная роль, которая доверена одному из лидеров проекта или его руководителю.

Однако, бюджет проекта можно сократить еще сильнее, если это нужно. Например, тимлид, техлид и архитектор — это сколько FTE (целых человек) для среднего SCRUM проекта? Лучшие ПМ говорят, что это один и тот же лидер разработки ПО для команды до 10 человек в проектах длиною в 6–9 месяцев. Нам кажется правильным в усредненных случаях (SCRUM команда проекта до 10 человек) сократить эти три роли до одного‑двух человек (1,5 FTE). Ключевая роль — тимлид, он аллоцирован на 100% и выполняет все типичные функции лида. Далее рассмотрим аллокацию архитектора: масштабы проекта (а не только бюджет) могут требовать привлечения solution‑ и даже enterprise‑архитектора. Однако, в оцениваемом горизонте полугода его вовлечение вряд ли займет более 0,5 FTE. И наконец, техлид — это та роль, которой следует прежде всего пожертвовать в проекте, который испытывает бюджетные ограничения. Вместе с этим роль техлида чрезвычайна важна при масштабировании разработки, особенно при использовании проприетарных технологий и сложных интеграций между проектами. Для более масштабных по количеству инженеров методологий разработки ПО (Scrum of Scrum, SAF) техлиды обеспечивают необходимую технологическую поддержку слаженности разработки ПО несколькими командами и соответствие получаемого программного продукта всем нефункциональных требованиям.

И наконец, последний подход к оптимизации состава проектной команды в виду ограничений по бюджету — это изменение бюджетирования DevOps‑инженеров (и похожих ролей, вроде сисадминов, инженеров сред, инженеров по автоматизации разработки ПО и т. п.). Выделение таких инженеров во внутренние службы, которые оказывают свои сервисы по внутренней цене компании, — это небыстрый, но эффективный вариант оптимизации бюджетов ваших проектов разработки. Конечно, каждому ПМ и тимлиду хотелось бы иметь выделенного инженера на среды, CI\CD и прочее, но более перспективным с точки зрения оптимизации затрат на проекты кажется комплексная автоматизация этих регулярных потребностей силами выделенных DevOps‑служб внутри софтверной компании. Безусловно такая трансформация несет в себе определенные риски, связанные с оперативностью решения инфраструктурных проблем в проекте, кроме того, в некоторых компаниях снижается глубина погружения DevOps‑инженеров в проблемы каждого проекта. Эти риски управляемы: с формальной точки зрения — это SLA и KPI в DevOps‑сервисах, с неформальной — создание хороших рабочих отношений, закрепление инженеров за зонами ответственности (например, по технологическим стекам или проектам).

По нашему мнению, данные оптимизации сокращают расходуемый бюджет в среднем SCRUM проекте (до 3 FTE при удачном распределении усилий). Также это позволяют увеличить управляемость бюджетом проекта, перенаправив дополнительные средства на усиление необходимых позиций вместо тех, что уже сложились из‑за устоявшихся привычек IT‑компании. При этом модификация данных рекомендаций (как показывает проектных опыт SSC) позволяет добиться оптимизации бюджета и в более масштабных проектах, где методология разработки ПО (например, SAF) подразумевает одновременное слаженное участие десятков специалистов.