Что такое оценка программного обеспечения и зачем она нужна клиентам? Оценка программного обеспечения — это процесс прогнозирования количества усилий и времени, необходимых программистам для разработки или обслуживания некоторого проекта. Клиентам обычно требуется оценка программного обеспечения, чтобы они могли понять, во сколько им обойдется разработка их программного обеспечения. Существуют различные факторы, которые могут либо положительно повлиять на точность оценки программного обеспечения, либо отрицательно повлиять на его отказ. Рассмотрим самые распространенные из них.

6 способов оценки программного обеспечения

  1. Основным условием точной оценки программного обеспечения является хорошая декомпозиция. Чем точнее требования заказчика, тем точнее их могут оценить программисты. Говоря об аутсорсинговой оценке программного обеспечения, важно понимать целесообразность такой декомпозиции, поскольку зачастую она может занимать очень много времени. Поэтому аутсорсинговые компании-разработчики программного обеспечения в большинстве случаев не могут себе этого позволить. Иногда детальная декомпозиция занимает до половины времени реализации проекта. К сожалению, аутсорсинговые компании не могут включить детальную декомпозицию в процесс оценки программного обеспечения.
  2. Еще один важный момент – оценка программного обеспечения должна проводиться всей командой, которая будет реализовывать проект. Кроме того, каждый член команды должен участвовать в обсуждении процесса оценки программного обеспечения. Это очень важно, потому что при обсуждении, в котором участвуют все, возникает много нюансов. Наличие мнения всех по этим деталям позволяет команде коллективно достичь наиболее точной оценки той или иной функции.
  3. Более того, все требования должны быть объяснены как можно яснее. Клиенту также желательно провести первоначальное обсуждение проекта со всей командой перед оценкой. Таким образом каждый в команде может узнать все ответы на волнующие его вопросы.
  4. В любом случае важно помнить, что любая оценка программного обеспечения является приблизительной. Никто, вероятно, никогда не даст прогноз со 100% точностью в отношении количества времени, необходимого для внедрения сложной системы, пока они не начнут работать над ней.
  5. Что необходимо иметь в виду, что по контракту с фиксированной ценой дальнейшее завышение невозможно. Наоборот, по договору «Время-материалы» Команда может предоставить завышенную оценку в некоторых случаях, когда клиент хочет какой-то новый функционал.
  6. В рамках Scrum команда дает приблизительную оценку программного обеспечения. Только для первых двух итераций команда может делать более-менее точные прогнозы. Также в начале часто даже клиенты не знают, чего они хотят от разработки. Детали функций еще недостаточно хорошо продуманы, поэтому для команды почти невозможно точно предсказать оценку программного обеспечения в таких обстоятельствах.
  7. Однако клиентам все же необходимо понимать, сколько денег им придется потратить на разработку программного обеспечения. Поэтому Команда делает декомпозицию и сравнивает одну задачу с другой, выстраивая спринты задач. Этот процесс называется картографированием историй. Первые два спринта содержат наиболее подробные описания самых важных функций, которые команда уже знает. Команда дает оценку программного обеспечения для этих функций при планировании и подготовке спринта. Затем Команда берет задачи на первый спринт в соответствии с оценкой программного обеспечения. Если они выполняют меньше или больше задач во время спринта, другие задачи перемещаются последовательно. Другими словами, если команда набрала 20 очков истории, но выполнила только 15, все задачи переместились. Также Команда понимает, что окончательная версия продукта будет готова позже, это потребует больше усилий и денег.

6. Что нельзя делать при оценке программного обеспечения

Существует множество факторов, которые могут негативно повлиять на точность оценки программного обеспечения. Мы хотели бы выделить 6 основных причин плохой оценки программного обеспечения:

  1. Плохое описание требований. Если продакт-менеджер неправильно формулирует требования, и они по-прежнему неоднозначны для команды, оценка программного обеспечения, скорее всего, не удастся. Это будет очень далеко от точности. Поэтому желательно, чтобы все детали требований были максимально четкими, чтобы все члены Команды понимали, что от них требуется.
  2. Разложение на высоком уровне. Углубление в декомпозицию требует тщательного исследования большего количества деталей. Это может привести Команду к нереалистичному прогнозу и, следовательно, к оценке программного обеспечения.
  3. Оценку делают люди, которые не будут заниматься разработкой проекта. Если разработчик не знаком с технологией и не будет работать над проектом, он не сможет сделать оценку.
  4. Оценка производится одним человеком, а не всей командой. Один человек просто не может оценить проект за других людей, отсутствующих во время обсуждения проекта. Только команда коллективно может дать наиболее точную оценку программного обеспечения.
  5. Слишком оптимистичная оценка, не учитывающая риски и проблемы. Также немаловажным моментом является то, что каждый член Команды должен оценивать задачу с учетом своей обычной, но не максимальной продуктивности.
  6. Давление со стороны коллег-инженеров или руководства. Если старшие программисты ожидают, что кто-то из членов Команды выполнит задачу быстрее, и тем самым давят на него, это может привести к замедлению работы и снижению производительности. В тех случаях, когда по каким-то финансовым причинам руководство компании ожидает, что команда потратит на проект меньше часов, оценка программного обеспечения будет неточной. В конце концов разработчики под давлением будут выполнять работу намного медленнее.

Адориасофт имеет проверенный процесс оценки программного обеспечения как по контракту Время-материалы в рамках Scrum, так и по контракту с фиксированной ценой. Свяжитесь с нами сегодня, чтобы получить точную оценку проекта и заказать разработку вашего отличного проекта!