Красивая идея продукта внутри крупной компании или стартапа почти всегда неизбежно сталкивается с рядом трудностей на этапе реализации.
Часто бывает, что работа продвигается, исправляют ошибки, приближается релиз, но общего понимания состояния продукта нет. Это происходит потому, что собственная гениальность создателей ПО или сервисов (особенно если речь идет о стартапах) ослепляет их, а проблемы продукта неадекватно понимаются.
В результате в лучшем случае команда не укладывается в сроки выпуска, а в худшем — рождается нежизнеспособный продукт, который пользователи презрительно называют альфа и посылают создателям лучи ненависти через форму обратной связи.
Капитан Очевидность намекает: чтобы этого не произошло, важно уметь понимать состояние вашего продукта на каждом этапе его разработки.
В этой большой статье предлагается метод оценки его состояния в максимально наглядной форме – в виде таблиц и графиков.
Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Внесем ясность: мы создаем Parallels Plesk Panel — панель хостинга, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга.
Используя эту технику, мы получили следующие результаты:
- существенно улучшилось качество выпускаемых релизов (по данным Incidentrate);
- релизы стали более предсказуемыми, точность наших прогнозов и оценок значительно возросла;
- появилось понимание, почему что-то идет не так и как этого избежать в будущем.
Я отвечу на любые вопросы.
Статья написана по мотивам выступления на конференции QASib в Омске.
Подписывая предложение о работе в крупной компании или изобретая стартап, мы ожидаем от работы денег, успеха и признания.
В начале пути часто кажется, что все хорошо и безоблачно, что мы гении, придумавшие крутой софт или сервис с набором полезных функций, у нас слаженная команда и много времени.
.
Путь к успеху выглядит простым и беспроблемным.
Понимание обычно приходит на этапе подготовки к релизу.
Начинаются проблемы: сторонняя команда, которой вы передали часть работы на аутсорсинг, сбивает вас со сроками, кто-то из вашей команды внезапно заболел, запланированные фичи оказались значительно сложнее при реализации, выбранные технические решения не выглядят самый успешный.
К тому же вы тонете в море ошибок, требования от будущих пользователей постоянно меняются, появляются новые сверхважные функции, которые обязательно нужно впихнуть именно в этот релиз.
На этом фоне мотивация людей медленно тает. Эти проблемы могут поглотить вас и помешать освобождению.
Следовательно, никакого «мешка с деньгами» не предвидится.
Это недалеко от паники.
Ответ на знаменитые вопросы «Кто виноватЭ» а что мне делать?" можно получить на основе анализа данных, которые неизбежно окажутся у вас на руках.
Если вы как-то и где-то фиксируете свои задачи, текущий прогресс, результаты, найденные проблемы и другую полезную информацию, то отслеживать статус продукта не составит труда.
Ведение «журнала» проекта в амбарной книге имеет право на жизнь, но хранить данные лучше в какой-то системе, имеющей API или понятную структуру базы данных.
Использование API и/или базы данных сделает информацию легко доступной и анализируемой.
Команда Parallels Plesk Panel работает над задачами и ошибками в системе Целевой процесс .
Данная система имеет ряд встроенных отчетов, которые позволяют оперативно получать информацию о релизе, текущем ходе работы над ним, выполненных задачах и тех, которые еще предстоит сделать, загрузке команды и балансировке ресурсов, найденных ошибках, динамике.
их местонахождения и т. д. .
Если нам нужна более подробная и разнообразная информация, то мы получаем ее напрямую из базы данных TargetProcess. Ну а теперь непосредственно к данным и графикам.
Один из первых шагов, который позволит вам правильно оценить состояние вашего продукта в будущем, — это оценить, успеете ли вы вообще сделать все, что запланировали.
С одной стороны у вас отличная команда, а с другой — набор фич от заказчика/владельца продукта/менеджера программы.
Это то, что нужно сравнивать.
Во-первых, вам нужно оценить, сколько человеко-часов (или стори-пойнтов, или «попугаев») может обработать ваша команда.
Например, продолжительность релиза оценивается в три месяца.
В каждом месяце четыре недели, в каждой неделе 5 дней, в сутках 8 часов (для простоты я не учитываю праздники).
Команда состоит из 10 человек, где трое — мегапродуктивные ребята, пятеро — обычные сотрудники и двое — новички, проработавшие над проектом совсем немного времени.
Суммируя и умножая, получаем, что наша команда способна переварить объем работы общим весом около 4000 человеко-часов за один релиз.
Теперь прикинем, что придется сделать команде: тестирование новых функций — 2200 часов, проверка ошибок — 350 часов, регрессионное тестирование в конце релиза — 600 часов, автоматизация — 500 часов, отпуска — 160 часов (их можно вычесть от мощности команды, и вы можете указать это здесь, как вам удобно), риски – 200 часов (обычно сюда входят болезни людей, неожиданное поступление новых функций с пометкой «должен», задержки по вине других команд и т. д.).
Итого 3800 часов.
Похоже, мы успеем все сделать и обеспечить выпуск необходимого качества.
Или нет? Что, если производительность нашей команды значительно меньше объема работы, которую еще предстоит выполнить? Здесь есть несколько вариантов:
- Промолчите и оставьте все как есть, думая, что это как-то решится потом само собой, или выбросите у людей отпуска, или автоматизацию, или часть тестирования, что, скорее всего, приведет к снижению качества продукта.
.
Ну и что? Отлично! Ничего страшного, если вы работаете над продуктом, который ненавидите, или с командой, которую хотите разрушить… Обидно, что такой подход так часто используется в индустрии.
- Донесите проблему ограничения продуктивности команды до менеджеров программ и проектов и добейтесь сокращения количества функций в релизе или перенесите дату релиза на более поздний срок.
Звучит более-менее так.
А можно отнестись к этой ситуации как к сложному и интересному испытанию и пойти по третьему пути.
- Придумайте способ сделать то же самое, но за более короткий промежуток времени и с меньшими усилиями.
В идеале следует использовать два последних варианта одновременно.
Ну или у вас был четкий план, как обойти эту проблему.
Сделанные вами оценки лягут в основу диаграммы сгорания релиза.
В переводе на русский Burn Down будет звучать как «сгореть дотла» — что хорошо соответствует смыслу этого графика — чтобы показать количество проделанной работы и оставшейся работы относительно времени.
Теперь будут слайды.
Рассмотрим в качестве примера график работы команды QA для релиза длительностью три месяца.
Зеленая линия соответствует идеальному использованию ресурсов, когда каждый член команды каждый день выполняет фиксированный объем работы, соответствующий его квалификации и производительности.
Синяя линия показывает объем работы, которую необходимо выполнить в любой момент времени.
Из графика видно, что:
- первые семь дней были планированием и оценкой задач по выпуску
- далее работа над релизом шла около трех недель (поскольку синяя линия параллельна зеленой, скорее всего задачи были выполнены по плану, и первоначальные оценки совпали с намеченными)
- через месяц после начала релиза мы видим скачок синей линии вверх, скорее всего, объясненный добавлением новых функций или переоценкой трудозатрат
- далее мы снова видим работу над задачами, которые идут явно не по плану (может быть вызвано болезнью кого-то из команды, задержками со стороны других команд, низким качеством фичи и т.д.)
А еще одна линия на графике, красная пунктирная, показывает, когда мы действительно можем ожидать окончания релиза, если продолжим работать в том же темпе, что и в последние дни.
Он пересчитывается каждый день на основе фактического уровня использования задач за последние дни.
График выглядит просто, но он очень полезен для понимания текущей ситуации в вашем проекте и позволяет своевременно корректировать планы исходя из текущей ситуации.
Полезный лайфхак.
Помимо общего графика проекта имеет смысл иметь отдельные графики разработки и QA. Если команды большие и их можно разделить на подгруппы, то каждой из них лучше вести свой график.
Это может быть невероятно полезно при поиске узких мест в вашем проекте.
Возможно, вам даже удастся найти команду, которая тянет весь проект вниз и не дает ему взлететь.
У нас часто возникают вопросы: исправляем ли? Мы вовремя? Ответ здесь может дать информация о количестве открытых ошибок в релизе, сгруппированных по приоритету.
Для каждой ошибки мы устанавливаем приоритет от p0 до p4, где:
- P0 – должен быть отремонтирован как можно скорее
- P1 – должно быть исправлено до окончания итерации/спринта.
- P2 – необходимо исправить до конца релиза
- P3 - почините, если есть время
- P4 – все остальное, без чего точно можно обойтись
Зеленой линией показано количество открытых ошибок p0-p1, судя по графику, можно предположить, что 4 и 8 недели — это окончания итераций, когда все ошибки p0-p1 исправлены.
Это один из критериев закрытия итерации.
Красная линия соответственно показывает количество открытых ошибок p0-p2, а синяя линия показывает общее количество открытых ошибок в релизе.
Поэтому, если вы видите в начале и середине итерации, что объём ошибок р0-р1 растёт настолько быстро, что невозможно всё исправить и проверить их исправления до окончания итерации, то нужно принимать соответствующие решения.
: переприоритизация ошибок (вы заинтересованы в снижении приоритета для части ошибок p0-p1), перенос некоторых функций на следующую итерацию (потратьте освободившееся время на исправление ошибок), продление итерации до тех пор, пока не будут устранены все ошибки p0-p1. исправляются, добавляют в команду дополнительные ресурсы и т. д. Ближе к концу релиза имеет смысл добавить в этот же график еще одну строчку.
Фиолетовая линия показывает количество ошибок, которые может исправить команда разработчиков.
То есть, если наш релиз должен произойти в начале 19-й недели, то за 18-ю неделю разработчики смогут исправить 38 ошибок, за 17-ю и 18-ю недели - 79 ошибок, за 16-17-18-ю недели - 147. ошибки и так далее.
Такое расписание позволяет спрогнозировать ситуацию, когда команда разработчиков не сможет исправить все ошибки, которые необходимо исправить до окончания релиза.
Это позволит заранее предпринять определенные действия:
- сортировать ошибки p1-p2, чтобы перераспределить их приоритеты, разработку сосредоточить только на тех ошибках, которые действительно нужно исправить, а не тратить время на ошибки p3-p4 и псевдобаги p1-p2
- привлечь дополнительные ресурсы для исправления ошибок
- перенести дату релиза на более позднее время и т.д.
На картинке показан пример релиза трёх итераций, где две итерации — это разработка новых функций и одна — стабилизация продукта.
Если мы посмотрим на этот график во время работы на одной из первых итераций, то это позволяет нам отслеживать качество фич, над которыми сейчас работают. Например, если бы на 6 неделе мы получили 60 ошибок вместо 37, то это было бы для нас сигналом о том, что нам нужно разобраться, почему на этом этапе итерации мы нашли в 2 раза больше проблем, чем обычно.
То же самое относится и к исправлению ошибок.
Например, если за 4 и 8 неделю было исправлено значительно меньше ошибок, чем обычно, то нужно понять, почему.
Баги сложнее? Или на исправление ошибок было выделено меньше времени, чем ожидалось? Если мы посмотрим на этот график на этапе стабилизации продукта, то сразу увидим, доводим ли мы продукт до состояния, когда его можно будет передать конечным пользователям.
Кажется, ответ прост: да, если количество найденных ошибок уменьшится, и нет, если увеличится.
Но это не всегда так.
Этот график дает нам только информацию о том, сколько ошибок было найдено, но не говорит нам, какие это ошибки.
Если мы посмотрим на распределение найденных ошибок по серьезности в одном и том же релизе, то станет ясно, что релиз стабилизируется, хотя количество найденных ошибок не уменьшается по мере приближения к дате завершения.
Баги, обнаруженные в последних релизах, менее критичны с точки зрения серьезности: за последнюю неделю полностью исчезли блокировщики, почти исчезли критики, количество найденных мажоров уменьшилось вдвое, но количество нормалей и миноров увеличилось.
Поэтому неубывающее количество найденных ошибок не означает, что продукт не улучшается.
Еще одним ценным источником информации является распределение ошибок по обстоятельствам, при которых они были обнаружены.
Для этого у нас есть специальное поле «Обнаружено при условии» для ошибок, которое может принимать следующие значения:
- Клиент - мы пропустили ошибку в одной из предыдущих версий, а клиенты нашли ее и сообщили нам.
- Регрессия – функциональность, работавшая в предыдущих версиях, в текущей нарушена.
- Свежий взгляд - мы стали лучше и чаще тестировать и нашли ошибки в предыдущих версиях, которые пропустили ранее
- Новый TC - мы нашли ошибку в новых функциях текущего релиза
- И другие.
| Что случилось? | Что делать? |
| Мы обнаруживаем множество регрессионных ошибок при тестировании новой функциональности, созданной в текущей итерации.
|
Нам нужно понять причину, по которой при создании нового функционала мы ломаем старый работающий, поговорить с разработчиками соответствующих фич, увеличить количество юнит-тестов, запланировать дополнительное регрессионное тестирование.
|
| Находим много новых ошибок TC | Поговорите с разработчиками о причинах низкого качества функций, отправьте их на доработку и улучшите процедуры проверки кода.
|
| Мы находим много свежих ошибок | С одной стороны, мы стали лучше тестировать, смотреть глубже и шире, с другой стороны, почему мы не обнаружили эти проблемы раньше? Если к концу релиза сроки очень сжаты, то такими ошибками можно пожертвовать, потому что продукт не станет хуже, а найденные ошибки могут никого не волновать, так как на них никто не жалуется.
|
Объединив это с распределением серьезности, вы сможете выявить наиболее проблемные на данный момент компоненты и попытаться понять, почему это происходит и как это исправить.
Если проблемные компоненты не меняются из недели в неделю, вас можно поздравить: вы нашли узкое место в своем продукте.
И если клиенты постоянно жалуются на эти компоненты, то есть смысл задуматься об их качестве, архитектуре, команде, которая над ними работает, добавлении туда дополнительных ресурсов как со стороны разработки, так и со стороны QA, увеличении охвата тестированием и многом другом.
.
Одним из основных источников информации о продукте, конечно же, являются ваши пользователи.
Когда вы не работаете над первой версией продукта, то у вас есть возможность воспользоваться отзывами от них, которые вы можете получить через вашу поддержку, форум, команду продаж, руководства, автоматические отчеты, встроенные в ваш продукт и т. д. Это позволит:
- понять, какие функции в целом востребованы, а какие нет, что стоит развивать, а что нет;
- понять, как именно клиенты используют ваш продукт, какие сценарии (очень часто бывает, что вы вроде бы все проверили перед релизом, а после релиза приходят баги, что такой-то сценарий не работает, и этот не работает, но вы пошли совершенно разными путями);
- используйте тестирование на основе рисков (например, проводите полное тестирование наиболее распространенных конфигураций и ограниченное тестирование всех остальных).
Поскольку мы пользуемся TargetProcess уже несколько лет, объем накопленной информации очень велик, это позволяет нам достаточно точно спрогнозировать, чего именно ожидать от релиза, понять, насколько мы ошибаемся в оценках, которые даем, сколько ошибок мы увидим.
найдем и сколько исправим, какие риски обычно они снимают и как их обойти, сколько именно времени нам нужно на те или иные задачи и т.д. На что еще стоит обратить внимание при анализе текущего состояния релиза:
- результаты регулярного выполнения автотестов,
- разница между первоначальной оценкой и фактически затраченным временем,
- качество функций по оценке людей, ответственных за тестирование этих функций,
- количество открытых ошибок по приоритету серьезности,
- количество ошибок при проверке относительно времени,
- какой процент ошибок, обнаруженных во время релиза, мы исправляем?
- плотность ошибок в коде и т.д.
В частности, при разработке недавно вышедшей Parallels Plesk Panel 11 это разрешили.
Должен быть список того, что стало настоящим прорывом в Plesk 11 с точки зрения QA. Конечно, если бы мы могли говорить об этом вслух.
Но! Очень важно помнить, что независимо от того, сколько данных вы соберете, сколько таблиц и графиков вы построите, Они принесут пользу только в том случае, если вы сделаете на их основе полезные выводы и измените продукт и процессы в лучшую сторону.
.
Теги: #управление проектами #качество проекта #качество #parallels #Plesk #тестирование ИТ-систем
-
Вредоносное По Gumblar Снова Активно!
19 Oct, 24 -
Инструменты Для Онлайн-Слежения
19 Oct, 24 -
Натуральные Энергетические Напитки
19 Oct, 24 -
Невозможно Объяснить Монаду
19 Oct, 24 -
Воздух Или Не Воздух?
19 Oct, 24
