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

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


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

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +2

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

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

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

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

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

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

            0

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

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

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

              0

              Поздравляю, вы изобрели Бочку Либиха.

                0

                В одной из команд мы внутри бизнес-задачи делали подзадачи для фронта, бэка и QA, каждой из таких подзадач можно было дать независимую оценку, при этом Джира сама суммирует оценку по всей задаче.

                  0

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

                    0

                    У нас суммирование было в сторипоинтах. Насчёт часов не уверен.

                  +3
                  Как вариант: можно вместо одной задачи создавать 2, одна для фронта, вторая для бека. И накидывать на спринт задачи исходя из скорости каждой группы отдельно. Мы делали так, было довольно удобно.
                    +1
                    И мешает ли что-нибудь нарезать задачи помельче — с разделением на фронт и бэк? Или на подзадачи разбить с разделением по командам?
                      0

                      Кстати наличие нескольких команд разработки прямо противоречит Скраму.

                        0
                        Ну, я наверно слово не самое удачное выбрал :) Наверно лучше не о командах говорить, а о группах… или о сегментах… А то, что трудоёмкость надо оценивать с учётом специализации участников — вроде нет наверно возражений ни у кого…
                          +1

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

                            0

                            Само собой, главное не попытаться разделить их по отдельным скрамам.

                              0

                              Кстати противоречат: «Скрам не признает подкоманд в Команде Разработки, независимо от областей, над которыми необходимо работать (например, тестирование, архитектура, эксплуатация или бизнес-аналитика). Это правило не имеет исключений.»

                                0

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

                                  0

                                  Это The Scrum Guide.

                          +1

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

                            +1

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

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

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


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

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

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

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

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


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

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

                                      0
                                      Странно, почему команда специализированная, а не fullstack?!
                                        0

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

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

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

                                              0
                                              Так проблема не в сторипоинтах, а проблема в фронтендерах.
                                              Ее надо решать, а не сторипоинты двигать.
                                                0

                                                Иногда это неэффективно в долгосрочной перспективе, потому что, во-первых, нагрузка может быть неравномерной (в начальной фазе фронтендеры интенсивно верстают интерфейс, затем потихоньку дорабатывают логику), во-вторых, если в компании свободных фронтендеров нет, то пока их будут искать, проект уже может закончиться.

                                                  0
                                                  Вот! Вообще по этому поводу я много смотрел видосов Максима Дорофеева.
                                                  Он как раз разбирает способы повышения эффективности команд.
                                                  0

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

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

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

                                                        0

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

                                                          0

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

                                                            +1

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

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

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


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

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

                                                                0

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


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

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

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


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

                                                                  Это да

                                                                    0

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


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

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

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


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

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

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


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

                                                                              0
                                                                              Нет не уверен. Просто предлагаю варианты.
                                                                          0

                                                                          То есть сразу ломаем Скрам, дробим команду на несколько, попутно усложняя процесс и взаимодействие. Ради чего, если команда небольшая?


                                                                          А если команда большая, то разделение, как и подбор подходящей методологии разработки очевидны.

                                                              0
                                                              Ну один из способов балансировки fullstack программисты. :-)
                                                                –2

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

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

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

                                                    0

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

                                                      –1

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

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

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

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

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

                                                      0

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

                                                      0

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

                                                        –1

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

                                                          +1

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

                                                            0

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

                                                              0

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

                                                                0

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

                                                                  0

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


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

                                                                    0

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

                                                                      –1

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

                                                              0

                                                              Нет. Кроссфункциональной должна быть команда, а отдельные разработчики могут быть специализированными (далее цитаты из перевода The Scrum Guide):


                                                              команда обладает всеми навыками, которые необходимы для создания Инкремента Продукта

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

                                                              Смысл состоит в том, что Скрам не работает, если какая-то задача по разработке продукта зависит от внешних факторов. Например, если для команды разработки выделен внешний дизайнер, который параллельно ведёт несколько проектов, а потому часто «уходит в себя»; или производится интеграция с внешней системой, доработкой которой занимается другая команда разработки. Такое невероятно часто встречается в реальных компаниях, но Скрам так работать не будет и положительный результат не гарантируется: дизайнер будет выпадать из контекста, может пропадать на время и проваливать сроки, внешняя команда разработки работает по своему процессу со своим беклогом и т.д.

                                                                +1

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

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое