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

Комментарии 74

А может дело в разбиении на задачи, ведь если каждая User Story несбалансирована по фронт/беку, то и суммарный результат никогда не будет сбалансирован?

Но ведь User Story от слова User. Пользователь озвучивает какую функциональность хочет и, в рамках этой функциональности происходит декомпозиция на конкретные таски. Было странно и довольно сложно для всех (особенно для БА) составлять Истории сразу пытаясь просчитать сколько в ней работы по каждому из направлений

Если разбиение мельче чем на UserStory делать запрещено, то единственное оставшееся решение — каждый спринт менять размер команды (балансировать бекенд/фронтенд в зависимости от баланса взятых задач). Вот цирк-то будет...

раздельный учет в разрезе нагрузки на фронт и бэк.

Вот и делайте декомпозицию, одну таску на фронт, одну на бэк. Бэк закончил, выставил свой статус.

User Story — используется для описания требований и тестирования.
А подзадачи — для планирования работ.
Смешать всё в одной таске, нуу, надо уметь, у вас не получилось.

Я, как пользователь API сервера, хочу отправить HTTP запрос такой-то, получить ответ такой-то и произвести такие изменения состояния сервера...?

А оценки как происходят? Каждый для себя оценивает задачи (фронтэнд-девелопер и бэкэнд-девелопер), а общая оценка тасков складывается в оценку стори (и потом не ясно кто сколько оценивал)?

То есть концептуальных вопросов по поводу валидности самой методологии и применяемых методов оценки у вас не возникает?

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

В стори поинтах суммирует или в часах?

НЛО прилетело и опубликовало эту надпись здесь
Как вариант: можно вместо одной задачи создавать 2, одна для фронта, вторая для бека. И накидывать на спринт задачи исходя из скорости каждой группы отдельно. Мы делали так, было довольно удобно.
И мешает ли что-нибудь нарезать задачи помельче — с разделением на фронт и бэк? Или на подзадачи разбить с разделением по командам?
НЛО прилетело и опубликовало эту надпись здесь
Ну, я наверно слово не самое удачное выбрал :) Наверно лучше не о командах говорить, а о группах… или о сегментах… А то, что трудоёмкость надо оценивать с учётом специализации участников — вроде нет наверно возражений ни у кого…

Функциональные команды в составе кроссфункциональной не противоречат.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

1) Как я понимаю, это уже конкретная трактовка скрама
2) То, что он не признаёт, не значит, что их не может быть. Скорее всего, имеется в виду, что не должно быть изменений в процессе, зависящих от наличия команд. Все должны участвовать в планированиях, дейли, ретро и т. п. независимо от специализации. Очень частая картина, когда разобрали задачи по фронту и бэку и пошли их обсуждать отдельно, а тестировщики вообще не участвуют в груминге/планировании

НЛО прилетело и опубликовало эту надпись здесь

В Jira можно создавать подзадачи. И вот эти задачи должны уже быть чисто бэк или чисто фронт. Вот и понятная разбивка по каждой пользовательской истории.

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

TFS многие не любят и осуждают (не попробовав) за недружелюбность, однако эта проблема там решена из коробки. Есть два уровня: требования с т.з. заказчика/пользователя и разбиение этих требований на конкретные задачи, которые понятны разработчику.
ИМХО лучше часы, чем сторипоинты. Такой пример. Предположим, что есть 2 команды. Первая команда говорит, что оценивает новую большую фичу в 100 сторипоинтов, вторая говорит, что 150. PM выбирает команду номер 1, потом оказывается, что в среднем у команды номер 1 — 1 сторипоинт = 1 час, а у второй 1 сторипоинт = 0.5 часа.
Кроме того в JIRA весьма специфически считаются KPI по сторипоинтам. Не закрыли внутри большой стори малюсенькую таску, а спринт закончился и вот вам KPI, за который вас побьют )

Если это "потом оказывается", значит менеджер не понимает, что такое сторипоинты. Он на этапе выбора должен знать сколько сторипоинтов делает в среднем за спринт каждая команда.


Я глубоко убеждён, что каждая таска в джире при работе по скраму, оцененная в СП должна быть способна доставляться (релизиться) независимо от других. Соответственно и списываются СП.

EvgSrm в джире можно настроить суммирование сторипоинтов в сторе исходя из проставленных стори поинтов в подзадачах. Если нет прав на редактирование джиры, попросите джира администраторов сделать такую надстройку. тогда можно будет планировать и стори поинты в сумме и стори поинты по подразделениям

Мне утверждают, что нельзя такого "из коробки", вернее "из облака"

И тут появляется только что закончивший читать Scrum and XP from the Trenches PM и говорит

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


А что, если история была почти закончена? Почему мы не используем дробные значения для таких
историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и
бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке
продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing
the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.

С моей точки зрения в духе книжки было бы попросить бекенд помочь фронтенду на простых или вспомогательных задачах — ситуация аналогична главе Чем занимается тестировщик, когда нечего тестировать. Либо устранением технического долга — внутренними вещами — если они совсем ничем не могут помочь спринту.

Странно, почему команда специализированная, а не fullstack?!
НЛО прилетело и опубликовало эту надпись здесь
Тогда PM делает какую-то дичь.
Считать эффективность надо по самому слабому компоненту (здесь фронтенд)
Его надо усилять, а не сторипоинты раскидывать.

Логика простая: полкоманды сидит полспринта без тасок в спринте и команда сделала N SP за спринт. Умножаем в следующем спринте SP на 1.25. Проблема в том, что на эти 25% берутся не чисто бэкенд задачи.

Так проблема не в сторипоинтах, а проблема в фронтендерах.
Ее надо решать, а не сторипоинты двигать.
НЛО прилетело и опубликовало эту надпись здесь
Вот! Вообще по этому поводу я много смотрел видосов Максима Дорофеева.
Он как раз разбирает способы повышения эффективности команд.

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

Так я и говорю. Что проблема не в сторипинтах. А проблема в другом. Команда собрана не сбалансировано. И тут не сторипоинты надо двигать, а проблему решать.

А вы её никогда и не сбалансируете. Если, конечно, команда не формошлёпством занимается. Проблема тут как раз в том, что вам сказали, что баллансировка возможна, а вы и уши развесили.

То есть любое соотношение бека и фронта эквивалентно? Можно оставить один бек и решать все задачи?

Если они согласятся фронтом заниматься :)

Боюсь даже спрашивать какая чёрная магия позволила вам сделать такой вывод. Но если вам нужно решение, то оно простое — отдельно оценивать и набирать в спринт задачи по каждой специализации.

Боюсь даже спрашивать какая чёрная магия позволила вам сделать такой вывод.

"Сбалансировать" — достигнуть наилучшего соотношения фронта и бека для решения поставленных задач. Если нельзя достигнуть наилучшего соотношения, то все соотношения одинаковы — в том числе один бек.


Но если вам нужно решение, то оно простое — отдельно оценивать и набирать в спринт задачи по каждой специализации.

Т.е. результатом спринта может быть что-то неготовое к использованию, например, сделан один бек без фронта?

Логика так не работает.


Да в этом спринте что-то полуготовое, зато в следующем будет готово больше чем обычно. А ещё есть куча не продуктовых задач, которые тоже надо делать.

зато в следующем будет готово больше чем обычно.

Да, если объем работы для Бека и фронта в среднем статистически соответствует их возможностям. То есть команда сбалансирована. Иначе будет просто накопление wip


А ещё есть куча не продуктовых задач, которые тоже надо делать.

Это да

Ну так это и есть "формошлёпство", когда среднее соотношение объёмов работы для бэка и фронта не меняется со временем и его можно статистически предсказать.


На проектах по-сложнее, во-первых, это соотношение будет постоянно плавать туда-сюда, а во-вторых будут появляться чисто бековые или чисто фронтовые задачи.

Если задача «чисто бековая», может выделить ее в отдельный микросервис и отдать её «чисто бековой команде»?! :-)

Посмотрю я как вы будете выделять в микросервис оптимизацию обработки какого-нибудь запроса. Или тюнинг процесса сборки. Или просто исправление бага.


Кроме того, не вполне понятна мотивация отдавать задачу другой команде, когда свои бэкендеры простаивают.

Если запрос «тяжелый», может его сделать ассинхронным выделит в какой-то микросервис, который будет принимать и обрабатывать такие запросы? :-)

А вы уверены, что такое решение ускорит обработку запроса, а не замедлит его?


И уверены ли вы, что такое архитектурное решение допустимо принимать ещё на этапе раздумий кому бы дать задачу, а не в процессе её решения, после изучения существующего кода?

Нет не уверен. Просто предлагаю варианты.
НЛО прилетело и опубликовало эту надпись здесь
Ну один из способов балансировки fullstack программисты. :-)

В строительстве тоже есть такие балансировщики, разнорабочими называются.

Я знаю, что «универсал, это тот кто делает все одинаково плохо».
fullstack — это один из способов.
Другой способ — увеличение frontend'еров.
Самый простой способ — просто подстроиться по ритм работы фронтендеров. А то, что бакендеры «прохлаждаются» — забить. :-)

Потому что грамотных фулстеков не существует?

Грамотные (опытные) фуллстеки существуют, одинаково хорошо выполняющих фронт и бэк нет, всегда перекос в 70-30 / 60-40, а вот 50-50 нет .

То есть стоят как сеньёры, а сами не выше мидла.

Скажем так. Если команда кроссфункциональная, то либо надо забить, что кто-то недогружен. Либо как-то решать проблему «слабого звена».
Одно из решений создавать фуллстек команду.

Кстати, решение "те, кто освободились, помогают тем кто работает" делает потихонечку всех T-shaped

Так они не «свою работу работают», а работают в команде.
Для fullstack-разработчиков нет «не моей задачи».
Есть задачи, которые сделаны и есть, которые предстоит сделать. :-)

Scrum предполагает, что каждый участник команды — компетентный профессионал, а не Джун. В скрам-командах джуны не участвуют.

Во большинстве компаний компетентных профессионалов даже на одну скрам команду не наберётся и то их по одному растаскивают по разным проектам.

может назначать сторипоинты таскам? да ну бред какой-то
сарказм

Разве скрам не требует взаимозаменяемости всех членов команды? Если бэк сделал все задачи по бэку, он должен не брать новые, а делать фронт, дизайнить дизайн или тестировать.

… или помыть полы, или сделать массаж напряжённым членам команды.

Только если уборщи(к)ца и массажистка являются частью команды и участвуют в стэндапах, планировании, груминге и ретроспективах.

От того, что вы включите массажистку в команду; бэкендер не станет хорошим массажистом.

Да, будет делать как может, и на выходе получится херня. Но в скраме так положено — насколько я знаю.

Не для всех видов массажа необходим хороший массажист, насколько я знаю. Некоторые виды массажа непрофессиональные люди волне успешно делают друг другу.


Бекэнд может помочь фронтенду, например, со вспомогательными — развертывание сред, воспроизведение багов, тестирование и т.д.

Расскажите руководителю компании про работающих в ней непрофессиональных массажистов на зарплате профессиональных разработчиков.

Лучше вы расскажите — это ж у вас принят "массаж напряженным членом" а у нас и фронт и бек — разработчики.

НЛО прилетело и опубликовало эту надпись здесь

Не требует. Он требует, чтобы команда содержала в себе всех, кого надо, чтобы решить задачу. Требует, чтобы часть задачи не делегировалась куда-то на сторону. Вот частая картина, когда одна девопс команда обслуживает множество команд разработки. В такой ситуации в definition of done команды не должно быть пунктов о, грубо говоря, деплое релизов. Или выделенные команды тестировщиков: тогда прохождения их тестов не должно быть.

НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории