Как вы задним числом измеряете фактическую сложность требования?

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

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

Время само по себе не сокращает его. Действительно, сложная задача потребует времени. Но есть факторы времени, которые искажают результаты и дают ложные срабатывания: Время относительно. Что такое "долгое время"? Если вы измеряете продолжительность, другие события могут мешать, вызывая увеличение продолжительности. Если вы измеряете рабочее время, то вы должны как-то нормализовать его в зависимости от уровня квалификации используемого ресурса (ресурсов) или типичного темпа работы одного ресурса над другим, т. е. одни люди работают быстро, другие медленно.

Наконец, некоторые простые задачи просто требуют много времени.

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

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

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

Вы можете отслеживать оценку по сравнению с фактическим временем, чтобы получить представление о первом.

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

В качестве альтернативы, если вы ищете некоторое подобие «сложности», в мире системной инженерии есть ряд инструментов, которые вы можете использовать для описания, моделирования и измерения сложности.

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

Чем дольше это занимало (включая кодирование, тестирование, исправление, тестирование и т. д.), тем сложнее это было.

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

Подводя итог: измерьте время работы над требованием.

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

Вот простой пример. Допустим, вам нужно сгруппировать определенные данные по годам и месяцам в порядке возрастания:

ee.sort_by { |e| e.date }. group_by { |e| e.date.strftime("%B %Y") }

Или у вас может быть довольно сложное решение с несколькими строками кода.

# several lines of code

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

Я предлагаю вам быстро поговорить после предоставления каждого требования, где вы сравните предполагаемые усилия/сложность с фактическими и сохраните результат. Когда у вас есть новое требование, вы сравниваете это требование с уже поставленным и используете результат, чтобы установить усилия и сложность нового.

Мы использовали следующий подход: мы создали три группы: S, M, L и разделили наши готовые требования на эти группы по их сложности (результат быстрого обсуждения). Получив новое требование, мы проверили, к какой группе оно относится. Скажем, новый был « М ». После доставки мы проверили его еще раз, и, когда он все еще был « М », мы поместили его в группу « М », если нет, мы пометили изменение, например, « М » -> « S », и поместили его в другую группу. .

Два хороших индикатора:

1. Отклонение усилия (для конкретного требования) — это один из способов измерения сложности. (Отклонение от расписания также может быть использовано для аналогичной цели)

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

Предположительно, более сложный продукт потребует больше итераций, чтобы «сделать правильный выбор», поэтому вы можете получить приблизительное представление о сложности, отслеживая количество и критичность ошибок в вашем коде, количество и продолжительность итераций для решения проблем с кодом. продукт и т. д.

Этот подход имеет ряд предостережений, некоторые из которых:

• Он предполагает единообразие в способностях людей, разрабатывающих продукты.
• Он предполагает единообразие сложности/критичности возникающих проблем.
• Предполагается, что требования не меняются со временем.

РЕДАКТИРОВАТЬ: К сожалению, я не прочитал вопрос должным образом в первый раз.

Измерить «сложно» постфактум просто , если ваши разработчики регистрируют свое время.

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

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

Вы сказали, что сначала оценили сложность. Таким образом, вы сравните расчетное с фактическим.

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

Другой вопрос - определение - как вы определяете сложность? Какие факторы могут привести к тому, что требование будет выглядеть сложным? Я знаю, что при ранжировании проектов по шкале сложности многие организации учитывают такие факторы, как факторы окружающей среды, политическая ситуация, поддержка управления, риски, внешние поставщики и т. д.

Прежде чем вы попытаетесь измерить что-либо, кроме времени, вам нужно понять это определение.

Каков базовый вариант использования?

Я подозреваю, что это проблема X/Y . В данном конкретном случае цель измерения сложности задним числом кажется попыткой решить вопрос «Насколько точными были оценки сложности?». что на самом деле является еще одним прокси для «Как я могу повысить точность оценок команды и / или плана проекта?»

Точность измерения

Похоже, что реальным измерением должна быть разница в расчетном времени по сравнению со временем «настенных часов» или изменение скорости команды с течением времени. Небольшие отклонения являются частью жизни; большие отклонения обычно означают проблему со скрытым процессом или неточные оценки. В любом случае, если ваши оценки постоянно ошибочны, значит, есть проблема, которую нужно раскрыть.

Я считаю, что все согласны с тем, что метрика, которую вы ищете, на самом деле очень субъективна. Однако это не означает, что вы не можете получить нужные данные. Предложение @Zsolt поговорить с вашей командой после этого, безусловно, является отличным подходом к получению этой метрики.

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

30-секундная версия... Идея состоит в том, чтобы взять значения из предыдущей работы и использовать их в качестве точек данных, чтобы дать оценку либо предполагаемой, либо только что выполненной работе. Это можно сделать независимо от используемой измерительной шкалы. Часто используется указанный выше размер футболки, но также популярна некоторая форма последовательности Фибоначчи . Лучше всего смотреть на X последних завершенных рабочих элементов, поскольку масштаб со временем будет меняться... в любом случае, все относительно! :)

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

Хотя относительный размер часто используется в Agile, нет никаких причин, по которым вы не можете использовать его в других средах/методологиях. Через некоторое время вы также можете наложить эти относительные размеры на фактически затраченное время. Именно тогда вы можете начать использовать относительные размеры в качестве инструмента оценки, не спрашивая людей об оценках типа «человеко-часов», которые большинство людей ненавидят делать и редко, если вообще когда-либо, находятся в пределах желаемой погрешности.

Надеюсь, это поможет!