Обучение

Новости
О центре
Центр карьеры
Сообщение об ошибке

Обучение

Ближайшие старты

IT Bootcamp

Новости

О центре

Центр карьеры

Корпоративное обучение

Отзывы

Истории успеха

Сообщение об ошибке
Введите поисковый запрос

«PERT работает – просто не все знают, как его правильно применять»

28 марта 2019

Наболевший вопрос специалистов по тестированию ПО – как научиться грамотно и точно формировать оценки необходимых времени и усилий на выполнение работы. Да ещё так, чтобы потом 100 процентов попадать в предполагаемые сроки. О том, как адекватно проводить эстимацию, не раздувать время тестирования и не брать цифры с потолка, рассказывает QA директор iTechArt, автор курса «Оценка трудозатрат и планирование тестирования» Оксана Скиндер.


Начинайте эстимацию с прояснения

Мы не можем оценивать то, что не знаем или плохо понимаем. Эстимация всегда начинается с прояснения. Первый этап – выяснение деталей, которые помогут понять, что нужно делать и какой результат мы должны получить. Точность оценки напрямую зависит от степени детализации первичной информации. Чем у нас её больше, тем точнее будет и оценка.

После того, как нам стало понятно, с чем мы имеем дело, приступаем к эстимации. Здесь перекликаются процессы планирования и непосредственно оценки времени. В зависимости от фичи или продукта принимаем решение, какие виды тестирования будем проводить, какую будем писать тестовую документацию и нужна ли она в принципе. После этого чётко виден фронт работы – мы его записываем, детализируем, эстимируем каждую часть в отдельности и предоставляем готовую оценку.

Привлекайте команду проекта к ревью оценки


Далее, если есть такая возможность, то важно показать оценку эксперту или команде. Как это происходило в моей практике. Например, я сделала оценку для команды из пяти человек и показываю её участникам: на оформление багов заложено столько времени, на прохождение усредненного тест-кейса – столько, предусмотрены такие-то виды тестирования. Согласны? Участники команды могут не согласиться и обосновать, почему для выполнения какой-либо задача нужно больше времени, что я забыла учесть. Таким образом, мы сможем предоставить заказчику более точную оценку.

Считаю, что ревью – очень полезный и нужный этап эстимирования. Поэтому старайтесь его не исключать. Он помогает дать грамотную оценку, а участники команды, в свою очередь, как бы подписываются под запланированными сроками и уже понимают, как и какой объём работы им нужно сделать.  

Не компенсируйте нехватку времени увеличением команды

После того, как удостоверились в правильности предложенной оценки, мы показываем её заказчику. Очень часто на этом этапе возникают новые подводные камни. Например, заложили на выполнение задания месяц, а заказчик говорит, что нужно справиться за неделю. Поэтому если у вас был заготовлен вариант действий на такой «пожарный» случай, то это очень хорошо.

Что происходит в реальности? Многие когда видят большой объём работы, сразу решают добавить людей в команду. Но это не работает! Любому новичку нужно «влиться» в процесс. Пока он разбирается со всеми нюансами, параллельно забирает время у опытного специалиста, которому задаёт вопросы. А их бывает немало. В итоге работа делается ещё медленнее. Мой совет: если у вас много работы и мало времени – никогда не добавляйте новых людей. Лучше урезать или скоуп, или объём тестирования, или, если ситуация критичная, подключить к тестированию разработчиков, которые есть на проекте, либо продукт-оунера, бизнес-аналитика. Конечно, если они располагают для этого временем. Не стоит соглашаться и на такой расклад, когда заказчик предлагает сам протестировать продукт. Из-за высокой загруженности делается это зачастую «на коленке». Толку от этого – ноль.

Анализируйте собственные ошибки и совершенствуйте последующие оценки


Как правило, на развитие навыка эстимирования у специалиста уходит от шести до девяти месяцев. Если речь идёт о повторяющихся задачах, работе на одном и том же проекте. То есть, если фичи примерно одинаковые и ничего экстра неординарного не добавляется (например, мы занимались вебом, а потом перешли на мобильную разработку), то в этом случае тестировщик за полгода практики сможет научиться правильно проводить оценку и  работать с рисками.

Важно понимать, что эстимация – это как вождение. Вы купили машину и ездите первый месяц по одному маршруту. В какой-то момент начинаете себя чувствовать уверенно и делать всё на автопилоте. А потом хоп и вам нужно проехать не с работы домой, а совершенно по другому пути. Возникает множество вопросов: как ехать, куда, где повернуть. Тоже самое и с процессом оценки тестирования. Если мы говорим про один проект и однотипные задачи, то да – реально за короткий срок научиться проводить оценку, предусматривать риски, анализировать ситуацию. Но если есть новая задача, то сюрпризы обеспечены.

Приведу пример. Я занималась эстимацией шесть лет, и тут в компании iTechArt мы запускаем новый вид деятельности – Product quality assessment. Это когда приходит заказчик и просит оценить качество произведённого продукта, который раньше никто не тестировал. Он спрашивает: сколько там у меня багов? Мы начинаем оценивать, сколько времени потребуется на выполнение этой работы: анализируем приложение, закладываем виды тестирования, тестовую документацию и так далее. Всё предусмотрели, делаем первый прогон и с первого дня понимаем, что не успеваем уложиться в предполагаемый срок. Почему? Оказывается, мы не заложили время на knowledge transfer – не учли тот факт, что специалисту нужно время, чтобы понять, с чем ему работать. Когда проводим эстимацию на постоянном проекте, то мы его уже знаем и не обращаем внимание на этот момент. А здесь новая активность и новые нюансы. Понятно, что когда мы во второй раз оказывали услугу Product quality assessment, то первое, что заложили – время на knowledge transfer.

Техники эстимаций нужно применять с умом


Оценка времени – это не теория. Да, сегодня все могут прочитать про PERT, метод «Дельфи», Planning Poker, но когда в реальности нужно применить что-то из этого, в голове только и крутится: как?

Возьмём метод PERT (Program Evaluation and Review Technique). Это такая оценка по трём точкам –  worst case, best case и most likely. Но как понять, какой кейс у нас worst? Что должно случиться? Или most likely – что это для нас значит? Сколько времени нужно заложить? Часто видела такой расклад: например, most likely – два дня, best – делим на два, worst – умножаем на два и вставляем полученные цифры в формулу. Потом что-то не сходится и специалист говорит: PERT у нас не работает. Но вы просто неправильно его применяете. Оценки требуют осознанности: почему делили на два, почему умножали, откуда взялись два дня на most likely.  

На курсе «Оценка трудозатрат и планирование тестирования» мы будем разбирать эти моменты именно с практической точки зрения. Я буду давать реальные фичи, а слушатели – проводить оценку. Мы обговорим все нюансы, которые могут возникнуть, и что необходимо учесть. Домашние задания каждый будет делать уже на своём проекте. На практике можно сразу оценить результат своих действий. Провёл эстимацию – заложил на на тестирование фичи три часа, а потратил пять. Анализируем, почему так вышло, и корректируем дальнейшие действия. На курсе слушатели получат «инструменты», которые можно применять в своей работе. И параллельно каждый уже в процессе обучения начнёт оттачивать навык эстимации.


Полная, частичная перепечатка или любое иное использование материалов с сайта IT-Academy разрешается только с указанием активной гиперссылки, ведущей на первоисточник (точный адрес страницы на www.it-academy.by).