выпуска (версия 1.0). Разработка идёт по скраму. В конце каждого спринта идёт тестирование, но на многие баги, в том числе критические, ПМ отвечает, что мы сейчас пилим основной функционал и у нас нет времени это сейчас фиксить. Исправим через спринт итд. За счёт такого подхода у нас накопилось достаточно много костылей и тот функционал, который мы уже успели сделать, работает мягко говоря не очень. Вопрос. Стоит ли настаивать на том, что бы продукт был относительно стабилен или закрыть глаза, поскольку мы только пилим основной функционал?
Так мне кажется это вопрос процесса тестирования. Если ты написал чёткий тест-план, в котором указал виды тестирования, и правильно расписал приоритеты и важность в кейсах/баг-репортах, то с первого же взгляда должны быть видны баги, которые нельзя не фиксить -- блокеры и критикал. К тому же, для последующего тестирования есть энтри кондишнс (условия начала тестирования). Если блокеры и критикал не пофикшены, то это препятствует тестированию
Нет. Стоит доносить информацию о рисках, проблемах и костылях. Их критичности и количестве. Дальше ребята, отвечающие за продукт должны решить, нужно ли им это править сейчас или нет. Если решат что нет, значит с точки зрения бизнеса запуститься как есть - важнее (а причин для этого может быть много).
Это может быть, но если ПМ говорит "норм, катим дальше", то это не имеет никакого значения.
Все баги можно не фиксить.
Так я не про все, я про блокеры и критикал. Если какой-то кор функционал работает не так, как должен, то нужно всеми силами доносить это до бизнеса, на мой взгляд. Поэтому я говорю, может человек не правильно приоритеты ставит. ПМ видит, что это не критично для бизнеса, и оставляет на потом)
Я пытался намекнуть, что история с багами это всегда про "cost vs value". Если стоимость того, что бы отложить релиз выше, чем стоимость этого самого бага в продакшене - то вообще без разницы, что оно там блокирует или не блокирует. Значит никому не нужно откладывать релиз.
Обсуждают сегодня