Эксперимент «От постановки проблемы до проверки прототипа за 3 дня», ретро и выводы

💙 Начнём с того, что понравилось:
— скорость. Хоть и казалось, что всё на бегу, делать дольше было бы сильно утомительнее;
— полное погружение: не отвлекались на другие задачи;
— удалось и покреативить-порисовать от души, и связь с реальностью сохранить;
— спустились к пользователю с «вижен» облачков;
— получили результат.


⚙️ Что учесть на будущее:
— составить подробное расписание и равномерно распределить нагрузку до старта, чтобы все участники знали заранее, что и когда их ждёт. У нас не получилось, потому что запускали эксперимент спонтанно;
— спринт хорош для проверки одной гипотезы и одного исследования, иначе что-то выпадет из фокуса и будет делаться по остаточному принципу. Так у нас вышло с экстра-продуктами;
— нужны активности в первый день для сближения, если в команде есть незнакомые друг с другом люди. Лексуса надо было приводить в первый день 🙂
— все участники должны верить в идею эксперимента — это важно для успешной работы команды;
— тест с клиентами лучше проводить в отдельный день и закладывать время на опоздания. Мы проводили вечером в последний день эксперимента — были почти без сил;
— заранее подумать о том, кого позвать на тест — в идеале должен быть пул клиентов, состоящий не только из знакомых и из знакомых знакомых, тогда не будет искажений в выборке;
— для прототипа лучше использовать другой инструмент и как можно тщательней прорабатывать основной сценарий.

💡 Выводы
Мы немножко и упоролись, но получили результат за 3 дня. Нас было шестеро — и это оптимальное количество людей, чтобы подойти к проблеме с разных сторон. Пять человек захотели участвовать ещё в таких экспериментах. Сам формат спринта показался хорошим для офлайна, в онлайне так не выйдёт.

Изначальную гипотезу подтвердить не удалось, но мы получили много информации для других гипотез и исследований. И если бы пошли с этой идей сразу в разработку, потеряли бы много времени и денег. Само исследование надо строить по-другому, в два этапа: сначала на текущем варианте, потом, после фидбэка клиентов, делать и показывать новый.

#продактвогне

Команда архитекторов из Тинькофф организовала книжный клуб Code of Architecture — для всех, кто строит программные системы. Сейчас читают книгу Software Architecture: The Hard Parts и позвали наших ребят из «Читаем вместе» поучаствовать в обсуждении.

Четвёртую и пятую главу разберут вместе с Юрой Пастушенко (Юра руководит командой автоматизации системы контроля качества в Dodo):

— обсудят подходы к архитектурной декомпозиции приложения (component-based decomposition и tactical forking);
— детально поговорят про component-based decomposition: расмотрят пошаговый процесс декомпозиции на основе компонентов.

Трансляция будет на ютуб-канале в четверг, 2 июня, в 18:00 (ссылка будет чуть позже), а пока можно посмотреть разбор первых трёх глав книги.

Всё-таки это было легендарно!

Лёша Берёзка, наш iOS-разработчик, рассказал историю того самого «ретро»: как он готовил мир под сценарий самой встречи, как беспокоился о том, чтобы ребятам было всё понятно, а на самом деле всё получилось… Да отлично получилось, на 10 из 10!

Тут вся правда.

Ура, организаторы DotNext выложили в открытый доступ материалы с прошлогодней конференции! Это значит, что и мы теперь можем поделиться с вами записью доклада Антона Оникийчука и Андрея Парамонова про кеширование данных.

Дело в том, что у нас есть частые запросы с телом ответа в несколько мегабайт (например, столько весит меню для мобильного приложения). При росте числа пользователей сервера перестали справляться. Добавлять сервера не хотелось, и в итоге сели за кеширование.

О чём рассказывают Антон и Андрей:

— какие пути кеширования данных прошли (внутренние in-memory и распределённые кеши, кеширование ответов на стороне приложения, кеширование на nginx);

— какие проблемы поймали с каждыми из них;

— как сделали так, что самый частый запрос к API сайта работает совсем без кешей;

— что планируем делать дальше.

Если вы пишете сервисы, которыми пользуется неограниченное количество пользователей и нагрузку спланировать тяжело — вам точно нужно посмотреть этот доклад. Кстати, он попал в топ-10 докладов, которые особенно понравились участникам конференции!

13 и 14 июня наши ребята выступают на TechLeadConf.

Доклад Миши Рубанова посвящён TDD в мобильной разработке. Он расскажет, как мы определяем интеграционные тесты. Покажет на примере, как управление через зависимости позволяет изолировать сценарий.

По теме ТDD на конференции будет три выступления, после которых состоится круглый стол с обсуждением вопросов, когда этот подход можно применять.

Доклад Виталия Помозова — про подходы, которые позволяют нам релизить не глядя. Он расскажет про опыт тестирования сервиса учёта, за который отвечает его команда, как мы реализуем CI/CD и реагируем на проблемные релизы. А также рассмотрит риски и причины, по которым это может подойти не всем.

Будем рады видеть вас на наших докладах и пообщаться в перерывах!

Когда мы распиливали платёжный шлюз, нам понадобился RPC-фрейворк. Сначала мы выбрали Thrift, но потом всё-таки перешли на gRPC.

Андрей Парамонов расскажет, почему это произошло, с какими проблемами мы столкнулись и про прикольные штуки в .NET 5, 6 и 7, которые делают gRPC дефолтным выбором для взаимодействия микросервисов. Разберёт особенности работы в K8s. Покажет, как использовать кусочки этой технологии по отдельности.

Если уже купили билеты на DotNext, добавляйте в избранное, чтобы не пропустить.

16 июня, начало в 16:30, онлайн.

Обычно мы ходим на конференции как слушатели и как участники. А несколько ребят из нашей большой IT-команды входят в программные комитеты (ПК) конференций. Нам стало интересно, чем, собственно, они там занимаются? Поговорили с Евгением Иванченко, лидером Web QA в Dodo Engineering, — он состоит в ПК TechLeadConf.

Чем занимаются в ПК IT-конференций?

— У ПК есть несколько основных задач:

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

2. Поиск докладов и докладчиков. Конечно, можно полагаться на то, что докладчики сами к нам придут с нужными темами, но этого недостаточно. Мы ищем людей, которые уже что-то рассказывали про интересующие нас темы или которые могут рассказать что-то интересное нашей аудитории.

3. Работа с докладчиками. Мы утверждаем темы, помогаем поработать над структурой доклада, обсуждаем выводы и как они были получены. Задаём уточняющие вопросы, чтобы понять, что именно будет в докладе. Помогаем улучшить его с точки зрения подачи, взаимодействия с аудиторией и динамики. Помогаем отбросить лишнее. Часто приходят докладчики с огромным массивом информации, который невозможно уложить в один доклад на 40 минут, тогда нужно на чем-то фокусироваться. Определяем, что интересно и докладчику, и аудитории конференции.

4. Небольшая часть работы состоит в том, чтобы проработать идеи мерча, подарков, стикерпака конференции. Поучаствовать в продвижении, написать статью, сходить на подкаст или дать интервью.

Сколько времени ты тратишь на это?

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

Какие есть плюсы и минусы?

— Минусов не вижу, зато плюсы очевидные:

🔹 нетворкинг: я постоянно знакомлюсь с огромным количеством людей — лидерами индустрии, которые готовы делиться своим опытом и знаниями;
🔹 расширение кругозора — узнаю много нового про технологии, опыт других компаний до того, как об этом узнают все остальные.

Продолжаем поход по офлайн-конференциям! Следующая — Heisenbug в Санкт-Петербурге.

Дмитрий Тучс, Head of QA в Dodo Engineering, считает, что опыт «разработки и поддержки QA-фреймворка» в резюме автоматизатора — скорее недостаток, чем преимущество. Потому что очень часто QA-фреймворки бесполезны для бизнеса, усложняют написание тестов вместо того, чтобы упрощать этот процесс. Зачастую они пишутся QA-инженерами, которые не обладают достаточными навыками, чтобы сделать аккуратный, минималистичный и действительно полезный фреймворк. А в половине случаев то, что называют фреймворком, на самом деле просто «набор полезных методов».

В докладе Дима поделится своим видением, сколько публичных классов должен иметь «идеальный» фреймворк и почему. Рассмотрит практические вопросы по работе с БД (JPA/Hibernate), с REST и gRPС и действительно ли нужен собственный фреймворк, если у вас «чистый» Selenium.

21 июня, 11:30

Если ещё не купили билет, держите промокод на скидку: DmitryTuchs2022JRGpc

В апреле мы перевели весь монолит на .NET6. а теперь полностью перевезли в Kubernetes!

И жить стало гораздо лучше:

✔️ больше не нужно поддерживать две системы (Windows-сервера и Kubernetes);

✔️ стала выше скорость разработки благодаря переходу на новый фреймворк и «генеральную уборку» в коде;

✔️ убрали ограничение, по которому мы могли выкладывать 1 страну на сервере — теперь можем выкладывать все страны сразу и свежий код доезжает до прода за 15 минут;

✔️ ускорили масштабирование и можем эластично добавлять сервера при большой нагрузке;

✔️ разворачиваем окружение для разработки за пару часов, а не дней;

✔️ прогоняем тесты за 20 минут, а не 40;

✔️ вот-вот запустим автоскейлинг.

А ещё… оставим подробности для большой статьи на Хабре, следите за анонсами!

Никогда такого не было, и вот опять! Михаил Рубанов на следующей неделе рассказывает про доступность и тестирование (нет, мы не отбирали у него паспорт, всё абсолютно добровольно).

4 июля, 19:00 live-coding сессия на канале Podlodka Crew

На примере open-source приложения Stepik Миша покажет, почему ваши приложения не работают для незрячих, что с этим делать, какой дописать код и как это протестировать.

Поставить колокольчик, чтобы не пропустить

6 июля, 19:00, вебкаст PRO Тест

О чём пойдёт речь:

- что подразумевается под доступностью цифровой среды, какие у неё виды;
- нужно ли встраивать Accessibility testing в общую стратегию тестирования;
- что обычно ломается в первую очередь.

Зарегистироваться

В прошлом году наша сеть потеряла 1-2% выручки из-за «стопов» пиццерий, связанных с отсутствием каких-либо продуктов. Оно и неудивительно, ведь для приготовления десяти самых популярных пицц из нашего меню требуется более 30 ингредиентов! Если брать в расчёт всё меню, то количество нужных ингредиентов вырастает до нескольких сотен.

Как управляющему пиццерией не сойти с ума от этого многообразия, заказать всего и в нужном количестве, при этом не сильно отвлекаясь от других дел, связанных непосредственно с управлением пиццерий? Для помощи в этой задаче мы и затеяли разработку решения, которое могло бы автоматизировать процесс.

В статье на Хабре рассказываем, как мы учились прогнозировать расход ингредиентов с помощью ML.