Retrospective findings

Team: PM: Givi Dzandzava; FE: Ihor Havrilenko; BE: Artur Bulan; QA: Artem Makarov; Team Leads: Alec Shpigar, Pavel Truhin

Link to the Retrospective document – Retrospective

Висновки

Опис

Відділ

Виділяти більший час на аналіз дизайну

Розглядати дизайн з позиції один одного, обговорювати кожен блок як фічу, а не поверхневий огляд сторінку

TEAM

Розглядати дизайн з позиції UI/UX, більше власних пропозицій з приводу покращення дизайну та функціоналу

Створити підхід ніби ми кожен сайт розроблюємо для себе і ми будемо основними користувачами. Надавати більше пропозицій до дизайну, навіть, якщо не ми його створювали. Критично осмислити кожен функціонал, передбачити його варіації та донести це до клієнта, запропонувати найкращі способи імплементаціх

TEAM

Створити уніфіковану структуру тасок

Затсосовувати уніфіковану структуру тасок, щоб пришвидшити вникання у таску

PM PROCESSES

Писати рекомендовані розміри та формати медіафайлів для блоків, зробити адмінку біль user friendly

Можливо додаткові description з зазначенням розмірів зображень у блоки, де потрібно вставляти медіафайли. Інші способи зробити адмінку більш User friendly

DEVELOPEMENT PROCESSES

Якщо міняємо розробника, робимо нову (внутрішню) естимацію

Кожна особа має сама оцінити скоуп роботи. Бажано фіксувати цей показник окремо

PM PROCESSES

Додавати репорти до виконанї таски/баги

Відноситься до фіксу багів. Треба створити щось по типу структури тасок. Можливо наступне: 1. Problem description (технічний опис, бо функціональний і так має бути наявний у багу) 2. How solved (опис рішення) 3. Screens 4. Links

DEVELOPEMENT PROCESSES

Додавати original estimate у таски

Додавати у відповідні поля у тасці Jira

PM PROCESSES

Створювати блоки за назвами блоків з естимації

Під час розгляду дизайну з командою, дати назву блокам, якої варто притримуватись на етапі розробки

DEVELOPEMENT PROCESSES

Розробники мають самостійно активно підключати Тім лідів

Не занурюватись у виконання таски надміру, чітко розуміти, коли вже час звернутись за допомогою до Тім лідів

DEVELOPEMENT PROCESSES

Слідкувати за документом естимації

Слідкувати за різницею естимованого та витраченого часу у відповідних полях таски

DEVELOPEMENT PROCESSES

Next project:

Project: Swisskrono

Team: PM: Kate Hvozd ; FE: Oleksii Reshetnyk Dmitriy Rogkov (Unlicensed) ; BE: val.b (Unlicensed) Anna Aksonenko ; QA: Artem Makarov Illia Bilyk (Unlicensed) ; Team Leads: Alec Shpigar , Honcharuk Oleh Pavlo Trukhin SysAdm/D.​OPS: Roman Kliuiko SEO: Anna Nikitina (Unlicensed) . (PM help Givi Dzandzava (Unlicensed) Andrii Kupriianov )

Link to the Retrospective document – Retrospective

Висновки

Опис

Відділ

1. Unique blocks separately on the design (if possible) + desk and mob in one board

Ask designer to prepare the unique blocks separately on the design if there are 2+ pages that share the same blocks. (PM)

PM PROCESSES

2. More carefull with complex functionality estimation

Be more carefull with complex functionality estimation

• (like map), ask client more questions and add more risks if it’s needed. In the estimation file add the full description of what was estimated with the note that “additional requiremnets will be estimated separately”) (PM)

• Backgrounds – more detailed exploring and estimation

PM PROCESSES

3. Requirements in 1 place

1 main file should include all the blocks descriptions + copy description in Jira task (Artem Makarov, Dima Rogkov)

PM PROCESSES

QA Estimation:

• Separate estimation for content testing (if content is final)

• add time for QA after WP Rocket activation

• proper BE testing

Add a separate estimate for content testing  – content testing was not specified in the estimate, content was located in different folders (Artem Makarov)

BE testing – test tha main BE QA scenarious: Add more text, bigger image, other type of file…

PM PROCESSES

5. Analyze design and agree with the client not-PP development if the design in not 100% PP (in email)

If cliemt wants a perfect pixel, demand a perfect design where everything is taken into account) (Artem Makarov)

PM PROCESSES

6. Copy important discussions from Slack to tasks (comments)

So the QA and other teammates know what was discussed and what solution used

TEAM

7. Use uploaded fonts + Git -> Delete merged branches

Fonts shouldn’t be google fonts (PM)

DEVELOPEMENT PROCESSES

8. Content manager onboarding on early stage to help BE if there is too much content

In general, a large amount of work with content instead of work with code .

9. On the start call choose the functionality that can be started from BE stage

Forms, load more, cookies sometimes should be developed on BE first to reduce double work.

DEVELOPEMENT PROCESSES

10. Analyze more the additional resources involving

1. BE feedback – How necessary are two backs on such projects?

2. QA feedback – convenient for me that there were 2 QA. This is a plus Also, there were no problems with two BE + But it was not very convenient to test at the beginning of the FE (Artem Makarov)

TEAM

11. Agree on the start call if the images for mobile should be uploaded separately

images for mobile – PM and developers at the beginning of the project should agree where we need a separate field for mobile Img or video (Kate Hvozd)

DEVELOPEMENT PROCESSES

12. Forbid the image and video editing by developers

Client should provide the final images and videos (Cropped and optimized).

DEVELOPEMENT PROCESSES

13. “/” in URL – remind on start call

Discuss in the begining and make sure that all links have / at the end (in the content) (PM)

DEVELOPEMENT PROCESSES

14. If there is Span underline or animation with running line – discuss on start call the possible issues

1. Span underline – if span class "underline" has a few words on mobile we had a bug with the underlining → solution → Add special rules for spans so it wraps fine. For animated links → solution → discuss with deigner that they should be always in 1 line with such animation. (PM)

2. animation with running line – Be ready for the bugs when its not inline-block. → solution → Only inline-block element will have this animation 100% working correctly on all browsers. (PM)

DEVELOPEMENT PROCESSES

15. Word wrap rules discussion on start call

word wrap – On the text pages we had "hyphens: auto;" but on other pages we have no wrapping. – Analyze the design and agree with dev team and client the wrapping rules and how we should act if we don’t have "hyphens: auto;" and the word doesn’t fit the container on mobile. Use correct lang for proper wrap

DEVELOPEMENT PROCESSES

16. Customizible position, background and z-index for all blocks by default.

 (Anna) – реквест на стартову тему

 DEVELOPEMENT PROCESSES

17. SMTP and Recapture setup and QA

Test a few times SMTP, especially on final stages. Ask client to not change the password without notifying us (PM). Always use client’s email.

DEVELOPEMENT PROCESSES

18. Discuss the launch in tiny detailes

Second launch – took much unpredicted time. – details here – in 18 point. Reasons:

• not much space on stage and live

• due to the specifics of the changes, it was difficult to find the necessary files in the uploads folder

Solution – Перенос частково вручну, частково через плагiн + щiльна робота з файлами через ssh

Suggestion – Точно зафіксувати дату початку роботи на stage і переносити зображення починаючи з цієї дати:

• врохувати це при створеннi архiву з зображеннями

• aбо вказати в налаштуваннях плагiну WP DB Migrate

https://gyazo.com/11a2cc957eb2a749a1f8a99361ee8571 

DEVELOPEMENT PROCESSES

19. Positive Jira prosses feedback

I really liked the organization and priority of tasks in Jire. That there was a separate task for each role and that there was a general task with subtasks within it. It is also convenient that PM himself reassigns a specific task to QA when subtasks are done. As a result, there were not a lot of duplicating tasaks that were incomprehensible to me in the jira. (Artem Makarov)

TEAM

Next project:

Project: OneLine: Migrol

Team: PM: Kate Hvozd ; FE: Andrij Rehush ; BE: val.b (Unlicensed) ; QA: Artem Makarov ; Team Leads: Artem Gnibeda , Honcharuk Oleh Pavlo Trukhin

Link to the Retrospective document – Retrospective

Висновки

Опис

Відділ

1. If there are a few emails in the row – each should be tested separately to make sure it was triggered by correct trigger (actition).

Win email sent before winning. Solution – Rewrite the logic.

(issue captured on the final tests, but developer said that it’s not easy to change the trigger, so we implemented some delay in email sending to cover this issue. However the client reported a bug anyway.)

DEVELOPEMENT PROCESSES

2. WP setup – Analyze the possible amount of fields and divide it accordinly to not exceed the limit or change the limit in advance.

some WP fields dissapered from theme settings because limits were reached.

Solution – Changed the limits in WP. (The issue apeared after we’ve implemented a few new fields).

DEVELOPEMENT PROCESSES

3. After each even small change the full functionality should be tested (even if it seems like the change is not connected to anything else. Including each email and their amaunt).

Links don’t work, the page reloads on click + triggers a duplicate email sending.

Solution – Links fixed, so they stopped trigerring the page reload and duplicate email sending.

DEVELOPEMENT PROCESSES

4. Set up correct receivers for emails that are triggered by crons. Be careful with transfers to prevent the code rewriting

Duplicated Reminder emails (and after fix appeared again)

Solution

• 1.06 (before launch) – changed the logic so users receive personalized emails and are o in the copy of each other

• 5.06 (after launch) – the fix made 1.06 was accidentally rewritten during some next transfer, so the fix was put back.

DEVELOPEMENT PROCESSES

5. Testing of the complicated functionality should include checkup of all the positive scenarios step by step. (To make sure that data saves correctely – accordingly to user actions)

Prize limits were reaching too fast as “-1” was on applied to more prizes then needed.

Solution: “-1” was applied to correct prize (not all the prizes form interests that were chosen)

DEVELOPEMENT PROCESSES

6. After form testing – always make sure that all the fields data appeared in WP and emails.

Sometimes some fields do not appear in the WP table (but saved in DB)

Solution:

• the frst time it was reported there were a few such cases. We haven’t found the reason why it happened and were monitoring it.

• then we assumed that the code should be rewritten but it will be too dangerous, so we’ve just moved the data from DB to the table and DB.

DEVELOPEMENT PROCESSES