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

1. Неконтролируемое разрастание проекта. Сколь бы адекватным не был Product Owner (PO), по мере жизни проекта у него появляются новые желания/требования/изменения. Методология легко подстраивается под новые задачи, но никак их не контролирует. Поэтому легко в какой-то определенный момент получить вопросы типа «Откуда такой бюджет?», «Почему первоначальная оценка проекта в разы превышает потраченное время?» и проч. Решение нашли в новом типе задач в Jira и предоставление заказчику времени, которое расходуется на все его «хотелки»;

2. Время на багфиксинг. Важный и интересный момент, который не раскрывает Scrum. Время на фикс багов уходит и его надо «бронировать» в спринт. И основная проблема в том, что данная величина не является константной. Если в начале проекта это 0-20 часов, то ближе к концу может достигать до 50% от всего спринта. И это может быть серьезное проблемой, когда бюджет уже превышен. В таком случае помогает показаться отношение времени разработки к багфиксу, чтобы снять ложное впечатление, что последние спринты заказчик платит за наши ошибки;

3. Необходимы дополнительные метрики. Одного velocity крайне недостаточно, чтобы показать/увидеть насколько справляется команда. Во-первых, гонка за показателями может привести к переоценке сложности задач, во-вторых, этот показатель никак не отражает качество кода, в-третьих, он стимулирует на разработку новых фитч, но никак не на багфикс. И опять же кроме Product Owner-а может быть ряд заинтересованных лиц, которые реально не учувствуют в проекте, но подписывают счета и именно для них важно видеть куда и на что уходят время и деньги. Поэтому такие показатели как скорость тестирования, время на багфикс, количество багов/1000 строк кода и проч. рано или поздно приходится считать. Опять же желательно следить за разрастанием проекта и отслеживать появления сhange requests и новых задач, а это еще несколько типов stories;

4. Scrum предполагает формирование команды с самого начала проекта, но далеко не всегда удается сохранить ее в том же составе. Новые задачи могут потребовать новых специалистов, люди увольняются, на их замену приходят новые и т.п., что так или иначе приводит к сложному и времязатратному вовлечению в курс дел. Поэтому требуется актуальная документация и чем сложнее и продолжительнее проект, тем более объемная документация необходима.

5. Необходимо постоянно следить за тем, чтобы разработчики были взаимозаменяемыми (и на этой основе формировать команду), а иначе на проекте будут появляться блокеры, когда Вася ждет Петю, Петя ждет Колю, а Коля тупит. Опять же, если взаимозаменяемость в команде будет высокой, не возникнет проблем с отпусками и больничными.

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

Итого, простого следования методологии, даже вполне эффективной, может быть крайне недостаточно. Поэтому в руках у менеджера должны быть дополнительные инструменты, которые позволят увидеть проблему до того момента, когда ее уже надо будет решать. И именно поэтому на своих agile/scrum/kanban проектах мы пишем документацию, ведем учет требований, отслеживаем время на багфикс, тестирование, считаем дополнительные метрики. Обычно для команды это практически незаметно (за исключением тех.документации) и больше ложится на плечи менеджера проекта, но сторицей окупается тем, что делает проект полностью прозрачным для всех заинтересованных лиц.

Автор: DeBovuar

Источник