Кто-нибудь работает с функциональными точками?

Ответ 1

Майк Кон в своем Agile Estimating and Planning считает, что FP - это здорово, но сложно получить право. Он (очевидно) рекомендует вместо этого использовать оценку на основе сюжетных точек. Я склонен согласиться с этим, так как с каждым новым проектом я все больше вижу преимущества Agile-подхода.

1) Является ли это достаточно точным способом оценки? (Я не безразличен здесь, но хочу знать только по сравнению с другими методами оценки)

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

2) И нужны ли усилия, которые вы должны извлечь из этого?

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

3) Какой тип функциональных точек вы используете?

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

4) Используете ли вы какие-либо инструменты для этого?

Excel отлично справляется со всеми формулами, которые вы можете использовать. Использование Google Spreadsheets вместо Excel помогает, если вы хотите сделать это совместно.

Существует также отличный инструмент, встроенный в Sparx Enterprise Architect, который позволяет делать оценки на основе использования случаев которые также могут быть использованы для оценок FP.

Ответ 2

Я был специалистом по функциям IFPUG Certified Function Point от 2002-2005 гг., и я все еще использую их для оценки бизнес-приложений (веб-сайтов и толстых клиентов). Мой опыт в основном состоит из небольших проектов (1000 FP или меньше).

Я остановился на функциональных точках после использования пунктов использования и строк кода. (Я активно работаю с методами оценки уже более 10 лет).

Некоторые вопросы о функциональных точках:

1) Является ли это достаточно точным способом делать оценки? (Я не необоснован здесь, но просто хочу знать другим методам оценки)

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

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

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

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

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

Как только что-то стало серьезным, и мы назначили команду, мы будем использовать Planning Poker и некоторые другие методы оценки, чтобы придумать независимое число, и сравним их.

2) И стоит усилий, необходимых польза от этого выйдет?

Совершенно верно. Я нашел, что подготовка счета является отличным способом проверки требований уровня пользователя на соответствие требованиям и полноте, в дополнение ко всем другим преимуществам. Это было даже при создании Agile-проектов. Я часто встречал подразумеваемые истории, которые клиент пропустил.

3) Какой тип функциональных точек вы используете?

CPM IFPUG (руководство по практике подсчета) 4.2

4) Используете ли вы какие-либо инструменты для выполнения это?

Шаблон электронной таблицы Excel, который я получил от человека, который обучил меня. Вы вставляете атрибуты файла или транзакции, и он выполняет поиск по всем таблицам.

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

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

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

Ответ 3

Великий hacknot теперь отключен, но он находится в книжной форме. У него есть эссе о функциональных точках: http://www.scribd.com/doc/459372/hacknot-book-a4, в результате они представляют собой фантазию (с которой я согласен).

Joel on Software имеет разумную альтернативу звука, называемую планирование, основанное на фактических данных, которое, по крайней мере, звучит, как это могло бы работать....

Ответ 4

Из того, что я изучил о функциональной точке (один из моих учителей был очень вовлечен в процесс теории точки функции), и он не смог ответить на все наши ответы. Точка точки не во многом, потому что она не потому что у вас есть что-то прочитанное или написанное, которое вы можете оценить правильно. У вас может быть результат из 450 пунктов функций, и некоторые из этих функций будут занимать 1 час, а некоторые - 1 неделя. Это показатель, который я больше никогда не буду использовать.

Ответ 5

• Нет, потому что любое конкретное требование может иметь произвольное усилие, основанное на том, насколько точным (или неточным) автором требования и уровнем опыта оценщика точки функции.
• Нет, потому что управление неточными выводами абстрактных функций не дает достоверной оценки.
• Нет, если я могу помочь.
• Инструменты? Для функциональных точек? Как насчет Excel? Или слово? Или Блокнот? Или Эдлин?