Если вы читаете этот пост, то, вероятно, работали по какой-то разновидности Scrum, но если нет, присаживайтесь и будьте моим гостем.

Давайте начнём с самого начала.

Что такое Scrum?

Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.

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

Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.

Дополнение: определения несовершенны по определению (а теперь прочитайте это ещё раз).

Я с открытой душой приму любую критику о своих определениях Scrum, Agile и любых других терминов, и лишь попрошу прочитать пост целиком, прежде чем писать разгневанные комментарии!

Теория и практика

Agile противоположен каскадной модели (Waterfall) — олдскульному способу создания ПО до 90-х.

Каскадная модель, как её представляют практикующие Agile: грязный поток

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

Я мог бы продолжать долго, но не буду, наверное, вы поняли принцип.

Типичный практик agile, работающий над одной и той же задачей четвёртый спринт подряд

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

Я бы ни за что не стал оспаривать авторитет людей, придумавших его теорию, потому что реальная проблема реализации Scrum заключается в нашем не очень идеальном мире.

▍ Церемонии

Самый фундаментальный термин Scrum — это спринт. По сути, спринты — это заранее установленные временные промежутки (обычно длящиеся две недели). В течение этого промежутка времени, наряду с циклами разработки, Scrum-команда должна следовать некоторым церемониям.

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

• Планирование спринтов — как бы просто ни звучало, это долгая сессия (до четырёх часов) по планированию пунктов/историй пользователя, которые необходимо реализовать в течение следующего спринта, задействующего scrum-команду.
• Ежедневные совещания — ежедневные КОРОТКИЕ совещания (примерно 15 минут), на которых маленькая команда разработчиков (примерно 3-7 человек) обсуждает свой прогресс и выделяет мешающие двигаться дальше проблемы, не вдаваясь в подробности. Это время, в которое можно попросить Алису устроить отдельное совещание о проблеме кэширования на стороне сервера и спросить Боба о том, почему параметр даты является строкой, а не временем Unix.
• Выполнение спринта — люди автономно берут задачи, а затем исполняют их и решают возможные проблемы на неформальных совещаниях, сессиях парного программирования, код-ревью и активного копипастинга из ChatGPT. А что насчёт тестирования? Это часть выполнения. QA? Тоже туда же. Документация? Вы знаете ответ. Задачи эксплуатации/DevOps/инфраструктуры? Можете догадаться сами.
• Обзор итогов спринта — долгое совещание (1-2 часа), призванное продемонстрировать результат спринта стейкхолдерам и получить от них обратную связь.
• Ретроспективное совещание — внутренний анализ того, что было сделано, с упором на помехи, чтобы убрать их из последующих спринтов и для общего постоянного совершенствования процессов, практик и инструментария для следующей итерации.
• Упорядочивание бэклога — не совсем церемония, но примерно 10% времени, которые команда во время спринта тратит на упорядочивание бэклога: разбиение, объяснение, поиск пробелов, формулирование определения «завершённости» и совместную расстановку приоритетов задач.

▍ Люди

Это отдельные личности или группы, определённые в Scrum:

• Стейкхолдеры — это заинтересованные лица, они хотят быть информированными, участвующими, они получают прибыль от продукта, чем бы ни был «продукт» в вашей компании. Да, при желании определение «продукта» можно растянуть на что угодно. Это могут быть конечные пользователи, другие команды и даже другие бизнесы.
• Владелец продукта должен использоваться в качестве моста между стейкхолдерами и разработчиками продукта, преобразующего требования в предпринимаемые действия; он должен понимать бизнес с точки зрения предметной области и целей бизнеса, управлять бэклогом и максимизировать получаемые результаты.
• Разработчики должны быть людьми, автономно отвечающими за операционные задачи, включая, но не ограничиваясь разработкой ПО, способными принимать технические решения, двигающие продукт в верном направлении.
• Scrum-мастер должен упрощать коммуникацию, отслеживать прогресс, выявлять и оценивать риски, проводить обучение и коучинг scrum самоуправляющейся команды, чтобы делать её эффективной.

О, да, знаменитая многозадачная продуктивность Scrum-мастера

Scrum поломан

Постойте-ка. То есть эти церемонии и должности настолько сложны, что для них необходим сертифицированный или профессиональный Scram-мастер? О, наивное дитя. Если вкратце, то очевидный ответ: нет. Хотите знать, почему?

Мы не живём в идеальном мире, где теория воплощается так, как написано в книгах.

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

Ещё один тикет в Jira? Поехали!

Планирование, вне зависимости от инструментария, занимает кучу времени, и в результате вы получаете заранее установленные задачи, измеряемые в сторипоинтах. Эти поинты, которые должны помочь в понимании сложности конкретной задачи, вместо этого используются для измерения времени.

Отлично, Шерлок!

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

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

Ладно, а почему мы не используем ряд Фибоначчи? И как насчёт покера планирования? Постойте, не торопитесь увольняться. Гарантирую, у меня есть оптимальное решение! Для упрощения оценки задачи можно просто назначать каждой из них размер одежды. Прекрасная идея.

Нам просто нужно обсудить, присвоить ли gRPC API размер задачи L или M, а единственным мерилом L будет время, которое мы потеряли на подборе способа непродуктивного измерения в миллиметрах.

Представим возможную ситуацию: ни владельца продукта, ни Scrum-мастера нет в офисе. Один на больничном, второй в отпуске. Будет ли ваша команда продолжать участвовать в ежедневных совещаниях? Сомневаюсь.

Что? Вы установили каждому собственную скорость как цель, которую нужно достигать в каждом спринте? Будьте готовы к отстойному коду и неполному, но автоматизированному тестированию.

Как только вы установите статическую метрику, люди рано или поздно адаптируются к тому, чтобы её обходить. А, да, и попрощайтесь с парным программированием и совместной работой, все слишком заняты зарабатыванием драгоценных сторипоинтов.

Задача слишком сложна, её нельзя разбить на части, она требует подробного анализа, в котором должны участвовать несколько команд в течение пары дней?

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

Думаете о составлении тикетов на каждую десятиминутную задачу наподобие форматирования файла, обновления URL и удаления неиспользуемых импортов? Добро пожаловать в ticket-driven development, где даже расхламление занимает кучу времени.

Пример достаточно частого случая: во время спринта кто-то нашёл баг.

«Хьюстон, у нас проблема, давайте обсудим её… с кем?»

С руководителем команды?

Со Scrum-мастером?

С техлидом?

С владельцем продукта?

С владельцем/менеджером сервиса? Да, у нас когда-то был PM в Scrum-команде, не спрашивайте, почему, это вполне реально и у меня есть доказательства.

Кого позовём на помощь?

Какое раздробленное руководство мы получили! Его слишком много для «автономной команды», не так ли?

Представьте, что вы согласовали со всеми этими людьми вашу проблему. Теперь представьте, сколько времени понадобится им для выяснения их части ответственности и нахождения решения.

Удачи, увидимся на следующем спринте!

Часто руководство считает Scrum эликсиром продуктивности и лекарством для любой недостаточно производительной команды, но в реальности всё почти наоборот.

Scrum не решает проблем с производительностью команд.

Медленная команда может стать ещё медленнее, и поверьте мне, вам будет больно смотреть на диаграмму сгорания задач.

Теперь это диаграмма выгорания

Есть ли способ заставить Scrum работать?

Я думаю, что он есть, но никогда не видел ни одного инженера, довольного реализацией Scrum в его компании.

Бинго.

Способ работы должен определяться на уровне команды её участниками, а не компанией.

Пророчество Agile наконец исполнилось!

• Время между поставками по проекту наконец-то становится малым и гибким! Нет необходимости называть его «спринтом» и превращать в постоянную гонку со временем. Качество создаваемого ПО существенно вырастет, потому что изменение масштаба свободно от ограничений жёстко заданных промежутков времени.
• Оценки выполняются так, как и должны: интуитивно и на основании предыдущего опыта, подтверждённого на уровне команды. В разработке ПО больше, чем во всех других отраслях, время должно считаться относительной величиной.
• Наряду с руководством в планировании должны участвовать люди, исполняющие запланированное, чтобы они могли обсудить это и найти изъяны, чтобы осталось время устранить их без стресса. Работу берёт на себя каждый отдельный участник, она не назначается руководителем/менеджером.
• Исполнение даёт ощущение влияния. У каждого разработчика в зависимости от его опыта должна быть определённая степень технической свободы и ощущение ответственности по отношению к продукту, коллегам и стейкхолдерам. Это снижает зависимости, делает команду разработки более независимой и более быстрой. Ежедневные обновления наконец-то отражают статус баг-трекера, информационных потоков и документации.
• Ежедневно назначаемые задачи коротки и дают реальную информацию о выполняемой работе. Никто не ощущает потребности заполнять свой список дел мелкими задачами или лгать о том, что он отстаёт или опережает график.
• Блокирующие проблемы устраняются внутри команды, всей командой, без необходимости взаимодействия с многоуровневым руководством и взятием на себя ответственности за каждое решение, каким бы ни был результат.
• О результатах сообщают с полной прозрачностью и действительно показывают статус даже самым сложным стейкхолдерам (обычно «самым важным» клиентам). Цель — получить реальную обратную связь, а не поглаживания по голове.
• Проверка выполненного выполняется честно и без обвинений, чтобы люди перестали манипулировать данными с целью создать впечатление, что они неплохо справляются, и вместо этого сосредоточились на устранении первопричин проблем.
• Бэклог наконец становится общей ответственностью и непрерывным процессом. Вы будете поражены эффектом этого простого (но нетривиального пункта).

Исправление

• Отнеситесь к ретроспективному совещанию серьёзно, как к моменту рефлексии с чистым разумом над тем, что оказалось хорошей стратегией, о том, как итеративно над ней работать, и как к времени благодарности команде за проделанную работу. Да, разумеется, вам также понадобится подумать, что прошло не так, почему и как это улучшить.
• Вместо обратной связи спрашивайте советов о том, как улучшить работу. Люди любят давать советы (иногда непрошенные, но это уже другая история), это помогает избежать «пустой» обратной связи и ответов «всё хорошо» или «всё плохо»; при получении хорошего совета его можно сразу применить, просьба о совете заставляет человека почувствовать себя более заслуживающим доверия, чем при просьбе о «простой» обратной связи.
• Доверяйте команде, будьте честными и перестаньте пытаться заниматься её микроменеджментом. Старайтесь больше делегировать и быть гибким, вы увидите, что предоставление свободы приводит к созданию более здоровой среды, в которой легче учиться быть ответственными, даже когда руководство не смотрит.
• Помните, что метрики иногда лгут, если вы не относитесь к ним критично, не впадайте в привычную склонность подтверждения своей точки зрения. Подходящее время для одной из моих самых любимых цитат: «если мучать данные достаточно долго, они признаются в чём угодно», — Рональд Коуз.
• Мотивируйте не бояться ошибок, признавайте их и устраняйте их без страха результатов анализа производительности. Перестаньте рассматривать под микроскопом все ошибки, сделанные разработчиками в предыдущем спринте, это только снизит их производительность и создаст токсичную рабочую среду.
  
  Нужно изучать ошибку, но не человека. Видите, что у разработчика возникли проблемы? Попробуйте расспросить, как у него дела, дайте ему передохнуть, и посмотрите на результаты в следующей итерации.

Знаю, что некоторые из вас подумают, что сказанное мной — это чушь.

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

Давайте теперь снова прочитаем манифест:

Люди и взаимодействия важнее процессов и инструментов

Работающее ПО важнее исчерпывающей документации

Совместная работа с клиентом важнее обсуждения контракта

Реагирование на изменения важнее следования плану

На этот раз вы не можете сказать, что заголовок был кликбейтом:

Scrum действительно ужасен.

Если только не сделать его Agile.

То есть гибким, адаптирующимся, совместным, подстроенным под людей и сосредоточенным на результатах, а не на метриках.

Узнавайте о новых акциях и промокодах первыми из нашего Telegram-канала ?