62
пользователь получает уведомление об успешном сохранении задачи и
автоматически возвращается на экран истории.
3.3.6. Разработка спринтов и доски Kanban
Последний необходимый элемент для корректной работы с
инструментами Scrum в нашей системе – это реализация Kanban-доски, с
помощью которой разработчики могут всегда видеть, на каком этапе
находится их каждая задача, и что им ещё предстоит сделать. По структуре
организации сущностей системы канбан-доска является дочерним
объектом класса Sprint, о котором речь пойдёт ниже.
Для добавления функционала запуска спринта, в основное меню
приложения добавлена новая кнопка-ссылка «Спринты», при нажатии на
которую пользователь переходит на роут спринтов. Опять же, для удобства
пользователя, визуально экран не отличается от проектов и историй:
представлен подгруженный список спринтов с кнопкой добавления нового.
Форма создания или редактирования спринта содержит следующие
поля:
1. Title, input, тип string – название спринта;
2. Team, multiple select, тип User – участники спринта.
Автоматически в селект заносятся все участники проекта.
Создатель спринта при необходимости может исключить кого-то
из этого списка.
3. Stories, multiple select, тип Story – относящиеся к спринту истории.
4. Duration, input, тип number (min: 1, max: 4) – количество недель
спринта.
5. Launched (только при создании спринта), тип boolean –
определяет, запущен ли спринт.
63
Истории можно создавать и редактировать по тому же принципу, как
это происходит с другими сущностями, описанными выше.
Как видно в вышеобозначенном списке, у класса Sprint имеется
важное для работы с ним свойство ‘lauched’, которое обозначает, запущен
ли спринт. Это свойство можно изменить в двух местах интерфейса: при
создании спринта, отметив соответствующий checkbox, или нажать кнопку
«Запуск» при редактировании спринта.
После того, как спринт будет запущен (или сразу создан со
свойством launched равным true), пользователь автоматически переходит
на доску Kanban, так как при создании спринта на сервере ему
присваивается id, а также создается экземпляр класса Kanban, который
состоит из массива объектов-статусов, имеющих порядковый номер и
название. По умолчанию каждый экземпляр создаётся со следующими
статусами:
1. {Name: “To Do”, Number: 1} – к выполнению;
2. {Name: “In Progress”, Number: 2} – в процессе разработки;
3. {Name: “Code Review”, Number: 3} – проверка кода;
4. {Name: “In Testing”, Number: 4} – на стадии тестирования;
5. {Name: “Done”, Number: 5} – выполнено;
Колбэк created компонента KanbanComponent запускает метод
distributeTasks, который посылает GET-запрос на сервер с id всех историй,
входящих в спринт, для получения всех задач, относящихся к этим
историям. После получения списка метод сортирует задачи и распределяет
их в соответствующие столбцы доски Канбан, что визуализируется в
представлении карточками задач.
Чтобы перевести карточку из одного статуса в другой, пользователь
выполняет это методом drag’n’drop, то есть при нажатии клавиши мыши
64
получает возможность переносить контейнер с задачей по экрану, а при
отжатии – карточка попадает в столбец, над которым она находилась в
этот момент. Этот эффект достигается с помощью стиля абсолютного
позиционирования, а процесс перетаскивания по экрану реализуется с
помощью встроенного vue-атрибута v-bind:style=“{…}”, который будет
отслеживать состояние свойства компонента position, имеющим свойства
типа number: left и top, то есть расстояние от левого и верхнего краёв
экрана соответственно. Свойства этого объекта будут меняться каждый
раз, когда пользователь будет совершать движение мышкой, и это
отслеживание запускается при нажатии на кнопку мыши над карточкой
задачи, и отключается после отжатия. После попадания карточки на
столбец нового статуса, клиент отправляет на сервер PATCH-запрос, в
котором указывает, какой статус необходимо присвоить этой задаче.
Название карточки задачи также является кнопкой-ссылкой, при
нажатии пользователем на которую открывается модальное окно с
подробностями этой задачи и возможностью её редактирования. Этот
функционал совершенно идентичен представленному в списке задач
истории: принцип работы Vue.js позволяет импортировать необходимые
для работы компоненты в любые места приложения и неограниченное
количество раз, поэтому не происходит даже минимального дублирования
кода и полностью соблюдается принцип frontend-разработки DRY: Don’t
Repeat Yourself (Не повторяй сам себя).
Дополнительный функционалом при запущенном спринте является
возможность изменить статус истории, относящейся к этому спринту. В
окне редактирования истории пользователю отображается селект статуса,
который может принимать три значения:
1. Активный – разрабатываемый в данный момент в рамках спринта;
2. Завершённый – если все задачи, относящиеся к истории, закрыты;
65
3. Замороженный – если подошло время закрывать спринт, но эти
истории ещё не закрыты. При создании следующего спринта эти
истории по умолчанию попадают в селект выбора историй для
реализации.
3.3.7. Подключение личного счёта
Вторая составляющая разрабатываемого приложения –
геймификация. Мы выбрали для дополнения Scrum-технологии два
геймифицирующих подхода: виртуальная валюта и бейджи. И если первый
подход имеет хоть какую-то связь с реальностью в виде бонусов, которые
можно приобретать за счёт полученной валюты, то второй – бейджи –
являются чисто игровым элементом, который никак не влияет на
реальность. Однако, он исключительно важен для приобретения
участниками команды статуса и возможности побороться за лидерство в
неофициальной иерархии.
Для определения количества накопленных пользователем финансов
классу User добавляется свойство amount, которое определяет, сколько на
данный момент у него имеется средств, которыми он может
распоряжаться.
Для работы с финансами в основное меню приложения добавляется
кнопка-ссылка на роут управления финансами. В колбэке метода created
компонента financesComponent мы запрашиваем на сервере подробности
финансов пользователя. В ответе нам приходит объект со следующими
свойствами:
1. History, массив, тип Transaction – отображение истории
совершенных пользователем операций;
2. Received, тип object – набор всех видов полученных
пользователем финансов:
66
a. fromUsers, тип number – сумма всех когда-либо полученных
пользователем перечислений от других пользователей;
b. fromManagers, тип number – сумма всех когда-либо
полученных пользователем перечислений от менеджеров;
c. prices, тип number – сумма всех выигрышей пользователем
за ставки на лидеров разработки;
d. encourageTasks, тип number – сумма всех полученных
пользователем финансов за своевременное выполнение
задач;
e. encourageTasks, тип number – сумма всех полученных
пользователем финансов за своевременное выполнение
задач;
f. encourageStories, тип number – сумма всех полученных
пользователем финансов за своевременное выполнение всех
задач истории;
g. encourageSprints, тип number – сумма всех полученных
пользователем финансов за своевременное закрытие всех
историй спринта;
h. full, тип number – сумма всех полученных пользователем
финансов из любых источников;
3. sent, тип object – набор всех видов потраченных пользователем
финансов:
a. toUsers, тип number – сумма всех когда-либо отправленных
пользователем перечислений другим пользователям;
b. bets, тип number – сумма всех средств, потраченных на
ставки на лидеров разработки;
67
c. purchases, тип number – сумма всех средств, потраченных
пользователем на покупки;
d. full, тип number – сумма всех потраченных пользователем
финансов на любые цели.
Эта информация отображается в представлении тремя блоками:
«История», «Потрачено», «Получено», нажатие на каждый из которых
разворачивает соответствующие подробности.
Помимо этого, в представлении имеется функционал траты
финансов. Для экономии времени пользователя ему не требуется
открывать отдельные экраны для этого и даже открывать какие-то блоки.
Один за другим, сверху вниз, реализованы следующие формы:
1. Покупка бонусов. Эта форма ограничена одним селектом, в
который асинхронно GET-запросом с сервера подгружаются
возможные варианты покупок. Кроме того, в селекте доступна
возможность ввода текста, которая отправляет дополнительный
GET-запрос на сервер с параметром title=’введенный текст’, что
позволяет сократить выборку бонусов. При нажатии кнопки
«Купить» создается новое обещание и отправляется запрос на
сервер, который списывает со счёта пользователя стоимость
покупки и отправляет уведомление менеджеру проекта о покупке,
которую ему нужно организовать.
2. Перечисление другому пользователю. Эта форма ограничена
тестовым полем типа number для ввода суммы, которую нужно
перечислить, и селектом, в котором нужно выбрать пользователя.
Особенностью селекта является асинхронная загрузка данных,
при которых первыми загружаются все участники проекта, в
котором в данный момент работает пользователь. При прокрутке
и достижении “дна” списка автоматически отправляются
68
дополнительные GET-запросы на получение пользователей из
других проектов. Помимо этого, так же, как и в покупках,
пользователь может ввести имя пользователя, чтобы уменьшить
выборку пользователей.
3. Ставка. Форма ограничена неактивным текстовым полем, в
котором отображается порядковый номер и название текущего
спринта, полем типа number для ввода суммы, которую
пользователь хочет поставить на лидера, и селектом
пользователей, который ограничен только участниками текущего
спринта. Если спринт не запущен, то эта форма неактивна. При
нажатии кнопки «Сделать ставку» на сервер уходит POST-запрос
с данными формы: id спринта, id пользователя и сумма ставки.
После успешного ответа от каждой совершенной траты с помощью
мутаций обновляется состояние имеющейся у пользователя суммы
виртуальной валюты, меняются суммы потраченных средств и добавляется
новый объект в массив транзакций.
3.3.8. Начисление валюты за разные виды деятельности
Один из наиболее сложных участков в плане разработки приложения
является точное и корректное начисление виртуальной валюты
пользователям системы.
Перечисление от другого пользователя или менеджера
Это наиболее простой случай, в котором участие клиента не
требуется: при перечислении пользователю валюты от другого
пользователя или менеджера сервер на своей стороне формирует в базе
данных дополнительную запись о произведённой транзакции, производит
пересчёт статистики начислений и увеличивает баланс пользователя на ту
69
сумму, которая была ему перечислена. Подробности этих расчетов будут
описаны в следующей части работы.
Выигрыши по ставке и завершение спринтов
В окне редактирования активного спринта добавлена кнопка
«Завершить спринт», которая идентична кнопке «Запуск» и, если
последняя доступна только спринтам со свойством launched равным false,
то первая – соответственно, при свойстве, равном true. Показ кнопок
пользователю в представлении также осуществляется с помощью
встроенного vue-атрибута v-if=“…”. Проверке также подвергается наличие
в спринте активных историй, и если по крайней мере одна такая найдена,
то кнопка «Завершить» остаётся неактивной.
При нажатии этой кнопки на сервер отправляется PATCH-запрос с
параметром finished=true, который означает, что следует обновить объект
спринта в БД и определить его как завершённый.
После этого происходит расчёт начислений валюты, процесс
которого будет подробно описан в подразделе, касающемся создании
серверной части приложения. В итоге победители ставок получают
награду и смогут заметить это, как только зайдут на экран финансов: в
обновившемся балансе и истории транзакций.
70
Рис. 3.8 Закрытие спринта, расчёт валюты и присвоение бейджей
Как видно на схеме, помимо выигрышей по ставке, каждый участник
команды разработки получает определённую сумму валюты за закрытие
спринта в том случае, если спринт был завершён вовремя и без
замороженных историй.
Начисления за выполненные задачи, истории
Как и в случае закрытия спринта, основную работу по этим
операциям берёт на себя серверная часть. На клиентской стороне может
произойти два события.
Как мы помним, когда задача оказывается в колонке статуса
«Выполнено», на сервер отправляется PATCH-запрос, указывающий на
смену статуса. В том случае, если статус – done, то ответственный за эту
задачу получает начисление суммы валюты, равной сложности
выполненной задачи, то есть количеству story-points. Успешный ответ
этого запроса разрешает созданное обещание, за которым следует проверка
всех задач, относящихся к истории только что выполненной задачи, и если
среди нет ни одной, не имеющей статуса done, то происходит вызов
модального окна, в котором пользователь должен подтвердить, что
71
историю также можно определять как выполненную. После этого
происходит ещё один PATCH-запрос, целью которого является обновление
статуса истории в БД, после которого все участники истории получают
начисление валюты в размере четверти сложности всех задач истории, по
которым они были ответственными.
3.3.9. Бейджи лидерства и достижений
Последним участком работы на клиентской стороне является
добавление и отображение бейджей, которые пользователь получает в
процессе работы с приложением.
Отображение
Отображаются бейджи в первую очередь в личном кабинете
(EditUserComponent) пользователя, где добавлены два раздела:
«Лидерство» и «Достижения».
Информация по ним приходит в ответе на GET-запрос с полем
расширения expand=badges, который сообщает серверу, что помимо
основной информации о пользователе мы хотим получить также всё, что
касается его бейджей. Массив бейджей состоит из объектов типа Badge,
которые обладают свойствами:
1. Title, тип string – название бейджа
2. Description, тип string – описание бейджа
3. imageURL, тип string – ссылка на картинку бейджа
4. type, тип string (может принимать значения только “leadership”
или “achievement”) – тип бейджа.
В представлении бейджи являются контейнерами, состоящими из
названия, картинки. Тип необходим для того, чтобы рассортировать
бейджи по соответствующим разделам, а описание – для добавления