Учебник-повесть по гибкой разработке
«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 — «готово».
Остальные — «в работе», «зависли», «ждёт доступа», «требует уточнения».
Элина включила презентацию:
«Ретроспектива: Что прошло хорошо? Что можно улучшить? Что попробуем в следующем спринте?»
— Ну что, — начала она, — давайте честно. Как прошёл спринт?
Пауза.
Дмитрий смотрит в ноутбук. Катя — в блокнот. Лиза — в телефон.
Никто не говорит.
— Может, начнём? — спросила Элина. — Что прошло хорошо?
Лиза подняла глаза.
— Ну… мы начали, — сказала она. — Это уже что-то.
— Хорошо, — кивнула Элина. — Записываю: «Начали спринт».
Тишина.
— А что можно улучшить?
Молчание.
Дмитрий наконец отрывает взгляд от экрана.
— Всё, — говорит он. — Всё можно улучшить. Начиная с идеи, что мы — команда.
— Дмитрий! — Лиза вскинулась. — Мы стараемся!
Бесплатный фрагмент закончился.
Купите книгу, чтобы продолжить чтение.