Команда разработки и self-organization

Команда сама решает, как выполнить работу, — и это не вежливая формальность, а условие, без которого весь Scrum рассыпается.

Команда разработки (Developers) — люди, которые превращают задачи бэклога в готовый продукт. Она кросс-функциональна (внутри есть все нужные навыки) и самоорганизуется: сама выбирает, как работать, и сама берёт задачи.

Разделение труда, ради которого всё затевалось

Три роли Scrum делят зоны решений так:

Вопрос	Кто отвечает
Что делать и зачем? В каком порядке?	Product Owner
Как это построить? Кто чем займётся? Сколько влезет в спринт?	Команда
Что мешает и как сделать процесс лучше?	Scrum Master (вместе с командой)

Граница между первой и второй строкой — самая важная в Scrum. Нарушают её постоянно: PO приходит с готовым техническим решением, менеджер лично раздаёт задачи, архитектор из соседнего отдела диктует, где хранить кеш.

Почему это плохо не из идейных соображений, а практически? Потому что решение принимает тот, у кого нет информации, а последствия расхлёбывает тот, у кого она была. Разработчик знает, что этот модуль трогали в марте и там всё держится на честном слове. Менеджер, который «оценил задачу в два дня», этого не знает. Оценка становится фикцией, а срок — гарантированно сорванным.

Кросс-функциональность: команда, которой не нужно ждать

Кросс-функциональная команда — это группа, которая может довести задачу до готового результата, не выходя за свои пределы. Внутри есть всё: бэкенд, фронтенд, тестирование, вёрстка, работа с базой, выкатка в продакшен.

Сравните два устройства организации на одной и той же задаче — «добавить фильтр в каталог»:

КОМПОНЕНТНЫЕ КОМАНДЫ (отделы по специальностям)

день 1-2   команда бэкенда делает API              (ждём)
день 3-6   задача в очереди фронтенд-отдела        (ждём)
день 7-9   фронтенд делает интерфейс
день 10-14 задача в очереди отдела тестирования    (ждём)
день 15    тестировщик находит ошибку в API
день 16-20 задача возвращается в очередь бэкенда   (ждём)

Итого: 20 дней, из них работы — 6


КРОСС-ФУНКЦИОНАЛЬНАЯ КОМАНДА

день 1     обсудили втроём, договорились о контракте API
день 2-3   бэкенд и фронтенд пишут параллельно, тестировщик готовит проверки
день 4     нашли ошибку, поправили за час — все сидят рядом
день 5     готово, выкатили

Итого: 5 дней

Разница не в скорости печатания кода — она вообще не в этом. Разница в ожидании. В первом варианте задача 14 дней из 20 просто лежит в чужой очереди. Кросс-функциональность существует ради того, чтобы этих очередей не было.

T-shaped специалисты

Здесь возникает возражение: «у нас в команде один фронтендер, если ему прилетят три задачи, он всё равно станет узким местом». Верно. Ответ — T-shaped специалисты.

Буква T — метафора. Вертикальная черта — глубокая экспертиза в одной области. Горизонтальная — рабочие навыки в смежных: не «умею как профи», а «могу подхватить и не сломать».

I-shaped (узкий)	T-shaped
«Я бэкендер, я вёрстку не трогаю»	«Основное — бэкенд, но простую форму сверстаю и тест напишу»
Простаивает, когда нет задач его профиля	Берёт то, что сейчас блокирует команду
Его отпуск останавливает половину работ	Его отпуск команда переживает
Спринт срывается из-за очереди к одному человеку	Пиковая нагрузка размазывается

Речь не о том, чтобы все стали одинаковыми универсалами — это как раз путь к посредственности во всём. Глубина остаётся. Но когда в конце спринта три задачи ждут тестирования, а разработчики сидят без дела, T-shaped команда просто садится тестировать. I-shaped — беспомощно смотрит и потом объясняет на ретро, что «тестирование — узкое место».

Самоорганизация и её пределы

Слово «самоорганизация» многих пугает: звучит как анархия. Ничего подобного. У самоорганизации очень чёткие границы.

Что команда решает сама

Как реализовать задачу технически: архитектура, библиотеки, структура базы.
Кто чем займётся. Задачи берут, а не получают.
Сколько работы взять в спринт. Никто не может «дать» команде больше, чем она согласилась взять.
Как разбить историю на технические подзадачи.
Свои внутренние правила: код-ревью, стиль кода, как проводить стендап.

Что команда НЕ решает

Продуктовые приоритеты. Взять из бэклога задачу №9 вместо №2, потому что она интереснее, — нельзя. Порядок задаёт PO.
Планку качества. Definition of Done — общий контракт, а не то, что можно тихо понизить в трудном спринте.
Внешние рамки. Требования безопасности, законы, отраслевые стандарты, архитектурные соглашения компании. Самоорганизация живёт внутри них, а не поверх.
Состав команды, бюджет, зарплаты. Это обычно за пределами Scrum.

Definition of Done стоит выписать явно — это тот самый общий знаменатель, который держит планку без начальника:

DEFINITION OF DONE — команда «Каталог»

Задача считается готовой, если:
- код прошёл ревью минимум одного члена команды
- есть автотесты на новую логику, вся сборка зелёная
- работает в Chrome, Safari, Firefox и на мобильных
- нет новых ошибок в консоли и в Sentry
- обновлена документация API, если контракт менялся
- выкачено на staging и проверено PO

НЕ «готово»: «работает у меня локально», «осталось только протестировать»

Обратите внимание: последняя строка — про фразы, которые чаще всего звучат в конце спринта. DoD существует именно для того, чтобы их обезвредить.

Как это работает

На планировании PO приносит истории и объясняет, зачем они нужны. Команда задаёт вопросы, оценивает, решает, сколько влезет. Дальше PO уходит из процесса «как» и в течение спринта отвечает на вопросы, но не распоряжается.

На стендапе разработчики говорят не начальнику, а друг другу. Это тонкий момент, который видно сразу: если все смотрят на Scrum Master и рассказывают, что сделали за вчера, — это отчёт, и он бесполезен. Если смотрят на доску и обсуждают, что мешает довести до конца ближайшую задачу, — это планирование дня.

Про размер: рабочий диапазон — примерно от трёх до девяти разработчиков. Меньше трёх — не хватает навыков и взаимозаменяемости. Больше девяти — количество связей между людьми растёт быстрее, чем польза от новых рук: команда начинает тонуть в согласованиях, а стендап растягивается до получаса. Знаменитое «правило двух пицц» из Amazon — про то же самое.

Частые ошибки

«Самоорганизация — значит, каждый сам за себя». Как раз наоборот: команда отвечает за цель спринта целиком. Ситуация «мои задачи готовы, а что там у тестировщика — не моя проблема» — это не самоорганизация, а её отсутствие.
Менеджер назначает задачи. «Петя делает бэкенд, Маша — фронт, Игорь — тесты». Через месяц никто не думает о продукте, все думают о своём куске.
Колодцы специализации. Каждый держится только за свою колонку на доске. В конце спринта пять задач висят на тестировании, а трое разработчиков «свободны». Лечится T-shaped развитием и правилом «стоп новым задачам, помогаем закрыть текущие».
Скрытая зависимость от внешнего отдела. Команда называется кросс-функциональной, но выкатка в продакшен — через заявку в другой отдел с ожиданием в пять дней. Значит, кросс-функциональности нет, а есть её видимость.
Команда из пятнадцати человек. Обычно означает, что там на самом деле две команды, которые мешают друг другу на одном стендапе.
Тихое понижение планки. «В этот раз без тестов, потом допишем». Не допишут. DoD — не переменная спринта.

Итоги

PO решает «что» и «зачем», команда — «как» и «сколько». Эта граница — основа всего Scrum.
Кросс-функциональность нужна не ради красоты, а чтобы задача не лежала в чужих очередях. Ожидание — главный пожиратель времени.
T-shaped специалист имеет глубину в своём и рабочие навыки в смежном. Он не даёт команде застревать на одном узком месте.
Самоорганизация не безгранична: приоритеты, планка качества и внешние рамки остаются снаружи.
Definition of Done — общий контракт качества, который нельзя понижать по ситуации.
Рабочий размер — 3–9 разработчиков. Больше — команда тонет в согласованиях.