Scrum — команда и Scrum Master
Миграции в инкременте — Пакетная работа; проверка — SQL для тестировщика.
Команда как единица работы
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 | Каналов |
|---|---|
| 5 | 10 |
| 7 | 21 |
| 9 | 36 |
| 10 | 45 |
Scrum требует, чтобы каждый понимал, что делают остальные. При росте n мозг перестаёт удерживать контекст — растут совещания, недопонимание, подгруппы с разными целями.
Ограничение рабочей памяти
Исследования Нельсона Коуэна (2001) уточняют: в фокусе внимания удерживается порядка четырёх объектов, а не "магических семи". Отсюда практический вывод: малая команда + явная доска лучше большой команды + статус-отчёты.
Делите продукт на несколько Scrum Team с общим Product Goal (масштабирование — LeSS, Nexus, SAFe
обзор в 7-03/1). Не раздувайте одну "супер-команду".
Автономия и цель
Три условия сильных команд в Scrum-практике:
- Понятная цель (зачем мы здесь).
- Автономия в решениях в рамках цели.
- Кросс-функциональность (навыки закрывают работу).
Без цели автономия превращается в хаос; без автономии цель превращается в микроменеджмент.
Scrum Master — происхождение роли
История из Easel: команда смотрела хака сборной All Blacks (регби) — ритуал сплочения перед матчем. Оттуда:
- фокус на Sprint Goal;
- ежедневные короткие стойки;
- review и retrospective;
- человек, который следит за процессом, а не "командует" — имя Scrum Master.
Обязанности SM:
- проводить time-box события;
- обеспечивать открытость (прозрачность);
- устранять препятствия — в том числе организационные (не только "сломался ПК");
- задавать вопрос: как делать ещё лучше то, что уже делаем хорошо?
Подробнее о событиях — Роли и артефакты; о дейли — 7-02/111.
"Вините игру, а не игрока"
На ретро полезно помнить фундаментальную ошибку атрибуции: чужие промахи кажутся чертой характера, свои — следствием обстоятельств. На ретро и постмортемах это порождает охоту на виноватых вместо исправления системы.
| Плохо | Лучше |
|---|---|
| "Вася опять всё тормозит" | "Что в процессе заставляет ждать ревью 3 дня?" |
| Личные ярлыки | Эксперимент на один спринт |
Связь с kaizen на ретроспективе — Внедрение.
Счастье как «предсказывающая метрика»
В гл. 7 книги Сазерленд развивает тезис: успех не делает людей счастливыми — счастливые команды чаще добиваются успеха. Для Scrum это не «тимбилдинг ради тимбилдинга», а связь с производительностью:
- падение индекса счастья в команде часто опережает падение velocity на несколько недель;
- финансовые отчёты смотрят в прошлое, а ответ «насколько ты доволен ролью и компанией» — про будущее настроение и вовлечённость.
Простой индекс счастья на ретро (по мотивам книги) — четыре вопроса каждому:
- Оцени свою роль по шкале 1–5.
- Оцени компанию / проект по той же шкале.
- Почему так?
- Что одно сделает тебя счастливее в следующем спринте?
Команда выбирает одно улучшение (kaizen) и включает его в Sprint Backlog со ясным критерием успеха — как обычную задачу. В кейсе Scrum Inc. из книги такой подход за несколько недель поднял velocity с 40 до 120 story points — не через давление, а через устранение реальных помех (в т.ч. «сырых» user stories).
Индекс работает, только если пункт 4 превращается в действие в следующем спринте. Иначе это очередной ритуал без kaizen.
Что читать дальше
| Тема | Ссылка |
|---|---|
| Спринт, ритм | ./4 |
| Потери multitasking | ./5 |
| Управление разработчиками | 7-02/13 |