Этот небольшой рассказ будет посвящен тому, как не попасть в ловушку мнимого контроля над процессом эстимации задач на предстоящий спринт. Сразу оговорюсь, что представленные ниже данные носят лишь показательный характер и комментарии по поводу неиспользования для целей эстимации чисел Фибоначчи здесь будут лишними.
Команда наша состояла из аналитика, тестировщика, дизайнера и 2-х разработчиков, однако для большей наглядности мы оставим только разработчиков.
Начинаем новый спринт и плавно переходим к оценке Пользовательских историй. Ничего нового. Идем дальше...
Планинг завершен и результаты можно увидеть выше. В работу взяли 3 Пользовательские истории оцененные в 16, 20 и 37 сторипоинтов соответственно. Итого – 73.
Далее, как и любая уважающая себя команда разработки обожающая все прелести работы по Scrum вносим эти оценки в Jira. При этом, вносим только общие (или средние – что еще хуже!) оценки по каждой истории.
Две недели работы не убирая рук с клавиатуры и не вставая с уже столь любимого годами офисного стула и можно созерцать новоиспеченную функциональность.
Но в чем же дело? Спринт закончился и мы видим, что фронт сделал всё как запланировали и ни на одно нажатие клавиши больше сделать бы не успел, а бэк вышел за рамки спринта и сделал больше задач чем планировалось.
И тут появляется только что закончивший читать Scrum and XP from the Trenches PM и говорит: «Все понятно!!! Надо взять на следующий спринт больше сторипоинтов и тогда-то все будет хорошо и никакой бэк от меня больше не убежит, прихватив с собой скоупчейндж!!»
Планируем новый спринт ….
Отлично! Взяли на 10 сторипоинтов больше!!! Теперь мы всё точно рассчитали!!
Еще 2 недели пролетают незаметно и пора подводить итоги.
Но ко всеобщему сожалению спринт все равно завершился совсем не так, как мы бы этого хотели.
Бэк опять почему-то вырвался вперед, а фронт вообще не успел сделать то, что планировали (возможность того, что фронт просто неопытный джун, а бэк неприкосновенный сеньор мы опустим и представим, что все дело лишь в неправильном планировании).
Очередной спринт был провален!!! Но почему, мы же взяли совсем немного больше сторипоитов и то, только для благих целей – чтобы дать необходимый объем работ для серверной части??!?
Как такое может быть?? Ответ — все дело в самой системе оценки. Вернемся к нашим спринтам.
Что же мы видим? Оказывается, взяв на новый спринт больше сторипоинтов чтобы загрузить бэк, мы лишь загрузили фронт.
Поняв это, первая мысль в шальной голове PMа – нужно узнать сколько сторипоинтов взял на себя фронт и сколько бэк. Но взглянув на общую оценку в Jira это просто невозможно, ведь все, что там можно узнать это общую (ну или среднюю) оценку по каждой истории, а вспомнить кто давай какие оценки уже нет возможности.
И тут решение приходит само. Для того, чтобы успешно регулировать нагрузку команды необходимо вести не только общий учет в сторипоинтах, но и раздельный учет в разрезе нагрузки на фронт и бэк. Это позволит узнать оптимальный объем работ для каждого направления и опираясь уже на него наполнять бэклог спринта. Пока данный подход нельзя реализовать в Jira без отдельного ведения заметок в MS Excel, но это не значит, что его не стоит применять.
Уверен со временем разработчики Atlassian придут к решению этой проблемы, а пока, просто не повторяйте наших ошибок!
P.S. Данные выводы применимы только для разработки клиент-серверных приложений, где происходит четкое разделение работы на фронт- и бэкэнд. Такой проблемы не должно возникать у команды Full-Stack разработчиков, которые сразу оценивают работу в двух направлениях.
