Эмпирическая оценка продолжительности проекта

Question

Каковы общие эмпирические формулы, которые могут дать приблизительную оценку продолжительности проекта для методологии водопада (допустимо колебание до 20%). Если это помогает в сужении ответ, можно предположить, что после более или менее известны:

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

2. Известные и фиксированные макс. количество пользователей приложения.

3. Технологический стек, который необходимо использовать, достаточно разнообразен (до 4 разных языков и до 6 различных платформ).

4. Ожидается взаимодействие до трех устаревших систем.

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

Answer 1

Сделайте себе одолжение и забрать Стива Макконнелла Software Estimation: Demystifying the Black Art. Если у вас есть доступ к прошлым оценкам и действиям, это может значительно помочь в создании полезной оценки. В противном случае я рекомендую эту книгу и определяю стратегию, наиболее применимую к вашей ситуации.

Answer 2

Только рассчитывайте использовать 70% вашего времени разработчиков. Остальные 30% будут потрачены на встречи, ответы на электронную почту, на лифте и т. Д. Например, если они работают 8 часов в день, они будут иметь возможность кодировать от 5,6 до 6,5 часов в день. Сократите это число, если они работают в шумной среде, где люди используют телефон.

Добавить 20% к любой оценке, которую разработчик дает менеджеру проекта.

Линии кода бесполезны в качестве показателя при оценке проекта.

Успех или неудача зависит от кратковременных требований заказчика. Если требования не завершены, рассчитывайте на то, что клиент недоволен готовым продуктом.

Подсчитайте, что не все требования будут продиктованы клиентом. В рамках проекта будут внесены изменения в требования.

Answer 3

Шаг 1. Создайте график, который является гранулированным, насколько это возможно.
Шаг 2. Спросите людей, как долго их функции будут проходить.
Шаг 3. Создайте электронную таблицу Excel, которая отображает прогнозы на фактическое время.
Шаг 4. Повторите шаги 1-3 для всех новых проектов. Используйте агрегированное сопоставление из предыдущих примеров шага 3 для перевода оценок разработчика в фактические оценки.

Обратите внимание, что есть инструменты, которые могут сделать это за вас.

См. Также Evidence-based-scheduling.

Answer 4

Этот проект не будет дешевым ...

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

Это хорошо. Вы не хотите наводнять количество разработчиков в проекте. Хотя, если вы идете выше 10 человек, делайте подсчет каждые 2, как только 1, так как остальные будут подниматься вверх. Если вы не можете разделить задачу на то, что может быть обработано двумя совершенно отдельными командами. Тогда у вас будет шанс получить некоторую тягу.

Известные и фиксированные макс. количество приложений пользователей.

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

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

Это не так важно, как ваши люди знают этот стек/набор языков? Если есть какие-либо учащиеся, поднимите оценку x2 или x3, если вы не выполните доказательство концепции, чтобы изучить технологию. Или еще лучше, возьмите боль и немного погуляйте. Если язык для внедрения или технология, которая будет использоваться, неизвестна, то вполне вероятно, что вы будете злоупотреблять технологией и делать то, что будет закручивать.

Убедитесь, что технология доказана, или вы в конечном итоге ее укусили.

• Есть ли источник для инструментов/технологий?
• Вы получаете поддержку?
• Вы понимаете продукт или используете его раньше?
• Им пользовался ли клиент раньше?

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

Ожидается взаимодействие до трех старых систем .

Это действительно кикер. Для интеграции с наследием задайте себе вопрос:

• С кем-то еще с ними связано?
• У вас есть доступ к людям со знанием этих систем?
• Они собираются поделиться этим знанием с вами?
• Нужно ли ждать изменений, создаваемых в этих системах?
• Существуют ли для вас испытательные системы?
• Существуют ли системы разработки для вас?

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

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

Answer 5

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

Try this list of estimation tools on Wikipedia.