Эстимейты в тестировании, Эстимейт при тестировании - Управление тестированием - Форум тестировщиков
Снизу вверх и сверху вниз В рамках данного метода основная задача проекта разделяется на более мелкие. Портал Тренинги. Отправлено 18 января -
А общая сумма перерасхода средств из-за неправильных эстимейтов при планировании проектов и вовсе колоссальна. В сегодняшнем материале мы поговорим о том, как проводить оценку времени на разработку наиболее эффективно и на что обращать внимание в первую очередь.
А также узнаем, как опытные разработчики советуют подходить к эстимейтам. Методы оценки времени на реализацию программных проектов 1.
Сравнение с уже реализованными проектами метод по аналогу Найти уже реализованный проект с максимально похожим функционалом и взять время, которое потребовалось на его реализацию за основу — это один из классических методов эстимейта. Одно из его основных преимуществ в том, что при рассмотрении уже реализованного проекта можно увидеть, сколько времени закладывалось на его разработку изначально, насколько точно этот план был реализован, с какими сложностями сталкивались разработчики и на каких этапах.
Чтобы облегчить процесс оценки и увеличить общую точность эстимейта, зачастую делается разделение общего проекта на ряд составных частей, время реализации которых оценивается отдельно метод по параметрам.
Каждый делает свою оценку, после чего результаты сравниваются и обсуждаются. Те, кто был автором самого низкого и самого высокого из эстимейтов, приводят свои аргументы в пользу такой точки зрения, и в ходе обсуждения команда стремится установить реалистичные и адекватные сроки. Снизу вверх и сверху вниз В рамках данного метода основная задача проекта разделяется на более мелкие.
Так, чтобы каждую из задач можно было с достаточной точностью оценить. После этого время, необходимое для реализации каждой задачи, суммируется, что и дает финальный эстимейт. На втором этапе проект уже оценивается как одно целое. Если разница между данной оценкой и той, которая получилась после первого этапа с разделением на мелкие части слишком велика, команда анализирует причины и работает над компромиссной оценкой.
Сторонняя оценка Для тех команд, которым особенно сложно определиться с эстимейтом при оценке проекта или противоречия среди членов команды не удается разрешить , есть вариант обратиться к сторонней команде, которая сможет посмотреть на проект со стороны и выдать более взвешенное и объективное решение.
Тройная оценка В рамках данного метода команда формирует три варианта оценки времени на реализацию проекта: оптимистичный О , пессимистичный П и наиболее приближенный к реальному Р. Советы и мнения бывалых 1. Индивидуальные эстимейты не могут переходить к другим членам команды без изменений Как отмечают многие опытные разработчики, при планировании нужно помнить о том, что разные программисты сильно отличаются друг от друга по способностям и опыту, как с индивидуальной точки зрения, так и в работе с определенными языками и технологиями.
Именно это одна из основных причин, по которым компаниям и командам разработчиков бывает очень сложно точно рассчитать время на реализацию того или иного проекта.
Не забывайте о времени, которое уходит на коммуникации В своем бестселлере Manage the Unmanageable об управлении командой разработчиков авторы Микки Мантл Mickey W. Кроме того, эксперты пишут, что только одна шестая от общего времени работы над проектом приходится непосредственно на написание кода.
Половина времени, а то и больше, уходит на тестирование и исправление ошибок. Поэтому опытные разработчики советуют всегда помнить эту статистику и учитывать ее при составлении планов. Особенно это важно для команд, которые насчитывают достаточно много разработчиков. По наблюдениям, добавление новых кодеров в команду, как только их общее число начинает превышать определенный порог обычно это человек максимум , начинает неизбежно замедлять работу над проектом в целом. Происходит это из-за того, что новому разработчику всегда требуется какое-то время на то, чтобы познакомиться с членами команды и уже существующим кодом проекта.
Чем больше информации предоставляет клиент, тем лучше вы понимаете, сколько человеко-часов потребуется на его реализацию. И чем быстрее вы поймете, что план нужно скорректировать, и сделаете это — тем лучше. Варианты оценки времени на проект для клиента не должны сильно различаться Если вы отправляете клиенту два или больше варианта эстимейтов например, упоминавшиеся выше оптимистичный, пессимистичный и реалистичный , убедитесь в том, что они не слишком отличаются друг от друга с точки зрения выделенного времени.
Для эстимирования необходимо привлекать экспертов в данной области, имеющих опыт в выполнении оценок. Если привлекается несколько экспертов, то для вычисления конечного результата можно использовать один из ниже приведенных способов получения единого результата.
Оценка по аналогам сверху вниз, Top-Down estimation. Основывается на использовании исторических данных. В качестве основы берутся те значения, которые были получены ранее при эстимирвании аналогичных проектов и вносятся коррективы с учетом специфики эстимируемого проекта или задачи.
Параметрическая оценка. Базируется на использовании разработанных алгоритмов и математических моделей для вычисления стоимости проекта и сроков его выполнения. В качестве исходных данных используются статические, исторические данные, различные метрики. Использование модели позволяет проанализировать влияние того или иного параметра на стоимость, бюджет и длительность.
Оценка по трем точкам. В качестве исходных данных для получения финального Ф эстимейта используются оптимистичные О , пессимистичные П и наиболее вероятные В эстимейты. Данный метод целесообразно использовать тогда, когда информация об исторических данных отсутствует полностью. Оценка «Снизу вверх» Bottom-Up estimation. Если проект или задача достаточно объемны, то для получения более точного эстимейта выполняется декомпозиция задач декомпозицию желательно производить до тех пор, пока продолжительность одной задачи не будет превышать 8 часов или не будет понятна для эстимирования исполнителям.
Planning Poker. Самый популярный на данный момент способ эстимирования задач.
При планировании спринта каждый из членов команды выбирает карту с наиболее подходящей оценкой. Участники, выставившие наивысший и наинизший бал, приводят свои аргументы после первого тура. Далее происходит повторное голосование. Цель — прийти к общему мнению. В среднем, за час удается проэстимировать задач.
Более подробно процесс рассмотрим в дальнейших статьях, а также детально поговорим о Story Points единица измерения, позволяющая выразить оценку общих усилий, которые потребуются для реализации того или иного функционала. Bucket System. Используются емкости ведра , на которых написаны цифры ряд Фибоначчи. Все таски, которые надо обсудить, выписываются на отдельные карточки. Команда выбирает карточек рандомно и обсуждает их.
