Как измерить оценку, и история указывает в Толпе? [закрытый]
С технической точки зрения все, что гарантируется, - то, что ссылка на объект является псевдонимом для него. Это при ссылочной передаче параметров капота сделано с указателями, деталь реализации. Это может сбивать с толку из-за ссылок, снова использующих & оператор, который является также адресом - но имеет в виду, что оператор на самом деле имеет различные значения в различных контекстах (в объявлении переменной или объявлении параметра это обозначает ссылочный тип, иначе это - адрес - кроме тех случаев, когда это является поразрядным - и). Поскольку это - технически просто псевдоним для объекта, ссылка 'всегда разыменовывается' как объясненный Worrier.
5 ответов
Ага! Так мне и надо писать по памяти.
Очко истории, конечно, связано с оценкой, и когда вы пытаетесь выяснить, сколько вы можете сделать для спринта, очко истории - это одна единица "работы", необходимая для реализовать часть или всю функцию. Один сюжетный момент может быть днем, часом или чем-то средним. Я перепутал «оценку» и «сюжетную точку» ниже, не знаю, о чем я думал.
Первоначально я написал «оценки» и «сюжетные точки». То, что я хотел написать (и отредактировал ниже), было «сюжетными точками» и «скоростью».
Сюжетные точки и скорость идут рука об руку, и они работают вместе, чтобы попытаться дать вам представление о том, «сколько мы можем завершить в заданный период времени ».
Рассмотрим пример.
Допустим, вы хотите оценить функции в часах, поэтому выполнение функции, для которой оценка составляет 4, займет 4 часа одним человеком, поэтому вы назначаете такую оценку всем функциям. Таким образом, вы считаете, что эта функция или ее "история" приносит 4 очка, когда дело доходит до конкуренции за ресурсы.
Теперь предположим, что у вас есть 4 человека в вашем проекте, каждый из которых работает в обычную 40-часовую неделю, но, в связи с этим, что касается других вещей, происходящих вокруг них, таких как поддержка, беседы с маркетологами, встречи и т. д., каждый человек сможет работать только над реальными функциями на 75%, остальные 25% будут использованы для других задач.
Итак. у каждого человека есть 30 доступных часов каждую неделю, что дает вам 30 * 4 = 120 часов за эту неделю, если вы посчитаете всех четырех человек.
Теперь предположим, что вы пытаетесь создать спринт на 3 недели, Это означает, что у вас есть 3 * 120 часов работы, которую вы можете выполнить. Это ваша скорость, как быстро вы двигаетесь, сколько «очков истории» вы можете выполнить.
Единица вашей скорости должна быть совместима с единицей для ваших очков истории. Вы не можете измерить истории в том, «сколько чашек будет потреблять разработчик (-и) при реализации этого» с «сколько часов у нас есть в наличии».
Затем вы пытаетесь найти набор функций, которые в совокупности занимают около , но не более 120 баллов в порядке их приоритетности. Это было бы просто суммированием сверху и снизу до тех пор, пока вы не дойдете до задачи, которая опрокидывает сумму, превышающую эти 120 баллов или равную им. Если он опрокинулся, не включайте задачу.
Вы можете так же легко оценить в днях или чашках кофе, потребленных разработчиком, так же, как это число является репрезентативным для типа работы, которую вы выполняете, и может быть связано с фактической работой, которую вы будете выполнять (т.е. сколько времени у вас есть в наличии).
Вы также должны оценивать свою рабочую нагрузку после каждого спринт, чтобы выяснить, является ли это число 75% точным. Например, если вам удалось выполнить только половину того, что вы намеревались сделать, выясните, были ли неверны оценки ваших функций или оценки рабочей нагрузки. Затем примите во внимание то, что вы узнали, при оценке и планировании следующих спринтов.
Также обратите внимание, что функции должны быть разделены, если они становятся слишком большими. Основная причина этого заключается в том, что в более крупные оценки встроено гораздо больше неопределенности, и вы можете уменьшить ее, разделив ее на подфункции и оценив их. Затем большая общая характеристика становится суммой всех под-функций. Это также может дать вам возможность разделить функцию между несколькими людьми, назначив разные вспомогательные функции разным людям.
Хорошее практическое правило состоит в том, что функции, оценка которых составляет более 1 дня, вероятно, следует разделить. *
Помните, что Очки - это просто ПЗУ (приблизительный порядок величины), установленное с помощью обычной практики « Планирование покера ». Первые несколько спринтов - это когда вы начинаете определять, что очки значат для команды, и чем дольше вы идете, тем точнее становится команда.
Кроме того, старайтесь использовать точки, которые немного больше разнесены. Практика, которую я видел и использовал, - это использование последовательности фибоначчи , это гарантирует, что у вас не будет слишком много разностей в 1 балл.
Также не забывайте, тестировщики, указывая историю, когда кто-либо, проводящий тестирование, должен взвесить, поскольку иногда простая задача разработки может потребовать больших усилий по тестированию, и если они истинные спринты, идея состоит в том, чтобы все было завершено, как могло бы отправлены (построены, протестированы и задокументированы).
При работе с новой командой или проектом мы всегда начинаем с предположения, что сюжетная точка - это единственный «идеальный день», и мы полагаем, что каждый разработчик проводит около 3,5 идеальных дней в неделю, и именно так мы вычислите нашу вероятную начальную скорость.
После того, как вы прошли стадию «планирования покера» и уравновесили / сравнили все свои истории, фактическая реальная продолжительность сюжетной точки действительно неизвестна - все, что у вас действительно есть, это довольно хорошее представление об относительной продолжительности, и постарайтесь вычислить вероятную скорость.
По крайней мере, я так делаю!
Если вы также нацеливаете свои очки на то, чтобы быть примерно равняется идеальному дню, тогда я бы предложил разбить ваши истории на более мелкие истории, иначе вы »Re не будет хорошо проводить время в планировании и отслеживании итераций.
Хорошие ответы со всех сторон.
Я хотел бы добавить один момент: на самом деле не важно, что вы выбираете в качестве основы для оценки ваших баллов (часы, идеальные дни и т. Д.) . Важно, чтобы оно было последовательным.
Если вы действительно сохраните его последовательным, это позволит вам обнаружить «истинную скорость» вашей команды. Например, предположим, что у вас было несколько итераций:
iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points
И теперь вы начинаете итерацию 4, и у вас есть следующее в отставании (отсортированном по приоритету):
item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points
Теперь, предполагая, что ваши оценки в баллах согласованы, вы можете быть достаточно уверены, команда завершит пункты 1, 2 и, возможно, 3, но определенно не 4.
Вы можете применить то же самое для выпуска невыполненных работ, чтобы улучшить прогноз даты выпуска. Это то, что позволяет командам Scrum улучшать свои оценки по мере продвижения.
Значение 10 это просто значение по сравнению с другими оценками, например, это вдвое меньше, чем 20, или немного сложнее, чем 9. Нет конкретного перевода 1 балл = x часов усилий - это то, на что следует указать.
Там, где я работаю, у нас есть то, что мы называем «эпическими точками», а именно: насколько сложна какая-то высокоуровневая история, например, интегрировать поиск в новый веб-сайт, который будет состоять из нескольких историй, которые нужно заполнить, а затем мы оцениваем часы на каждую историю создается путем разбивки каждой эпопеи, например, просто поместите Поиск на сайте вспомогательных документов. «Эпические точки» распределены в виде вариации чисел Фибоначчи (1,2,3,5,8,13,21,28,35), так что в более широком смысле более расплывчатые эпосы просто получают большую ценность, например, значение больше 8 - это показатель того, что их можно разбить на более легко поддающиеся оценке истории. Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в каждом спринте день теряется из-за встреч, таких как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому до спринта всего 9 дней. Добавляя парное программирование для некоторых вещей, времени на исправление ошибок и другой непроектной работы, такой как билеты в службу поддержки, становится довольно сложно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.
Первые несколько спринтов здесь значения начинают становиться более конкретными, поскольку на основе приобретенного опыта оценки могут стать более ясными с точки зрения того, как угадать значение.
это показатель того, что его можно разбить на более легко поддающиеся оценке истории. Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в каждом спринте день теряется из-за встреч, таких как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому до спринта всего 9 дней. Добавляя парное программирование для некоторых вещей, времени на исправление ошибок и другой непроектной работы, такой как билеты в службу поддержки, становится довольно сложно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.Первые несколько спринтов здесь значения начинают становиться более конкретными, поскольку на основе приобретенного опыта оценки могут стать более ясными с точки зрения того, как угадать значение.
это показатель того, что его можно разбить на более легко поддающиеся оценке истории. Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в каждом спринте день теряется из-за встреч, таких как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому до спринта всего 9 дней. Добавляя парное программирование для некоторых вещей, времени на исправление ошибок и другой непроектной работы, такой как билеты в службу поддержки, становится довольно сложно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.Первые несколько спринтов здесь значения начинают становиться более конкретными, поскольку на основе полученного опыта оценки могут стать более ясными с точки зрения того, как угадать значение.
Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в каждом спринте день теряется из-за встреч, таких как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому до спринта всего 9 дней. Добавляя парное программирование для некоторых вещей, времени на исправление ошибок и другой непроектной работы, такой как билеты в службу поддержки, становится довольно сложно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.Первые несколько спринтов здесь значения начинают становиться более конкретными, поскольку на основе приобретенного опыта оценки могут стать более ясными с точки зрения того, как угадать значение.
Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в каждом спринте день теряется из-за встреч, таких как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому до спринта всего 9 дней. Добавляя парное программирование для некоторых вещей, времени на исправление ошибок и другой непроектной работы, такой как билеты в службу поддержки, становится довольно сложно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.Первые несколько спринтов здесь значения начинают становиться более конкретными, поскольку на основе приобретенного опыта оценки могут стать более ясными с точки зрения того, как угадать значение.