Как стать автором
Обновить

Сторипоинты опасны для разработки клиент-серверных приложений

Время на прочтение3 мин
Количество просмотров8K

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


Команда наша состояла из аналитика, тестировщика, дизайнера и 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 разработчиков, которые сразу оценивают работу в двух направлениях.

Теги:
Хабы:
Всего голосов 19: ↑14 и ↓5+9
Комментарии74

Публикации

Истории

Работа

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань