Приблизительные подсчеты по проекту

0
791
views

Перевод статьи “Project Estimations”.

Приблизительные подсчеты по проекту

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

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

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

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

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

Но перед этим вам нужно придумать правильную начальную спецификацию.

После подготовки спецификации, если у вас есть бэкграунд в программировании (как у меня), следуйте такому плану:

  1. Для начала вам нужно бегло просмотреть спецификацию и разбить часы.
  2. Любая задача, выполнение которой предположительно займет больше, чем 5-8 часов, должна быть разделена на подзадачи.
  3. Затем вам нужно оценить опыт и навыки задействованных лиц, а затем произвести переоценку времени, вернувшись к п.2.
  4. Оцените риски и предусмотрите возможность новых, незапланированных требований, и вернитесь снова к п.2.
  5. Теперь добавьте небольшой зазор к подсчитанным часам, а затем еще раз пересчитайте время.

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

И последнее (по счету, но не по значению!). Если вы — менеджер проекта, тогда умножайте предварительные подсчеты, сделанные разработчиками, на 1,5 (лучше, если можете умножить на 2 или даже на 3) и согласовывайте с клиентом.

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

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

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

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



ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here