Оценка

Статья
06/10/2015

Автор Митч Лейси. Владелец, Mitch Lacey & Associates, Inc, консультационная фирма, специализирующаяся на принятии и усовершенствовании гибкого подхода и Scrum.

Январь 2012 г.

Mitch Lacey (Митч Лэйси)( обсуждаются оценку проекта программного обеспечения окружающую сложности, а также советы и tricks с помощью 2 гибких методов оценки программного обеспечения для вычисления проектов.

Применение

Управление жизненным циклом приложений; Team Foundation Server.

Содержимое

Введение
Поэтому оценивать трудно
Методы оценки
Баллы описания как единица измерения
Покер-планирование
Оценка на стене
Оценка
Определение приоритетов
Заключение

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

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

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

Поэтому оценивать трудно

В большинстве проектов необходимо выполнить оценку заранее. Чтобы понять, почему это такая проблема, необходимо изучить конус неопределенности, который предложен Барри Бемом в 1981 году и заново введен и Стивом МакКоннеллом в 1997 году в его книге Остаться в живых! Руководство для менеджера программных проектов.

Конус неопределенности

Конус демонстрирует, что больше всего неопределенности имеет место в начале любого проекта (дисперсия от 4x до 0,25x в диапазоне). Эта изменчивость означает, что мы оцениваем, что одногодичный проект может фактически занимать любой срок от 3 до 48 месяцев. Начало любого проекта — это время, когда это у нас меньше всего определенности в проекте, однако когда нас просят дать оценки, которые будут очень точными.

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

Методы оценки

Есть Широкий набор допустимых методов оценки, в том числе подсчет, экспертная оценка (индивидуумы и группы), разрешение, аналогия, прокси-оценка, покер-планирование и оценка стены. Можно также использовать такие средства, как Cocomo II. Все эти методы требуют, чтобы мы выбрали единицу оценки - часы, дни, недели, месяцы, дней, абстрактные дни, размер футболки, точки - или все из них. Если мы не понимаем единицу измерения, оценка не означает ничего. Учитывая все это, неудивительно, почему мы испытываем трудности с оценкой.

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

Баллы описания как единица измерения

Лучше всего баллы описания определяет Майк Кон : "Баллы описания — это единицы измерения для выражения общего размера описания функциональности, функции или другого элемента работы". «Баллы описания говорят об объеме описания функциональности относительно других, с точки зрения размера или сложности. Чтобы помочь командам понять концепцию относительного размера, Майк часто использует "собачьи баллы". Строка "dog" из 2 точек (малая) имела бы значение Chihuahua. Строка "dog" из 13 точек (большая) имела бы значение Great Dane. С этими 2 точками отсчета в голове, довольно легко определить размер других пород собак относительно чихуахуа или дога. Бигль, приблизительно вдвое больше чихуахуа, может быть равен 5. Лабрадор, который больше бигля, но меньше датского дога, может быть равен 8.

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

Если доходит до выбора номером для представления этих размеров, мне кажется, что последовательность Фибоначчи подходит наилучшим образом. Число Фибоначчи является суммой предыдущих двух чисел. Поэтому для 1 и 2 следующее число — 3. 3 и 2, следующее — 5. 5 и 3, следующее — 8 и т. д. Я предпочитаю числа Фибоначчи в сравнении, скажем, с системой размеров футболок или увеличением по экспоненте (4/8/16/32/64/128/256 и т. д.), поскольку мы как люди хорошо используем десятичные числа. Когда мы выходим из этого диапазона, даже если в нем, скажем, xs, s, m, l xl, становится запутанно. Числа Фибоначчи являются простыми, легкопонятными, и обеспечивают достаточную точность для достижения цели, предоставляя относительные оценки. Можно выбрать другой набор чисел, но помните, что последовательность очень важна.

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

Покер-планирование

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

Начните с колоды карт для покера планирования. Карты для покера планирования можно легко сделать из карточек с цифрами, наклеенных на игральные карт, или купить — их даже делает Visual Studio. Каждая карта содержит одно из чисел в выбранном диапазоне расстояния баллов описаний (1, 2, 5, 8, 13 и т. д.). Каждому участнику сдаются "карты", которые содержат полный набор доступных баллов описаний.

Пример покерных карт для планирования

После раздачи карт начинается игра.

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

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

Если наблюдается большой разброс (например, отображаются числа в диапазоне от 1 до 8), команда тратит время на обсуждение описания. Для сконцентрировать обсуждение, попросите людей, высказавших самую низкую и высокую оценки, объяснить причины их оценок. Здесь ценность имеет разговор, а не цифра, поскольку именно в ходе разговора происходит познание и выявление каких-либо предположений. После краткой 30-секундной или минутной дискуссии команда повторит шаги 4 и 5. Это продолжается до тех пор, пока команда не будет соглашаться в оценке для описания функциональности.

Это кажется относительно прямолинейным, но важно понять некоторые основные правила. Во-первых, если вся команда не приходит к некоему соглашению, переходить к другим вопросам не следует. Например, пусть в команде будет один человек, который предпочитает 8, а все остальные выбирают 5. Если координатор собрания говорит "Достаточно близко". Здесь мы выберем пять, двигаемся дальше", что сделает человек, у которого восемь? На основе моего опыта этот пользователь согласится со всем. что решит команда, но полностью перестанет участвовать. Планирование таким образом может идти быстрее, однако вы потеряли что-то ценное. Кроме того, что этот человек хуже понимает свою работу, команда теряет вклад и точку зрения одного своего члена. К тому же, в несогласии нет ничего страшного. Ценное понимание поступает из обсуждений того, почему один человек выбрал число больше, чем все остальные. Если вы оказались в патовой ситуации, пусть координатор попробует метод "от кулака до пяти пальцев". Это творит чудеса для прохождения собраний без изменения участников.

Поскольку метод планирования покера выражает оценки в точках, он идеально подходит для оценки невыполненных работ по продукту. Задел работы спринта, однако, должна быть вычисляется в часах. С другой стороны, покер планирования может успешно использоваться (и уже используется) для оценки заделов работы спринта; цифры на картах, однако, становятся часами, а не баллами. Поэтому, простое правило:

Невыполненная работа по продукту оценивается в баллах.
Невыполненная работа по спринту оценивается в часах.

Можно использовать покер-планирование в начале любого проекта и во время его жизненного цикла, по мере того как новая информация появляется, меняются приоритеты и появляется ясность.

Оценка на стене

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

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

Чтобы выполнить оценку стенки, сначала необходимо распечатать описания функциональности пользователей на карточках. Затем соберите команду и заинтересованных лиц в комнате с большой пустой стеной (примерно 5 метров шириной и 2.5 - 3 метра высотой); поймите две вещи про стену:

Высота определяет приоритет. Описания функциональности вверху имеют более высокий приоритет, описания внизу — более низкий. Приоритет описаний может быть основан на окупаемости инвестиций, ценности для бизнеса или на чем-то таком же простом, как «это просто важно, и я знаю, почему».
Ширина зарезервирована для размера. Описания функциональности слева меньше, описания справа — больше. (Можно изменить это и перемещаться справа налево, если вы, допустим, в Японии, это логичнее.) Важно представить себе линию, проходящую горизонтально, и еще одну, проходящую вертикально. Члены команды и заинтересованные лица должны спросить себя: где по отношению к другим описаниям должно быть расположена это?

Команда будут использовать стену, чтобы назначить размер всем Описаний функциональности. Заинтересованные лица будут использоваться стену, чтобы назначить приоритет Описаний функциональности. Как и в случае с методом планирования покера, используется относительный размер, но вместо использования двух описаний функциональности ссылки для сравнения стена становится константой. Маленькое описание функциональности? Переместить влево. Большое описание функциональности? Переместить вправо. Важное описание функциональности? Поместите его повыше. Описание функциональности, без которого мы можем обойтись сейчас? Поместите его пониже.

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

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

Оценка

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

Если у рабочей группы возникли проблемы с этим, можно более эффективно структурировать материал на стене, предоставив дополнительные справочные описания с рейтингом от 1 до 8 баллов. Не беспокойтесь о создании более подробного справочного описания; все, что больше по размеру, обычно разбивается на части, поскольку повышается приоритет. После того как команда определила пять описаний функциональности, поместите их на стене в месте, связанным с их размерами (снова перемещая слева направо). Оставьте справа на стене место для описаний функциональности крупнее, чем 8 пунктов. Поместите эти описания функциональности на стене и попросите команду разместить оставшиеся описания функциональности на стене относительно этих опорных описаний, помня о том, что меньшие описания располагаются слева, а большие — справа.

Когда описания функциональности на стене, пусть команда определит логические разрывы ожидания между допустимыми размерами статьи. Проклейте скотчем вертикальную линию между группами описаний, чтобы наглядно изобразить эти разрывы. Скоро ваша стена будет выглядеть примерно так, как показанная здесь. Все в первой группе может быть равно 2; все во второй — 3; все в третьей группе — 5; и все в последней группе — 8. Числа не очень важны; важен тот факт, что все описания функциональности теперь оценены относительно друг друга.

Пример оценки на стене — относительная сортировка

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

Определение приоритетов

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

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

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

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

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

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

Пример оценки на стене — сортировка по приоритету

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

Оценка на стене — четыре квадранта

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

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

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

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

Два Метода оценки, которые я рекомендую — покер-планирование (для небольших наборов описаний функциональности) или оценка стены (хорошо для управления большими необработанными наборами Невыполненной работы по продукту). Либо предоставит данные, необходимые, чтобы начать формирование плана, что является конечной целью оценки.