Перейти к основному содержимому

Scrum — команда и Scrum Master

ОБЯЗАТЕЛЬНО
Руководителю Тимлиду

Команда как единица работы​

Scrum опирается на простой тезис: в промышленном и интеллектуальном труде почти всё делают команды, а не герои-одиночки. Награды только за личные KPI, разнесённые по отделам «анализ → разработка → тест», разрушают поток — человек закрывает свой этап и не отвечает за продукт.

Кросс-функциональность «от начала до конца»​

Многофункциональная команда (третья опора вместе с автономией и целью) включает все навыки, чтобы довести элемент бэклога до Done без бесконечной передачи «через стену».

Классическая схемаScrum-команда
Отделы по фазам SDLCОдна команда на продукт / поток ценности
Hand-off и очередиСовместная ответственность за инкремент
«Не мой участок»Общая Sprint Goal

Пример — репортажная группа NPR в Каире (2011): общая цель, полная автономия в выборе сюжетов, минимум внешнего микроменеджмента; позже NPR применяет Scrum и в разработке медиа.

Состав типичной IT-команды — в Командной работе.

Золотой размер — 3–9 человек​

В типовых рекомендациях по Scrum — от 3 до 9 участников в Scrum Team (Scrum Guide: обычно 10 или меньше).

Исследование Лоуренса Путнэма​

Анализ сотен проектов (Путнэм, 1990-е): при одинаковом объёме работы группы 3–7 человек тратили порядка ~25% усилий групп 9–20 человек. Больше людей — не линейно больше результата; часто дольше и дороже.

Коммуникационные каналы​

Число пар связей в команде:

C = n(n − 1) / 2

где C — число коммуникационных каналов, n — размер команды.

nКаналов
510
721
936
1045

Scrum требует, чтобы каждый понимал, что делают остальные. При росте n мозг перестаёт удерживать контекст — растут совещания, недопонимание, подгруппы с разными целями.

Ограничение рабочей памяти​

Исследования Нельсона Коуэна (2001) уточняют: в фокусе внимания удерживается порядка четырёх объектов, а не «магических семи». Отсюда практический вывод: малая команда + явная доска лучше большой команды + статус-отчёты.

Больше 9 человек

Делите продукт на несколько Scrum Team с общим Product Goal (масштабирование — LeSS, Nexus, SAFe; обзор в 7-03/1). Не раздувайте одну «супер-команду».

Автономия и цель​

Три условия сильных команд в Scrum-практике:

  1. Понятная цель (зачем мы здесь).
  2. Автономия в решениях в рамках цели.
  3. Кросс-функциональность (навыки закрывают работу).

Без цели автономия превращается в хаос; без автономии цель превращается в микроменеджмент.

Scrum Master — происхождение роли​

История из Easel: команда смотрела хака сборной All Blacks (регби) — ритуал сплочения перед матчем. Оттуда:

  • фокус на Sprint Goal;
  • ежедневные короткие стойки;
  • review и retrospective;
  • человек, который следит за процессом, а не «командует» — имя Scrum Master.

Обязанности SM:

  • проводить time-box события;
  • обеспечивать открытость (прозрачность);
  • устранять препятствия — в том числе организационные (не только «сломался ПК»);
  • задавать вопрос: как делать ещё лучше то, что уже делаем хорошо?

Подробнее о событиях — Роли и артефакты; о дейли — 7-02/111.

«Вините игру, а не игрока»​

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

ПлохоЛучше
«Вася опять всё тормозит»«Что в процессе заставляет ждать ревью 3 дня?»
Личные ярлыкиЭксперимент на один спринт

Связь с kaizen на ретроспективе — Внедрение.

Что читать дальше​

ТемаСсылка
Спринт, ритм./4
Потери multitasking./5
Управление разработчиками7-02/13

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Освоение главы0%