Инициаторами введения метрик во всех продуктах и публичное их отображение были руководители it-направления в компании. Я был полностью за, так как мы некоторые показатели в монолите уже замеряли и следующим шагом логично было бы собирать их не только в монолите, но и в других сервисах тоже.
А начали собирать метрики в монолите тестировщики и разработчики, без чьих-либо указаний, больше года назад.
Да, вы правы, это важное замечание. Необходимо понимать кто и зачем создает метрики.
Мы создавали метрики не для того, чтобы кого-то наказывать или кому-то показывать что у нас все хорошо. Мы действительно хотим создавать качественный продукт и поэтому решили это качество измерять.
вот несмотря на то, что в тексте подчёркивается многократно, что это «право» разработчика — всё же не очень верится, что это именно инициатива самих разработчиков, а не добровольно-принудительная указка сверху.
Я не знаю как вас убедить в том, что это не обязательно, у нас есть разработчики, которые не работали в пиццерии никогда и это нормально.
окей, я может некорректно выразился, скажу по-другому: получается, ваш разработчик как бы сразу же и тестировщик?
Я бы не сказал так. Пользоваться продуктом и тестировать его — это разные вещи. Разработчик просто выступает в роли пользователя. Он разрабатывает продукт для кого-то, в частности для сотрудников пиццерии и пользуются они ей в определенном окружении, условиях. Вот на это окружение и условия, в том числе, ходят смотреть разработчики.
это право сотрудника, ровно и пойти в пиццерию, тоже его право.
Обычно вообще отдельные люди транслируют потребности бизнесов в айти команду. То, что у вас этим занимаются разработчики, означает, что вы сэкономили на подобных людях.
сошлюсь на текст из абзаца «Кто должен ходить в гембу»
Для продактов это один из основных видов деятельностей, в пиццерии они черпают идеи, получают инсайты, видят картинку в целостности. Продакт-менеджеры используют гембу для тестирования гипотез, глубинных интервью, customer-development, составления customer journey map и так далее.
Разработчики не транслируют потребности бизнеса, они пользуются продуктом в реальных, полевых условиях.
Всегда полезно смотреть на процесс с разных сторон. Сфера интересов и знаний каждого человека сильно различается и то, что разработчику будет понятно как оптимизировать тот или иной процесс с помощью технологий, далеко не факт, что будет понятно менеджеру или любому другому человеку, далёкому от IT.
Что касается продуктов и аллергии на эти продукты, то это не значит, что куски рыбы прям с планшета свисают и попадают в другую пиццу. Плашеты мы обрабатываем регулярно как пищевые поверхности. Никто не оставит планшет грязным, для этого есть чек листы и обходы пиццерии.
С процессами в то время было не очень, вы правы. Но мы исправляем их потихоньку.
Да, бизнес позволяет это делать и даже больше скажу введение матрицы приоритетов это инициатива бизнеса.
Финальная валидация интеграции кода всех команд у нас выполняется автотестами.
Прежде чем разойтись по командам мы провели эксперимент. Двух тестировщиков оставили заниматься финальной валидацией продукта, после прохождения автотестов. Команды знали об этом экспермиенте. Баги найденные тестировщиками на этом этапе приравнивались к багам которые мы выпустили в прод. Команды стали внимательнее относится к коду, который сливали в дев. Мы смотрели сколько багов найдут тестировщики руками после прохождения автотестов и сравнивали с количеством багов найденных во время регресса до начала эксперимента. Количество багов не изменилось и критичность пропущенных багов осталась на том же уровне. Увидев что нет разницы мы решили вообще не проводить ручную финальну валидацию. Тут вопрос в потенциальных убытках, которые компания может понести от пропущенных багов и затратах на поиск этих багов. Мы приняли риски и сократили время выпуска продукта, в других ситуациях такой подход не допустим и это нормально.
Про ротацию. “Нужно согласие отпускающей команды” я имел ввиду что нельзя просто так взять и уйти ничего не сказав команде, не обсудив с ней это. И мы ни в коем случае не мешаем переходу.
По сути изменилось время начала взаимодействия. Раньше взаимодействие тестирощика и разработчика начиналось когда код разработчика попадал в релизную ветку и сводилось к тому, что тестировщик приносил баг, найденный на стейдже и потом перепроверял его, теперь тестировщик участвует в командных активностях, в командном планировании или груминге, выполняет приемочное тестирование до того, как код сольется в дев ветку. Может показать сценарии по которым он будет тестировать фичу, чтобы разработчик сразу учел различные моменты и стало меньше возвратов задачи на доработку.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.
Баги, которые найдены и будут поправлены через неделю складываем в Кайтен. У нас есть общая доска для всех команд, там и держим их. А команды когда затягивают эту багу уже хранят как им удобно, у моей команды физическая доска.
А начали собирать метрики в монолите тестировщики и разработчики, без чьих-либо указаний, больше года назад.
Мы создавали метрики не для того, чтобы кого-то наказывать или кому-то показывать что у нас все хорошо. Мы действительно хотим создавать качественный продукт и поэтому решили это качество измерять.
Я бы не сказал так. Пользоваться продуктом и тестировать его — это разные вещи. Разработчик просто выступает в роли пользователя. Он разрабатывает продукт для кого-то, в частности для сотрудников пиццерии и пользуются они ей в определенном окружении, условиях. Вот на это окружение и условия, в том числе, ходят смотреть разработчики.
сошлюсь на текст из абзаца «Кто должен ходить в гембу»
Разработчики не транслируют потребности бизнеса, они пользуются продуктом в реальных, полевых условиях.
Всегда полезно смотреть на процесс с разных сторон. Сфера интересов и знаний каждого человека сильно различается и то, что разработчику будет понятно как оптимизировать тот или иной процесс с помощью технологий, далеко не факт, что будет понятно менеджеру или любому другому человеку, далёкому от IT.
Что касается продуктов и аллергии на эти продукты, то это не значит, что куски рыбы прям с планшета свисают и попадают в другую пиццу. Плашеты мы обрабатываем регулярно как пищевые поверхности. Никто не оставит планшет грязным, для этого есть чек листы и обходы пиццерии.
Да, бизнес позволяет это делать и даже больше скажу введение матрицы приоритетов это инициатива бизнеса.
Прежде чем разойтись по командам мы провели эксперимент. Двух тестировщиков оставили заниматься финальной валидацией продукта, после прохождения автотестов. Команды знали об этом экспермиенте. Баги найденные тестировщиками на этом этапе приравнивались к багам которые мы выпустили в прод. Команды стали внимательнее относится к коду, который сливали в дев. Мы смотрели сколько багов найдут тестировщики руками после прохождения автотестов и сравнивали с количеством багов найденных во время регресса до начала эксперимента. Количество багов не изменилось и критичность пропущенных багов осталась на том же уровне. Увидев что нет разницы мы решили вообще не проводить ручную финальну валидацию. Тут вопрос в потенциальных убытках, которые компания может понести от пропущенных багов и затратах на поиск этих багов. Мы приняли риски и сократили время выпуска продукта, в других ситуациях такой подход не допустим и это нормально.
Про ротацию. “Нужно согласие отпускающей команды” я имел ввиду что нельзя просто так взять и уйти ничего не сказав команде, не обсудив с ней это. И мы ни в коем случае не мешаем переходу.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.