Я был сертифицированным специалистом по функциональным точкам IFPUG в 2002–2005 годах и до сих пор использую их для оценки бизнес-приложений (веб-приложений и толстых клиентов). Мой опыт в основном с небольшими проектами (1000 FP или меньше).
Я остановился на функциональных точках после использования точек использования и строк кода. (Я активно работаю с методами оценки уже более 10 лет).
Некоторые вопросы о функциональных точках:
1) Это достаточно точный способ
делать оценки? (Я не безрассудный
здесь, но просто хочу знать, по сравнению
другим методам оценки)
Трудно ответить быстро, поскольку это зависит от того, где вы находитесь в жизненном цикле (от проблескового эффекта до готового). Вы также должны понимать, что оценка важнее, чем точность.
Их самая большая сила в том, что в сочетании с историческими данными они хорошо держатся под давлением лиц, принимающих решения. Отделяя масштаб проекта от производительности (h / FP), они приводят к гораздо более конструктивным разговорам. (Я впервые увлекся оценкой на основе метрик, когда мне, веб-программисту, пришлось убедить личного друга основателя и генерального директора моей компании вернуться к своим инвесторам и сказать им, что обещанная им дата недостижима. Мы все Я знал, что это так, но именно история проекта и функциональные размеры (в то время это были доморощенные примеры использования) действительно убедили его.
Их преимущество самое большое на ранних этапах жизненного цикла, когда вам нужно оценить выполнимость проекта еще до того, как команда будет собрана.
Вопреки общепринятому мнению, не нужно много времени, чтобы придумать полезный счет, если вы знаете, что делаете. Только исходя из базовых типов информации (логических файлов), полученных на начальном собрании клиента, и средней производительности нашей команды, я мог бы получить приблизительный подсчет (но не более грубый, чем все другие неизвестные на этом этапе) и полезную оценку. во второй половине дня.
Объедините анализ функциональных точек с семинаром по упрощенным требованиям, и у вас будет отличный подход к настройке проекта.
Когда все стало серьезно, и мы назначили команду, мы бы использовали Planning Poker и некоторые другие методы оценки, чтобы придумать независимое число, и сравнить их.
2) И стоит ли усилий, необходимых
польза, которую вы получаете от этого?
Абсолютно. Я считаю, что подготовка подсчета является отличным способом проверки требований на уровне целей пользователя на предмет согласованности и полноты в дополнение ко всем другим преимуществам. Это было даже в создании гибких проектов. Я часто встречал скрытые истории, которые клиент пропустил.
3) Какой тип функциональных точек
вы используете?
IFPUG CPM (Руководство по подсчету) 4.2
4) Используете ли вы какие-либо инструменты для выполнения
это?
Шаблон электронной таблицы Excel, который мне дал человек, который меня обучал. Вы вставляете в файл или атрибуты транзакции, и он выполняет все таблицы поиска.
В качестве заключительного замечания, оценка NO является настолько точной (или, точнее, точной), как хотелось бы счетчикам бобов, по причинам, которые были хорошо задокументированы во многих других местах. Таким образом, вы должны управлять своими проектами так, чтобы это можно было удовлетворить (три ура для Agile).
Но оценки по-прежнему являются важной частью поддержки принятия решений в бизнес-среде, и я бы никогда не хотел остаться без своих функциональных точек. Я подозреваю, что люди, которые характеризуют их как «фантазию», никогда не видели, чтобы они использовались должным образом (и я видел их чрезмерно раздутыми и неправильно использованными, поверьте мне).
Не поймите меня неправильно, у ФП иногда возникает произвольное чувство к ним. Но, перефразируя Черчилля, функциональные точки - это наихудший из возможных методов оценки на ранних этапах жизненного цикла, за исключением всех остальных.