Оглавление:
оценка программного проекта
Pixabay
Введение
Оценка просто сложна. К сожалению, это тоже очень необходимо. Компании используют оценки для составления графиков выпуска, принятия обязательств перед своими клиентами, принятия решения о том, стоит ли внедрять предлагаемую функцию, отслеживания скорости работы команд и эффективного определения приоритетов работы. Руководители часто хотят знать, когда функция или результат будут готовы к производству. В конце концов, разработка программного обеспечения - это нетривиальное вложение. Как бы руководитель проекта сделал оценку без оценок? Если бы люди могли точно предсказывать будущее, люди не выигрывали бы на скачках в 2% случаев. Оценка - это великая загадка. Компаниям важно и необходимо просить своих сотрудников делать невозможное: предсказывать будущее.
Во-первых, давайте рассмотрим некоторые популярные методы оценки (на случай, если вы упустили часть азарта). Затем мы сможем понять, что это значит для нас и наших проектов.
Модель гадалки
Эта модель почти не требует усилий для получения оценки. Оценщики немного думают о том, что нужно сделать для реализации и тестирования функции, а затем выкидывают число. Это очень похоже на «… (долгая пауза)… ммммм… 6 недель». Затем все кивают, и мы идем дальше. Они могут потратить немало времени на интерфейс, обсуждая то, что им известно о требованиях (что, вероятно, не является полной картиной). Такой тщательный анализ делает их оценку более надежной. В конце проекта всегда есть разумное объяснение того, почему оценка так далека от реальности. Всегда есть непредвиденные обстоятельства, которые могут послужить козлом отпущения. Часто никому не приходит в голову, что модель имеет серьезные недостатки.
Итак, как мы можем улучшить этот процесс? Я знаю! Мы можем использовать технику разложения (то есть разделять и властвовать). Этот подход предполагает, что вы знаете полный объем функции или проекта во внешнем интерфейсе. Каждая функция разбита на небольшие куски. Каждый кусок оценивается (стиль гадалки), затем мы складываем их, чтобы получить общую оценку функции / проекта. Это, безусловно, более сложный подход, но он кажется лучше по двум причинам:
- Меньшие объемы работы, как правило, легче надежно оценить.
- Хотя все еще существует возможность ошибки (+/- некоторая сумма), есть предположение, что ошибки нейтрализуют друг друга, когда вы все это сложите, и вы получите более надежную общую оценку.
Фундаментальный недостаток этого подхода состоит в том, что отдельные участники (люди, которые на самом деле делают работу) повсеместно недооценивают. Они по-прежнему значительно лучше, чем те, что наверху и вокруг них, но это не высокая планка. Это не похоже на тот случай, потому что все мы видели случаи, когда разработчики удивлялись, выполнив что-то раньше срока. Но это единичные данные, а не тенденция. Люди действительно иногда выигрывают в казино; тратьте деньги в казино каждый день в течение года, и у вас будет меньше денег, чем вы начали. Если вы отслеживаете оценки и фактические данные в течение года или двух, вы обнаружите, что оценки действительно не соответствуют действительности. Хотя многие бизнесмены абсолютно уверены, что разработчики лениво дополняют свои оценки и тратят дополнительное время на «золотую тарелку» или проверку своих запасов,данные показывают иное. Стратегия «отмены» не работает.
Ну что теперь? Давайте откажемся от модели гадалки и переключимся на подход, основанный на размере. Оказывается, хотя люди довольно плохо оценивают время завершения, на самом деле мы довольно хорошо умеем говорить о масштабах чего-либо. Мы особенно хороши в сравнительном измерении размеров («он больше, но меньше того»). Если мы думаем о размере или сложности, а не о времени, наш мозг обрабатывает это более надежно. Затем мы можем взять значения размеров и рассчитать фактическое количество часов для проекта на основе изящной волшебной формулы! И тогда на сцену выходит популярная модель функциональных точек (сцена слева).
Анализ функциональных точек (FPA)
Для анализа функциональных точек нам необходимо определить пять типов вещей в нашем приложении: внешние входы, внешние выходы, внешние запросы, файлы внешнего интерфейса и внутренние логические файлы (не беспокойтесь об определениях; вы можете изучить их позже). Каждый пример из них (функции) имеет связанную с ней сложность (низкая, средняя или высокая). Мы используем приведенную ниже таблицу, чтобы выяснить, сколько баллов присваивается каждой функции.
Теперь, если мы сложим баллы для всех наших функций, мы можем получить число, например, 457 функциональных баллов для нашего проекта. Тогда нам просто нужна формула, чтобы вычислить количество часов… Исходя из нашего последнего проекта, наша «скорость выполнения» составляла 15 функциональных баллов на человека в месяц. Это примерно 30 человеко-месяцев работы, а у моей команды из 12 человек должно пройти чуть больше двух с половиной месяцев. Та-да!
Это, безусловно, более сложная, чем наша предыдущая модель. Фактически, необходимо распознать четыре ключевые области сложности.
- Пять типов компонентов не обязательно интуитивно понятны, и легко забыть поместить что-то в список или назначить это неправильному сегменту.
- Таблица, используемая для фактического создания функциональных точек, содержит магические числа, для проверки которых потребуется много усилий. Правильно ли откалиброваны эти числа для получения надежных оценок для моих команд?
- Скорость выполнения (важный элемент головоломки) рассчитывается на основе производительности вашей команды. Как часто нужно рассчитывать новое число? На самом деле здесь очень мало указаний.
- Что такое низкая, средняя или высокая сложность? Как мы это определяем, чтобы все это понимали? Разве это не критично для точности наших расчетов?
В этом очень простом примере есть несколько движущихся частей, и мы даже не обсуждали более сложные модели сложности и другие данные, которые могут быть задействованы (например, стоимость, скорость поддержки, плотность дефектов и т. Д.). Больше движущихся частей означает больше возможностей для возникновения ошибок. Мы сейчас слишком усложняем оценку? Мы не платим разработчикам за то, чтобы они уделяли много времени оценке. Я не могу продать смету своим клиентам. Мне нужен рабочий софт. Есть что-нибудь еще?
Переход на Agile
Теперь давайте кратко рассмотрим agile scrum (достаточно, чтобы провести сравнение). Как указывалось ранее, люди плохо оценивают время и довольно хорошо умеют определять размеры. Вот пара терминов, которые нужно понять:
- Спринт - временной отрезок (обычно две недели).
- Пользовательская история - это отдельная работа, желательно достаточно небольшая, чтобы ее мог выполнить один человек в спринте. Это то, что мы оцениваем.
Самая популярная стратегия - использование последовательности Фибоначчи (0, 1, 2, 3, 5, 8, 13) для оценок. Это не линейно - по мере того, как вы поднимаетесь по шкале, размер промежутков увеличивается. Ключ в том, что расхождения должны быть достаточно большими, чтобы не было причин спорить о незначительных различиях. Как только вы превысите 3, разница между 4 и 5 или 7 и 8 будет настолько незначительной, что бессмысленно тратить время на выяснение того, какой именно. Последовательность по основанию 2 также будет работать (0, 1, 2, 4, 8, 16 и т. Д.).
«Но подождите, это всего лишь число. Что это означает? Сколько часов в балле? » Баллы не предназначены для прямого соотнесения с часами, потому что в этом случае у команд возникнет соблазн вернуться к оценке в часах, а затем как-то преобразовать это в баллы. Как обсуждалось ранее, точность наших оценок зависит от сравнительного определения размеров, а не от оценки количества часов, которые потребуются. Если вы дадите команде возможность мыслить часами, вы поставите под угрозу свою способность точно оценивать.
Допустим, вы начали с калибровочного упражнения. Соберите свою команду в комнату и проведите их по списку из 10–12 пользовательских историй. Выберите тот, который маленький, но не самый маленький, и сделайте его первым. Просмотрите его и объявите, что эта история - «3». Вы не спрашиваете. Вы говорите. Затем переходите к следующему рассказу. «Если бы это было 3, что это?» Теперь команда оценивает истории относительно других историй. В конце концов, у них будет довольно хорошее представление о том, что составляет «1», «2» и т. Д. Они не оценивают. Время не имеет значения. Они оценивают истории по сравнению с другими историями, у которых уже есть номер. Затем вы можете поместить примеры рассказов для каждого числа в последовательности в документ, называемый линейкой. Они могут использовать это как ссылку, если не уверены, что такое «5».
Теперь вот ключ. Волшебный соус, благодаря которому эта работа работает, - это «скорость» (количество очков, которое команда может набрать за спринт, усредненное за 3-4 спринта). Допустим, ваш спринт длится две недели, а ваша команда из 8 человек имеет среднюю скорость 35 очков. Вы получаете 35 баллов за 640 часов работы (8 x 80 часов). Если мы выясним, что для завершения работы над функцией потребуется около 100 баллов, то я знаю, что это около 6 недель работы и ~ 1900 часов. Команда очень хорошо умеет последовательно оценивать истории, и вы используете это для планирования своего проекта. Этот расчет работает, потому что продолжительность одинакова от спринта к спринту.
Чтобы выполнить долгосрочное высокоуровневое планирование, вы можете попросить своих потенциальных клиентов разбить высокоуровневые функции на промежуточные однострочные истории и присвоить им баллы. Будет потеряна степень точности, но вы используете модель, которую они уже понимают. Более точным путем будет относительный размер на уровне функций. «Этот объект больше, чем этот 40-точечный объект, меньше, чем тот объект из 120 точек, и немного больше, чем объект из 65 точек, который мы только что сделали». Истории сгруппированы в «былины». Если каждая функция является эпической, в конце вы узнаете, сколько очков потребовалось для ее выполнения. Сохраняйте историю этого, и вы можете использовать ее для планирования выпуска.
Заключение
Сегодня используется множество методологий. У каждого есть свои плюсы и минусы. Каким-то образом нам нужно выяснить, как повысить точность наших оценок, чтобы мы могли принимать правильные решения. Это не означает, что наши оценки должны быть точными. Они просто должны быть достаточно точными, чтобы быть полезными. Если вы не понимаете оценки, вы можете предположить, что оценки не были точными, потому что команда не справилась с работой. Не правильно оценили или неправильно выполнили проект. Избиения будут продолжаться, пока оценки не улучшатся. Но оценки никогда не следует использовать как обязательство. Это лучшее предположение, основанное на той ограниченной информации, которой мы располагаем сегодня. Когда появляется новая информация, мы должны разрешить пересмотр оценок. Все остальное ожидает невозможного, и это проблема лидерства (а не команды).
Подход Scrum намного проще, чем то, что мы видим в анализе функциональных точек. И я бы сказал, что это намного надежнее, чем волшебные таблицы с магическими числами. Он дает максимальную отдачу (минимальные усилия при достаточно высокой степени точности). С точки зрения усилий, это не создает тяжелого процесса для понимания и использования командами. На самом деле, оценка гибкости может произойти очень быстро, когда каждый поймет детали оцениваемой работы. Это, безусловно, лучше, чем вытаскивать цифры из воздуха. Использование скорости делает кое-что очень важное: оно вводит исторические данные в расчет. Каждый спринт вы пересчитываете свою скорость. Это очень важно, поскольку со временем производительность меняется. Команды, использующие FPA, могут получить свою скорость выполнения из своего предыдущего проекта,что в некоторых случаях было несколько месяцев назад. С тех пор, наверное, многое изменилось. Я предлагаю вам изучить Agile и действительно приложить усилия, чтобы понять суть истории и скорость. Не прибегайте к оценке в часах только потому, что вы это понимаете. Я думаю, вы поблагодарите себя позже.