Этот небольшой рассказ будет посвящен тому, как не попасть в ловушку мнимого контроля над процессом эстимации задач на предстоящий спринт. Сразу оговорюсь, что представленные ниже данные носят лишь показательный характер и комментарии по поводу неиспользования для целей эстимации чисел Фибоначчи здесь будут лишними.
Команда наша состояла из аналитика, тестировщика, дизайнера и 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 разработчиков, которые сразу оценивают работу в двух направлениях.
Комментарии (40)
Frag
16.10.2019 11:51А оценки как происходят? Каждый для себя оценивает задачи (фронтэнд-девелопер и бэкэнд-девелопер), а общая оценка тасков складывается в оценку стори (и потом не ясно кто сколько оценивал)?
Throwable
16.10.2019 11:51+2То есть концептуальных вопросов по поводу валидности самой методологии и применяемых методов оценки у вас не возникает?
staticlab
16.10.2019 12:06В одной из команд мы внутри бизнес-задачи делали подзадачи для фронта, бэка и QA, каждой из таких подзадач можно было дать независимую оценку, при этом Джира сама суммирует оценку по всей задаче.
aPoStAI
16.10.2019 12:27+1Как вариант: можно вместо одной задачи создавать 2, одна для фронта, вторая для бека. И накидывать на спринт задачи исходя из скорости каждой группы отдельно. Мы делали так, было довольно удобно.
s-n-ushakov
16.10.2019 12:27И мешает ли что-нибудь нарезать задачи помельче — с разделением на фронт и бэк? Или на подзадачи разбить с разделением по командам?
staticlab
16.10.2019 12:46Кстати наличие нескольких команд разработки прямо противоречит Скраму.
s-n-ushakov
16.10.2019 12:54Ну, я наверно слово не самое удачное выбрал :) Наверно лучше не о командах говорить, а о группах… или о сегментах… А то, что трудоёмкость надо оценивать с учётом специализации участников — вроде нет наверно возражений ни у кого…
ktzv
16.10.2019 15:08+1В Jira можно создавать подзадачи. И вот эти задачи должны уже быть чисто бэк или чисто фронт. Вот и понятная разбивка по каждой пользовательской истории.
sup
16.10.2019 15:56Сторипоинты это абстракция, которая не должна равняться времени. Но реально человек всё равно оценивает таски по времени и вся эта система начинает худо-бедно работать только когда сторипоинт становится эквивалентом какого-то большого временного промежутка, чтобы иметь запас на непредвиденные трудности. И вообще, сторипоинты это для менеджеров, вы-то всё равно ваши юзерские истории расписываете на таски оцененные в реальных часах и только после этого соглашаетесь на спринт, разве нет?
codecity
16.10.2019 16:50TFS многие не любят и осуждают (не попробовав) за недружелюбность, однако эта проблема там решена из коробки. Есть два уровня: требования с т.з. заказчика/пользователя и разбиение этих требований на конкретные задачи, которые понятны разработчику.
harry2019
16.10.2019 17:38ИМХО лучше часы, чем сторипоинты. Такой пример. Предположим, что есть 2 команды. Первая команда говорит, что оценивает новую большую фичу в 100 сторипоинтов, вторая говорит, что 150. PM выбирает команду номер 1, потом оказывается, что в среднем у команды номер 1 — 1 сторипоинт = 1 час, а у второй 1 сторипоинт = 0.5 часа.
Кроме того в JIRA весьма специфически считаются KPI по сторипоинтам. Не закрыли внутри большой стори малюсенькую таску, а спринт закончился и вот вам KPI, за который вас побьют )VolCh
17.10.2019 06:14Если это "потом оказывается", значит менеджер не понимает, что такое сторипоинты. Он на этапе выбора должен знать сколько сторипоинтов делает в среднем за спринт каждая команда.
Я глубоко убеждён, что каждая таска в джире при работе по скраму, оцененная в СП должна быть способна доставляться (релизиться) независимо от других. Соответственно и списываются СП.
Arsikman
16.10.2019 19:04EvgSrm в джире можно настроить суммирование сторипоинтов в сторе исходя из проставленных стори поинтов в подзадачах. Если нет прав на редактирование джиры, попросите джира администраторов сделать такую надстройку. тогда можно будет планировать и стори поинты в сумме и стори поинты по подразделениям
ApeCoder
16.10.2019 23:38+1И тут появляется только что закончивший читать Scrum and XP from the Trenches PM и говорит
Если я правильно понимаю, что написано в книжке и вашу ситуацию, то увеличить количество сторипоинтов на следующую итерацию это против книжки потому, что считаются только готовые истории, а те, в которых сделан только бекенд не считаются.
А что, если история была почти закончена? Почему мы не используем дробные значения для таких
историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и
бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке
продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing
the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.С моей точки зрения в духе книжки было бы попросить бекенд помочь фронтенду на простых или вспомогательных задачах — ситуация аналогична главе Чем занимается тестировщик, когда нечего тестировать. Либо устранением технического долга — внутренними вещами — если они совсем ничем не могут помочь спринту.
mad_nazgul
17.10.2019 08:28Странно, почему команда специализированная, а не fullstack?!
staticlab
17.10.2019 12:16Команда кроссфункциональная, это разработчики в ней специализированные.
mad_nazgul
17.10.2019 13:41Тогда PM делает какую-то дичь.
Считать эффективность надо по самому слабому компоненту (здесь фронтенд)
Его надо усилять, а не сторипоинты раскидывать.VolCh
17.10.2019 15:56Логика простая: полкоманды сидит полспринта без тасок в спринте и команда сделала N SP за спринт. Умножаем в следующем спринте SP на 1.25. Проблема в том, что на эти 25% берутся не чисто бэкенд задачи.
mad_nazgul
18.10.2019 06:27Так проблема не в сторипоинтах, а проблема в фронтендерах.
Ее надо решать, а не сторипоинты двигать.staticlab
18.10.2019 10:47Иногда это неэффективно в долгосрочной перспективе, потому что, во-первых, нагрузка может быть неравномерной (в начальной фазе фронтендеры интенсивно верстают интерфейс, затем потихоньку дорабатывают логику), во-вторых, если в компании свободных фронтендеров нет, то пока их будут искать, проект уже может закончиться.
VolCh
18.10.2019 11:41Проблема в том, что соотношение "капасити" фронтов и бэков не соответствует тому, что попадает в спринт. решать можно по разному, вплоть до уменьшения числа бэков. Но просто "с улицы" советовать без понимания сути проекта, планов на него, возможностей компании и т. п. — как-то не очень разумно.
vintage
17.10.2019 18:36+1Потому что грамотных фулстеков не существует?
mad_nazgul
18.10.2019 06:30Скажем так. Если команда кроссфункциональная, то либо надо забить, что кто-то недогружен. Либо как-то решать проблему «слабого звена».
Одно из решений создавать фуллстек команду.ApeCoder
18.10.2019 09:49Кстати, решение "те, кто освободились, помогают тем кто работает" делает потихонечку всех T-shaped
Asen
18.10.2019 12:07Scrum предполагает, что каждый участник команды — компетентный профессионал, а не Джун. В скрам-командах джуны не участвуют.
vintage
18.10.2019 14:15-1Во большинстве компаний компетентных профессионалов даже на одну скрам команду не наберётся и то их по одному растаскивают по разным проектам.
tumbler
А может дело в разбиении на задачи, ведь если каждая User Story несбалансирована по фронт/беку, то и суммарный результат никогда не будет сбалансирован?
EvgSrm Автор
Но ведь User Story от слова User. Пользователь озвучивает какую функциональность хочет и, в рамках этой функциональности происходит декомпозиция на конкретные таски. Было странно и довольно сложно для всех (особенно для БА) составлять Истории сразу пытаясь просчитать сколько в ней работы по каждому из направлений
tumbler
Если разбиение мельче чем на UserStory делать запрещено, то единственное оставшееся решение — каждый спринт менять размер команды (балансировать бекенд/фронтенд в зависимости от баланса взятых задач). Вот цирк-то будет...
RouR
Вот и делайте декомпозицию, одну таску на фронт, одну на бэк. Бэк закончил, выставил свой статус.
User Story — используется для описания требований и тестирования.
А подзадачи — для планирования работ.
Смешать всё в одной таске, нуу, надо уметь, у вас не получилось.
VolCh
Я, как пользователь API сервера, хочу отправить HTTP запрос такой-то, получить ответ такой-то и произвести такие изменения состояния сервера...?