Привет! Я Игорь, фронтенд-разработчик в Selectel. Когда-то давно я был проектным менеджером в небольшой компании, где было принято работать по модели Waterfall. Все этапы разработки были определены заранее, а на каждый этап отводилось определенное время.
Задачи были оценены строго по часам, ни о каких спринтах мы не знали. Когда что-то не учитывалось — все планы и сроки срывались из-за невозможности адаптировать разработку под изменение среды. В общем, у нас были четкие временные отрезки, немного хаоса и пузырек валерьянки на столе…
Почасовая оценка задач мне всегда казалась неэффективной. Но в то время не было опыта взаимодействия с другими методологиями. Сейчас я счастлив, ведь работаю с относительной оценкой задач в Story Points. ? Добро пожаловать под кат, если тоже хотите добавить в ваш рабочий процесс немного гибкости!
Используйте навигацию, если не хотите читать текст полностью:
→ Немного о Story Points
→ Недостатки оценки в часах
→ Преимущества Story Points
→ Методы оценки в Story Points
→ Планирование и игра в покер
→ Чек-лист по ошибкам
→ Заключение
Немного о Story Points
Story Points (SP) — это единицы измерения, которые используют для оценки задач в различных методологиях. В нашем случае речь пойдет о методике организации командной работы Scrum.
Scrum — разновидность гибкой методологии разработки (Agile), в которой задачи распределяются на временные отрезки (спринты) и могут оцениваться в SP.
Если вкратце, то в Story Points выражается сложность решения задачи или, в какой-то степени, количество требуемых усилий для ее выполнения. То есть вместо того, чтобы оценивать задачу в часах, мы учитываем, сколько усилий она потребует, и ставим ей определенный SP. При этом изначально определяем последовательность значений, которую будем использовать. Некоторые из них:
- линейная последовательность (1, 2, 3, 4, 5, 6, 7),
- последовательность удвоения (1, 2, 4, 8, 16),
- последовательность Фибоначчи (1, 2, 3, 5, 8, 13).
Однако вовсе необязательно привязываться в числовым значениям. В качестве единицы измерения вы можете выбрать любой параметр, который отражает сложность задачи. Например, некоторые команды используют альтернативные шкалы оценки с попугаями или размерами маек (S, M, L, XL). В целом, это не так важно, вы можете дать волю своему креативному мышлению. Главное — разобраться в сути Story Points и недостатках использования абсолютных единиц измерения.
Недостатки оценки в часах
При первом знакомстве с методом оценки «в попугаях» возникают вопросы. Например, зачем использовать SP вместо часов, дней или любой другой хорошо известной единицы времени? Упрощает ли это оценку и насколько это полезно?
Основная проблема оценки в часах — невозможность точно определить, сколько же нужно времени на решение задачи. А неверная оценка усложняет планирование в долгосрочной перспективе и приводит к срыву сроков. Иногда — к провалу проекта.
Время, которое потребуется исполнителю для решения задачи, сильно зависит от него самого. В большинстве сфер более компетентный специалист предоставит качественное решение задачи быстрее. Разработка — не исключение: у специалистов разные скилы, каждый решает задачу со своей скоростью.
При долгосрочном планировании вы не сможете сделать расчет, если типовые задачи будут решать за разное время. Вдобавок, в оценку задачи часто не входит ее воркфлоу: создание, описание выполненной работы, ревью и исправления. В итоге получается, что и на само планирование с подсчетом времени уходит очень много времени. ?
Преимущества Story Points
Так как SP — относительная единица измерения, которая лишена многих недостатков, свойственных для абсолютных. Во-первых, само планирование проходит быстрее, так как вам не нужно определять точное время для реализации задачи. Во-вторых, два SP в текущем спринте будут равнозначны двум SP в последующих, что упрощает анализ типовых задач в долгосрочной перспективе
Вместо оценки конкретного исполнителя, исходя только из его уровня, понимания задачи и опыта решения аналогичных задач, мы учитываем общие командные усилия, которые нужны для реализации. Помимо прочего, следует учитывать следующие критерии:
- сложность работы — технический аспект и понимание способа реализации;
- объем работы — время на реализацию, тестирование, ревью и возможные дальнейшие изменения;
- неопределенность и риски — уверенность в возможности реализации, зависимость от других членов команды и просто человеческий фактор, который никто никогда не отменял.
Методы оценки в Story Points
SP с оценкой по эталонной задаче
Из списка задач в спринте выбирается самая маленькая, которой ставится наиболее низкая оценка, например 1SP. Эта задача является эталонной. С ней сравниваются следующие.
Мы спрашиваем себя, насколько вторая задача требует больше усилий по сравнению с эталонной. Далее — присваиваем ей оценку. Здесь есть нюанс: от спринта к спринту веса эталонных задач должны быть примерно одинаковыми. Советую придумать правила для оценивания.
SP с относительной оценкой
Метод предполагает использование одной из последовательности значений, относительно которой будут оцениваться задачи. Тут уже неверно сравнивать их между собой.
Каждая команда выбирает последовательность, исходя из собственной специфики работы и задач. Мы в отделе используем последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21). В ней для каждого значения есть свое описание условия/критерия, которому должна соответствовать задача для получения Story Point.
Приведу пример таблицы для сопоставления значения Story Point и критерия соответствия.
|
SP |
Условие |
Пример задачи |
|
1 |
Тривиальная задача, которая не должна занимать много времени и не связана с изменением логики. Чаще связана с небольшими визуальными элементами/ стилями/ текстом. |
|
|
2 |
Правки или небольшое дополнение существующей функциональности, в которой все понятно. Реализация не должна вносить большие изменения. |
|
|
3 |
Правки или добавление функциональности, для которой уже подготовлены необходимые элементы, но потребуется больше времени на реализацию. Реализация вносит более объемные изменения в коде, но при этом не должна быть сложной и требовать больших временных затрат на вникание в логику. |
|
|
5 |
Реализация новой функциональности. Возможно, для нее уже существует часть элементов или подготовлена минимальная среда. Чаще необходим поиск решений, создание прототипов макетов элементов или функционала. |
|
|
8 |
Задача повышенной сложности, для реализации которой нужна совместная работа с другим отделом. Большой объем работы, чаще с выяснением непонятных моментов, проверкой гипотез и поиском решений. Возможно для функциональности ничего нет и все нужно писать с нуля. |
|
|
13 |
Реализация отдельного раздела/сервиса с добавлением ранее не используемых инструментов. Задача на правки или расширение функционала глобально для всего сервиса с большим объемом написания кода. Необходимо проектирование, дизайн, работа с другим отделом и поиск решений. Ожидается наличие подводных камней, реализация в несколько подходов и вероятная декомпозиция задачи. |
|
|
21 |
Задача, которую на данном этапе невозможно выполнить. Подготовка к реализации сервиса/ раздела. Чаще такие задачи следует сразу разбить на подзадачи и продумать план их реализации. |
|
Чаще всего задачи с низкой оценкой занимают основную часть спринта, так как она более точная. Для задач с высокой оценкой зачастую происходит декомпозиция и последующая переоценка. Сам метод достаточно гибкий и позволяет более обобщенно задавать оценку — свободнее использовать рамки отведенного времени на выполнение задачи.
Согласитесь, это намного удобнее, чем оценка в часах. Особенно, когда есть различные факторы, включая человеческий, из-за которых невозможно рассчитать точное время выполнения. Ведь быстро — не всегда хорошо.
Планирование и игра в покер
В процессе Scrum Planning мы определяем цель нового спринта: смотрим, что не успели выполнить в предыдущем, анализируем. В результате мы формируем финальный список задач для оценки.
Задачи в новом спринте оцениваем с помощью Scrum Poker. Это необязательный инструмент, но многие команды используют именно его. «Играя в покер», команда берет задачу из списка и кратко обсуждает ее. Далее — каждый участник выставляет оценку на доске. Значения вскрываются после того, как все участники поставили оценку.
Каждый участник выставляет оценку «рубашкой вверх».
После того, как все участники поставили оценку, значения вскрылись.
Если значения совпадают и все согласны с ними — отлично! Если нет, то обсуждаем причины разницы и принимаем решение об итоговой оценке. Если необходимо — переоцениваем предыдущие задачи и оцениваем новые. Смотрим, что помещается в спринт по Story Points и какие более приоритетные задачи следует в нем оставить.
Чек-лист по ошибкам
Расскажу о наиболее распространенных ошибках, с которыми можно столкнуться при использовании Story Points. Используйте и делитесь своими советами в комментариях!
1. Оценка в Story Points на основе времени и игнорирование воркфлоу
Пожалуй, самая частая ошибка на старте. Важно помнить, что при оценке следует включать все этапы работы над задачей, через которые она проходит до конечного клиента, а не только время написания кода.
Антипример: специалист завершил задачу по созданию простой функциональности, чья оценка была основана только на учете времени его написания. Далее — две недели буксовал на этапах ревью и тестирования.
Не забывайте про время на проверку, исправление багов, тестирование и внедрение!
2. Оценка без учета технического долга
Далеко не весь код можно назвать идеальным, актуальным и хорошо работающим. Особенно это касается легаси. Если вы уверены, что ваш код прекрасен и будет жить долго, — будьте спокойны. В любом другом случае, когда код следует обновить, лучше учитывать и необходимость рефакторинга или исправления старого кода.
3. Оценка без учета зависимости от других команд
Если ваш отдел состоит из нескольких команд, не забывайте учитывать их усилия для реализации поставленной задачи.
4. Недостаточное описание задачи
Чем более детально задача будет описана, тем быстрее и точнее вы оцените задачу, лучше поймете контекст. Это также поможет предотвратить изменение оценки во время спринта.
5. Игнорирование неопределенности и рисков при оценке
Детальное описание есть, все супер. Вы начали работать — и тут пишет заказчик, что все нужно переделать. Как следствие — сроки сдвинулись, а другие задачи пострадали.
Оценка задачи без учета новых требований, возможных правок и изменений от заказчика может сорвать сроки даже в самом распланированном спринте.
6. Отсутствие четких критериев для оценки
Чтобы члены команды не рассматривали по-разному одну и ту же задачу, можно создать шаблон с примерами уже оцененных задач и следовать ему. Так вы избежите недопониманий при оценке и сократите время обсуждения.
7. Оценка задач без учета предыдущего опыта
Если команда не анализирует прошедшие спринты и не учитывает опыт при оценке задач, то сама модель рабочего процесса не будет развиваться. В таком случае высока вероятность ошибок в одних и тех же местах.
Чтобы точнее оценивать задачи в будущем, стоит включить анализ оценки в ретроспективе и учиться на ошибках.
Заключение
Независимо от используемого подхода оценки задач, без анализа сами по себе оценки бесполезны. Раньше мы использовали линейную последовательность от 1 до 10, где 1 — самая тривиальная задача, 2 — чуть сложнее и т. д. С ней было просто работать, но в итоге не хватило гибкости для оценки объемных задач. Последовательность не учитывала значительные различия в сложности между ними.
До того, как остановиться на ряде Фибоначчи, мы несколько раз меняли последовательность, каждый раз улучшая систему оценки. Процесс доработки воркфлоу длится и по сей день.
Каждая команда должна выбирать не только последовательность, но и саму методологию, исходя из своей специфики работы. Главное, чтобы выбранный способ оценки был понятным и удобным для всех членов команды, позволял точно оценивать задачи и эффективно распределять усилия.
Комментарии (41)
koreychenko
24.07.2024 09:58+9Я в это много раз играл в разных компаниях и нигде нормально не работало. Менеджмент не умеет в абстрактные стори-поинты и в конце концов тебе все равно придется вводить коэффициент перевод попугаев в мартышек. А если тебе все равно переводить надо, то почему бы сразу и не оценивать целевых единицах.
Фишка стори-поинтов в том, что они не про время вообще. Мы внутри себя договорились расценивать их как некую единицу неопределенности.
Если задача понятная - бери и делай, то это будет 1 стори поинт (ну 2), даже если это вручную заменить в 100 классах А на Б. Сложно? Нет. Долго? Долго. Т.е. эта задача может занять весь спринт по времени.А бывают задачи, которые хрен знает как решать. Может надо какую либу готовую поискать или подход погуглить. Т.е. ты примерно представляешь, но слишком много неизвестных. Поэтому ты честно говоришь, что это 7-12 баллов. Хотя по факту ты можешь нагуглить что-то готовое и решить эту задачу за пару часов.
friend001002
24.07.2024 09:58+4А в чём разница то?
Вот есть у меня маленькая задача. Можно оценить её в час, можно в XXS, а можно в SP1. Но если окажется, что задача не такая уж и маленькая, все три вида оценки окажутся неверными.
Проблема же не оценить в час, а как-то понять, что подводных камней не найдётся и что вообще задача решаема на текущей инфраструктуре и с текущими инструментами.
seriouscat
24.07.2024 09:58+2Нет никакой разницы, кроме частотности значений на шкале оценки и связанных с этим проблем. Ценность покера больше в том, что задачи обсуждаются, выдвигаются какие-то гипотезы, принимаются решения и задаче проставляется какой-то вес, глядя на который можно примерно оценить усилия в соотвествии с принятой в команде шкалой.
Если впоследствии окажется, что оценка не верна, то ничего не мешает ее поменять. Конечная оценка при резолве задачи уходит в статистику. Если процесс не меняется, то со временем получаем примерную производительность
Theillear Автор
24.07.2024 09:58+2Проблема же не оценить в час, а как-то понять, что подводных камней не найдётся и что вообще задача решаема на текущей инфраструктуре и с текущими инструментами.
Для нахождения подводных камней есть предварительные процессы по анализу задач, что и должно обеспечивать уже на самом планировании определенную оценку.
Оценка временем для задач, особенно сложных и новых, может быть крайне неточной.
SP избегают иллюзии точности во времени, а больше ориентированы на сложность и ресурсоемкость.
Например, незнания, как добавить модалку и как добавить многоязычность в проект немного разные… В обоих случаях ты не знаешь что/как делать, но у тебя есть понимание, что одна задача по любому займет больше ресурсов, чем другая.Из этого и выйдет, что в соответствии с критериями оценки будет выставлена подходящая. А в будущем будет ясно сколько похожих задач можно сделать за спринт.
friend001002
24.07.2024 09:58SP избегают иллюзии точности во времени
А как оно работает? Если я решил, что задача -- это SP1, то мы же потом всё равно делаем Scrum Poker и прикидываем время на выполнение этой простой задачи. То есть сначала мы от времени избавляемся, а потом снова возвращаем.
aleksanderL
24.07.2024 09:58SP избегают иллюзии точности во времени, а больше ориентированы на сложность и ресурсоемкость.
Ага отлично, создают иллюзию вообще какой-то оценки, которую вообще невозможно никуда ни во что перевести. А нам нужно понять, что мы за Ближайшие полгода сможем хотя бы примерно сделать, Особенно это весело с новой командой.
Мне пришёл новый разработчик новая команда, и оценили задачу в 32 story point, что мне с этим делать? Как понять много ты или мало, смогут они это сделать за неделю или за месяц?
Если пришла новая команда новые разработчики, оценили задачу условно в месяц разработки - я прекрасно понимаю, что с учетом рисков, того что там вылезет, всяких интеграций, тестирования, подводных камней в инфраструктуре заказчика, это всё растянется на 2 месяца. Ну, окей, User Story нарезали, поехали пилить
aleksanderL
24.07.2024 09:58Проблема же не оценить в час, а как-то понять, что подводных камней не найдётся и что вообще задача
Это как раз то, от чего пытаются спрятаться за сторипоинты. Но на самом деле в реальности на больших объёмах какая-то задача заняла больше времени, а другая наоборот Меньше времени, и как раз в среднем появляется 10-15% погрешности в ту или иную сторону, которая в будущем просто надо учитывать.
Но днями, и неделями куда проще оперировать чем мутными сторипонтами, которые не разработчики не понимают толком, не менеджеры.
Естественно, если у нас бирюзовый старта, которому вообще пофиг, что когда будет сделано, мы просто сидим и делаем, то там можно вообще ничего не оценивать.
Dalek_painter
24.07.2024 09:58+1Всегда удивляла оценка в малых числах. Учитывая, что используем мы целые, то с 1 до 2 разрыв в 2 раза, с 2 до 3 - 1,5 раза. Это мешает построить ровный график зависимости а самое главное, в реальности при этом задачи могут так сильно не различаться по сложности на низком уровне. От умножить на 100 и уже варьировать легче.
Но самое главное - это все не решает ошибку при назначении оценки. Что вы будете выбирать из карточек с поинтами, часами, размерами порноактрис, чем менее рутинная задача, тем выше шанс назначить не тот "маркер", так как работа становиться более творческой, если можно так сказать.
Gorthauer87
24.07.2024 09:58+3По сути, вся реальная ценность во всех этих оценках это просто разделить задачи на простые и нет. И дальше определиться с приоритетами. Ну что в первую очередь, что нет.
А понять сколько это займет времени в целом невозможно. Ну можно только очень грубо прикинуть.
ggo
24.07.2024 09:58+2Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
aleksanderL
24.07.2024 09:58Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
Тогда к чему эти новые виртуальные единицы измерения времени, если можно мерить в днях, только потом вводить поправочные коэффициенты в зависимости от эффективности команды?
Ksael
24.07.2024 09:58Потому что добавляя поправочные коэффициенты ты уже создаёшь новую сущность "времени" , и у тебя все равно появляется виртуальный "час" который не равен часу в реальности. И это проблема, потому что и то и то называется "час", но от команды к команде значит разное.
По этому со СП работать проще, потому что это довольно понятная абстракция и не нужно вводить никаких доп коэффициентов и иметь одинаковые слова для разных понятий.
ruslan_sverchkov
24.07.2024 09:58потому что и то и то называется "час", но от команды к команде значит разное
в отличие от сторипоинтов, которые на самом деле от команды к команде значат разное, час от команды к команде как раз значит одно и то же) из команды эта оценка уходит уже после применения "доп коэффициентов". Впрочем час это плохая единица, бизнесу она не интересна, для разработчиков она стрессовая, вот день это норм
Ksael
24.07.2024 09:58Так мы уже говорим о точке зрения бизнеса, внутри разных команд "часы" будут разные, как и сп.
aleksanderL
24.07.2024 09:58По моему опыту даже новая команда, где разработчики друг друга первый раз видят, достаточно точно оценивают трудозатраты задач в днях, в среднем на больших масштабах ошибаясь в меньшую сторону примерно на 20-25%
Mike-M
24.07.2024 09:58+1Прочитал всю статью, комментарии и остался при своем мнении: самая точная оценка времени выполнения задачи — как только, так сразу )
Jon7
24.07.2024 09:58Если я правильно понял то измерение в story point работает так. Заказчик хочет пачку фич. Эту пачку раскладывают по story points. Каждая отдельная story point выкатывает в прод несколько фич из пачки и показывает заказчику прогресс . Каждая story point имеет свою себестоимость в человекочасах работы команды. Эту себестоимость, плюс частично общепроизводственные расходы, плюс прибыль, плюс налоги и оплачивает заказчик.
Поправьте если я ошибся.
therb1
24.07.2024 09:58SP относительная единица.
Время тоже относительная единица.
И у любого человека есть представление что такое секунда, минута, час и т.д.
А вот как оценить задачу в майках или стори поинтах человеку придется учиться.
Но по факту в голове разработчика будет лежать мапа 1 SP = 30 минутам и в голове менеджера будет лежать мапа 1 SP = 20 минутам. И того и те и другие оценивают задачи по времени, но еще и используют промежуточную конвертацию при общении между собой.
И это я еще лишь слегка упомянул о разном восприятии "1 Попугая" у разных людей.
tommyangelo27
24.07.2024 09:58Ну... У нас на работе майки использовали по-другому. Размер называли только для предварительной оценки, чтобы дать примерное понимание, что вот эта задача займёт около 1-2 дней, а вот та - примерно полтора месяца.
Но, если бизнес принимает план и приоретизирует задачу - мы делали уже более детальный эстимейт в часах.
Это к тому, что у маек не было прямого перевода в часы, они скорее сумма времени и сложности.
JuryPol
Вы сами не чувствуете, как запредельно глупо это выглядит?
То есть взяли сторипойнты, начали оценивать задачи в попугаях и профит!!! Получите точную оценку! В попугаях, ага… Спринты - временнЫе отрезки, срок завершения проекта определен. А вы со своим скрам-мастером попугаев штабелями укладываете.
Что мешает всю эту суету с анализом спринтов, с покером, если угодно, производить с оценкой в часах? По этим же методикам через несколько спринтов может и начнете точнее потребное на задачи время определять? Для пущего наукообразия можете и числа Фибоначчи оставить. Чтобы легче было верхнему руководству по ушам ездить…
event1
Проблема в том, что если задача оценена в 1 час, а заняла 15 минут, она всё равно займёт 1 час. А если задача оценена в 2 попугая, а заняла 15 минут, то она займёт 15 минут, а разработчик закроет больше попугаев за спринт. Естественно, это всё теория, а на практике бывает разное. И чаще фигня, чем не фигня. (сам я скрумом не пользуюсь и никого не призываю, если что)
BuHHTuK
Спорный момент, пользуетесь часами при оценке, значит должны адекватно учитывать трудозатраты и оглядываться на ситуации когда оценили в час, а вышло 15 минут.
При SP все зависти от базового значения и его корреляции со временем)
P.S На практике, попасть точно с оценкой можно только в случае типовых задач, которые 20 раз делали и всем все понятно, а так, в среднем по больнице синусоида +/- 15% от оценки и неожиданные всплески
event1
Попугаев вообще не нужно коррелировать со временем. В скруме важно оптимально упихать спринт. А знать какая конкретно задача сколько времени заняла не так важно
BuHHTuK
согласен, не так важно,с точки зрения планирования можно просто корректировать значение SP, которое команда способна выполнить за спринт. Тут имел ввиду, что что может 2SP за 15 минут это норма, а если нет, то на ревью можно будет разобраться в чем дело, может просто переоценили задачу и тд (если конечно именно эта задача как то повлияла на спринт).
aleksanderL
Это где вы так счастливо живёте? Если для высокого руководства нужно построить хоть какую-то дорожную карту, Привет, переводим стори пойнты в дни.
Если вы разработчик, то конечно это не ваша головная боль
event1
Встроенные системы. Продуктовая разработка. Тендеры, долговременные клиенты и вот это вот всё.
У вас простите высокое руководство интересуется, сколько времени займёт каждую кнопочку добавить? План для руководства делают по-большому обычно. Каждый пункт в сотню попугаев. Да к тому же, мы же про разработку ПО говорим. Все знают что мы никогда не укладываемся в сроки.
Ещё раз повторюсь, что весь смысл мероприятия с попугаями заключается в том, что:
время разработки одного попугая может сильно варьироваться. Время разработки сотни попугаев будет варьироваться намного меньше. И,
с другой стороны разработчик получивший задачу на два попугая не станет жертвой тех же ожиданий (как внешних, так и внутренних), что разработчик получивший задачу на 2 часа.
aleksanderL
Планирование то у вас есть?
Просто вы создали свою виртуальную единицу измерения времени, которую понимает только команда и менеджер.
Всё равно в конечном итоге это всё утрамбовывается в двухнедельный спринт, по сути SP всё равно равен какому-то количеству человекочасов.
Та же история: тебе дали задачу на половину стори поинта, ты её два дня делал, "ты что совсем что ли?"
Команда должна в днях оценивать крупные User Story, а конкретные мелкие задачи по добавлению кнопочек и изменению цвета, разработчик вообще не должен знать какая у них оценка.
JuryPol
И какая проблема? Правим оценку для таких задач, ведь есть анализ по результатам спринта. И ровно то же самое делаем, если «соучастниками» являются модные попугаи. Что меняется? Да ровным счетом ничего. Причём, если анализа спринта нет, то тоже ничего не меняется. Продолжаем брать оценку с потолка.
Что интересно, если проект выполняется на аутсорсе, там попугаи не прокатывают. Наверное потому, что вопрос об отношениях попугаев и часов встанет в первые же дни.
event1
Никто никогда не узнает, что задача на самом деле заняла 15 минут. И, соответственно, никто ничего не сможет скорректировать.
На аутсорсе только счёта выставляются за часы. А внутри работа может быть устроена как угодно.
JuryPol
Так же и и со сторипойнтами. Никто и никогда не узнает, что вот эта задача была оценена в десять сторипойнтов неправильно. Но это ведь будет возможным только в том случае, если весь скрам у вас скукожился до попугаев. Если же упомянутые в статье процессы отстроены, то узнают. И вот сюрприз, в одинаковой мере и про часы, и про попугаев.
event1
вы подразумеваете, что есть некая "правильная" привязка попугаев к часам. А её нет. Есть среднее количество попугаев на спринт и предполагается, что в установившемся режиме оно мало меняется от спринта к спринту. Конечно, можно произвести нехитрую калькуляцию и пересчитать попугаев в часы. Но этого не нужно делать, потому что весь смысл скрума как раз в том, чтобы планировать спринтами.
aleksanderL
Так точно так же, если в сприт влезает только X условных дней разработки, то вот сколько есть. Остальное - это резерв на коммуникации и влёты.
event1
Ещё раз, проблема в том, что если разработчику дали задачу на 4 часа, она никогда не займёт меньше 4х часов. С попугаями такой проблемы нет, потому что от попугаи не равны какому-то фиксированному количеству часов.
aleksanderL
Это как? Закрыл таску, посмотрел что у неё оценка выше и пошёл курить? Он по идее на сабтаске оценку видеть и не должен.
По здравому смыслу, разработчики должны оценивать крупные Стори, а подзадачи - это уже детали. Если упарываться до 1-4 часов, то вы только этим и будете заниматься.
ruslan_sverchkov
Изи, в спринт влезает 10 попугаев, задачу оценили в 10 попугаев, следовательно меньше спринта она не займет)
JuryPol
Отнюдь… Я пытаюсь сказать, что введение оценки задач в размерах трусов или в попугаях изначально вещь предназначенная только для создания дымовой завесы. Нужная лишь для того, чтобы в любой момент как всю команду, так и любого исполнителя нельзя было взять … за определенное место и попросить дать ответ, а чем вы тут вообще страдаете уже третью неделю?
Повторюсь, никуда вы не денетесь от того, что определяет все реальный мир с его временнЫми требованиями, сроками сдачи, продолжительностью спринтов в днях и т.д. Или вы что, всерьез считаете, что пресловутая гибкость, которую дает скрам, обеспечивают ваши попугаи и числа Фибоначчи? Ни разу даже и не смешно… А вот имитировать скрам с помощью попугаев - удобно, не спорю…
seriouscat
У спринта Capacity также оценивается в сторипойнтах, этот тот объем который команда в состоянии закрыть за 2 недели согласно статистике, которая уже накопилась к этому времени. Так что никто не сравнивает попугаи с часами. И уж гораздо проще оценить задачу в безразмерных единицах (пусть даже в размерах футболок как описано в статье), имеющих при этом свой вполне определенный внутрикомандный вес и эталон, чем в человекочасах
aleksanderL
Все эти стори пойнты нужны исключительно для того чтобы не пугать особо чувствительных разработчиков, когда они опять облажались с оценками.
Менеджеру всё равно приходится переводить эти стори поинты в часы. А хороший менеджер оценку в часах от команды всё равно домножает на поправочные коэффициенты.
Мой опыт показывает, что оценка в часах она понятнее для всех, на больших масштабах сходится к понятному коэффициенту поправки.
Для оценки в часах можно также использовать покер планирования, груминги, условный Middle разработчика час. В нашем случае, мы вообще все истории оцениваем в условных днях.
Theillear Автор
SP действительно не дают точной оценки в абсолютных единицах времени, но их цель и не в этом. Они нужны для более гибкого планирования работы в команде, учитывая неопределённости и вариативность задач.
В данном случае фокус внимания с задач переходит на спринты. Т.е. тут сам спринт выступает в роли одной большой задачи, которую проще оценить в относительных единицах, благодаря чему в долгосрочной перспективе получается более точная статистика по закрытым задачам за спринт - меньше разброс и лучшее понимание возможного выполненного объема при следующем планировании.
aleksanderL
Если мы будем это же оценивать в условных человека днях, то чем это хуже, кроме большей понятности прозрачности?
Да, условный "человеко день" в конце концов будет равен примерно полтора рабочих дня реальных.
Дни понятнее для менеджмента и новых разработчиков в команде, которые приходя в storypoint команды охреневают, что за сторипоинты как в них оценивать.