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