Retrospective findings -Swisskrono

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

  1. 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

  1. Requirements in 1 place

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

PM PROCESSES

  1. Separate estimation for content testing (if content is final – needed)

Add a separate estimate for content testing  – content testing was not specified in the estimate. Also, the content is located in different folders, which requires more time to search and compare it. (Artem Makarov)

Add more text, bigger image, other type of file…

PM PROCESSES

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

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

PM PROCESSES

  1. Optimize the amount of items in checklist + agreed with Team leads the default testing rues for FE and BE.

On almost all tasks, there are unnecessary todos such as checking various devices and so on. (Dima Rogkov) – agree with Team leads the default testing rues for FE and BE. (PM)

TEAM

  1. Use uploaded fonts

Fonts shouldn’t be google fonts (PM)

DEVELOPEMENT PROCESSES

  1. 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 (синяя звезда) .

  1. On the start call choose the functionality that will be started from BE stage

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

Бекові елементи – Досить часто на проектах виникає проблема з контакт формами, кукізами, лоадмор і подібними елементами, які спочатку пишуть фронти, потім беки натягають (наскільки це дозволяє верстка і плагіни), а потім як правило ще спільними зусиллями допилюють. Це пойнт ту дискашен 🙂 – Нещодавно на проекті спробувала зворотній порядок (бек робить форму і віддає html фронту, який це стилізує і щось дописує по скриптам якщо треба), мені здається це трохи пришвидшує роботу. Або ні.

DEVELOPEMENT PROCESSES

  1. 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

  1. 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

  1. Forbid the image and video editing by developers

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

DEVELOPEMENT PROCESSES

  1. “/” 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

  1. 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

  1. 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

  1. QA Estimation – add time for QA after WP Rocket activation

  1. 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

  1. Discuss the launch in tiny detailes

Second launch – took much unpredicted time.

Reasons:

  • мало місця на stage

  • мало місця на Live (ми залізли за ліміти, але це не вплинуло на працездатність сайту)

  • через специфіку змін було важко знайти потрібні файли в папці uploads

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

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

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

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

https://gyazo.com/11a2cc957eb2a749a1f8a99361ee8571

DEVELOPEMENT PROCESSES

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

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

DEVELOPEMENT PROCESSES

  1.  Код ревью

Чи потрібно вносити зміни? Колись ми з Олегом домовились на ревью, що його зауваження – на майбутнє, а вже зроблене не чіпаємо (крім випадків критичних багів і т.п.)
І також можливо це зручніше робити через гітлаб, через мерж реквест в мастер і коменти там же. (Але якщо реквести довго висять, підуть конфлікти, то може краще й так) → узгодити флоу

DEVELOPEMENT PROCESSES

  1. Git – Delete merged branches

DEVELOPEMENT PROCESSES

  1. 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

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

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

Comments

Leave a Reply