Красивая идея продукта в рамках крупной компании или стартапа почти всегда неизбежно сталкивается с рядом сложностей на этапе воплощения. Частенько бывает, что работа идет, баги фиксятся, релиз приближается, но общего понимания состояния продукта нет как нет. Так бывает потому, что собственная гениальность создателей софта или сервиса (особенно если речь идет о стартапах) застит им глаза, и проблемы продукта понимаются неадекватно. Как результат — в лучшем случае команда не попадает в сроки релиза, а в худшем – на свет появляется нежизнеспособный продукт, который пользователи презрительно называют альфой и шлют создателям лучи ненависти через форму обратной связи.
Капитан Очевидность намекает: чтобы такого не допустить, важно уметь понимать, в каком состоянии находится ваш продукт на каждом этапе его развития. В этой большой статье предлагается методика оценки его состояния в самой наглядной форме – в форме таблиц и графиков. Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Чтобы было понятно: мы делаем Parallels Plesk Panel – хостинг-панель, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга. Применив эту методику, мы получили вот такие результаты:
- существенно улучшилось качество выпускаемых релизов (согласно Incident rate);
- релизы стали более предсказуемыми, точность наших прогнозов и оценок выросла в разы;
- появилось понимание, почему что-то идёт не так и как этого избежать в будущем.
Заинтересованных лиц прошу под кат и в комменты. Отвечу на любые вопросы.
Статья написана по мотивам выступления на конференции QASib в Омске.
Подписывая оффер на работу в крупной компании или придумывая стартап, мы ждем от работы денег, успеха и признания. В начале пути часто кажется, что всё прекрасно и безоблачно, что мы гении, придумавшие классный софт или сервис с набором полезнейших функций, у нас сработавшаяся команда и уйма времени. Дорога к успеху выглядит простой и беспроблемной.
Понимание обычно приходит на этапе подготовки к релизу. Начинаются проблемы: сторонняя команда, которой вы зааутсорсили часть работ, динамит вас со сроками, кто-то в вашей команде неожиданно заболел, задуманные фичи при имплементации оказались существенно сложнее, выбранные технические решения выглядят не самыми удачными. К тому же вы тонете в море багов, требования от будущих пользователей постоянно меняются, возникают новые суперважные фичи, которые обязательно нужно впихнуть именно в этот релиз. На этом фоне мотивация людей потихоньку тает. Эти проблемы могут вас поглотить и помешать состояться релизу. Следовательно, и «мешка с деньгами» не видать. Тут уж и до паники недалеко.
Ответ на известные вопросы «Кто виноват?» и «Что делать?» может быть получен на основе анализа данных, которые неизбежно будут собираться у вас на руках. Если вы хоть как-то и где-то фиксируете свои задачи, текущий прогресс, результаты, найденные проблемы и другую полезную информацию, то отслеживать состояние продукта будет несложно. Ведение «бортового журнала» проекта в амбарной книге имеет право на жизнь, но лучше хранить данные в некоей системе, у которой есть API или понятная структура базы данных. Использование API и/или БД сделает информацию легко доступной и анализируемой.
Команда Parallels Plesk Panel ведет работу с задачами и багами в системе TargetProcess. Эта система имеет ряд встроенных отчётов, позволяющих нам оперативно получать информацию о релизе, текущем прогрессе по работе над ним, сделанных задачах и о тех, которые ещё предстоит сделать, загрузке команды и балансировке ресурсов, найденных багах, динамике их нахождения и т.д. Если же нам нужна более детальная и разнообразная информация, то мы получаем её напрямую из базы TargetProcess.
Ну а теперь непосредственно к данным и графикам.
Одним из первых шагов, которые в будущем вам позволят правильно оценивать состояние вашего продукта, — это оценка того, успеете ли вы вообще сделать всё то, что задумали.
С одной стороны, у вас есть прекрасная команда, а, с другой стороны, набор фичей от заказчика/product ownerа/program managerа. Вот это и нужно сопоставить.
Для начала нужно прикинуть, сколько человеко-часов (или стори поинтов, или «попугаев») ваша команда сможет переварить. Например, продолжительность релиза оценена в три месяца. В каждом месяце по четыре недели, в каждой неделе по 5 дней, в каждом дне 8 часов (для простоты не учитываю праздники). Команда при этом состоит из 10 человек, где трое – это мегапроизводительные ребята, пятеро – обычные сотрудники и двое – новички, проработавшие над проектом совсем немного времени. Просуммировав и умножив, мы получим, что команда у нас способна переварить за один релиз объем работ суммарным весом около 4000 человеко-часов.
А теперь прикинем, что команда должна будет сделать: тестирование новых фичей – 2200 часов, верификация багов – 350 часов, регрессионное тестирование в конце релиза – 600 часов, автоматизация – 500 часов, отпуска – 160 часов (можно их вычесть из team capacity, а можно заложить здесь, как кому удобнее), риски – 200 часов (сюда обычно попадают болезни людей, новые фичи, приезжающие неожиданно с пометкой «must», задержки, вызванные другими командами и т.д.). Итого 3800 часов. Выглядит, что мы успеваем сделать всё и обеспечить релиз должного качества.
Или нет?
А что если у нас производительность команды существенно меньше объёма работ, который предстоит сделать?
Тут есть несколько вариантов:
- Промолчать и оставить всё как есть, подумав, что потом как-нибудь само собой решится, или выкинуть отпуска людей, или автоматизацию, или часть тестирования, что скорее всего приведёт к снижению качества продукта. Ну а что? Нормально! Нормально, если вы работате над продуктом, который ненавидите, или с командой, которую хотите разрушить… Жаль, что такой подход так часто используется в индустрии.
- Донести эту проблему ограничения производительности команды до програм- и проджект-менеджеров и добиться уменьшения количества фичей на релизе или сдвига срока релиза на более позднюю дату. Звучит более-менее. А можно отнестись к этой ситуации как к сложному и интересному испытанию и пойти по третьему пути.
- Придумать способ, как сделать всё то же самое, но за меньший промежуток времени и с меньшими усилиями. В идеале стоит использовать два последних варианта одновременно.
Обязательно следите за тем, чтобы объем работы, которую нужно сделать, коррелировал с объемом работы, который ваша команда способна переварить. Ну или у вас был чёткий план, как эту проблему обойти.
Сделанные вами оценки положат основу для release burn down chart.
В переводе на русский burn down будет звучать как «сгореть дотла» — что хорошо соответствует смыслу этого графика – показывать объём сделанной и оставшейся работы относительно времени.
Вот теперь будут слайды.
Рассмотрим для примера график работ QA команды для релиза продолжительностью три месяца.
Зелёная линия соответствует идеальной утилизации ресурсов, когда каждый член команды каждый день выполняет фиксированный объем работы, соответствующий его квалификации и производительности. Синяя линия показывает объём работы, который необходимо сделать в каждый момент времени.
Из графика видно, что:
- первые семь дней шло планирование и оценка задач на релиз
- потом около трех недель шла работа на релизом (так как синия линия параллельна зелёной, то, скорее всего, задачи делались по плану, а первоначальные оценки попали в точку)
- через месяц после начала релиза мы видим скачок синий линии вверх, объясняющийся, скорее всего, добавлением новых фичей или переоценкой трудозатрат
- потом опять мы видим работу над задачами, которая явно идёт не по плану (может быть вызвана болезнью кого-то из команды, задержками на стороне других команд, низким качеством фичей и т.д.)
Если у нас это было заложено в рисках – отлично, если нет – то нужно принимать решение о том, что делать, чтобы исправить ситуацию.
И ещё одна линия на графике, красная пунктирная, показывает, когда ожидать окончания релиза на самом деле, если мы продолжим работу с таким же темпом, как и в последние дни. Она пересчитывается каждый день, исходя из реальной скорости утилизации задач за последние дни.
График выглядит просто, но при этом является очень полезным для понимания текущей ситуации в вашем проекте и позволяет своевременно скорректировать ваши планы, исходя из текущей ситуации.
Полезный лайфхак. Помимо общего графика для проекта имеет смысл иметь отдельные графики для девелопмента и для QA. Если команды большие и их можно разделить на подкоманды, то лучше для каждой из них держать свой график. Это может оказаться безумно полезным в поиске узких мест в вашем проекте. Возможно, вам удастся даже найти ту команду, которая тянет весь проект вниз и не даёт взлететь.
Часто у нас возникают вопросы: а то ли мы чиним? А успеваем ли? Ответ нам здесь может дать информация о количестве открытых багов на релизе, сруппированных по приоритету.
У каждого бага мы выставляем приоритет от p0 до p4, где:
- P0 – должен быть починен ASAP
- P1 – должен быть починен до конца итерации/спринта
- P2 – должен быть починен до конца релиза
- P3 — починить если будет время
- P4 – всё остальное, без чего точно можно жить
В качестве примера рассмотрим следующий график.
Зелёная линия показывает количество открытых багов p0-p1, судя по графику, можно предположить, что 4 и 8 недели являются концами итераций, когда все баги p0-p1 чинятся. Это один из критериев закрытия итерации.
Красная линия, соответственно, показывает количество открытых багов p0-p2, а синяя линия – общее количество открытых багов на релизе.
Следовательно, если вы видите в начале и середине итерации, что объём багов p0-p1 растёт настолько быстро, что исправить все и проверить их фиксы до конца итерации невозможно, то нужно принимать соответствующие решения: переприоретизация багов (интересует уменьшение приоритета для части багов p0-p1), перенос части фичей на следующую итерацию (освободившееся время потратить на багфиксинг), продлить итерацию до тех пор, пока не будут починены все баги p0-p1, добавить дополнительных ресурсов в команду и т.д.
Ближе к концу релиза в этот же график имеет смысл добавить еще одну линию. Фиолетовая линия показывает количество багов, которые сможет починить команда девелоперов. То есть, если у нас релиз должен случиться в начале 19-й недели, то за 18-ю неделю девелоперы смогут починить 38 багов, за 17-ю и 18-ю недели – 79 багов, за 16-17-18-ю недели – 147 багов, и так далее.
Такой график позволяет вам спрогнозировать ситуацию, когда команда девелоперов не способна починить все баги, которые должны быть починены до конца релиза. Это позволит вам заранее предпринять определённые действия:
- отсортировать баги p1-p2 с целью их переприоретизации, девелопменту сфокусироваться только на тех багах, что действительно нужно чинить, и не тратить время на баги p3-p4 и псевдобаги p1-p2
- привлечь дополнительные ресурсы к багфиксингу
- подвинуть дату релиза на более позднее время и т.д.
Следующая вещь, на которую имеет смысл смотреть – это количество найденных и исправленных багов относительно времени.
На картинке показан пример релиза из трех итераций, где две итерации – это девелопмент новых фичей и одна – стабилизация продукта.
Если мы смотрим на этот график в момент работы над одной из первых итераций, то это позволяет отслеживать качество фичей, над которыми сейчас идёт работа. Например, если бы на 6-й неделе мы получили вместо 37 багов 60, то это было бы для нас сигналом о том, что нужно разобраться, почему мы нашли проблем в 2 раза больше, чем обычно на этой стадии итерации.
Примерно то же самое касается багфиксинга. Например, если на 4-й и 8-й неделе починено существенно меньше багов, чем обычно, то нужно понять почему. Баги сложнее? Или на багфиксинг выделено меньше времени, чем предполагалось?
Если мы смотрим на этот график на этапе стабилизации продукта, то сразу видно, приводим ли мы продукт к тому состоянию, когда его можно отдавать конечным пользователям. Кажется, что ответ прост: да, если число находимых багов падает, и нет, если растёт. Но и это не всегда так. Этот график даёт нам лишь информацию о том, сколько багов найдено, но не говорит о том, что это за баги.
Если же мы рассмотрим распределение найденных багов по severity на том же самом релизе, то станет понятно, что релиз таки стабилизируется даже при том, что число найденных багов не уменьшается по мере приближения к дате окончания работ.
Находимые баги на последних релизах являются менее критичными с точки зренияseverity: блокеры на последней неделе совсем изчезли, критикалы почти исчезли, число найденных major’ов уменьшилось в два раза, а вот число нормалов и миноров возросло.
Следовательно, неуменьшающееся число находимых багов не говорит о неулучшении продукта.
Ещё один ценный источник информации — распределение багов по обстоятельствам, при которых они были найдены.
Для этого у нас у багов существует специальное поле “Found under condition”, которое может принимать следующие значения:
- Customer — мы пропустили баг в одной из предыдущих версий, а кастомеры его нашли и зарепортили нам
- Regression — работающая в прошлых версиях функциональность оказалась сломана в текущей
- Fresh Look — мы стали лучше и больше тестировать и нашли баги из прошлых версий, которые пропустили ранее
- New TC — мы нашли баг в новых фичах текущего релиза
- И другие...
Понимание того, как найденные баги распределяются по этим категория, даёт нам ряд полезной информации, которую вкратце можно представить вот в такой легко воспринимаемой таблице.
| Что случилось? | Что делать? |
| Находим много регрессионных багов при тестировании новой функциональности, сделанной в текущей итерации | Нужно понять причину, почему, делая новый функционал, мы разламываем старый работающий, поговорить с разработчиками соответствующих фичей, увеличить количество юнит-тестов, запланировать дополнительное регрессионное тестирование. |
| Находим много new TCs багов | Поговорить с разработчиками о причинах низкого качества фичей, отправить их на доработку, улучшить процедуры code review. |
| Находим много fresh look багов | С одной стороны, мы стали лучше тестировать, смотреть глубже и шире, с другой стороны, почему мы эти проблемы не обнаружили раньше? Если очень поджимают сроки в конце релиза, то подобными багами можно пожертвовать, т.к. продукт не станет хуже, а найденные баги, возможно, никому и не мешают, раз на них никто не жалуется из пользователей. |
Ещё один полезный источник информации – это распределение багов по компонентам, оно нам даст ответ на вопрос о том, какой компонент вашего продукта слаб в коленках.
Совместив это с распределением по severity, можно выделить наиболее проблемные компоненты на текущий момент и попытаться понять, почему это происходит и как это исправить.
Если проблемные компоненты не меняются от недели к неделе, вас можно поздравить: вы нашли узкое место в вашем продукте. А если ещё и кастомеры постоянно жалуются на эти компоненты, то имеет смысл задуматься об их качестве, архитектуре, команде, которая над ними работает, о добавлении туда дополнительных ресурсов как со стороны девелопмента, так и со стороны QA, увеличении тестового покрытия и многом другом.
Одним из главных источников информации о продукте для вас, безусловно, являются ваши пользователи. Когда вы работаете не над первой версией продукта, то у вас есть шанс воспользоваться обратной связью от них, которую вы можете получать через ваш саппорт, форум, сэйлзов, руководство, автоматические репортилки, встроенные в ваш продукт и т.д.
Это позволит:
- понять, что из фичей вообще востребовано, а что – нет, что стоит развивать, а что – нет;
- понять, как именно кастомеры используют ваш продукт, какие сценарии (очень часто бывает, что вы перед релизом вроде бы всё проверили, а после релиза приходят баги о том, что вот такой-то сценарий не работает, и такой не работает, а вы ходили совершенно другими тропками);
- использовать risk-based testing (например, проводить полное тестирование на наиболее распространённых конфигурациях и урезанное на всех остальных).
Ещё один мощный инструмент – это сопоставление текущей ситуации с предыдущими релизами.
Так как TargetProcess мы используем несколько лет, то объём накопленной информации очень велик, это позволяет нам достаточно точно предсказывать, чего именно ожидать от релиза, понимать, насколько мы ошибаемся в тех оценках, которые даём, сколько мы багов найдём и сколько починим, какие риски обычно стреляют и как их обходить, сколько именно времени нам потребуется на те или иные задачи и т.д.
На что ещё стоит обращать внимание при анализе текущего состояния релиза:
- результаты регулярного исполнения автотестов,
- разница между первоначальными оценками и реально потраченным временем,
- качество фичей, проставляемое людьми, ответственными за тестирование этих фичей,
- кол-во открытых багов по severity-priority,
- кол-во багов на верифай относительно времени,
- какой процент найденных во время релиза багов мы чиним,
- плотность багов в коде и т.д.
Как видите, все эти графики и таблицы – очень мощный и полезный инструмент, который поможет вам правильно и точно спланировать релиз, учтя большинство возможных проблем, заранее предсказать проблему и помочь вовремя её исправить, и, что не менее важно, избежать её в будущем.
В частности, при разработке вышедшей недавно Parallels Plesk Panel 11 они позволили.
Тут должен быть список того, что по части QA стало в Плеске 11 настоящим прорывом. Конечно, если об этом можно было бы говорить вслух.
Но! Очень важно помнить, что сколько бы много данных вы ни собирали, сколько бы много табличек и графиков вы ни строили, польза от них будет только в том случае, если вы будете делать на основе них полезные выводы и менять продукт и процессы к лучшему.
Автор: kriogen
