Разработчики и самоуправление в Scrum
Узнайте, как Разработчики применяют принципы самоуправления в Scrum. Разберитесь, за что они отвечают, как планируют Спринты и почему техническая автономия приносит ощутимые результаты.
Большинство IT компаний до сих пор опираются на жесткую иерархию. Проектный менеджер распределяет задачи между инженерами, ведет учет выполнения в таблицах и дважды в неделю требует отчеты о статусе. Scrum полностью отвергает такую модель. В Scrum Разработчики не просто исполнители задач, ожидающие указаний. Это автономная, самоуправляемая команда, которая превращает идеи в работающее программное обеспечение.
Кто относится к Разработчикам
Руководство по Scrum 2020 года определяет Разработчиков как членов Scrum команды, которые создают любую часть готового к использованию Инкремента в каждом Спринте. Это понятие охватывает не только программистов серверной части. Если в вашей команде есть UX дизайнеры, администраторы баз данных, специалисты по безопасности или инженеры по качеству, все они считаются Разработчиками.
Среди Разработчиков нет внутренних подкоманд или иерархий. Тестировщик не подчиняется ведущему архитектору. Все несут равную ответственность за качество и поставку Инкремента. Когда команда принимает такую плоскую структуру, необходимость в передаче задач из рук в руки отпадает. Никто больше не заявляет, что функция готова с его стороны, пока она пылится непроверенной на тестовом сервере.
Что означает самоуправление на практике
Самоуправление означает, что Разработчики самостоятельно определяют, кто что делает, когда и как. Product Owner решает, какие проблемы требуют решения, и задает бизнес приоритеты с помощью Product Backlog. При этом никто не диктует Разработчикам, как проектировать архитектуру, писать тесты или кому поручить реализацию конкретного интерфейса.
Если для рискованного компонента команда выбирает парное программирование, это ее право. Если они решают отрефакторить платежный сервис вместо быстрой временной заплатки, руководство должно уважать этот выбор. Разработчики полностью отвечают за техническую реализацию от начала и до конца.
Четыре основные зоны ответственности
Автономия без ответственности превращается в хаос. Руководство по Scrum возлагает на Разработчиков четыре ключевые зоны ответственности, которые направляют их повседневную работу:
- Создание плана на Спринт, то есть Sprint Backlog.
- Обеспечение качества за счет строгого соблюдения Definition of Done.
- Ежедневная адаптация плана для достижения Sprint Goal на Daily Scrum.
- Взаимная профессиональная ответственность внутри команды.
Обратите внимание, что каждая из этих обязанностей является коллективной. Отдельный программист не может в одиночку решить пропустить модульные тесты ради дедлайна. За соблюдение Definition of Done отвечает вся команда. Если кто-то пытается срезать углы, остальные участники должны открыто на это указать.
Граница между тем, что делать, и тем, как делать
Самоуправление чаще всего рушится при размывании границ. Бывший инженер в роли Product Owner может попытаться навязать разработчикам схему базы данных. В такой ситуации самоуправление исчезает. Разработчики теряют чувство ответственности за продукт и возвращаются к пассивному исполнению указаний.
Эту границу легко удерживать, если обе стороны уважают компетенции друг друга. Product Owner задает цель, объясняет бизнес контекст и ограничения. Разработчики изучают задачу, оценивают трудозатраты, проектируют решение и прогнозируют, какой объем работы поместится в Спринт. Если объем задач превышает возможности команды для достижения Sprint Goal, Разработчики согласовывают с Product Owner исключение лишних элементов. Они не должны работать по восемьдесят часов в неделю, чтобы покрыть нереалистичные ожидания.
Почему организациям трудно дается автономия Разработчиков
Традиционных руководителей идея самоуправления часто пугает. Им кажется, что они теряют контроль. Они опасаются, что без централизованного распределения задач инженеры займутся посторонними проектами или перестанут двигаться к цели. На самом деле все происходит наоборот.
Когда специалисты сами выбирают задачи и берут обязательства по достижению общей цели, их вовлеченность растет. Им важен результат, поскольку этот план составили они сами, а не начальник сверху. Создание качественного программного обеспечения представляет собой слишком сложный процесс для директивного управления сверху вниз. Люди, которые работают непосредственно с кодом, должны иметь полномочия принимать решения на месте.