Перевод статьи “Project Estimations”.
Одними из самых сложных задач в разработке программного обеспечения являются правильные предварительные подсчеты по проекту.
В традиционной инженерии вы заранее знаете, какие шаги потребуются, чтобы завершить дорогу, здание или мост. Там предварительные расчеты будут более или менее верными по сравнению с тем, с чем вы столкнетесь в разработке ПО.
Разработка программ не является инженерией в строгом смысле, потому что это все еще растущая отрасль и здесь пока нет устоявшейся методологии для подбора технических решений. А еще и требования клиента меняются в ходе каждого цикла (или спринта, или чего-нибудь еще из того, что вы применяете), что еще больше усложняет задачу!
В Waterfall, Agile и других моделях есть много стандартных способов произведения приблизительных прикидок. В большинстве случаев этим занимается целая команда. Однако в личной практике, желая получить лучшие прикидки исходя из начальных требований, я применяю следующий метод.
Начать хорошо с разделения задач и требования по проекту до минимального размера, что может позволить вам более аккуратно вычислить дедлайны и временные метки.
Но перед этим вам нужно придумать правильную начальную спецификацию.
После подготовки спецификации, если у вас есть бэкграунд в программировании (как у меня), следуйте такому плану:
- Для начала вам нужно бегло просмотреть спецификацию и разбить часы.
- Любая задача, выполнение которой предположительно займет больше, чем 5-8 часов, должна быть разделена на подзадачи.
- Затем вам нужно оценить опыт и навыки задействованных лиц, а затем произвести переоценку времени, вернувшись к п.2.
- Оцените риски и предусмотрите возможность новых, незапланированных требований, и вернитесь снова к п.2.
- Теперь добавьте небольшой зазор к подсчитанным часам, а затем еще раз пересчитайте время.
Часы на тестирование и отладку должны также включаться в подзадачи. Их тоже надо тщательно измерить, чтобы получились правильные прикидки.
И последнее (по счету, но не по значению!). Если вы — менеджер проекта, тогда умножайте предварительные подсчеты, сделанные разработчиками, на 1,5 (лучше, если можете умножить на 2 или даже на 3) и согласовывайте с клиентом.
Реальные факторы будут зависеть от того, какая часть разработки использует код повторно, от проверенных API, а частично — от внедряемых вами инноваций. Эффективность работы разработчиков является критически важным моментом. Также существует такой фактор, как принятие на себя чрезмерных обязательств — он может привести к проблемам на поздних стадиях. Иногда разработчики, занятые в проекте, могут быть слишком уверены в своих способностях или способностях своей команды и из-за этого устанавливать недостижимые цели.
Все проекты уникальны, что влияет на предварительные подсчеты. Это касается не только комплектующих, но также психики клиента, концепции, кошелька и толерантности. Все мы хотим выдавать наилучший результат с помощью оптимальных ресурсов, времени и адекватного QA. Но реальность такова, что есть некоторые ограничивающие факторы, с которыми приходится сталкиваться (как все вы и сами знаете, исходя из своего опыта, или обнаружите вскоре).
Как я уже говорил, с учетом роста и развития индустрии программного обеспечения, предварительные подсчеты в ней можно отнести скорее к искусству, чем к науке. Во многих случаях нет гарантии, что вы сможете правильно прикинуть расходы и дедлайны даже очень сильно стараясь!
Небольшое предупреждение: все, что здесь написано, основывается на личном опыте автора и подходит не для всех ситуаций.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
