Comments 74
А может дело в разбиении на задачи, ведь если каждая User Story несбалансирована по фронт/беку, то и суммарный результат никогда не будет сбалансирован?
Если разбиение мельче чем на UserStory делать запрещено, то единственное оставшееся решение — каждый спринт менять размер команды (балансировать бекенд/фронтенд в зависимости от баланса взятых задач). Вот цирк-то будет...
раздельный учет в разрезе нагрузки на фронт и бэк.
Вот и делайте декомпозицию, одну таску на фронт, одну на бэк. Бэк закончил, выставил свой статус.
User Story — используется для описания требований и тестирования.
А подзадачи — для планирования работ.
Смешать всё в одной таске, нуу, надо уметь, у вас не получилось.
Я, как пользователь API сервера, хочу отправить HTTP запрос такой-то, получить ответ такой-то и произвести такие изменения состояния сервера...?
То есть концептуальных вопросов по поводу валидности самой методологии и применяемых методов оценки у вас не возникает?
Функциональные команды в составе кроссфункциональной не противоречат.
1) Как я понимаю, это уже конкретная трактовка скрама
2) То, что он не признаёт, не значит, что их не может быть. Скорее всего, имеется в виду, что не должно быть изменений в процессе, зависящих от наличия команд. Все должны участвовать в планированиях, дейли, ретро и т. п. независимо от специализации. Очень частая картина, когда разобрали задачи по фронту и бэку и пошли их обсуждать отдельно, а тестировщики вообще не участвуют в груминге/планировании
В Jira можно создавать подзадачи. И вот эти задачи должны уже быть чисто бэк или чисто фронт. Вот и понятная разбивка по каждой пользовательской истории.
Сторипоинты это абстракция, которая не должна равняться времени. Но реально человек всё равно оценивает таски по времени и вся эта система начинает худо-бедно работать только когда сторипоинт становится эквивалентом какого-то большого временного промежутка, чтобы иметь запас на непредвиденные трудности. И вообще, сторипоинты это для менеджеров, вы-то всё равно ваши юзерские истории расписываете на таски оцененные в реальных часах и только после этого соглашаетесь на спринт, разве нет?
Кроме того в JIRA весьма специфически считаются KPI по сторипоинтам. Не закрыли внутри большой стори малюсенькую таску, а спринт закончился и вот вам KPI, за который вас побьют )
Если это "потом оказывается", значит менеджер не понимает, что такое сторипоинты. Он на этапе выбора должен знать сколько сторипоинтов делает в среднем за спринт каждая команда.
Я глубоко убеждён, что каждая таска в джире при работе по скраму, оцененная в СП должна быть способна доставляться (релизиться) независимо от других. Соответственно и списываются СП.
И тут появляется только что закончивший читать Scrum and XP from the Trenches PM и говорит
Если я правильно понимаю, что написано в книжке и вашу ситуацию, то увеличить количество сторипоинтов на следующую итерацию это против книжки потому, что считаются только готовые истории, а те, в которых сделан только бекенд не считаются.
А что, если история была почти закончена? Почему мы не используем дробные значения для таких
историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и
бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке
продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing
the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.
С моей точки зрения в духе книжки было бы попросить бекенд помочь фронтенду на простых или вспомогательных задачах — ситуация аналогична главе Чем занимается тестировщик, когда нечего тестировать. Либо устранением технического долга — внутренними вещами — если они совсем ничем не могут помочь спринту.
Считать эффективность надо по самому слабому компоненту (здесь фронтенд)
Его надо усилять, а не сторипоинты раскидывать.
Логика простая: полкоманды сидит полспринта без тасок в спринте и команда сделала N SP за спринт. Умножаем в следующем спринте SP на 1.25. Проблема в том, что на эти 25% берутся не чисто бэкенд задачи.
Ее надо решать, а не сторипоинты двигать.
Он как раз разбирает способы повышения эффективности команд.
Проблема в том, что соотношение "капасити" фронтов и бэков не соответствует тому, что попадает в спринт. решать можно по разному, вплоть до уменьшения числа бэков. Но просто "с улицы" советовать без понимания сути проекта, планов на него, возможностей компании и т. п. — как-то не очень разумно.
А вы её никогда и не сбалансируете. Если, конечно, команда не формошлёпством занимается. Проблема тут как раз в том, что вам сказали, что баллансировка возможна, а вы и уши развесили.
То есть любое соотношение бека и фронта эквивалентно? Можно оставить один бек и решать все задачи?
Если они согласятся фронтом заниматься :)
Боюсь даже спрашивать какая чёрная магия позволила вам сделать такой вывод. Но если вам нужно решение, то оно простое — отдельно оценивать и набирать в спринт задачи по каждой специализации.
Боюсь даже спрашивать какая чёрная магия позволила вам сделать такой вывод.
"Сбалансировать" — достигнуть наилучшего соотношения фронта и бека для решения поставленных задач. Если нельзя достигнуть наилучшего соотношения, то все соотношения одинаковы — в том числе один бек.
Но если вам нужно решение, то оно простое — отдельно оценивать и набирать в спринт задачи по каждой специализации.
Т.е. результатом спринта может быть что-то неготовое к использованию, например, сделан один бек без фронта?
Логика так не работает.
Да в этом спринте что-то полуготовое, зато в следующем будет готово больше чем обычно. А ещё есть куча не продуктовых задач, которые тоже надо делать.
зато в следующем будет готово больше чем обычно.
Да, если объем работы для Бека и фронта в среднем статистически соответствует их возможностям. То есть команда сбалансирована. Иначе будет просто накопление wip
А ещё есть куча не продуктовых задач, которые тоже надо делать.
Это да
Ну так это и есть "формошлёпство", когда среднее соотношение объёмов работы для бэка и фронта не меняется со временем и его можно статистически предсказать.
На проектах по-сложнее, во-первых, это соотношение будет постоянно плавать туда-сюда, а во-вторых будут появляться чисто бековые или чисто фронтовые задачи.
Посмотрю я как вы будете выделять в микросервис оптимизацию обработки какого-нибудь запроса. Или тюнинг процесса сборки. Или просто исправление бага.
Кроме того, не вполне понятна мотивация отдавать задачу другой команде, когда свои бэкендеры простаивают.
В строительстве тоже есть такие балансировщики, разнорабочими называются.
Потому что грамотных фулстеков не существует?
Грамотные (опытные) фуллстеки существуют, одинаково хорошо выполняющих фронт и бэк нет, всегда перекос в 70-30 / 60-40, а вот 50-50 нет .
Одно из решений создавать фуллстек команду.
Scrum предполагает, что каждый участник команды — компетентный профессионал, а не Джун. В скрам-командах джуны не участвуют.
может назначать сторипоинты таскам? да ну бред какой-то
сарказм
Разве скрам не требует взаимозаменяемости всех членов команды? Если бэк сделал все задачи по бэку, он должен не брать новые, а делать фронт, дизайнить дизайн или тестировать.
… или помыть полы, или сделать массаж напряжённым членам команды.
Только если уборщи(к)ца и массажистка являются частью команды и участвуют в стэндапах, планировании, груминге и ретроспективах.
От того, что вы включите массажистку в команду; бэкендер не станет хорошим массажистом.
Да, будет делать как может, и на выходе получится херня. Но в скраме так положено — насколько я знаю.
Не для всех видов массажа необходим хороший массажист, насколько я знаю. Некоторые виды массажа непрофессиональные люди волне успешно делают друг другу.
Бекэнд может помочь фронтенду, например, со вспомогательными — развертывание сред, воспроизведение багов, тестирование и т.д.
Не требует. Он требует, чтобы команда содержала в себе всех, кого надо, чтобы решить задачу. Требует, чтобы часть задачи не делегировалась куда-то на сторону. Вот частая картина, когда одна девопс команда обслуживает множество команд разработки. В такой ситуации в definition of done команды не должно быть пунктов о, грубо говоря, деплое релизов. Или выделенные команды тестировщиков: тогда прохождения их тестов не должно быть.
Сторипоинты опасны для разработки клиент-серверных приложений