Проект Smart Price — это идея, объединившая нашу команду в желании создать свое собственное приложение для экономии на продуктах. Когда работа только начиналась мы посчитали проект подходящим для реализации именно в бизнес-инкубаторе: это самостоятельная разработка и управление, а также продвижение продукта.

Эта статья — дополнение другого материала, в котором мы рассказали об идеологии Smart Price, идее, команде и будущем проекта. На этот раз мы коснемся технических аспектов работы над приложением.

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

Сначала для разработки MVP-версии (Minimum Viable Product, англ. минимально жизнеспособный продукт, прототип) мы решили использовать телеграм-бот, ведь этот интерфейс был знаком пользователю и удобен. На этом этапе попросту не нужно было полноценное приложение, мы хотели проверить технологию распознавания и классификации товаров из QR-кода чека.

После успешного запуска MVP, мы решили расширить функционал и разработать отдельное мобильное приложение. Оно бы синхронизировало отсканированные чеки с сервером, где создавались бы отчеты по минимальной цене продукта, а также в приложении появилась функция формирования продуктовой корзины пользователя.

Перед созданием приложения мы описали UI/UX дизайн, в котором объяснили логику взаимодействия пользователя с интерфейсом, переходы по страницам, добавление чеков, создание корзин и прочее. Мы использовали Figma для общего дизайна и Mindject MindManager для описания логики переходов между страницами.

Само приложение команда решила делать на технологии Xamarin Forms, так как в основном мы используем стек технологий .Net. Кроме того Xamarin Forms поддерживает паттерн проектирования MVVM, так что мы сразу создавали кроссплатформенное приложение под Android и iOS. Собственный API мы реализовали на ASP.Net Core: преимущество этой платформы заключается для нас во встроенной поддержке паттерна MVC, что в свою очередь позволило быстро реализовать контроллеры для авторизации пользователя и получения чека.

Первоначальная версия мобильного приложения состояла из следующего функционала: системы авторизации/регистрации пользователя, системы синхронизации чеков с сервером, интерфейса отображения отчетов, таких, как минимальная стоимость товара/корзины по магазинам. Отчеты оказались одним из главных и самых сложных функционалов проекта.

Алгоритм отчета заключается в анализе чека или списка продуктов пользователя и поиске данных товаров в различных магазинах с учетом стоимости корзины и полноты списка. Тут мы и столкнулись с проблемой классификации наименований продуктов. Ряд одинаковых товаров в разных магазинах мог и записываться по разному: в одном магазине «молоко веселый молочник», а в другом «мол. весел. молоч.». Чтобы приложение считывало эти товары правильно, вне зависимости от написания, мы внедрили нечеткий поиск. Данный алгоритм выдавал хорошие результаты, но этого было недостаточно.

В многих магазинах сокращения доходили до неприлично коротких, так что даже покупателю было порой трудно сказать, что он купил: однажды попался ребус «ПЗМ». Это оказался "пакет зеленый майка".

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

Разработка по Scrum

При разработке проекта мы использовали методологию Scrum. На первоначальном этапе мы составили бэклог, в котором описали основные истории проекта. Обычно работа по этой методологии разбивается на спринты, периоды в 2-3 недели, и в начале каждого спринта проводится планирование: выбираются истории из общего бэклога, переносятся в отдельный спринт-бэклог, где исполнители выбирают задачи на спринт и указывают время разработки, исходя из сложности процесса. По окончанию спринта, то есть через 2 недели, проводится демонстрация разработки проекта за текущий спринт и ретроспектива, на которой обсуждаются ошибки и возможные изменения.

В ходе работы мы улучшали навыки управления проектом. Начав с физической доски, мы доросли до электронной доски Jira.

При работе с физической доской по методологии SCRUM мы расчерчивали доску на следующие колонки: входящие задачи, планирование, задачи в разработке, тестирование, готовые задачи. Кроме того мы рисовали диаграмму сгорания.

У ведения физической доски есть свои плюсы и минусы. Несомненный плюс данного подхода в том, что каждый из участников команды может лучше понять методологию Scrum. В электронных досках, например, в Jira, много лишних опций, которые усложняют процесс настройки и запутывают новых пользователей. К тому же все действия на электронных досках учитываются программой и моментально прорисовываются на диаграммах. Удаление или добавление задач в ходе работы может сильно подпортить график. На физической доске можно исправить график самостоятельно, исходя из новых, появившихся в ходе спринта, задач. Минусом использования физической доски являются большие временные затраты на составление доски и написание задач, а также отсутствие возможности работать с доской удаленно.

Расписание нашего обычного рабочего дня обычно выглядит так:

• 11:00 – 11:15 — проведение ежедневного митинга (обсуждаем, какие задачи были выполнены вчера, какие задачи выполняются сейчас)
• 11:15 – 16:50 — активный этап разработки поставленных задач (каждый берет задачи с доски и работает над ними, не забывая периодически записывать время, потраченное на решение; учет времени важен, так как позволяет точнее оценивать задачи в будущем)
• 16:50 – 17:00 — подведение итогов дня, построение диаграммы сгорания по выполненным задачам.

Среди обычных рабочих дней методология Scrum предполагает совместное планирование спринтов. Раз в пару недель мы проводили обсуждение с Product Owner и обсуждали цели предстоящего спринта. Учитывая следующий этап разработки, мы переносили задачи из общего бэклога в спринт-бэклог и решали, сколько времени понадобится для реализации каждой из них, то есть проводили оценку времени. Этот этап занимает обычно около трех часов. Иногда Owner и команда дают разную оценку сложности задачам, и тогда каждый ставит свою оценку времени и объясняет, почему понадобится именно столько времени на выполнение пункта. После планирования мы распределяли задачи текущего спринта по доске, указывая исполнителя и оценку времени. Этот этап занимает разное время, в зависимости от используемой доски, в нашем случае мы тратили на это около полутора часов.

Помимо планирования спринтов в нашем рабочем процессе были демо-дни. Демо проводились в последний день спринта, когда мы выкатывали очередной релиз программы и обсуждали, что сделано за две недели. Такая отчетность помогала нам поддерживать связь в команде и держаться намеченного курса. Непосредственное общение с Owner'ом повышает уровень ответственности у тимлида и помогает оперативно исправлять и дорабатывать меняющийся прямо на наших глазах продукт.