Как у нас скрам [не] работал

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

- "Будь как Василий!" — говорит мне Константин — владелец продукта. В отличие от меня он работает тут с незапамятных времен, многое повидал, в том числе и начало Agile трансформации компании.

- "Пример Василия, конечно воодушевителен и интересен, а можешь рассказать как у вас в целом процесс устроен и как вы к нему пришли?"

Начало пути было прозаическим до нельзя. Крупная международная компания с отечественными корнями и собственными продуктами пришла к своему величию благодаря двум столпам: глубокой экспертизе и проектной структуре. Если с экспертизой все понятно, то с проектами и подавно. Нужно что-то сделать или доделать — создаем проект. Планируем ресурсы, согласовываем сроки, заверяем на всех уровнях и вперед. Успели в срок — премия. Не успели чуток — премия для всех, кроме менеджера проекта. Ибо плохо планировал. Не успели совсем — без премии все. Но это в теории. На практике же менеджер проекта не видел премий практически никогда. Были и интересные курьезы: например, если человек увольнялся до завершения проекта, его премия делилась на оставшихся, бюджет же так и так спланирован.

Почему проекты были органичны для нашей компании, несмотря на наличие собственных продуктов? Во-первых, потому что основные продукты были зарегулированы стандартами различной международности. Во-вторых, потому что основным лейтмотивом бизнеса была максимальная гибкость в кастомизации решений под конкретных заказчиков. Но бесконечно дебит с кредитом на таких входных данных сходится не будет, если речь идет об R&D. В какой-то момент пришло понимание, что необходимо обновить и оптимизировать процессы, а также ускорить выпуск обновлений. Тогда цикл обновлений был от полугода…

Сказано — сделано! Что там было про ускорение цикла разработки? Там еще про прозрачность было… А, да вот же, Scrum! Впрочем проекты в джире мы тоже пока оставим, на всякий пожарный. Ага, и планирование оставим. И согласование.

Над одним из продуктов, назовем его SDK, работало тогда порядка 20 человек. Это собственно разработчики (бэк и фронт), эксперты, тестировщики, автотестеровщики. И четыре менеджера, один отвечающий за всё, и три за отдельные области. Чтобы долго не ходить, назвали это все одной Scrum командой.

Собственно дейлики получились достаточно томными. Представьте себе круг из >20 человек, каждый из которых отвечает по шаблону "Что делал вчера? Что буду делать сегодня? Какие проблемы испытываю?". В среднем со всеми паузами, шутками и погружением в детали проблем конкретных докладчиков такой митинг спокойно расходовал час. На каждом из митингов обязательно присутствовали менеджеры, чтобы держать руку на пульсе. А еще обязательно был представитель от команды UX дизайнеров. Откуда появились дизайнеры? Ну, они всегда были, просто в своей отдельной UX команде. А дейли разработки казался идеальным местом, где можно публично спросить о статусе UX задач. Из других Scrum активностей было только планирование спринта и отчет по количеству закрытых задач в конце.

В какой-то момент пришло понимание, что так продолжаться больше не может. Право дело сколько можно жить без естимейтов? Не зря же в Jira есть специальное место под Story Points. Сказано — сделано! Теперь каждая задача на планировании оценивается в идеальных часах. Идеальные часы — это не Ролексы если что. Идеальные часы — это такие часы, которые были самозабвенно и безраздельно потрачены на разработку фичи. То есть, туалет, перекуры и тестирование не учитываются, как и Scrum активности. В конце спринта смотрели сколько реально часов списано на закрытые задачи и высчитывали коэффициент погрешности, скажем 3.4, умножив на который все оценки бэклога и добавив процентов 30 можно спрогнозировать когда определенный функционал будет доставлен на прод. У нас же все еще есть планирование проектов для премий, помнишь?

Разработчики морщились, ворчали, но Scrum есть Scrum. Возможно так бы оно все и варилось дальше, если бы не случилось судьбоносное решение увеличить инвестиции в SDK. Команда разработки стремительно увеличилась до 30 человек. Плюс менеджеры, плюс UX, плюс на пиво. Просто перестали все помещаться в круг. А без круга терялось понимание кто должен говорить следующий на дейли. В общем бардак пришел также стремительно.

Делать нечего, пришлось департамент реорганизовывать. А делать это решили по профессиональному признаку. Новая структура включала в себя следующие команды:

Причем последний был ad hoc командой, собираемой из менеджера, разработчика и тестировщика раз в полгода. Но для полноты картины пускай будет.

В каждой команде были введены ретроспективы, а для красоты отчетности было решено использовать Burndown Chart, который предоставляла Jira. Буквально первый же спринт в новом сетапе команд выдал следующий график:

Каждая ступенька вниз — это закрытый тикет в Jira. И первая такая ступень встречается только к трети спринта. Поздно ли это? Пока не понятно.

На середине графика внезапно появляется ступень вверх. Это задача, которая была либо взята в разгар спринта как «очень очень срочная ну правда горит жжот», либо переоткрыта командой QA (при переоткрытии не изменяли поле Stoty Points) .

В конце графика идет резкая лесенка, подвисающая в воздухе. Откуда взялся этот воздух? В первую очередь это оверкоммитмент. Или по нашенскому — превеликое обязание. А во вторую… взгляни на следующий спринт:

Бодрая лесенка-то продолжается аж с первых минут! Это показывает наглядно зависимость между функциональными командами, когда команда QA не может работать в том же спринте, что и разработчики, поэтому задачи закрываются со смещением.

Также зависимости между командами иллюстрирует сплошная горизонтальная линия. Там сначала ждали текст спецификации, основанный на международных стандартах, затем ждали UX макеты, потом фронтенд ждал бэкенд, потом все ждали QA… В итоге закрыть успели одну задачу, не считая тех, что перевалились с предыдущего спринта и были закрыты в самом начале.

Почему происходило превеликое обязание или по ихнему оверкоммитмент? При планировании каждый разработчик набирал себе задач на спринт, ориентируясь на его собственное понимание идеальных часов. Коммитмент был не от команды, а от совокупности индивидуумов. Соответственно и ошибка была не средняя, а совокупная. И риск не завершить задачу вовремя множился, т.к. над ней работал как правило один человек (заболел, внезапные семейные дела — некому подстраховать) . Дополнительно сказывалось то, что в новый спринт автоматом брали и те задачи, что были отданы на тестирование, но не успели закрыть.

Зависимости же между командами были обречены на возникновение. Просто из-за самого факта деления по функциональному признаку. Если между Backend и Frontend еще можно было каким-то образом нивелировать негативный эффект за счет предварительного совместного проектирования интерфейсов, то с остальными зависимостями это уже провернуть не выйдет. Хотя пытались обойти и это. Например, перед имплементацией чего бы то ни было, сначала производилось исследование. Собиралась вся доступная информация о фиче, вычитывалась спецификация, уточнялись спорные моменты у экспертов, проверялись UX макеты… Затем все это упаковывалось в один или несколько Jira тикетов, чтобы непосредственный исполнитель мог просто взять и делать фичу в следующем спринте, без страха и сомнений. Проблема была в том, что каждый проводил эти предварительные исследования с разным качеством, поэтому страх, сомнения и дополнительные временные затраты на уточнения все равно имели место быть.

Возможно так бы оно все и варилось дальше, если бы не новое судьбоносное решение. Новая стратегия компании меняла фокус, и вместо универсального SDK требовался вполне конкретный набор продуктов. Сказано — реорганизовано! Новые команды включали:

Именно в таком сетапе удалось наконец-то достичь одной из главных изначальных целей: сократить время доставки обновлений. С полугода+ прыгнули до 1 месяца. А с началом СВО распрощались наконец с проектной бюрократией, ибо планировать anyway можно было не далее пары дней, хехе.

- "Кость, подожди. Но ведь эти результаты вообще не связаны со Scrum, разве нет?"

- "Хм, ну прозрачность то мы повысили? Повысили. Все в команде знают, кто что делает благодаря спринт планнингам и дейли. Менеджмент знает скорость и эстимейты — появилась предсказуемость. Цикл релизный, говорю ж, уменьшили в 6 раз — кастомеры будут довольны новыми фичами."

- "Гибкость?" — впрочем я уже примерно догадывался, что услышу в ответ.

- "И гибкость есть! Мы теперь выкидываем сравнимые задачи из спринта, если появляются срочные. Ну и каждый спринт планируем исходя из новых приоритетов." — Константин действительно верил в гибкую разработку.

- "Штош. Звучит… резонно. Так как сейчас выглядит burndown у Васи то?"

- "Ээээ… А что это после планируемой даты окончания спринта тянется?"

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

- "Так это же стабилизационный период! Их команда переоценивает остаток задач в течении спринта, но иногда не угадывают, поэтому вот, берут в конце таймаут на доделки."

Все имена и совпадения — чистые совпадения, а текст — вольная авторская интерпретация.

Поделитесь своими историями вкатывания в Scrum =)