Баттл: кто проектирует интеграцию лучше
Разработчик vs аналитик

В разработке постоянно встаёт вопрос интеграции со сторонними сервисами. Разработчики априори лучше разбираются в средствах разработки — зачем привлекать любителя аналитика?

Подготовили карточки с разбором 👉

💡 Есть предустановленное приложение. Нужно сделать так, чтобы приложение считывало штрих-код лампочки и выдавало пользователю детальную информацию о ней.

👆👆👆 Такое задание предстояло решить участникам «Хакатона ВГУ», который мы организовали в начале марта.

Обычно хакатон — это соревнование для разработчиков. Мы поменяли формат: в нашем хакатоне участвовали полноценные команды.

В каждой команде были:
🔹 проджект-менеджер,
🔹 аналитик,
🔹 тестировщик,
🔹 фронтенд-разработчики: iOS, Android, Flutter,
🔹 бэкенд-разработчики.

На хакатоне мы воссоздали процесс работы, который бывает на реальных проектах:

🔥 У каждой команды — свой заказчик, с которым необходимо общаться, согласовывать логику и презентовать работу.
🔥 Стресс-тесты: «на ходу» появлялись новые требования, сроки сокращались, мы просили реализовать нереализуемое и двигали приоритеты задач.
🔥 Ловушки: шаблон ТЗ с частично описанной логикой, специально допущенными ошибками и логическими «ямами», специально допущенные баги в реализованных фичах.

Участникам удалось понять, как выглядит работа на реальном проекте и какую зону ответственности занимает каждая из ролей, поработать в команде, реализовать проект и презентовать его остальным участникам и жюри 😎

💬 «Я в восторге: до Surf никто не устраивал подобное. Такой опыт получаешь не каждый день, работая над реальным проектом в прямом эфире!» — Диана, BA

💬 «Это самое яркое событие за 3 года обучения! У вас получилось создать прям рабочую обстановку, организация просто на высшем уровне: начиная от концепции мероприятия, деления на роли и команды, заканчивая едой», — Иван, бэкенд-разработчик

❓ Хотели бы поучаствовать в таком хакатоне?

«Как амбассадор „Мемологического сообщества“, я хочу рассылать крутые мемы сразу всем участникам, а не каждому по отдельности».

Это ☝️ — пример User Story.

User Story помогает человеческим языком описать функциональность программы: будто о фичах рассказывает приятель в дружеской беседе.

Фокус в таком описании всегда на пользовательском опыте. Ведь фичи создаются не чтобы занять разработчиков — а для людей, которые будут пользоваться продуктом.

Выглядит несложно, правда? Но на самом деле есть ряд нюансов, которые нужно учитывать, чтобы User Story действительно пригодилась при разработке продукта, а не стала карго-культом.

Итак, User Story написана. Как оценить её качество?

Собрали в карточках основные признаки хорошей User story. Тыц!