DOU Labs: як в Provectus створили ProPlanner – SMART-планувальник робочих завдань

У рубриці DOU Labs ми запрошуємо IT-компанії ділитися досвідом власних цікавих розробок і внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на [email protected] .

Привіт! Мене звуть Дмитро, я Software Engineer в компанії Provectus. Сьогодні розповім про ProPlanner — одному з наших внутрішніх проектів, який дозволяє зручно ставити і відстежувати цілі.

Ідея

Правильно ставити завдання, щоб досягати цілей в термін — один з найважливіших принципів роботи. Але іноді за великим ми не бачимо малого, а отже, визначивши мету, можемо забути про дрібні кроки на шляху до неї. Ідея проекту ProPlanner виникла з потреби покроково прописувати всі завдання і підзадачі, які ведуть до мети. Таким чином простіше відслідковувати прогрес і фіксувати всі дрібні, але важливі сабтаски.

З сервісів, в яких реалізована ця задумка, можна згадати StickK , Goalscape , why I am і Lifetick . Але у них, на жаль, немає можливості інтеграції з Google Calendar або постановки цілей по SMART.

Проект ProPlanner реалізовували в рамках внутрішньої програми Provectus «Формула-1». Співробітники компанії поділяються на команди і створюють проект з нуля. Потім до них приєднуються зовнішні стажисти, щоб допомогти з технічним втіленням ідеї. Команда проекту: я — Діма Іванов (Front-End), Аліна Грищук (Back-End), Діма Чехонин (QA), Іра Геращенко (QA), Саша Лобунець (QA) і Маша Олійник (Product Owner).

ProPlanner ми задумали як продукт для планування робочих процесів за методом SMART. Первісна ідея була зробити SMART goal maker, виключно для постановки цілей. Пізніше ми вирішили, що технічна реалізація такого проекту дуже проста і ускладнили завдання, додавши календар, щоб фіксувати як довготривалі цілі, так і дрібні робочі таски.

Так з'явився ProPlanner, з допомогою якого можна ставити SMART-цілі і розраховувати час на їх виконання. Всі ми знаємо: чим «розумніші» і зрозуміліше сформульована задача, тим простіше її виконати. Сервіс так і задумано: встановлювати розумні таски і вчасно їх завершувати.

Щоб досягти задуманого, в ProPlanner ми додали наступні функції:

User Story виглядає наступним чином:

1. Користувач створює мета: називає, описує, позначає deadline виконання.

2. Далі розписує мета за методологією SMART (додаток в процесі підказує основні вимоги до критеріїв).
3. Якщо необхідно, то мета можна розбити на більш дрібні дії. Для цього є можливість створення підзадач.
4. Всі цілі відображаються в календарі згідно з вищезазначеними термінами.

5. Якщо користувач увімкнув автоматичну синхронізацію з Google Calendar, то створені цілі автоматично відображаються в ньому.
6. Прогрес виконання цілей можна відстежити за допомогою progress bar.

Технічна реалізація

На проекті ProPlanner працювали чотири розробника: два Back-End і два Front-End. Реалізація — сервер на NodeJS для фронтенда, API-сервер на RoR і google аутентифікації.

Для взаємодії фронтенда з 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 своїх співробітників, але аналогів нашого продукту ми так і не знайшли.

Незабаром плануємо продовжити роботу:

Додавши необхідний функціонал, будемо тестувати ProPlanner як внутрішній сервіс для постановки цілей при Performance Review співробітників Provectus.

Опубліковано: 09/04/19 @ 10:00
Розділ Різне

Рекомендуємо:

Три історії про IT-шників, що займаються громадською діяльністю
Ruby/Rails дайджест #28: важливі оновлення для кількох версій Ruby on Rails, реліз Ruby 2.5.5 і 2.6.2
Прогнозування на стороні клієнта за допомогою TensorFlow.js
DOU Books: 5 книжок про дизайн-рішення від Андрея Русакова, Principle Experience Designer у SoftServe
Чи повинна картка товарів бути унікальною?