Delivered our Way - biuletyn 2023-10-12

Zapraszamy na aktualności!
Framework Współpracy
W ramach Frameworku Współpracy z Delivery odbyły się kolejne spotkania sterujące. Raporty ze spotkań:
2023-09-26 T1/T2/T3 tollgate
2023-10-12 Meeting notes - Q1 Quality
Zaczęliśmy wprowadzać zmiany w mechanice działania zadań typu Program w projekcie PRODUKT:
Został uruchomiony automat podliczający czas poświęcony na realizację inicjatyw.
Program ten:
Szuka wszystkich programów w statusach innych niż Done i Won't do
Zagląda do wszystkich epików jakie są podpięte do programu, a następnie do wszystkich zadań w epikach i zbiera informacje o zalogowanym czasie
Zebrane godziny rozdziela na kupki "zalogowane w Delivery" oraz "zalogowane poza Delivery"
Zapisuje do pól "WH burnt in total", "WH burnt in Delivery", "WH burnt outside Delivery" (zakładka KPI)
Cechy działania programu:
Wszystkie zapisane zmiany wykonywane są z poziomu użytkownika @Szymon Pająk , więc w historii zadania odnajdziecie, że to Pająk je edytuje (kiedyś to pewnie zmienimy). Jeśli zapisane godziny budzą Wasze wątpliwości, przyczyną może to, że @Szymon Pająk nie ma dostępu do Waszego projektu. Eskalujcie takie sytuacje.
Automat rozdziela godziny w i poza Delivery w oparciu przynależność do roli "delivery-memebers" (jest literówka w nazwie roli - wiemy). Jeśli zapisane godziny budzą Wasze wątpliwości, przyczyną może to, że użytkownik logujący czas do projektu nie należy do ww grupy.
Automat będzie działał co 24h i uruchamiał się w godzinach wieczornych
Ważne jest logowanie na bieżąco, bo jeśli ktoś będzie dokładał godziny do projektu, który jest już w statusie finalnym, wartość pola nie zostanie zaktualizowana
Możecie natknąć się na takie lapsusy:

Są to błędy zaokrągleń. W Delivery zalogowano 5h i 1m, a poza Delivery 1m. Każdy ogonek system zaokrągla w górę. Suma minut jest poniżej 6h wiec zaokrąglenie nadal wynosi 6h. Miejcie to na uwadze.
Podliczanie kosztów projektów (i korzystanie z widoku harmonogramu) pozwoliło zaobserwować pewien problem w sposobie wiązania ze sobą zadań. Często posługiwaliśmy się wyrażeniem "child issues"/"rodzic"/"dziecko" w znaczeniu relacji program-epic-zadanie. Doprowadzało to do nieporozumień, ponieważ oprócz relacji program-epic-zadanie istnieje jeszcze możliwość luźnego wiązania zadań i jedną z relacji było "is child of"/"parent of"/... (tutaj były aż dwa rodzaje relacji używających nomenklatury rodzic-dziecko). Były to dwie różne relacje, ocierające się tą samą nazwą. Niepoprawne łączenie zadań za pomocą "luźnych wiązań" skutkowało tym, że projekty źle się wyświetlały na roadmapie lub niepoprawnie liczyliśmy ich koszt. Aby zmitygować ryzyko dalszych pomyłek, zmieniłem nazwy luźnych relacji na następujące:

Powiązania w zadaniach, które wiązaliście luźno relacją "is child/parent of" zostały hurtem zmienione na dwie powyższe. Dlaczego jedna z relacji ma w nazwie "deprecated"? To ze względu na wspomnianą powyżej nadmiarowość w konfiguracji - dwie relacje o nieznacznie różnych nazwach opisywały to samo. Obecnie nazwy zostały wyprostowane, a w przyszłości być może uda się pozbyć tej "deprecated" i zostanie tylko jedna z nich. Od teraz zatem, gdy będziemy mówić o relacji rodzic-dziecko, będzie to wskazywało wyłącznie na powiązania między programem, epiciem i zadaniami, a nie będzie dotyczyło możliwości luźnych powiązań między zadaniami.
Jeśli ktoś w swoich dokumentach na Confluence używa makr z wyrażeniami: > issueIsChildOf = ZADANIE-1lub podobnymi, nawiązującymi do usuniętych rodzajów relacji, to należy zacząć korzystać wyrażeń:> "issueIsUnderTo(deprecated)" = ZADANIE-1albo (dla drugiej relacji)> issueIsUnderTo = ZADANIE-1Audyt KPMG wykazał konieczność dodatkowych działań związanych z prowadzeniem projektów. Szczegóły wymogów znajdziecie tutaj: Komunikat ws wytycznej KPMG
Logowanie czasu pracy nad tematami produktowymi, ale nie będące elementem konkretnego projektu, ani utrzymania. Propozycja jak poradzić sobie z tym problemem znajduje się w dokumencie Logowanie prac nad produktem
J23 znowu nadaje, czyli wieści z SRE
Rekomendacje
W tym nowym dziale Biuletynu będziemy informować o rekomendacjach praktyk, jakie powstają w SRE.
Najnowszy wpis z rekomendacji z almanachu SRE: Paweł Stanka: Spring /RestTemplate - problem z defaultową pulą połączeń
Przegląd incydentów
Odbyły się dwa przeglądy, z których notatki możecie przejrzeć tutaj:
Metodyka obsługi Incydentów i działań naprawczych
Przeglądy incydentów i codzienne obcowanie z zadaniami pozwoliło zauważyć stosowane przez niekonsekwencje w tworzeniu zadań na działania naprawcze. Poniższy link prezentuje opis w jaki sposób należy generować takie zadania: Paweł Stanka: Linkowanie działań naprawczych do Incydentów [JIRA]
Awarie Bramki Płatniczej
Analiza dokonana przez @Paweł Stanka i @Jakub Demczuk wykryła białkowe czynniki doprowadzające do lockowania się bazy danych Bramki. Zapoznajcie się z wątkiem Jakub Demczuk: DBeaver musi odejść
Co w trawie piszczy
Zespół Data & Services SMS
Cały zespół “Delivery Payments”
Zespół Payments Onboarding
Zespół Payments Online
Zespół Data & Services Identity
Zespół Data & Services Frontend
Zespół Back Office DevNetOps
Nowa nazwa bloga
Nową nazwę bloga już poznaliście. Walka propozycji o prymat nie była zażarta. Jedna z propozycji od razu rozbiła bank! Kto jest szczęśliwym zdobywcą
…?

@Michał Stan
Gratulujemy i zapraszamy po nagrodę!