Comments 20
Непонятно как рассчиталось количество SP для фичи. На примере первой: 5 дизайн, 1 фронт, 1 qa. Почему итог пять, если они делаются последовательно? На диаграмме Ганта размер блоков не соответствует оценке, что немного сбивает. ))
Итоговая оценка SP для фичи не зависит от последовательности работ над ней, вы просто оцениваете усилие команды. В первом примере наибольшие усилия потребуются от дизайнера, а 1 SP со стороны фронта, можно сказать, погрешность в данном случае. Итоговая оценка выбирается всеми участниками, часто в качестве итоговой выбирается оценка подкоманды, у которой больше всего возникнет трудностей. Точно могу сказать, что нельзя в качестве итоговой оценки брать среднее значение. Я поступаю так: команда оценила - обсудили, почему такие оценки поставили, - сошлись на некоторой общей оценке, которая всех устраивает, т.е. выбранная оценка покрывает предположительную сложность работы каждой подкоманды. p.s. Проверю размеры блоков, может, где-то промахнулся. Спасибо.
На самом деле SP вообще не пригодны для каких-то оценок, кроме оценок рисков (и тогда сводятся к майкам). Вообще использование SP в большинстве случаев антипаттерн, но в предложенной методике и так настолько много сомнительных решений, что одним больше или меньше - уже не важно.
Насчёт антипаттерна - любопытно. Дайте ссылочку, где почитать
Например есть статья от человека, который придумал SP: https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Про оценки сроков и трудоемкости неплохо написано у ДиМарко и Листера в "Вальсируя с медведями", короткий пересказ, например, в https://dev.to/tlakomy/why-i-don-t-like-story-point-driven-estimates-28h7
Но вообще бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать.
Вообще, Scrum как магнит притягивает к себе кучу разнообразных плохих практик, по вполне понятным причинам.
бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать
Говоря так, вы заблуждаетесь. Оценка в стори-поинтах обязательно соотносится с исполнителем. Только исполнитель в данном случае -- это не конкретный человек, а конкретная команда людей. И если состав команды изменился -- беклог следует переэстимировать.
Насчет сылок на статьи -- там речь, скорее, не про сами стори-поинты, а про их неправильное использование. Собственно, первый же коммент под одной из статей ровно об этом:
It seems to me that your issue isn't story points themselves, but the usage of them.
Story Points (in combination with Team Velocity) - allows PMO to forecast delivery, to know if the set of requirements is achievable by the deadline or not.
Story Points isn't, and shouldn't ever be, a way to measure developer productivity (either within a Team or between Teams). There's better tools for that job (such as Git Quick Stats).
Команда может быть исполнителем с предсказуемой производительностью только если:
1) структура команды не меняется
2) все сотрудники в команде являются одинаковыми по производительности
3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Все это приводит к бесполезности и оценки в SP и в оценке velocity вообще.
Тот же Рон про велосити пишет "If I invented velocity, I'm sorry" ( https://twitter.com/RonJeffries/status/1488220234750246919)
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Касаемо 2 и 3 пунктов -- все ровно наоброт: когда сотрудники имеют одинаковую производительность, а задачи одинаковые и рутинные, -- то нет ничего проще, как рассчитать нормы времени в часах и использовать их при планировании.
Сложность наступает тогда, когда задачи не рутинные, а сотрудники имеют разную производительность. Каким образом вы предлагаете в этом случае проводить оценку? И отдельный вопрос: сколько времени вы на нее потратите?
Между тем стори-поинты как раз и помогают быстро и с достаточно большой степенью вероятности оценить сроки доставки объема задач. Ключевые слова здесь вероятность и объем задач: не стоит цели точно оценить конкретную задачу, цель в том чтобы оценить доставку всего объема работ.
Практика показывает, что уже после второй-третьей итерации, за счет обратной связи в расчете велосити, оценки становятся исключительно точными. То что вы этого не наблюдали, говорит либо о том, что либо вы работаете на каком-то очень специфичном проекте, либо у вас не было опыта правильного их использования.
Что касается первого пункта -- да, как я говорил изначально, при смене структуры команды беклог следует переэстимировать. Но как часто у вас меняется структура команды, если не брать отпуска или больничные? Раз в полгода-год? -- это не смертельно. А в случае отпусков или больничных -- просто уменьшаем велосити пропорционально выбывшим часам сотрудников -- и плюс/минус с большой степенью вероятности попадем в оценку.
А для каких целей нужна оценка?
Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано).
Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Мы не считаем, что велосити пропорционально выбывшим сотрудникам, но нужно на что-то опереться при следующем планировании. Можно вычесть пропорционально, а можно вообще не вычитать и смотреть, сколько команда сделает.
Про признание авторов: знаете теорию публичного апи? Что оно зачастую используется не так, как задумано автором.
А для каких целей нужна оценка?
У вас есть беклог из 100500 задач, вам нужно понять:
1) сколько из них вы возьмете в ближайший спринт?
2) сколько времени потребуется, чтобы переработать весь беклог (или его часть)?
Эстимация в стори-поинтах отлично решает обе эти задачи. И главное -- решает быстро и достаточно точно.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Падает оно, разумеется, не ровно пропорционально. Но если человек ходит в отпуск 2 недели за полгода, то влияние этой самой "непропорциональности" на проект будет столь невелико на фоне остальных факторов, что упарываться на это счет точно не стоит.
Но меня забавляет настойчивость в использовании плохих методов менеджмента,
Возможно дело в том, что у многих эти методы работают и приносят результат? А если у вас они не работают, возможно, дело вовсе не в методах? )
Согласен. И даже переоценивать фичи не приходится при незначительном изменении состава команды, т.к. сложность не меняется для оставшейся части команды, она просто не может выполнить тот же объем работы, и это нужно учитывать при планировании следующей итерации. Только если команда поменяется вся нужно переоценивать, но я такое на практике не встречал. Корреляции всегда есть от спринта к спринту, поэтому мы считаем среднее значение, на которое опираемся в дальнейшем.
If they’re not providing great value to your team or company, I’d advise dropping them on the grounds that they are waste. If, on the other hand, you just love them, well, carry on!
Нет речи об антипаттернах, каждый инструмент имеет смысл применять там, где он полезен. Статья в целом о том, что SP часто неправильно используют. И автор, по своему обыкновению, предлагает попробовать NoEstimates. Просто ещё один способ оценки, несмотря на название) И, кстати, использование SP без привязки к команде, т.е. исполнителю, - как раз и есть пример неправильного использования))
Я потерял картинку с оценкой фичей в часах, которую сделали после системного анализа, поэтому диаграмма казалась неверной. Обновил статью, спасибо.
Привет, а как вам вариант декомпозиоровать фичи посильнее и уже эти подзадачи оценивать в sp?
При такой схеме спринтов с нулевым велосити можно будет избежать и вообще можно будет отказаться от оценок в часах.
Привет! Пробовал и такой вариант, но с ним был ряд проблем, которые мне не удалось решить. Кстати, в текущем примере я просто показал суммарную оценку в часах для каждой фичи, саму декомпозицию я опустил, т.к. решил, что про это достаточно было упомянуть. Обычно задача (часть фичи) не должна превышать 16 часов.
Оценка в SP хороша тем, что не требует деталей. И когда я работал без этапа системного анализа, оценивать в SP - это был единственный вариант. Я писал в статье, почему стоит включать системный анализ.
А когда он есть, уже есть возможность оценить именно в часах. А с оценкой в часах легко можно наполнить спринт и спланировать работу команды на диаграмме Ганта, а в SP я не знаю, как это сделать.
Также, когда у вас и фичи, и технические задачи, и баги в SP, сложно предоставить бизнесу информацию, а сколько же бизнес-задач делается за спринт. А когда вычитаешь SP для бизнес-задач из всех задач, то получаешь искаженное значение. И я ни разу не встречал бизнес, которому был бы интересен тех долг.
Поэтому у меня получился такой скомбинированный подход.
А есть понимание насколько хорошо идёт попадание в оценки ? И какой % времени занимает системный анализ ?
По моему опыту хорошее попадание в оценки случается только если команда +- одни и те же задачи делает каждый спринт.
Ну и по поводу бизнеса , конечный он разный бывает, но зачем ему вообще знать сколько именно задач вы делаете за спринт? Бизнесу интересно какие фичи команда запустила и каких бизнес результаты показала по итогу. Для этого можно формат демо например использовать, синкаться с бизнесом и получать образную связь можно там.
А кто как оно внутри команды устроено - как будто дело самой команды. И тут я согласен с вашим тезисом, что у каждой команды могут быть свои процессы, если ваши показывают хороший импакт в бизнес то круто , спасибо за статью .
Это зависит от того, кто делает системный анализ, от его опыта и знания продукта. В моем опыте неплохие показатели такие: простая фича – 1 день (пара экранов, пара запросов), средняя фича – 5-7 дней, сложная фича (обычно, когда участвуют смежные команды) – 2-3 недели.
В оценку мы хорошо попадаем (хотя это зависит от качества аналитики, но, когда она приличная, попасть несложно), даже если делаем что-то новое. 90% точно попадаем или заканчиваем немного раньше. Тут мне также помогают коэффициент разработки и оценка покером со всей командой. Т.е. мы всей командой собираемся и обсуждаем пути решения фичи. Это особенно помогает, если проект большой и всего не знаешь о нем. Например, на обсуждении понимаем, что нам нужно для этой фичи сделать вот то-то и то-то, а тут другой разработчик говорит, что что-то подобное в проекте уже есть, посмотрите там-то и там-то.
Бизнесу неважно, сколько мы делаем за спринт, да. Скорость разработки, в моем случае, это фактура, с которой мы идем бизнесу, если нам нужно объяснить, почему мы не успеем выполнить задачи в желаемый бизнесом срок. Т.е. мы не просто голословно заявляем, что не справимся (и, возможно, нас стоит уволить :) ), а приносим данные, с которыми сложно спорить. А когда есть данные, всегда можно конструктивно обсудить пути решения. Также по этим данным можно принимать и другие решения, например, о расширении команды.
Честно говоря, диаграмма Ганта выглядит избыточной на столь коротком временном промежутке, как спринт. В остальном -- все разумно.
Кстати, ваш подход со сторипоинтами и часами прекрасно ложится на Microsoft Azure DevOps -- у них оно заточено именно на такой процесс.
Как рассчитать скорость работы команды и не завалить дату релиза? Спринтовая модель глазами тимлида