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

Question

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

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

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

Вопросы

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

1. Появилась новая и отличающаяся от других функциональность,

2. Все приоритеты изменились,

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

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

---

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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