Оценка скорости и точности программного обеспечения

Допустим, у вас есть проект, который будет включать два веб-приложения (которые будут совместно использовать сборки DAL/DAO/BO и некоторые библиотеки OSS):

  • Полусложное приложение для управления, которое использует Windows Live ID для аутентификации, а также способно взаимодействовать с различными службами уведомлений (электронная почта, смс, твиттер и т. д.), целевые уведомления составляют около 10% функциональности.
  • пользовательское приложение от низкого до полусложного уровня с меньшей функциональностью, но большей надежностью, которое также использует Windows Live ID для проверки подлинности

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

Вопросы

  1. Сколько времени / обычно вам требуется, чтобы сделать надежную / ценную оценку?
  2. Что бы вы посоветовали ускорить оценку, не жертвуя точностью?
  3. Сколько провисания (с точки зрения затрат / времени) вы бы добавили в зависимости от скорости оценки (когда вы скажете: я мог бы оценить это немного больше, потому что я думаю, что это все еще довольно плохо)
Источник

5 ответов

Решение

Интересный вопрос. Я боюсь, что ответ "это действительно зависит!" Я знаю, что это не очень полезно (хотя это правда), поэтому вот несколько факторов:

1) Качество и полнота требований и их уточнение. Для меня это чаще всего проектно-сметный убийца. Если у вас нет требований к качеству, у вас нет разумных оснований для оценки. Здесь мы используем стиль разработки продукта в стиле "RUP-lite", поэтому, будучи техническим инженером, я не дам ничего, кроме приблизительной оценки, пока мы не завершим наш этап "разработки" и не получим подтверждение от управления продуктами, что основные 80% характеристик продукта на самом деле точно покрыты.

2) Объем и характер продукта. Больше / дороже / сложнее = существенно дольше оценивать. Я потратил годы на разработку решений для наземных операторов связи, которые имеют нормальные и надежные требования к операторам связи ("5 9" времени безотказной работы, требуемые SLA, означают, что вы действительно должны хорошо поработать над дизайном решения и устранением неисправностей!). В такой среде со всеми движущимися частями в функциональных областях бизнеса оценка работы будет зависеть от получения полной картины... в частности, кросс-функциональные зависимости и внешние зависимости могут быть РЕАЛЬНЫМ убийцей здесь. Тем не менее, я также создал много упакованного и корпоративного программного обеспечения. В таких средах это намного проще, так как область действия, как правило, существенно меньше, поэтому его легче оценить.

3) Насколько "новый" этот проект? Насколько "нова" команда для этого продукта или набора технологий? Чем новее продукт или команда, тем больше и больше буферов вы должны выделить.

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

Это может занять всего пару дней или недель.. все зависит от размера. "Два или три дня", честно говоря, недостаточно для определения размеров чего-либо, кроме самого тривиального проекта.

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

И последнее: FWIW, я делаю это с 81 года, и я считаю, что точная оценка продолжительности / стоимости проекта - это самая сложная / опасная часть инженерного управления.

Источник

Поскольку мы используем гибкие методы (в частности, Scrum), у нас уходит на час больше времени, чем у пользователей, чтобы расставить приоритеты.

Больше времени не приводит к большей точности.

Сложная часть заключается в том, чтобы заставить пользователей расставлять приоритеты. Мы постоянно слышим эту дискуссию: "Если все не будет завершено вовремя, все это бесполезно". "За исключением компонента XYZZY, который имеет некоторую ценность". Этот аргумент может продолжаться часами, пока не будет решено, что XYZZY должен быть первым.

Как правило, мы стараемся создавать 4-недельные спринты. Первые несколько сложны, потому что всегда есть что-то новое. После первых двух (или трех) мы, кажется, установили устойчивый темп.

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

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

После первых двух спринтов

  1. Там новая и другая функциональность,

  2. Приоритеты все изменились,

  3. Детали каждого варианта использования были резко пересмотрены.

Что означает "точность", когда то, что вы пытаетесь оценить, меняется в конце каждого спринта?

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

Клиенты замечают это, и один из них сказал, что мы "тратим много времени на доставку того, что говорится в контракте, но это не то, что нам нужно".

Проблема с твердыми предварительными оценками состоит в том, что они ведут собственную жизнь. Чем больше вы "вкладываете" в оценку, тем больше оценки оказываются полезными. Они бесполезны, потому что, как правило, они совершенно не правы. Они основаны на предварительных предположениях, которые абсолютно неверны.

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

Не делай это заранее. Если ваш контракт требует от вас сделать это заранее, убедитесь, что у вас есть возможность контроля изменений, и сообщите клиенту, что вы обязательно внесете изменения по мере продвижения вперед. Как вы, так и клиент узнаете, вы оба должны внести изменения.

Источник

Чтобы получить достоверную оценку, вам действительно необходимо составить список задач, которые необходимо выполнить. Разбейте его на истории / задачи (даже если вы не используете Agile) и оцените их. Это уже может занять много времени, особенно количество исследований (поиск библиотек, которые могли бы выполнять эту функцию уведомлений, чтобы снизить затраты). Я бы взял по крайней мере 3 дня - однако 1-2 недели звучат для меня более разумно. Это не маленький проект.

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

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

Источник

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

Мы рассчитали 5 дней на создание этих страниц, на самом деле это заняло 10 дней и т. Д.

В долгосрочной перспективе подобная информация (надеюсь!) Позволит вам получить более точные оценки.

Источник

Ну, общая цитата: "Цена будет между 50% и 400% наших первоначальных оценок". Причина, по которой эта цитата выросла, в том, что это правда. Точность оценки во многом зависит от вашей предметной области. Если вы уже в сотый раз продали данный тип блогового движка, вы точно уверены в оценках. Однако чаще всего вы не обладаете такими глубокими знаниями о домене (если приложение уже существует, зачем создавать новое?).

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

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

Рассмотрим проект с 5 итерациями:

  • Начните с постановки основных этапов. Они могут быть изменены, но предоставят ваши первые оценки окончательного продукта.
  • План итерации № 1.
  • Оцените итерацию #1, скорректируйте итоговые оценки соответственно.
  • Сделать итерацию # 1
  • Промыть / повторить до итерации № 5
  • Вы сделали:)
  • Задумайтесь над своим проектом. Как развивались ваши оценки? Причины? Учись на практике:)

Большинство клиентов предпочитают иметь частичные оценки и частичные поставки, а не какую-то нереалистичную цель, которую продали им некоторые костюмы:)

Источник
Другие вопросы по тегам