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