Зачем использовать баллы истории вместо часов для оценки?

Использование точек — это один из вариантов того, что часто называют « относительным размером ». Чтобы получить очень рекомендуемую начальную перспективу, посмотрите это видео , а затем вернитесь. Большинство применений оценки в пунктах ограничивают вас нижней частью ряда Фибоначчи: 1, 2, 3, 5, 8, 13, потому что цель состоит в том, чтобы сгруппировать вещи одинакового общего размера, а не преследовать очень точную оценку.

Story Points часто принимают во внимание три разных аспекта при оценке: Сложность, Усилие и Сомнение. Это позволяет им более эффективно фиксировать источники вариаций, из-за которых почасовая оценка будет неверной.

Сложность — это «вещи, которые мы должны выяснить». Мы знаем, что можем решить проблему, и у нас, вероятно, есть хорошее представление о том, как мы к ней подойдем, но нам все еще нужно это понять.

Усилия — это огромное количество вещей, которые необходимо сделать. Для меня этот пример — настройка списков SharePoint, потому что я точно знал, как все решить, и я знал, сколько их было, но все равно требовалось время, чтобы пробежаться по ним.

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

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

Окончательная точечная оценка — это просто способ сказать: « принимая во внимание все эти вещи, я думаю, что это больше, чем большинство вещей, которые мы назвали тройкой, и меньше, чем большинство вещей, которые мы назвали восьмерками, так что это должна быть пятерка "

Я бы не сказал, что очки лучше. Это метод, ориентированный на другой аспект оценки. Может оказаться, что ваша балльная оценка будет более отстойной. Имейте это в виду.

1. При оценке в часах вы сосредотачиваетесь на ответе на вопрос «Сколько времени это может занять у нас?». Так что в основном это более или менее предположения, основанные на вашем предыдущем опыте.

2. При оценке в баллах вы ориентируетесь на относительные размеры или сложность оцениваемых задач/историй/чего угодно. Итак, вы обычно берете некоторые из ваших задач и применяете к ним одно из значений баллов, а позже для каждой другой задачи вы пытаетесь ответить на вопрос «Насколько она велика по сравнению с теми, которые я уже оценил».

Ключевым моментом в оценке баллов является то, что вам нужно фактически измерить, как оценки соотносятся со временем. После некоторого начального времени в проекте (особенно когда вы начинаете с оценки в баллах) вы узнаете, сколько баллов вы можете получить за каждую итерацию или фиксированный период времени. Это дает вам основу для планирования будущих выпусков.

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

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

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

Для начала вам нужно будет выбрать пару заданий/историй средней/средней сложности/размера. Назначьте им несколько точек из выбранного вами диапазона точек (обычно ряда Фибоначчи). Эти задачи/истории становятся вашими эталонными задачами/историями. Теперь назначьте баллы остальным задачам в зависимости от того, насколько сложной/большой является каждая задача по сравнению с вашими эталонными задачами. Большие задачи получают более высокие баллы, чем баллы за эталонные задачи. В конце оценочного упражнения (обычно выполняемого с помощью Planning Poker) вы суммируете все баллы, чтобы получить общее количество баллов для этого проекта.

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

Все дело в том, чтобы абстрагироваться от ложной реальности.

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

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

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

Как всегда, на этот вопрос нет простого ответа. Я бы сказал, что вы должны выбрать то, что лучше всего подходит для вас . Однако, как вы говорите, работа с часами не работает для вас.

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

Другое дело, что при работе с очками (1,2,3,5,8,13,20) или размерами (S, M, L, XL) вы просто определяете сложность задачи. Скорость показывает, сколько точек вы можете добавить в итерацию, но скорость меняется .

И чем менее утомительна работа с точками - если вы плохо оценили, ваша скорость упадет.

Хотя это, вероятно, и не является предполагаемой функцией, одно из преимуществ использования баллов с точки зрения менеджера заключается в том, что задачи измеряются по сложности, а не по времени, что позволяет вам легко увидеть, кто в команде работает быстрее, чем все остальные. Например, вы знаете, что человеку А требуется 2 часа, чтобы сделать что-то, а человеку Б требуется 10 часов (для конкретной задачи; возможно, для другой задачи наоборот). Если человек А оценил 2 часа, а затем заболел, человек Б отстает от оценки на 8 часов, даже не начав. Но если вы дадите ему баллы, а затем усредните результаты по команде, вы, скорее всего, достигнете своей отметки в целом.

Есть две причины, по которым мне нравятся очки вместо часов.

Часы имеют подразумеваемую точность и, как правило, считаются точными на 100%, все люди понимают, что такое час, поэтому, если вы говорите 10 часов, это должно быть десять часов. Чтобы компенсировать это, человек, оценивающий, построит некоторое «дополнительное время», чтобы компенсировать неизвестные. Это просто человеческая природа, они не хотят нести ответственность за оценку, когда у них нет всех необходимых данных.

Проблема в том, что чем больше задача/история, тем больше сложность и тем больше времени потребуется для получения действительно точной оценки. В какой-то момент это просто не стоит усилий. Особенно, когда вы смотрите на работу, которая не будет сделана в течение нескольких месяцев.

С другой стороны, точки имеют «приемлемую» подразумеваемую неточность, поскольку они относятся только друг к другу.

Используя ряды Фибоначчи: 1, 2, 3, 5, 8, 13 и т. д., команда может компенсировать как сложность проекта, так и ожидаемые усилия. По мере того, как числа становятся больше, в оценку встраивается нечеткость. Время не тратится впустую на попытки определить, является ли это числом 9, 10 или 11, больше ли оно, чем то, что команда называет 8, и меньше, чем то, что команда называет 20, то это 13. По мере того, как история приближается к принятию в итерацию, она далее разбивается и уточняется, а точность оценки улучшается.

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

Джефф

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

Оценки в часах обычно можно преобразовать в баллы, но оценки в баллах, как правило, нельзя преобразовать обратно в часы.

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

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

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

Все это довольно обманчиво. Дело в том, что в нашей голове мы склонны преобразовывать очки обратно в часы, когда знаем нашу скорость. Пуристы могут говорить о очках весь день, но это просто люди, которые пытаются быть высокомерными. На самом деле ключ здесь в том, чтобы побудить людей, оценивающих, мыслить в относительных терминах; например, этот проект примерно такой же сложный, как тот проект, и этот проект занял, x hoursпоэтому этот проект должен занять y hours.

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

Story Points работают лучше всего, когда существуют следующие условия:

1. Организация имеет высокую толерантность к риску, что допускает значительные отклонения запланированного от фактического в начале нового, трудно поддающегося оценке проекта.
2. Команды работают в закрытой системе, где все команды следуют agile, а команды стабильны. Никакие ресурсы не используются совместно, и командам не требуется взаимодействовать с командами, используя другие методы (например, Waterfall).
3. В состав команды входит заинтересованный владелец продукта или конечный пользователь.
4. Выделенный тестовый ресурс, автоматизация или и то, и другое позволяют получать относительно стабильные оценки тестирования.
5. Команда координирует приоритизацию технического долга с каждым спринтом вместе с приоритетами заказчика.
6. Планирование включает только магазины, перенесенные в завершение, или истории, определенные как «достаточно хорошие» для оценки (например, хорошая пользовательская история, бизнес-правила, универсальные или специфичные для субъекта, условия приемки/критерии тестирования могут быть установлены в течение 24 дней после постановки задачи.
7. После планирования с владельцем продукта командам разрешается «время наедине» и техническое руководство для обсуждения и определения приоритетов задач.
8. Во время спринта команда ежедневно оценивает прогресс, сотрудничая и устраняя препятствия. Команды придерживаются задач, которые они взяли на себя.
9. Им не требуется заполнять стандартную или традиционную документацию, такую ​​как BRD или SRS, до начала работы.
10. Обязательства по проекту или другие элементы, которые команда не может контролировать, не определяют приоритеты спринта, но учитываются при планировании.
11. Команды демонстрируют и исправляют в течение спринта, как вклад в скорость
12. Команды получают кредит за работу, выполненную за спринт, хотя история может быть неполной, но код готов к работе — по крайней мере, частично.
13. Команды не торопятся, чтобы проанализировать различия в скорости, определить, что им нужно улучшить в ретроспективе, определить план и измерить свой успех.
14. Качественный, свободный от ошибок код развертывается вовремя, больше ничего не ломает, соответствует критериям приемки и тестирования и не оставляет незавершенной работы с огромным количеством технического долга.

Если команда не может отметить каждое из этих полей «да, мы делаем это», ваше руководство будет сопротивляться, и следующим шагом станет баланс для управления бизнесом. Как упоминалось в предыдущем ответе, командам следует начать планировать очки и часы для решения этого сценария. Менеджмент знает, что каждый пункт истории равен некоторой стоимости в человеко-часах. Идентифицируйте это как команду или будьте готовы, когда это будет определено для вас деловым нравом.

Некоторое время назад я написал соответствующий пост в блоге: «Осталось несколько часов работы».

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

Я немного согласен с комментарием Blaze, но я постараюсь обосновать его более удачно:

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

Вот как вы в конечном итоге используете скорость, как уже упоминалось. После нескольких итераций разработки, которые занимают x времени и получают y баллов, вы можете получить свою скорость, а затем использовать ее для планирования будущего.

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

Story Points лучше всего работают в Scrum из-за мышления метода.

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

Например, история А оценивается примерно в 5 Story Points, а общее количество Story Points в следующие 2 недели спринта составляет около 20. Если вам как продакт-менеджеру нужно знать, сколько времени займет история A, что ж.. , 2 недели ваш ответ. Параллельно с другими Stories в спринте.

В конце концов, вы всегда можете попытаться рассчитать соотношение человеко-дней на Story Point. В приведенном выше случае 20 Story Points займут 2 недели (10 дней). Это означает, что это может занять 5 Story Points. Задача займет 2,5 дня. Но в Scrum вы не упаковываете релиз через 2,5 дня. Вы должны дождаться завершения Спринта, что составляет 2 недели. Что делает соотношение человеко-дней на Story Point довольно бесполезным.

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

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

Здесь есть элемент опасности в том, что я вижу, как многие команды полагают, что они «заработали деньги» на разработке, они наконец-то раскрыли секрет прогнозирования с помощью математики! - это ложное срабатывание, потому что если кто-то выделяет историю как «маленькую» (подход размером с футболку), а затем этот человек распаковывает 20 задач, чтобы завершить эту историю, то каждая из этих задач по-прежнему выделяет временные переменные для уравнения.

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

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

Как я уже сказал, вы можете «обыграть» моделирование прогнозов с помощью методов абстракции, таких как система баллов, но когда дело доходит до распределения и даже скорости, время все еще ускользает. Вот почему большинство команд считают, что x недель — это спринт, тогда как, если бы это была действительно абстрактная методология, это было бы «это спринт из 45, а следующий — спринт из 24» или что-то в этом роде... спринт бы быть переменным по длине и времени. Вместо этого вы оказываетесь в этом когнитивном диссонансе вокруг абстракции точек в относительное время? но как использовать произвольные исходные данные для количественной оценки данных?

Еще один момент, который следует добавить, заключается в том, что команда часто оценивает работу до ее выполнения. Оценки, основанные на времени, относятся к людям, завершающим работу. Относительный размер (Story Points с использованием Planning Poker) — это размер команды. Это не специфично для людей.

В основном время и сюжетные очки не эквивалентны .

Баллы добавляют абстракцию от времени по психологическим причинам, неявно, чтобы предотвратить выгорание программиста. Кто-то все еще должен превратить абстракцию во временные/финансовые затраты. Он просто проходит вверх по цепочке до тех пор, пока кто-то не захочет взять на себя ответственность за него.

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

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

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

Если коротко, то «часы — это в лучшем случае только предположение». Но если вы посмотрите на стори-пойнты — называйте их как хотите — вы рассматриваете карту действий (и естественные зависимости внутри этой карты), которые в конечном итоге приведут к тому, что эти оплачиваемые часы будут потрачены.

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

Story Points не следует использовать для планирования проекта. Нет никакой цели. Оценки должны строиться в человеко-неделях или человеко-месяцах. Сюжетные очки не предоставляют никакой информации, на которую можно было бы воздействовать. История оценивается в 10 баллов. Что такое 10? Это 10 на 1 человека, это 10 на 100 разработчиков, работающих над проектом?

Использование человеко-недель прямолинейно.

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

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