В рубрике DOU Labsмы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.
Привет! Меня зовут Дмитрий, я Software Engineer в компании Provectus. Сегодня расскажу о ProPlanner — одном из наших внутренних проектов, который позволяет удобно ставить и отслеживать цели.
Идея
Правильно ставить задачи, чтобы достигать целей в срок — один из важнейших принципов работы. Но иногда за большим мы не видим малого, а значит, обозначив цель, можем забыть о мелких шагах на пути к ней. Идея проекта ProPlanner возникла из потребности пошагово прописывать все задачи и подзадачи, ведущие к цели. Таким образом проще отслеживать прогресс и фиксировать все мелкие, но важные сабтаски.
Из сервисов, в которых реализована эта задумка, можно вспомнить StickK, Goalscape, I am whyи Lifetick. Но в них, к сожалению, нет возможности интеграции с Google Calendar или постановки целей по SMART.
Проект ProPlanner реализовывали в рамках внутренней программы Provectus «Формула-1». Сотрудники компании разделяются на команды и создают проект с нуля. Затем к ним присоединяются внешние стажеры, чтобы помочь с техническим воплощением идеи. Команда проекта: я — Дима Иванов (Front-End), Алина Грищук (Back-End), Дима Чехонин (QA), Ира Геращенко (QA), Саша Лобунец (QA) и Маша Олейник (Product Owner).
ProPlanner мы задумали как продукт для планирования рабочих процессов по методу SMART. Первоначальная идея была сделать SMART goal maker, исключительно для постановки целей. Позже мы решили, что техническая реализация такого проекта слишком проста и усложнили задачу, добавив календарь, чтобы фиксировать как долгоиграющие цели, так и мелкие рабочие таски.
Так появился ProPlanner, с помощью которого можно ставить SMART-цели и рассчитывать время на их исполнение. Все мы знаем: чем «умнее» и понятнее сформулирована задача, тем проще ее выполнить. Сервис так и задуман: устанавливать умные таски и вовремя их завершать.
Чтобы достичь задуманного, в ProPlanner мы добавили следующие функции:
- Создание целей с возможностью редактирования и удаления.
- Формирование подзадач для целей (для детальной проработки и планирования action плана).
- Просмотр целей и задач в календаре.
- Интеграция с Google календарем.
User Story выглядит следующим образом:
1. Пользователь создает цель: называет ее, описывает, обозначает deadline выполнения.
2. Далее расписывает цель по методологии SMART (приложение в процессе подсказывает основные требования к критериям).
3. Если необходимо, то цель можно разбить на более мелкие действия. Для этого есть возможность создания подзадач.
4. Все цели отображаются в календаре в соответствии с обозначенными сроками.
5. Если пользователь включил автоматическую синхронизацию с Google Calendar, то созданные цели автоматически отобразятся в нем.
6. Прогресс выполнения целей можно отследить с помощью progress bar.
Техническая реализация
На проекте ProPlanner работали четыре разработчика: два Back-End и два Front-End. Реализация — сервер на NodeJS для фронтенда, API-сервер на RoR и google auth.
Для взаимодействия фронтенда с API мы выбрали JSON API. Эта спецификация отлично подходит для создания SPA, так как позволяет уменьшить количество запросов на сервер. JSON API разрешает серверу отправлять связанные ресурсы вместе с запрошенными первичными ресурсами. Также при запросе можно определить поля, которые нужно получить, и отправлять не всю сущность, а только то, что необходимо. Отметим, что детально формализованная спецификация удобнее для стажеров, так как всё необходимое есть в документации.
Фронтенд написан на типичном наборе React+Redux. Специально не брали ничего экзотического, чтобы ребята успели разобраться в инструменте. Выбрали React, так как для него есть много туториалов, видеоуроков, проектов в GitHub и зрелых библиотек, а также отличные инструменты разработчика для браузеров.
Мы хотели сделать приложение соответствующим концепции Progressive Web Apps и, думаем, нам это удалось. Так как код был на Gitlab-репозитории, то для упрощения деплоя использовался Gitlab CI. После ревью кода и слияния feature ветки разработчика в develop (стажеры старались работать по Git flow), Gitlab runner автоматом проверял код на ESLint ошибки и пересобирал текущий бандл.
Для разработки API использовали фреймворк Ruby on Rails 5.2. Применяли стандартизированные современные технологии: помимо JSON:API, также использовали JWT authentication в сочетании с Google OAuth.
С ребятами мы практиковали разные подходы к разработке и учились на своем опыте. Начали мы со стандартного rails way c fat model, skinny controller etc. C ростом функциональности (от стандартных поисковиков к двусторонней синхронизации с Google Calendar с применением транзакций и работе в бекграунде) поддерживать аккуратный код было все сложнее.
Поэтому провели анализ состояния проекта, изучая подходы для его структурирования. Так мы начали использовать сервисы, и в результате пришли к внедрению Trailblazer*, что позволило нам полностью переосмыслить архитектуру строения проекта. Trailblazer — это библиотека, которая добавляет новый слой в приложение и позволяет разбить процесс работы точки доступа на различные этапы (policy/validation/processing/saving and more).
Тестирование
У нашей команды было время на то, чтобы усовершенствовать свои знания в теории тестирования, SQL, Git, REST API, SQL injections, Unix command line и т. д. Потом мы решили сделать high-level тесты на существующие требования. Очевидно, что они менялись, но тесты редактировались, и в итоге их получилось 233. Инструментом для тест-менеджмента выбрали QATouch, и нам понравилось (хоть там и ограниченное количество бесплатных тестов).
Back-end команда справлялась быстрее, поэтому API тестировался первым. Для тестов использовали Postman. Отдельная благодарность разработчикам за прекрасную документацию! Основной целью менторов тестировщиков было показать, как важно участвовать в процессе разработки: не просто проверять то, что сделано, но и предлагать то, что планируется, предотвращая баги даже на уровне спецификации.
Построение процессов
В ходе реализации ProPlanner возникали и проблемы. Стажеры отметили, что построение процессов было самой слабой стороной проекта. Все дело в том, что наши планы не совпадали с фактическими возможностями. Мы пользовались методом Scrum. Согласно ему, менторы и Product Owner заполняют бэклог фичами, раз в неделю проходит спринт, на котором распределяются тикеты на основе диаграммы Гантта и сториборда. Также мы планировали проводить daily митинги с командой.
По факту, пришли к методу Kanban. На запланированные встречи не все могли приходить, так как они совпадали с рабочим временем менторов. Спринты долго не закрывались, и тикеты переносились из одного в другой спринт. В итоге мы решили использовать Kanban, а выполнение и скорость работы контролировали руководители направлений.
Коммуникацию по проекту мы вели в Slack. За время стажировки у нас накопилось 11 тысяч сообщений! Митинги проводили только онлайн с помощью Hangouts Meet или Zoom. Использовали багтрекинговую систему Jira, систему тест-менеджмента QA Touch и вики — Confluence.
Результаты и планы
Условия, созданные для ProPlanner, были максимально близки к условиям реального проекта. Мы работали над продуктом 4 месяца и за это время, кроме программирования, прокачали навыки работы в команде, оценивание задач и умение аргументировать свои решения. Нам удалось создать продукт, который основан на методологии SMART. Многие компании сейчас активно пользуются этом подходом в рамках Performance Review своих сотрудников, но аналогов нашего продукта мы так и не нашли.
Вскоре планируем продолжить работу:
- Синхронизировать продукт с внутренней HRM системой.
- Разработать элементы геймификации: получение очков и достижений за выполненные цели, рейтинг сотрудников.
- Создать анимированного персонажа, который дает советы для постановки целей по SMART.
Добавив необходимый функционал, будем тестировать ProPlanner как внутренний сервис для постановки целей при Performance Review сотрудников Provectus.