Комментарии 34
есть еще метод оценки сверху вниз. в начале оцениваем общую стоимость проекта, без углубленного изучения отдельных составляющих. Затем, когда появляется больше различных нюансов и подробностей, эти общие цифры детализируются по мере продвижения работы.
Чаще всего этот метод используется стадии зарождения проекта, когда отсутствуют детальные данные о структуре и компонентах, необходимых для реализации работы. Чтобы осуществить подсчет с помощью метода “сверху вниз», профессионалы опираются на свод общих знаний и личного опыта в этой сфере. Кроме того, специалисты примерно определяют риски, которые могут возникнуть, в процессе работы над проектом.
есть еще метод оценки сверху вниз. в начале оцениваем общую стоимость проекта, без углубленного изучения отдельных составляющих. Затем, когда появляется больше различных нюансов и подробностей, эти общие цифры детализируются по мере продвижения работы.
Чаще всего этот метод используется стадии зарождения проекта, когда отсутствуют детальные данные о структуре и компонентах, необходимых для реализации работы. Чтобы осуществить подсчет с помощью метода “сверху вниз», профессионалы опираются на свод общих знаний и личного опыта в этой сфере. Кроме того, специалисты примерно определяют риски, которые могут возникнуть, в процессе работы над проектом.
По экспертной оценке, вы имеете ввиду каких-то сторонних специалистов с большим опытом?
Нет, не обязательно. На самом деле, эксперт тут, это просто человек, который мог работать раньше с подобной задачей (или такой же). Или например, у вас есть задача на интеграцию, где есть человек, который знает, как работает эта интеграция. Можете привлечь его для дополнительных советов.
Проблема экспертной оценки в том, что он бы сделал эту задачу за пять часов, а человеку, который первый раз в глаза технологию видит, надо будет пять часов только на то, чтобы с технологией разобраться. Пример: есть подрядчик, мы всем делаем SOAP, они о нем впервые услышали от нас. В итоге мучались две недели, хотя я им питоновский код даже скинул, но в итоге мы перепилили им на простой GET, возвращающий JSON. Т.е. я бы у них загрузку нашего JSON из SOAP-сервиса сделал бы за условные 10 минут, а у них там только неделю это отлеживалось, после чего достало их нытье и я переработал сервис, чтобы они могли себе грузануть JSON обычным GET.
ЗЫ: да, я понимаю, что вообще JSON и SOAP - это как бы вообще не близко, и через SOAP слудовало бы передавать массив объектов - XML-сиквенс. Но, думаю, такой подход вообще бы растянул интеграцию по шкале времени в бесконечность. И, наверное, надо было бы сразу им JSON выгружать через GET, но у нас все взаимодействие было построена на SOAP и мы не планировали выходить за рамки. Но в итоге вышли.
О да, такие случаи тоже бывают! Техника в целом не самая моя любимая именно поэтому, тут надо осторожно привлекать экспертов :)
Да просто эксперта попросите сделать детальную декомпозицию и подсветить риски.
А если это интеграция, то добавьте стандартных рисков, типа дока не та, интегратор не отвечает... В общем послушайте эксперта в интеграции, подойдите пессиместически. Ведь приятно потом получить результат быстрее, счастье оно тогда когда результат или сходятся с ожиданиями или превосходит их.
Вот так сидишь, оцениваешь задачи, а на саму оценку тоже надо время заложить ))
Замкнутый круг :)
Мы закладываем, я или на себя вешаю инвистигейт или на кого-нибудь из команды(но это уже после аналитика и моего анализа что все данные по задаче собраны верно), кто устал пилить и хочет в облаках полетать. В среднем ставим 8 часов на инвистегейт, но я сейчас в продукте работаю и с этим конечно легче, в аутсорсе было в основном докажи заказчику что эта задача стоит этих денег
не пытайтесь даже давать оценку задачам, если работаете в полном хаосе, где нет вообще понимания, что такое спринт. на моем опыте, все постоянно смещалось, лучше просто работайте по приоритетам и оценивайте по приоритетам.
Сам не раз сталкивался с ситуацией, когда оценил задачу в 2 часа, а потребовалось 8… Но это тоже опыт и это тоже исторические данные, которые в итоге помогут нам в оценках далее. Согласен, что по приоритетам тоже можно и стоит давать оценку, но опять же, если видеть конкретный результат в цифрах, можно оценить, достигли мы успеха или это провал. Опять же на основе результата, делаем дальнейшее планирование.
что сложнее всего оценить в работе, какие задачи?
Каждая задача требует тщательного анализа перед оценкой. Мне зачастую сложно бывает оценить простейший баг-фикс, просто потому что могут какие-то непредвиденные обстоятельства вылезти. В целом, этот процесс только улучшается с опытом, поэтому чем чаще мы оцениваем, тем лучше и точнее получается на мой взгляд. Но тут да, стоит придерживаться советов, как избегать трудности, которые я упомянул в статье.
.Вот кстати сложный вопрос, у нас например была ситуация с продуктом, когда разработчик который работал больше 5 лет, оценил задачу на рефакторинг достаточно простого компонента в X, а в итоге вышло почти 4Х. И к нему никаких претензий, потому что нашлось столько подводных камней что в итоге закурили даже те кто не курил. А отправлять каждую задачу на ±3 согласоваие это путь в болото
Three-point estimate звучит, как какая-то фигня.
Если мы уже сделали 3 оценки, то зачем нам зводить всё в одно число?
Почему бы не продолжить оперирывать 3-мя числами?
Тем самым закладывая в план те задачи, которые можно сделать дополнительно если большая часть задач будет реализована по оптимистичной оценке, а помечая задачи, от которых можно отказаться, если реализация будет проходить пессиместично.
Более того, подсчёт среднего может сильно сбивать с толку, когда оптимистичная оценка слишком далека от пессимистичной.
Например:
Надо нам интегрировать новое железо.
Оптиместическая оценка - 2 часа, в случае, если все драйвера подойдут и либы будут работать, как описано в доках.
Пессиместичная оценка - 40 часов, в случае, если драйвера придётся писать самостоятельно.
Ну и возникает вопрос, откуда, в этом случае взять наиболее вероятнаю оценку.
Рассмотрим 2 варианта:
Наиболее вероятная оценка - 2.
Наиболее вероятная оценка - 40.
В первом случае средняя выйдет 8.
Во втрором - 27.
И что нам это даст? Только то, что мы с огромной вероятносью получили неверную оценку.
Почему не использовать три числа вместо одного?
Да, использование только одного числа не дает полного представления о возможных вариациях в оценке времени или ресурсов. И ваше предложение использовать три числа для планирования задач тоже вполне адекватно, для более гибкого планирования. Но сводя в одно просто помогает упростить коммуникацию (легче воспринимать оценку через одну цифру, чем через 3) и проще проводить анализ результатов (для сравнения и создания трендов).
Проблема с расчетом среднего значения:
И да, расчет среднего значения может быть трудным, особенно когда оптимистичная и пессимистичная оценки сильно различаются. Однако, трехточечная оценка обычно включает в себя взвешенное среднее, где наиболее вероятное значение учитывается с большим весом, то есть этот метод как раз помогает сгладить влияние крайних значений.
Эти средние значения действительно могут вводить в заблуждение. Однако, трехточечная оценка не предполагает использование только среднего значения, а позволяет видеть диапазон и распределение вероятностей.
Опять же, это одна из техник, которая может подходить под контекст задачи, а может действительно сделать оценку труднее.
Всегда юзал снизу-вверх, но если были траблы с оценкой - перерабатывал чтобы успеть к дедлайну. Лично моя психологическая трабла, я всегда оцениваю оптимистично, надо зарубить на носу свои сроки умножать на 2. Ну вот даже допустим затащил всю PA на проект за пол года, а это по сути жестко. Сейчас я уже выгорел, если честно. Хочется только сидеть и играть в компик недельку другую. Помогите.
Как эти методики оценки ни назови - они являются лишь различной обработкой экспертных цифр оценки. Которая выбирается в зависимости от того, какой из вариантов результата больше нравится оценивающему :)
А как насчет коллективных оценок?
Смысл этих методик не в том, чтобы получить точные цифры, а в том, чтобы достичь консенсуса и общему пониманию сложности задач среди членов команды. Главное - это создание общих ожиданий и обсуждение потенциальных рисков и сложностей. Когда команда договаривается о сложности задачи (например через покер планирования), она также определяет, какие ресурсы и усилия будут необходимы для её выполнения. Таким образом, методики оценки служат скорее инструментом коммуникации и планирования, а не точным научным методом.
Если говорить о заказной разработке, то клиент не любит платить за максимальные оценки, которые зачастую подразумевают под собой увеличение времени на разработку, соответственно бюджет на все активности вырастет. Все же бизнесу хотелось бы побыстрее и подешевле. Да и максимальные оценки могут создать у клиента ожидания, что проект будет завершен позже, чем это реально возможно. Если команда завершит проект раньше, это может вызвать вопросы о завышенных оценках, что тоже может выстрелить неудачно такой случай.
Конечно, в некоторых ситуациях можно использовать максимальные оценки и работать в рамках бюджетов, но это подход тоже имеет свои риски и недостатки. Более точные оценки помогают лучше управлять проектом и достигать баланса между качеством, стоимостью и сроками.
Но опять же, если у вас есть конкретные случаи или задачи, в качестве примера, было бы интересно посмотреть, обсудить :)
К сожалению, если не оценивать, то и результаты не получить объективные, с которыми можно работать. Здесь важны цифры, с которыми уже можно в какой-то степени работать, анализировать, что могло пойти не так и наоборот. Оценка и нужна для понимания своих действий, мониторинга и коммуникации. Точных оценок не получить всегда, согласен, есть свои трудности. Опять же, если у вас есть конкретный пример, возможно следует его анализировать и попробовать в след. раз как раз подойти к оценке более адекватно, затрагивая все зависимости, сложности, почему у вас не получилось попасть в рамки.
то есть по вашему, лучше работать вне планирования? звучит, как провал )) тут клиент точно с вами работать больше не будет!
В оценке снизу вверх привели пример декомпозиции тестирования. В результате этих работ будут заведены ошибки, которые нужно будет исправить, перепроверить и снова завести новые ошибки и так по кругу.
Как оценивать этот этап исправления ошибок?
Мы как раз когда декомпозируем, закладываем часть времени на стабилизацию и ретесты после исправления багов. В итоге да, это наверно сложный пункт, чтобы оценить точно, но его тоже стараемся под какой-то цифрой в часах давать, опять же чтобы понимать свое планирование!
Расскажите, как QA лид, в деталях, как именно вы оцениваете этот этап. Для меня сейчас этот вопрос стоит остро, хочется узнать о вашем опыте.
Ох, давайте попробуем собрать мысли :)
- Понимание и декомпозиция всех этапов: Мы разбиваем весь процесс тестирования на отдельные задачи, такие как работа с требованиями, первичное тестирование, создание баг-репортов, ретесты после исправлений и т.д.
- Оценка времени на каждый этап: Для каждой задачи мы оцениваем, сколько времени потребуется на её выполнение. Например, для первичного тестирования одной фичи может понадобиться 5 часов, а на ретест после исправления багов — 2 часа. Здесь важно отметить, что сложно дать точную оценку времени на ретест, так как это зависит от времени, необходимого разработчикам чтобы пофиксить баги. Мы проводим синки с командой для обсуждения оценок и их корректировки при необходимости, те же самые дэйли встречи, где обсуждаем проблемные ситуации.
- Учёт непредвиденных задержек: Закладываем дополнительное время (например, 10-20% от общей оценки) на случай непредвиденных проблем и задержек в момент ретеста. В определённых случаях мы округляем оценки в большую сторону. Например, если ретест какого-то бага может занять буквально 2-3 минуты, мы добавляем буфер и округляем до 0.5 часа. Но этим не стоит злоупотреблять, всё зависит от условий.
- Адаптация плана в процессе: Если возникают новые баги, или требуется больше времени на исправление, мы корректируем наш план и перераспределяем ресурсы для ускорения и улучшения процесса стабилизации.
- Анализ ситуации: Регулярно анализируем производительность команды и корректируем оценки на основе текущих данных. Если определённые задачи ранее потребовали больше/меньше времени на ретест и стабилизацию, мы сохраняем эту информацию для истории и используем её для корректировки оценок на текущие и будущие подобные задачи в процессе планирования.
- Коммуникация с командой: Периодически сообщаем всем заинтересованным сторонам о текущем состоянии тестирования и исправления багов, поддерживаем обратную связь и при необходимости корректируем оценки.
Мой личный совет: всегда держите команду в курсе ваших затруднений, если вы не успеваете по оцененному времени. Таким образом, можно совместно корректировать ситуацию.
Публикации
Как оценивать проектные задачи, чтобы не слить бюджет и не убить команду: советы QA-лида