Какие метрики рассчитать, если написание спецификации стоит потраченного времени?

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

И вот в чем загвоздка: ваши оценки, скорее всего, будут отличаться на несколько порядков. Они становятся более точными только по мере того, как ваша команда понимает проблемную область и оценивает не более чем на 2-4 недели вперед, максимум. Барри Бем (и Стив МакКоннелл) проиллюстрировали этот эффект принципом «конуса неопределенности»:

Чем дальше вы находитесь от реализации системы или функции (слева), тем больше неточность ваших оценок (-0,25x - 4x). По мере того, как вы приближаетесь и лучше понимаете проблемную область, оценки начинают приобретать большую точность (0,8x - 1,0x). Именно поэтому в программных проектах, где много "шума" или "сложности" (т.е. почти в каждом проекте), мы хотим оставить конкретную оценку до последнего ответственного момента - не более чем за 2-4 недели.

Вы также можете с абсолютной уверенностью ожидать одного: спецификации БУДУТ меняться со временем. То, как вы планируете адаптироваться и управлять этими изменениями, будет измерять ваш успех.

Таким образом, лучшим суждением, которое может быть принято в отношении объема вашей работы, будет собрать команду, которая будет работать над проектом, и «заказчика» для совместной проработки больших мазков — основных особенностей проекта. Запишите их в виде пользовательских историй, которые команда оценивает с использованием относительных весовых баллов (см. книгу Майка Кона об Agile Estimating and Planning) и разработайте план выпуска, который даст заказчику «черновик» прогноза того, чего ожидать — затем они могут решить, будет ли инвестиции принесут доход, который они ищут.

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

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

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

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

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

Сосредоточьтесь на сути и на том, что наиболее важно для вашего клиента. Общие бизнес-цели и видение. Мне нравится «лифт-тест» — чтобы объяснить, что делает ваш продукт менее чем за две минуты:

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

(из книги Джеффри Мура "Преодоление пропасти")

Возможно, это не ответ на ваш вопрос, но написать такую ​​маленькую "спецификацию" можно было бы для любого проекта.