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