Почему мы используем сюжетные точки вместо человеко-дней при оценке пользовательских историй?

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

В чем преимущество введения абстрактного понятия (сюжетные точки), где мы можем просто использовать конкретное измерение, например, расчетные человеко-дни? Мы также можем рассчитать скорость, оценить охват итерации и т. Д., Используя расчетные человеко-дни.

Напротив, сюжетные точки сложнее использовать (потому что концепция абстрактна), а также сложнее объяснить заинтересованным сторонам. Какое преимущество оно предлагает?

124 голоса | спросил Louis Rhys 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

15 ответов


123

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

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

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

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
56

Если вы используете числа Фибоначчи (или что-то подобное), это ограничивает количество опций при оценке истории. Я работал с группой, которая использовала только низкие числа: 1, 2, 3, 5, 8 и 13. У нас была эталонная история, которая составляла 5. Это позволило нам легко сделать быстрые решения по сложности истории, делая Планирование покера , Другим побочным эффектом было то, что все, что оценивалось 13, вероятно, имело недостаточную информацию и должно было быть разбито дальше. Я серьезно сомневаюсь, что это было бы легко и просто, если бы мы использовали сырые часы.

Владелец вашего продукта говорит на языке ваших заинтересованных лиц и должен иметь возможность переводить между точками истории и человеко-часами (или другими единицами) по мере необходимости. В течение моего времени в качестве ПО у меня были некоторые данные о том, что 1 сюжетная точка = 4 человеко-часа, но очевидно, что каждая команда отличается.

Edit:

С учетом того, что 1 балл = 4 часа, теоретически вы можете поменять свою колоду Планирования покера на 4, 8, 12, 20, 32 и 52. Но эти цифры с трудом справляются. Я думаю, что мысленно абстрагирую ценности обратно до чего-то простого, например, «меньше суток», «больше недели» и т. Д. И если я собираюсь это сделать, я мог бы также придерживаться абстрактного блока без истории.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
23

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

Вместо того, чтобы все, участвующие в оценке, должны думать, что «ОК .. выглядит как 2 человеко-дня ... но последний спринт мы недооценили все, так что, может быть, это действительно 2,5 человеко-дня или 3?», они несут на себе как всегда. «Пять сюжетных точек!»

Затем вы корректируете свою оценку того, сколько точек истории может пройти команда в спринте, основываясь на фактических измеренных достижениях в предыдущих спринтах. «Мы уже делали 90-110 сюжетных очков за спринт!»

Я бы сказал, что теория заключается в том, что разработчики лучше оценивают сложность relative разных задач dev, чем они оценивают absolutes . Особенно, если несколько человек оценивают задачу, которую может выполнить любой из них (и не каждый работает на той же скорости, что и все остальные).

Циничная альтернатива: Я видел, что он сказал, что разработчики никогда не приходят под временными оценками. Если что-то занимает больше времени, чем предполагалось, вы прошли. Но если что-то занимает меньше времени, чем предполагалось, разработчики могут играть с ним, делать золотые пластины или просто замедляться и успокаиваться, так как им дается мягкое задание. Взятие реальных единиц времени из оценки может обуздать эти тенденции. Завершить циничную альтернативу.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
17

Дни человека или человеко-часы - это, как вы говорите, бетон. Поэтому, когда задание оценивается в 5 часов и занимает 6, теперь это более поздняя задача.

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

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

Это не означает, что нет споров или произвольного назначения очков. У нас есть члены нашей команды, которые почти всегда голосуют самым низким числом и жалуются, когда считают, что задача 1, и мы считаем, что это 3, что мы страдаем от точечной инфляции.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
12

Абстракция - это своего рода точка. Использование «человеческого дня» в качестве измерения имеет ряд подводных камней, в том числе:

  1. Если команда не знакома с технологией, которую они собираются использовать, то может быть очень сложно дать оценку в реальном времени того, как долго может потребоваться задача. Они гораздо более склонны давать хорошие относительные оценки - например, «задача A, вероятно, займет вдвое больше времени, чем задача B».
  2. Различные люди работают по разным ставкам! Если вы используете «человеческие дни», вы в значительной степени должны изменить оценку времени, когда задача передается от одного разработчика к другому. Кто определяет, сколько работы составляет «человеческий день» в любом случае?

Если вы хотите оценить человеко-дни, это простой расчет:

user points in story / average user points per developer per day = estimated man days
ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
5

Как уже упоминалось, сюжетные точки являются относительной мерой сложности. Для оценки можно использовать мощность 2-й серии (1,2,4,8,16 ...) или шкалу Фибоначчи (1,2,3,5,8,13,20 ...). Поскольку поддерживаемые разработчики вполне умеют говорить что-то вроде этого:

  

Функция A почти в два раза сложнее, чем функция B

Но действительно сложно сказать, «как долго» эта функция будет реализована для реализации. Вы позволяете этому уравновешиваться скоростью. Поэтому, если что-то оценивалось как 5, но оказалось равным 13, более медленная скорость нормализует это для итерации (или вы можете переоценить).

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

  

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

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

Точки истории

  • Помогает управлять кросс-функциональным поведением, то есть команды оценивают истории w.r.t. общая сложность реализации на всем пути от UI до DB и обратно.
  • Оценки SP не распадаются, т. е. через несколько месяцев 5-точечная история по-прежнему может составлять 5 очков, но идеальная дневная оценка может измениться в зависимости от приобретенного навыка развития /скорости этого конкретного программиста.
  • SP - это чистая мера размера, то есть они только и отражают только размер w.r.t. сложность. Период. Никакой продолжительности и т. Д., Бросил его. Это задача скорости. Но не так с идеальными днями. На самом деле в идеальные дни существует тенденция путать его с календарными днями. Сохраняя его абстрактным, поскольку SPs борется с соблазном сравнить с реальностью. Просто размер. Нет ерунды.
  • Обычно это быстрее, чем идеальные дни. Это может быть сложно для первых двух историй, но как только вы получите это, это быстрее.
  • Разные разработчики могут по-другому оценить свою идеальную дату для завершения истории. Я мог бы сделать то же самое в 3, и вы могли бы в 5. SP более или менее единообразны по всем направлениям. Они, таким образом, выравнивают игровое поле.

Идеальные дни

  • Легче объяснять за пределами команды; по очевидным причинам:)
  • Легче оценить сначала, как указано выше. Но как только вы получаете зависание SP, он приходит естественным образом.

Теперь, какой из них выбрать, зависит от команды. Однако, поскольку большинство ответов здесь и мой личный опыт, я предпочитаю сюжеты. Идеальные дни на самом деле не имеют такой большой пользы от SP (и Майк Кон также выступает за SP вместе со многими другими гибкими евангелистами).

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
3

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

Возьмите этот пример, который использует человеческие дни:

Команда оценивает различные задачи с человеко-днями. Он работает некоторое время, но через некоторое время вы видите, что команда выполняется быстрее со многими задачами, чем первоначально предполагалось. Поэтому команда переоценивает задачи. Это работает некоторое время, и через некоторое время вы снова видите одно и то же: команда быстрее выполняется со многими задачами. Таким образом, вы снова переоцените , и эта история повторяется снова и снова ...

Почему? Потому что производительность вашей команды увеличилась. Но вы не знаете об этом.

Тот же пример с сюжетными точками:

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

Почему? Поскольку производительность увеличилась. И вы можете измерить его. И вам не нужно переоценивать все после того, как производительность вашей команды увеличилась.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
2

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

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

Как сказал Наполеон: план бесполезен, планирование неоценимо.

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

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
1

Если вы подходите к человеку на улице и спрашиваете: «Насколько велика Т-рекс?» ответы будут колебаться, даже если большинство людей знают, что такое T-rex, насколько он велик, но никто не знает наверняка - потому что у нас нет относительной шкалы к исходному уровню.

Это когнитивное поведение, которое вы пытаетесь выяснить при прогнозировании, и многие циклы циклов методологий с « У меня есть это! .. У меня есть секрет точного прогнозирования! "змеиное масло в массы. Когда вы на самом деле прогнозируете, что на самом деле говорите outloud « , я ДОПУСКАЮ x дней /часов /очков для этого, чтобы завершить " - это в некотором смысле создание «временного окна», для этого события, которое должно быть выполнено внутри.

Для меня очки просто меняют границы, в конце дня, если вы не в команде, которая с удовольствием говорит « * Ну, у нас есть 3 недели на спринт, а большой сосок ... я думаю, что мы должны стрелять за 30 очков, чтобы закончить в этом цикле! кто со мной! * ", и это так глубоко, как вы идете в моделировании прогнозов - отлично! .. реалистично вы просто устанавливаете суровый бюджет и все. Вы также в ретроспективе смотрели на работу, завершенную с чувством «святого дерьма, мы сделали 33pts, что спринт, это было довольно круто», и об этом мало что можно сделать. Вы можете использовать скорость, чтобы определить середину спринта, которую вы получаете взрыва для своего бюджетного доллара, задав outloud « . Разве мы ударили 15 пп еще? Будем ли мы», но потом ваша спина добавит относительное время к уравнению aren ' t you? ", но опасность здесь заключается в том, что теперь вы используете Velocity для измерения производительности, а не производительности, которая, как я понимаю, запускает управление реактивной версией (точки истории) в голове.

Точечная система почти слишком умна, чтобы не заметить, что вы все еще присоединяете относительное время к уравнению, все от ваших согласованных «циклов спринта» до ваших ежедневных стояков, в которых вы вводите какое-то скрытое правило вокруг продолжительности + сложность = « Макс берет на себя долгое время "врожденная кишка, чувствующая командный код красным моментом?

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

Я бы сказал, что система Point работает, если вы не прогнозируете . Вы соглашаетесь на кусок работы, основанный на алгоритме подкачки, но это ваш самый близкий подход к прогнозированию. На самом деле вы управляете выпуском, чтобы искать естественные перерывы в очереди «отставания», которые подходят для темы (например, в Silverlight, менеджеры продукта будут ждать, пока они завершат свое отставание и соберут вместе те темы, которые мы изначально установили). никогда не знала, что конкретно делает команда инженеров, у нас просто был базовый план. Затем мы возьмем эту работу и построим вокруг нее маркетинговое мероприятие (Microsoft Mix))

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

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

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

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

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

Путешествуя по всему миру в качестве евангелиста, я увидел, что многие команды ругаются за все, что им дорого, что они взломали код Agile Forecast ... но я всегда щелкал языком, улыбался и уходил с подумал « да ... ты почти сделал, но эту любовницу мы называем« время »... она просто жестока ... "

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
0

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

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

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

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

Например, ваша команда разработала 5 историй в общей сложности на 23 очка на итерации 1 и 8 историй за 20 очков на итерации 2. Из этого вы можете оценить, что на итерации две ваши команды сделают несколько рассказов, общее количество которых около 20 пунктов на итерации 3.

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

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
-1

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

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
-1

Я думаю, что метод Story Point имеет как минимум два важных преимущества по сравнению с методом Man-day: Во-первых, это проще оценить в SP. SP является относительным, и такие люди, как мы, лучше в относительной, чем абсолютная оценка, например, метод человека.

Во-вторых, когда вы оцениваете в SP, вы получаете «Team SP» не «Individual Manday». Когда вы спросите: «Как долго эта задача займет?», Старший разработчик может дать вам 1 день, но 5 дней для младшего. Это Человек-день зависит от того, кто выполнит эту задачу. Если владелец изменен (и он будет!), Вы должны перепланировать все. С SP он все тот же, кто принимает задачу.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
-1

Я удивлен, что никто не упомянул Закон Паркинсона .

  

Работа расширяется, чтобы заполнить время, доступное для его завершения.

В принципе, если вы оцениваете в какой-либо единице времени для больших задач, разработчики будут стремиться потратить время, которое, по их оценкам, заполнить или пройти. Когда вы оцениваете в туманное время, например, Story Points или Shirt Sizes, вы избегаете этой ловушки.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
-1

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

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

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

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

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34
-2

Оценка сюжетной точки следует за рядом фибоначчи 1,2,3,5,8,13,21 ...

Человеческий мозг может легко отображать вещи, основанные на размерах. Например: у нас есть сообщение на карточке и присваиваем ему пункт 2 и 3, а третий размер карты будет означать 2 * 3 = 6 сюжетных точек.

Story Point 6 падает между рядами фибоначчи номер 5 и 8, а 5 - более близким числом, и, следовательно, сюжетная точка будет 5.

ответил inf3rno 10 +03002017-10-10T06:56:34+03:00312017bEurope/MoscowTue, 10 Oct 2017 06:56:34 +0300 2017, 06:56:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132