Category: One-Line: Play2Win

1. Estimated VS Spent time spent on the project (BE, FE, QA, PM, code review, total), Estimated = 80 – 127h, Spent = 127h

2. Time and number of bugs found by the client; CB = 1.93h, Bugs found by QA = 7.19h

3. Additional client requests = 207,8h

Project: OneLine: Play2win

Team: PM: Kate Hvozd ; FE: Andrij Rehush ; BE: Artur Bulan , Anna Aksonenko ; QA: Artem Makarov ; Team Leads: Artem Gnibeda , Pavlo Trukhin

Link to the Retrospective document – Retrospective

Conclusions (короткий висновок 1 реченням)

Description (опис що було хорошого чи поганого і якщо погане то як вирішували)

Тимчасова колонка

(додаткові коментарі під час ретро колу)

Department

1. High level of flexibility and “foreign” code absorbing and reworking Kate Hvozd

Description – Play2win is a mixture of Old Migrol version, Win4win + Elementor set up by another dev team + new custom functionality. So working with it was a big challenge. Client changed her mind about global settings several times and all of them were implemented on time and in a good quality.

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

2. Code review for complicated tasks and further log monitoring Kate Hvozd

Description – Reminders stopped sending on competitions

Solution – code reworked

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

3. Мігрол має редизайн сайти, дочірні сайти, копії і т.д. Artur Bulan

Description –

Solution – Було б добре, якби всі сайти були в одній стилістиці коду, наприклад, як Page Builder для Rief Media, щоб не створювати сайт з нуля, а потім в кінці підганяти під ідентичність

Розробити темплейт для розгортання нових подібних проектів з колесами і компетішенами, щоб зберегти однакову структуру.

Краще не використовувати стилі Play2win для подібних сайтів, краще Мігрол за основу колесних сайтів.

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

4. Чітке розуміння повної картини проекту Artur Bulan

Description – Це стосується більше замовника, щоб імплементація нового функціоналу не відбувалась в терміновому порядку у зв’язку з тим, що не вирішено чи варто мати функціонал чи ні

Solution – Максимально добиватись від замовникак цілісної картини того, що він бажає отримати в кінці роботи над проектом. Бо були зміни в останній час, які дуже сильно ламали логіку роботи (прим. Pavlo Trukhin)

добиватись від замовникак цілісної картини

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

5. Дизайн або чіткіший опис Andrij Rehush

Description – часто не зрозуміло як має виглядати та чи інша доробка яку потрібно доробити

Solution – було б добре яки вони надавали дизайн або чітко описували, що потрібно зробити

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

6. Дизайн Artem Makarov

Description – часто до змін немає дизайну.

Solution – Було б добре додати до змін не тільки опис, а ще дизайн, щоб не виникало непорозумінь щодо того, як це має бути реалізовано.

більш чіткі вимоги коли нема дизайну – давати конкретні значенння по шрифтам і відступам. Залучати нашого дизайнера на підготовку дизайну маленьких змін. Або підключати на обговорення команду для вирішення візуальної реалізації на попередньому колі.

В дизайні включати найдовші назви.

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

7. Часто змінювалась логіка Колеса та Компетішинів. Artem Makarov

Description -Дуже часто змінювалася логіка Колеса і Компетішин. Було трохи незрозуміло, на якому етапі ми знаходимося та як реалізовавувати далі.

Solution – треба код фріз. А то наче ми все зробили і на насутпний день 10+ нових тасок на зміну)

затримка перекладів впливає на швидкість і якість тестування, затримка перекладів x2 закладати на час.

• код фріз – більш строго з клієнтом.

DEVELOPEMENT PROCESSESQA PROJECT MANAGEMENT

8. Пошук кращих рішень

Pavlo Trukhin

Description – Ми вже маємо досвід розробки 2 “рекламних колес”. Тепер це можемо використовувати цей досвіт при розробці наступних.

Solution – Приділяти більше уваги плануванню, пошук кращого технічного рішення (враховуючи потенційні проблеми, які ми вже можемо передбачувати). Можна сказати цей пункт – підсумок попередніх:)

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

9. ————

Description –

Solution –

DEVELOPEMENT PROCESSES QA PROJECT MANAGEMENT

10. ————

Description –

Solution –

DEVELOPEMENT PROCESSES QAPROJECT MANAGEMENT

OneLine: Play2win

Incident #1 [48h reminders stopped sending on competitions]

28.11.2024 3:35PM

(on live after launch)

client didn’t know about the issue (after win4win recent reminders bug we decided to fix Play2win bug quietly and track time to another task.)

Kate Hvozd

Anna Aksonenko (fixed)

Artur Bulan (main dev but was on the sick leave)

Artem Makarov

Pavlo Trukhin

nobody

Request optimization: some checkups moved from code to DB request directly, so the data we receive became smaller and more actual.

Reason the issue appeared:

Request didn’t include strict timeframe (we were taking all old registrations created earlier than some date and later it lead to the accumulation) and in the code the registrations without partner ID were excluded (but they were not excluded from the request, so we received 1000+ rows, а потім у коді крутили їх виключаючи по одному).

If it’s a new code – the Code review was required and possibly there the logic problem could be captured.

Reminder log should be checked from time to time or additionally some monitoring with Slack notification applied. If the log was checked from time to time it should be possible to notice the gradual increase in reminders number.

(This issue couldn’t be captured by the one time testing)