Этот небольшой рассказ будет посвящен тому, как не попасть в ловушку мнимого контроля над процессом оценки задач на предстоящий спринт. Сразу оговорюсь, что представленные ниже данные носят лишь ориентировочный характер и комментарии по поводу неиспользования чисел Фибоначчи для целей оценки здесь будут излишними.
Наша команда состояла из аналитика, тестировщика, дизайнера и 2-х разработчиков, но для большей наглядности оставим только разработчиков.
Начинаем новый спринт и плавно переходим к оценке пользовательских историй.
Ничего нового.
Вперед, продолжать.
Планирование завершено, и результаты можно увидеть выше.
Мы взяли 3 пользовательские истории, оцененные в 16, 20 и 37 Story Points соответственно.
Всего – 73. Далее, как любая уважающая себя команда разработчиков, любящая все прелести работы в Scrum, вносим эти оценки в Jira. При этом мы вводим только общие (или средние – что еще хуже!) оценки для каждой истории.
Две недели работы, не отрывая рук от клавиатуры и не вставая с так любимого годами офисного кресла и вы сможете лицезреть новый функционал.
Но в чем дело? Спринт закончился и мы видим, что передний сделал всё как планировал и не успел бы сделать ни одного нажатия клавиши, а вот задний вышел за рамки спринта и выполнил больше задач, чем планировал.
И тут появляется ПМ, только что дочитавший Скрам и XP из окопов, и говорит: «Всё понятно!!! Мне нужно набрать больше сторипойнтов для следующего спринта и тогда все будет хорошо и никто от меня больше не убежит, забрав с собой смену масштаба!! Планируем новый спринт. 
Большой! Мы взяли ещё 10 стори поинтов!!! Теперь мы всё точно рассчитали!! Пролетают еще 2 недели и пора подводить итоги.
Но, к всеобщему сожалению, спринт все равно завершился совсем не так, как нам хотелось.
Назад снова по каким-то причинам взяли на себя инициативу, а передние не успели сделать то, что задумали (опустим возможность, что впереди всего лишь неопытный младший, а сзади - неприкасаемый сеньор, а представьте себе, что все дело в неправильном планировании).
Очередной спринт не удался!!! Но почему, мы взяли совсем немного больше сюжетных линий и то только в добрых целях - обеспечить необходимый объем работы серверной части??!? Как это может быть?? Ответ в том, что все дело в самой рейтинговой системе.
Давайте вернемся к нашим спринтам.
Что мы видим? Получается, что взяв для нового спринта больше сторипойнтов для загрузки задней части, мы загрузили только переднюю.
Поняв это, первая мысль в безумной голове ПМ — нужно узнать, сколько сторипоинтов взял на себя фронт, а сколько — назад. Но глядя на общий рейтинг в Jira, это просто невозможно, потому что там можно узнать только общий (ну или средний) рейтинг каждой истории, и запомнить, кто какие оценки поставил, уже невозможно.
А дальше решение приходит само.
Чтобы успешно регулировать нагрузку команды, необходимо вести не только общий учет в сторипойнтах, но и раздельный учет в разрезе нагрузки на фронт и тыл.
Это позволит узнать оптимальный объем работы по каждому направлению и на его основе заполнить бэклог спринта.
Пока этот подход невозможно реализовать в Jira без отдельного ведения заметок в MS Excel, но это не значит, что его не следует использовать.
Я уверен, что со временем разработчики Atlassian придут к решению этой проблемы, а пока просто не повторяйте наших ошибок! P.S. Эти выводы применимы только для разработки клиент-серверных приложений, где есть четкое разделение работы на фронтенд и бэкенд. Эта проблема не должна возникнуть у команды Full-Stack разработчиков, которые оценивают работу сразу в двух направлениях.
Теги: #Управление разработкой #Управление проектами #спринт #управление проектами #scrum
-
Гибридный Формат – Ни Рыба Ни Мясо Удаленно
19 Oct, 24 -
Новая Онлайн Игра Планета Железяка
19 Oct, 24 -
Игра «Технический Долг»
19 Oct, 24 -
Олимпийские Медали Из Старых Гаджетов
19 Oct, 24 -
10 Дзен-Лайфхаков
19 Oct, 24
