12+
Sprint Zero

Объем: 78 бумажных стр.

Формат: epub, fb2, pdfRead, mobi

Подробнее

Учебник-повесть по гибкой разработке

«Agile — это не процесс. Это то, как вы говорите, когда никто не смотрит.»

— Элина, тимлид

Введение: Почему Agile иногда терпит крах (и как его спасти)

Agile-манифест был написан в 2001 году четырнадцатью людьми, которые хотели изменить мир разработки. Они поставили людей важнее процессов, работающий продукт важнее документации, сотрудничество важнее контракта, готовность к изменениям важнее следование плану.

Прошло более двадцати лет.

Agile стал стандартом.

Но в сотнях команд по всему миру он превратился в ритуал без смысла:

— Ежедневные стендапы, где все говорят: «работаю» и молчат.

— Ретроспективы, на которых пишут: «всё норм».

— Jira, где задачи горят красным, а команда — от выгорания.

Agile терпит крах не потому, что плох. А потому, что его делают формально.

Эта книга — попытка вернуть Agile к его сути.

Через историю одной команды, которая начинает с провала — и заканчивает пониманием:

Agile — это не то, что вы делаете. Это то, как вы думаете.

Как читать эту книгу

Книга состоит из восьми глав, каждая из которых — одна неделя жизни команды.

После каждой главы — раздел:

— «Что мы узнали» — ключевые уроки

— «Вопросы для обсуждения»

— «Практическое задание»

Вы можете читать книгу:

— Как небольшую повесть — чтобы прожить путь команды

— Как учебник — для курсов по Agile, управлению проектами, soft skills

— Как кейс — для обсуждения в командах, на коуч-сессиях

Книга подойдёт студентам, junior-разработчикам, тимлидам и всем, кто хочет понять: как Agile работает на самом деле — и почему чаще всего не работает.

Часть I. Падение: Форма без смысла

Когда процессы есть, а команды — нет

Глава 1. «Всё по плану»

Компания «Нейросфера» запускает амбициозный стартап — приложение для персонализированного обучения с ИИ. Всё должно быть готово к демо-дню через 5 месяцев.

В проект приходит Элина, новый тимлид, только что закончившая курс по Agile. Она уверена: если внедрить Scrum, всё пойдёт как по маслу.

Понедельник, 9:00 утра.

Офис «Нейросферы» пахнет кофе, новым ламинатом и лёгкой паникой.

Элина стояла у доски с маркером в руке. На доске — красиво нарисованная схема Scrum-процесса: бэклог, спринт, дейли, ретро, демо. Всё чисто, всё по учебнику. Она вчера до двух ночи смотрела видео от Ken Schwaber и перечитала Agile-манифест. Она была готова.

— Доброе утро, команда, — сказала она, стараясь звучать уверенно. — Сегодня у нас Sprint Zero. Начинаем с планирования первого двухнедельного спринта. Цель — запустить MVP: регистрацию, профиль пользователя и первый модуль обучения.

В комнате молчание. Дмитрий, senior-разработчик, смотрел в экран ноутбука. Лиза, Product Owner, щёлкала мышкой, будто пыталась убежать. Катя, junior, сидела, как мышь, и держала блокнот так, будто он мог её защитить.

— У нас есть бэклог, — продолжила Элина, указывая на Jira. — 27 задач, оценённых в story points. Мы выбрали 35 пунктов на спринт. Всё укладывается в velocity команды за прошлый проект.

— А у нас был прошлый проект? — вдруг спросил Дмитрий, не отрываясь от экрана. — Я что-то не припоминаю, чтобы мы вместе что-то заканчивали.

Лиза фыркнула, но тут же замолчала.

— Ладно, — сказала Элина, игнорируя колкость. — Давайте распределим задачи. Кто возьмёт регистрацию?

— Я, — сказала Катя тихо. — Но у меня ещё нет доступа к бэкенду.

— Будет, — пообещала Лиза. — Обещала Игорю, что сегодня получим.

— Игорь — это заказчик, — пояснила Элина. — Он сказал, что хочет посмотреть прототип уже через неделю. Надо успеть.

— Через неделю? — Дмитрий наконец оторвался от экрана. — У нас ещё нет архитектуры, нет доступа, нет дизайна, а у нас уже дедлайн?

— Ну, это не дедлайн, — сказала Лиза, — это «желаемый срок».

— Ага, — сказал Дмитрий. — У нас «желаемый» дедлайн, «ожидаемая» архитектура и «плановый» доступ. Отличный старт.

Элина почувствовала, как внутри всё сжалось. Она хотела сказать: «Мы же Agile! Мы адаптируемся!» — но никто бы не поверил. Вместо этого она написала на доске: Цель спринта: MVP к демо-дню.

— Мы справимся, — сказала она. — Главное — коммуникация, прозрачность и командная работа.

Команда молчала. Было глухо, как будто на совещании призраков.

Дейли не состоялся — потому что не было, что обсуждать.

Спринт начался.

Он уже был обречён.

📚 Что мы узнали

1. Sprint Zero — это не просто «подготовка»

Многие команды считают, что Sprint Zero — это когда «ещё ничего не делают, только готовятся». На самом деле — это первый настоящий спринт, в котором закладывается фундамент: архитектура, инструменты, доступы, коммуникация.

Если его проигнорировать — следующие спринты будут строиться на песке.

2. Velocity нельзя копировать «с прошлого проекта»

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

3. Agile требует доверия и психологической безопасности

Команда молчала, потому что:

— боялась критики,

— не доверяла новому тимлиду,

— видела, что заказчик давит, а PO не защищает.

— Без доверия — нет честных дейли, нет открытых ретроспектив, нет Agile.

4. Product Owner должен быть «щитом» для команды

Лиза сказала: «Игорь хочет через неделю». Но она не сказала: «Это нереально».

Хороший PO — не тот, кто передаёт требования, а тот, кто управляет ожиданиями, объясняет сложность и защищает команду от хаотичных изменений.

5. MVP — это не «всё, но вчерне»

MVP (Minimum Viable Product) — это минимальный продукт, который можно показать и получить обратную связь. Но если нет базовых условий (доступы, архитектура, дизайн), то MVP не построить.

Agile не отменяет подготовки.

❓ Вопросы для обсуждения

— Почему команда не подняла свои риски на встрече? Кто в этом виноват — участники или фасилитатор?

— Можно ли считать Sprint Zero успешным, если команда не договорилась о целях и условиях?

— Как Элина могла бы начать иначе, чтобы установить доверие?

— Почему Дмитрий ведёт себя так цинично? Это личная проблема или признак системной дисфункции?

— Должна ли команда брать на спринт задачи, если нет доступа к системам?

🛠️ Практическое задание

Создайте чек-лист для Sprint Zero

Представьте, что вы тимлид новой команды. Напишите 10 обязательных пунктов, которые должны быть выполнены до старта первого рабочего спринта.

Пример:

— Определён Product Owner

— Утверждена архитектура MVP

— Настроены репозитории и CI/CD

— Проведён kick-off с командой и заказчиком

Подсказка: включите технические, организационные и человеческие аспекты.

Глава 2. «Daily Standup: 7 минут молчания»

Вторник, 10:00 утра.

Ровно через 24 часа после красивой доски с планом спринта.

Элина снова стояла у доски. На этот раз — перед небольшой группой людей, собравшихся вокруг стола. Все стояли. Потому что так «надо».

«Daily Standup. 15 минут. Каждый говорит: что сделал, что будет делать, какие препятствия».

— Начинаем, — сказала Элина. — По часовой стрелке. Дмитрий?

Дмитрий не отрывался от экрана.

— Работаю с бэкендом. То, что в таске.

— Что конкретно? — уточнила Элина.

— Пишу код.

— Препятствия?

— Нет.

Следующая — Катя. Она встала чуть ближе к стене, как будто пыталась в неё втиснуться.

— Я… начала разбираться с формой регистрации. Но у меня нет доступа к базе. И ещё… дизайн не утверждён.

— Препятствия? — спросила Элина.

— Ну… да. Нет доступа. И макеты в Figma устарели.

— Лиза, — повернулась Элина, — ты можешь помочь с доступом и дизайном?

Лиза посмотрела на телефон.

— Я написала Игорю. Он сказал, что передаст доступ «в ближайшее время». А макеты… он вчера вечером просил изменить цвет кнопки. Я ещё не обновила.

— Ага, — сказал Дмитрий. — «В ближайшее время» — это как «через неделю» или «никогда»?

Лиза покраснела.

— Я работаю над этим, — тихо сказала она.

— Мой ход, — сказал Элина. — Вчера я настроила Jira-видимость и подготовила отчёт по риску задержки. Сегодня встречаю нового DevOps-инженера — он должен настроить CI.

Молчание.

— Всё? — спросила Элина.

Никто не сказал ни слова.

— Ну… спасибо, — сказала она. — Время — 7 минут.

Она посмотрела на часы.

15 минут не прошло. Но команда уже расходилась.

Позже, в обед, Катя подошла к ней у кофемашины.

— Я не хотела говорить при всех… но я не понимаю, зачем мы это делаем. Стоим, говорим «работаю», и всё. Никто не помогает. Никто не слушает.

— Это чтобы быть в курсе, — сказала Элина.

— А если я скажу, что не справляюсь, — прошептала Катя, — меня сочтут слабым. Дмитрий уже сказал, что junior — это «балласт».

Элина почувствовала, как внутри что-то сломалось.

Она думала, что стоять — это быть Agile.

Что говорить по очереди — это коммуникация.

Но на самом деле — это была церемония без смысла.

И команда это чувствовала.

📚 Что мы узнали

1. Daily Standup — это не отчёт, это синхронизация

Главная цель дейли — выявить зависимости и помочь друг другу. Это не отчёт перед начальством. Если команда просто перечисляет задачи — это не Agile, это театр процесса.

✅ Хороший дейли:

«Я не могу закончить форму, потому что жду дизайн. Кто может помочь?»

❌ Плохой дейли:

«Я работаю. Ничего не мешает. Всё ок.»

2. Психологическая безопасность — основа Agile

Команда не будет говорить о проблемах, если боится:

🔹быть высмеянной,

🔹показаться неопытной,

🔹вызвать раздражение у сильного члена команды (вроде Дмитрия).

Agile не работает без доверия.

«Люди в команде должны чувствовать, что могут говорить правду, не рискуя своей репутацией» — Эдмондса, The Fearless Organization

3. Препятствия (blockers) — это не просто «нет доступа»

Это системные проблемы:

🔹отсутствие ясности,

🔹давление со стороны заказчика,

🔹отсутствие поддержки от PO,

🔹токсичное поведение в команде.

Хороший Scrum Master не просто фиксирует blockers — он борется с ними.

4. Product Owner должен быть на дейли — и активно участвовать

Лиза была, но не включилась. Она не сказала:

🔹«Я беру на себя задачу по доступам»,

🔹«Я уточню приоритеты с Игорем»,

🔹«Я обновлю макеты до обеда».

PO — часть команды, а не наблюдатель.

5. Церемонии без смысла убивают Agile

Если дейли превращается в рутину — его нужно пересмотреть.

Может, команда не готова к ежедневной синхронизации?

Может, нужен другой формат?

Agile требует инспекции и адаптации — даже к своим собственным правилам.

❓ Вопросы

— Почему Катя не сказала о своих проблемах на встрече? Что могло бы изменить её поведение?

— Как Элина могла бы переформулировать дейли, чтобы сделать его полезным?

— Должна ли команда продолжать дейли, если он не приносит пользы? Какие альтернативы?

— Что делать, если один из участников (как Дмитрий) демотивирует других?

— Можно ли считать дейли успешным, если он длился 7 минут?

🛠️ Задание

Перепишите сценарий дейли, чтобы он стал полезным

Представьте, что вы — Scrum Master. Перепишите диалог из главы так, чтобы:

— каждый участник получил помощь,

— были выявлены зависимости,

— PO взял на себя обязательства,

— junior почувствовал поддержку.

Пример начала:

Элина: «Ребята, давайте не просто рассказывать, что делаем, а спросим: кому нужна помощь? Кто кого ждёт?»

Глава 3. «Бэклог — это не Jira»

Среда, 15:17.

Дверь в переговорку распахнулась. Вошёл Игорь — заказчик, основатель стартапа, человек, который «видит рынок». В руках — iPad, на лице — энергия, граничащая с паникой.

— Лиза! Нам нужно срочно поговорить! — сказал он, не здороваясь. — Я только что вернулся со встречи с инвесторами. Они в восторге от идеи, но говорят: «А где персонализация? Где ИИ? Где прогресс?»

Лиза побледнела.

— Мы работаем над этим, Игорь. Сейчас в бэклоге есть задачи по рекомендательному алгоритму. Они в спринте 2…

— Спринт 2?! — перебил он. — Нам нужно показать ИИ уже на демо! Через 4 недели! Инвесторы ждут «умный продукт», а не форму регистрации!

Он подошёл к экрану, открыл Jira.

— Вот! Добавим:

«Прогнозирование успеха ученика на основе поведения» — 5 баллов.

«Адаптивный путь обучения с ИИ» — 8.

«Чат с виртуальным наставником» — 13.

«Интеграция с нейросетью для анализа внимания» — 20.

— Всего 17 задач. Вставьте в текущий спринт. Это критически важно.

Лиза посмотрела на Элину. Та стояла у доски, как вкопанная.

— Игорь, — сказала Лиза дрожащим голосом, — у нас уже 35 story points. И мы не закрыли даже базовые функции. Мы не можем просто…

— Можете! — сказал он. — Вы же Agile! Вы должны быть гибкими! Если нужно — выкиньте что-то ненужное. Например, эту регистрацию. Кто вообще будет регистрироваться, если не будет ИИ?

Дмитрий, сидевший в углу, хмыкнул:

— Ну, теперь понятно, зачем мы делаем продукт. Не для пользователей. А для инвесторов.

Игорь ушёл, оставив после себя шквал уведомлений в Jira и пустоту в переговорке.

Лиза смотрела на экран. Новые задачи уже висели в спринте. Красные. Срочные.

Катя тихо спросила:

— А что теперь делать мне с формой?

Элина подошла к доске. Стерла надпись «Цель спринта: MVP».

Написала новое:

Цель спринта: угодить заказчику?

— Лиза, — тихо сказала она. — Ты действительно считаешь, что эти задачи — приоритет?

— Я не знаю, — прошептала Лиза. — Я должна делать то, что говорит Игорь.

— Тогда ты не Product Owner, — сказала Элина. — Ты почтальон.

— А разница?

— Большая. PO решает, что важно. А не просто передаёт чужие слова.

📚 Что мы узнали

1. Бэклог — это не список задач. Это стратегия

Product Backlog — это иерархия ценности, а не склад требований. Хороший бэклог:

🔹отсортирован по приоритету (а не по «громкости голоса заказчика»),

🔹основан на гипотезах о пользе для пользователя,

🔹пересматривается регулярно.

✅ Agile-команда спрашивает: «Почему это важно? Для кого? Как проверим?»
❌ Формальная команда: «Заказчик сказал — делаем».

2. Product Owner — это не администратор, а лидер

PO должен:

🔹защищать команду от хаотичных изменений,

🔹объяснять контекст: «Почему мы это делаем?»,

🔹принимать решения, а не перекладывать ответственность на заказчика.

«Если PO всегда соглашается — значит, он не работает» — Рон Джеффрис

3. Agile не означает «делать всё, что просят»

Гибкость — это умение адаптироваться осознанно, а не под давлением. Agile требует:

🔹инспекции («Это действительно важно?»),

🔹адаптации («Как переприоритизировать?»),

🔹смелости («Нет — тоже вариант ответа»).

4. MVP — это не про технологии, а про проверку гипотез

Игорь хочет «ИИ» — но зачем? Чтобы пользователи учились эффективнее? Или чтобы впечатлить инвесторов?
Agile-команда должна проверять гипотезы, а не реализовывать фантазии.

Пример гипотезы: «Если мы покажем ученику прогноз успеваемости, он будет чаще заходить в приложение».

5. Jira — это инструмент, а не истина

Добавить задачу в Jira — не значит, что она должна быть сделана. Бэклог — живой артефакт. Он должен меняться, но не под давлением, а на основе данных и диалога.

❓ Вопросы

— Кто должен определять приоритеты в Agile-команде: заказчик, PO или вся команда?

— Как Лиза могла бы мягко, но чётко отказать Игорю?

— Что делать, если заказчик не понимает, как работает Agile?

— Можно ли считать спринт успешным, если команда сделала всё, что просили, но продукт никому не нужен?

— Почему Дмитрий называет команду «почтальонами»? Это справедливо?

🛠️ Задание

Переприоритизируйте бэклог

У вас есть текущий бэклог (условно 20 задач). Заказчик добавил 5 новых — «очень срочных». Ваш спринт уже перегружен.

Ваша задача:

Выберите 3 задачи из новых, которые действительно добавляют ценность (обоснуйте почему). Найдите 3 задачи из текущих, которые можно отложить (с пояснением). Напишите письмо заказчику, в котором объясните изменения. → Сохраните уважение, покажите понимание его целей, предложите компромисс.

Подсказка: используйте фреймворк «Мы ценим X, поэтому предлагаем Y»
Пример: «Мы ценим впечатление инвесторов, поэтому предлагаем показать прототип ИИ-наставника без полной интеграции».

Глава 4. «Ретроспектива: „всё норм“»

Пятница, 16:55.

За окном — серый вечер, дождь по стеклу.

В переговорке — тишина.

Команда сидит за столом. Спринт окончен.

Демо не состоялось.

Jira показывает: 3 задачи из 35 — «готово».

Остальные — «в работе», «зависли», «ждёт доступа», «требует уточнения».

Элина включила презентацию:

«Ретроспектива: Что прошло хорошо? Что можно улучшить? Что попробуем в следующем спринте?»

— Ну что, — начала она, — давайте честно. Как прошёл спринт?

Пауза.

Дмитрий смотрит в ноутбук. Катя — в блокнот. Лиза — в телефон.

Никто не говорит.

— Может, начнём? — спросила Элина. — Что прошло хорошо?

Лиза подняла глаза.

— Ну… мы начали, — сказала она. — Это уже что-то.

— Хорошо, — кивнула Элина. — Записываю: «Начали спринт».

Тишина.

— А что можно улучшить?

Молчание.

Дмитрий наконец отрывает взгляд от экрана.

— Всё, — говорит он. — Всё можно улучшить. Начиная с идеи, что мы — команда.

— Дмитрий! — Лиза вскинулась. — Мы стараемся!

Бесплатный фрагмент закончился.

Купите книгу, чтобы продолжить чтение.