Przystępny słownik pojęć Agile

Co robi w pracy Scrum Master? Jak wytłumaczyć tę i wiele innych kwestii komuś, kto nigdy nie zetknął się z ideą Agile? Pełna definicja ze wszystkimi odniesieniami będzie zupełnie niezrozumiała, więc zdecydowanie nie trzeba startować od zera i objaśniać wszystkiego. Wszystko da się ładnie uprościć.

Mistrz młyna to ktoś, kto zwinnie przeskakuje wodospady. To mocno niepełna, ale formalnie poprawna definicja opisująca, na czym polega praca Scrum Mastera. Jest niejasna dla osób postronnych i dobrze sprawdza się w trakcie rodzinnych spędów, powstrzymując kolejne pytania. W innych okolicznościach zdecydowanie lepiej spróbować rozwiać wątpliwości pytającego w zrozumiały dla niego sposób.

Niniejszy słowniczek powstał jako pomoc w łatwym zorientowaniu się, o co chodzi w Agile i Scrum dla tych, którzy do tej pory nie mieli wcale lub prawie wcale do czynienia z tą tematyką. Z tego powodu niektóre sformułowania i używane słownictwo mogą wzbudzać kontrowersje wśród zaawansowanych praktyków lub/i ortodoksów tematyki. Uproszczone i niewyczerpujące tematu definicje zastosowano celowo, aby nie stwarzać dodatkowej bariery przez opisywanie niezrozumiałych pojęć za pomocą innych niezrozumiałych pojęć.

Do pełnego zrozumienia danego terminu niekiedy trzeba będzie przejrzeć dwie, trzy dodatkowe definicje lub wręcz przeczytać wszystko, zastanowić się, a potem przeczytać jeszcze raz, zwracając uwagę na fragmenty, które umknęły lub były niezrozumiałe przy pierwszym podejściu. Dokładnie tak, jak z instrukcją obsługi dowolnego urządzenia. Nie jest to trudne, a do tego można to robić na raty (czyli jak na Agile przystało – w modelu iteracyjnym).

Agile

Sposób myślenia i pracy zgodny z założeniami Manifestu Agile. W ujęciu projektowym, wspólne określenie zwinnych metod wytwarzania oprogramowania opartych o model iteracyjno-przyrostowy. Skupia się na dostarczaniu produktu w sposób ciągły przy silnym zaangażowaniu klienta w proces. W założeniu zespoły pracują zwinnie, czyli szybko i elastycznie dopasowują się do zmieniających się wymagań klienta i warunków zewnętrznych. Polecany przy projektach posiadających niestabilne wymagania i brak jasnej, konkretnej i niezmiennej wizji produktu końcowego. Umożliwia rozpoczęcie działania bez kompletu szczegółowych wymagań oraz dopuszcza możliwość ich zmiany bez konieczności zaczynania pracy od nowa. Jego głównym celem jest podniesienie jakości produktu (rozumianej jako zadowolenie klienta oraz stopień dopracowania produktu) tak, by odpowiadał realnym potrzebom klienta, a nie tylko początkowym wymaganiom.

Agile Coach

Osoba edukująca innych, czym jest Agile. Główną rolą jest zazwyczaj wspieranie organizacji w transformacji zwinnej oraz praca z jej częścią biznesową na poziomie kadry zarządzającej wyższego szczebla. Między Scrum Masterem a Agile Coachem granica jest płynna, ale podstawowym wymogiem, aby Scrum Master został Agile Coachem, jest doświadczenie nie tylko w pracy z zespołem, ale też z całą organizacją. Nie decyduje o sposobie i metodach wprowadzania filozofii Agile w organizacji, a skupia się na edukacji, celem wspierania organizacji we wprowadzaniu oraz utrzymywaniu zwinności, rozumieniu i stosowaniu obranej metodyki.

Agile Fluency Model

Model opisujący stopień dojrzałości i efektywności zespołów zwinnych. Stworzony przez Jamesa Shore’a i Diany Larsen, Agile Fluency Model określa cztery poziomy płynności (Fluency Levels): Focusing, Delivering, Optimizing, Strengthening. Każdy poziom opisuje stopień, w jakim zespół przyswoił zasady i praktyki Agile, i jakie korzyści z tego wynikają dla organizacji. Model ten jest używany przez Scrum Masterów i Agile Coachów do oceny postępów zespołu i planowania jego dalszego rozwoju.

Agile Manifesto (Manifest Agile)

Dokument opracowany w 2001 roku przez 17 praktyków tzw. lekkich metod (m. in. Scrum, XP, DSDM, FDD, CC) opisujący wspólne podstawy i założenia tych metod oraz podkreślający wartości na jakich się opierają. Przy okazji opracowywania Manifestu Agile zmieniono nazewnictwo i zamiast “metod lekkich” pojawiły się “zwinne” (agile).

Agile Maturity Model (Model Dojrzałości Zwinności)

To narzędzie służące do oceny stopnia dojrzałości organizacji, zespołu lub jednostki w kontekście pracy zwinnej. Umożliwia ocenę, na ile dana jednostka w pełni wdrożyła zasady Agile, a także identyfikację obszarów wymagających usprawnień. Często składa się z kilku poziomów (np. Początkujący, Średniozaawansowany, Zaawansowany), z których każdy definiuje konkretne kryteria związane z adaptacją i przestrzeganiem zasad Agile, takich jak samoorganizacja, ciągłe doskonalenie, adaptacja do zmieniających się warunków i stosowanie praktyk zwinnych.

Agile Team (Zespół Zwinny)

Zespół pracujący opierając się na zasadacg Agile, który charakteryzuje się samoorganizacją, wysokim poziomem autonomii oraz współodpowiedzialnością za wynik końcowy. Zespoły Agile często składają się z osób posiadających różnorodne kompetencje (wielofunkcyjne), które wspólnie dążą do osiągnięcia określonych celów biznesowych. Cechą charakterystyczną zespołów Agile jest również regularna inspekcja i adaptacja sposobu pracy, tak aby proces i produkt były dostosowywane do zmieniających się potrzeb interesariuszy.

BDD (Behavior-Driven Development)

Podejście do wytwarzania oprogramowania, które kładzie nacisk na definiowanie zachowania systemu z perspektywy użytkownika. BDD pomaga zespołom zrozumieć wymagania biznesowe i tworzyć specyfikacje w języku zrozumiałym zarówno dla deweloperów jak i interesariuszy. Jest często stosowane jako rozszerzenie Test-Driven Development (TDD).

Burn-down chart (Wykres Spalania)

Sposób wizualizacji, w formie wykresu, czasu i pracy pozostałych do wykonania w danym Sprincie/projekcie. Pionowa oś wykresu to mierzalny zakres pracy (np. Story Pointy), pozioma oś to czas (np. w dniach). Na wykresie zazwyczaj znajduje się linia wartości uśrednionych przedstawiająca idealny, liniowy spadek pozostałej do wykonania pracy. Wykres obrazuje tempo realizacji zadań w danym Sprincie, a linia idealna pokazuje w jakim tempie Zespół powinien pracować, aby ukończyć założone zadania.

Burn-up chart

Sposób wizualizacji pracy i czasu pozostałych do wykonania w danym Sprincie/projekcie, w formie wykresu. Częściej stosowany w przypadku projektu niż Sprintu. Pionowa oś wykresu to mierzalny zakres pracy (np. Story Pointy), pozioma oś to czas (np. iteracje). Na wykresie znajduje się linia przedstawiająca zmiany w zakresie pracy (zmiana ilości Story Point), druga linia wskazuje, ile pracy zostało wykonane w poszczególnych iteracjach. Wykres obrazuje w jakim estymowanym czasie przy bieżącym tempie, prace dla wycenionych SP zostaną ukończone. Jest to możliwe poprzez uśrednienie i przedłużenie linii wykonanej pracy.

Capacity (Pojemność)

Estymowana praca możliwa do wykonania przez dany Zespół w trakcie Sprintu. Zawsze odnosi się do konkretnego Zespołu. Całkowicie zależna od nieobecności deweloperów oraz ich zaangażowania w inne zadania. Możliwa do określenia na podstawie Velocity, Load oraz dostępności poszczególnych deweloperów.

Daily

Jedno z wydarzeń (ceremonii) scrumowych. Codzienne spotkanie Zespołu Deweloperskiego, odbywa się każdego dnia Sprintu, zazwyczaj w tym samym miejscu i o tej samej porze; zwane też stand upem z racji tego, że często odbywa się na stojąco. Czasowo ograniczony jest do 15 minut. Służy koordynacji prac na okres do następnego Daily, określeniu czy istnieją problemy zagrażające realizacji Celu Sprintu oraz sprecyzowaniu, co Zespół Deweloperski zamierza zrobić, aby zrealizować Celu Sprintu.

Definition of Done (DoD; Definicja Ukończenia)

Lista kryteriów, jakie musi spełniać każde pojedyncze zadanie, nad którym Zespół Deweloperski pracuje w trakcie Sprintu, po spełnieniu których wszystkie strony procesu uznają zadanie za zakończone. Jest tworzona w oparciu o standardy obowiązujące w organizacji lub w przypadku ich braku – przez Zespół Deweloperski. Może być dyskutowana i zmieniana przez Zespół w trakcie Retrospektywy. Zazwyczaj im dojrzalszy Zespół, tym bardziej rozbudowana jest DoD. Istnienie listy z jasno sprecyzowanymi wymaganiami zapewnia, że wszyscy uczestnicy procesu wiedzą co oznacza stwierdzenie, że dane zadanie jest skończone i nie ma miejsca sytuacja, w której następuje rozbieżność pomiędzy tym, co uważa za skończone Zespół Deweloperski, a tym, co za skończone uważają Product Owner i Interesariusze. Stan ukończenia zadania jest zero-jedynkowy. Nie istnieją zadania częściowo skończone. W wypadku, gdy nad projektem pracuje kilka zespołów, wszystkie powinny mieć tą samą Definicję Ukończenia.

Definition of Ready (DoR; Definicja Gotowości)

Lista kryteriów, jakie musi spełniać każde pojedyncze zadanie w Backlogu, aby Zespół Deweloperski mógł je realizować podczas Sprintu. DoR jest tworzona przez Product Ownera i ulepszana z Zespołem Deweloperskim w trakcie Retrospektywy. W przypadku Definicji Gotowości „gotowy” nie oznacza, że zadania w Backlogu muszą być w 100% zdefiniowane, muszą być „wystarczająco gotowe”, aby Zespół Deweloperski był przekonany, że może z powodzeniem przystąpić do realizacji zadania, rozumie ryzyko biznesowe i cel klienta.

Deployment

Fizyczne umiejscowienie produktu w wyznaczonym przez klienta środowisku (np. produkcyjnym).

Design Thinking (myślenie projektowe)

Metoda twórczego rozwiązywania problemów, zdefiniowana po raz pierwszy na Uniwersytecie Stanforda w USA w latach 60. Zakłada, że celem jest dostarczenie innowacyjnych, dopasowanych do oczekiwań końcowego odbiorcy, rozwiązań poprzez wykorzystywanie metod pracy pobudzających kreatywność. Metoda ta skupia się na użytkowniku i zrozumieniu jego potrzeb. To właśnie te realne potrzeby, nie zaś założenia tworzone na podstawie wyobrażeń o użytkowniku są punktem wyjścia do pracy nad produktem. Proces twórczy podzielony jest na kilka etapów:

• Empatia – poznanie potrzeb końcowego klienta/użytkownika, jego perspektywy, obserwacja zachowań,
• Zdefiniowanie problemu – kluczowy etap polegający na zdefiniowaniu właściwego problemu, wymaga przełamania ram myślowych i i szerokiego spojrzenia,
• Generowanie pomysłów – tworzenie wielu, w tym nieszablonowych, sposobów rozwiązania zdefiniowanego problemu,
• Budowanie prototypów – wizualizacja rozwiązania problemu i zebranie opinii na jego temat,
• Testowanie – sprawdzanie efektywności rozwiązania w środowisku użytkownika.

Development Team (Dev Team; Zespół Deweloperski)

Jedna z trzech ról w Scrumie, grupa profesjonalistów – od 3 do 9 osób – która wspólnie posiada wystarczające kompetencje do wytworzenia Przyrostu produktu. Liczebność zespołu jest ograniczona ze względu na stopień komplikacji komunikacji w większych grupach i zbyt małą produktywność w mniejszych grupach. W Zespole nie ma podziału na role (tester, frontend dev, backend dev itp.) – wszyscy są nazywani deweloperami (związane jest to z kwestią wspólnej odpowiedzialności zespołu), ale to nie znaczy, że wszyscy muszą mieć kompetencje programistyczne. Zespół Deweloperski ma bardzo dużą autonomię i sam określa, co robi i w jaki sposób. Nikt nie narzuca Zespołowi sposobu, w jaki praca zostanie wykonana (wyjątkiem są ogólne reguły organizacji). Zespół w całości ponosi odpowiedzialność za wykonaną pracę.

DevOps

Skrót od Development and Operations. Osoba łącząca w sobie kompetencje dewelopera i wdrożeniowca lub osoby odpowiedzialnej za utrzymanie programu/systemu. Niekiedy dodaje się także do tego kompetencje związane z testowaniem lub bezpieczeństwem (ang. DevSecOps). W klasycznym układzie te kompetencje należą do różnych osób lub zespołów. Może też oznaczać rodzaj kultury w skali całej organizacji. Wymaga to połączenia obszarów, które w firmach zazwyczaj funkcjonują oddzielnie: zespołu rozwijającego oprogramowanie (Dev) oraz zespołu operacji (Ops).

Dual-Track Agile

Metoda pracy, w której zespół jest podzielony na dwie ścieżki: Discovery (odkrywanie) i Delivery (dostarczenie). Discovery polega na badaniu i weryfikacji hipotez, testowaniu rozwiązań z użytkownikami, iteracyjnym projektowaniu i doprecyzowaniu wymagań. Delivery to właściwa praca deweloperska, w ramach której zatwierdzone funkcje są rozwijane i wdrażane do produktu. Dual-Track Agile pozwala zespołom na jednoczesne eksperymentowanie i szybkie dostarczanie wartości.

Elements of Scrum (Elementy Scrum)

Wszystkie składowe frameworku Scrum. Brak jednego elementu z poniższej listy wyklucza możliwość pracy w Scrum:

• 3 role: Product Owner (Właściciel Produktu), Development Team (Zespół Deweloperski) i Scrum Master (razem tworzą Zespół Scrumowy),
• 3 artefakty: Product Backlog, Sprint Backlog, Przyrost (Increment),
• 4 zdarzenia: Planning (Planowanie), Daily, Sprint Review (Przegląd Sprintu), Sprint Retrospective (Retrospektywa Sprintu),
• 3 filary: Przejrzystość, Inspekcja, Adaptacja.

Empiricism (Empiryzm)

Doktryna filozoficzna o nazwie pochodzącej od starogreckiego słowa oznaczającego doświadczenie. Głosi, że źródłem poznania są bodźce zmysłowe docierające do człowieka, a wiedza wynika z doświadczania i podejmowania decyzji w oparciu o to, co zostało poznane. W zarządzaniu projektami oznacza to, że wszelkie decyzje powinny być oparte na obserwacji i doświadczeniu.

Flow Metrics (Metryki Przepływu)

Koncepcja ta koncentruje się na mierzeniu efektywności przepływu pracy i identyfikacji wąskich gardeł w procesie dostarczania wartości. Metryki przepływu, takie jak Flow Velocity, Flow Efficiency, Flow Load, czy Flow Time, pomagają zrozumieć, w jaki sposób zadania przepływają przez zespół oraz gdzie występują przestoje. Flow Metrics są stosowane w ramach podejścia Flow Framework™, stworzonego przez Mike’a Kerstena, aby zarządzać przepływem pracy na poziomie organizacji.

Increment (Przyrost)

Wszystkie zadania i elementy z Backlogu ukończone w trakcie Sprintu oraz wszystkie zadania z Backlogu ukończone w trakcie poprzednich Sprintów. Każdy Sprint powinien zakończyć się stworzeniem działającego fragmentu oprogramowania/produktu możliwego do pokazania Interesariuszom. W pierwszym Sprincie powstaje pierwszy fragment, w każdym kolejnym zostaje dobudowany do niego kolejny, a suma tych fragmentów tworzy Przyrost produktu.

INVEST

Metoda określania poprawności konstrukcji User Story. W myśl tej metody US powinny być:

• Independent – niezależne od siebie nawzajem,
• Negotiable – negocjowalne (zakres prac do wykonania jest ustalany na drodze rozmów/negocjacji między Zespołem Deweloperskim a Product Ownerem),
• Valuable – wartościowe (posiadają określoną wartość biznesową i są wartościowe z punktu widzenia użytkownika końcowego),
• Estimable – szacowalne (User Story powinno być na tyle precyzyjnie określone, aby było możliwe oszacowanie czasu ich implementacji),
• Small – małe (możliwe do zrobienia w trakcie jednego Sprintu),
• Testable – testowalne (implementacja jest możliwa do potwierdzenia).

Kanban

Metoda stosowana w procesach wytwórczych, w których produkcja jest uzależniona od zamówień odbiorców (nie zaś od planu produkcji), oparta na rzeczywistym zużyciu materiałów. Opracowana została w latach ’40. XX w. na potrzeby systemów produkcyjnych Toyoty. Zapewnia ciągłość produkcyjną przy założeniu nieustannej optymalizacji procesu. Najbardziej efektywna jest w przypadku procesów ciągłych, których nie da się wygodnie i naturalnie podzielić na iteracje, np. praca przy obsłudze help-desku. Jednym z charakterystycznych elementów jest wskaźnik Work In Progress Limit, czyli ograniczenie zadań, które mogą być otwarte na jednym stanowisku.

W procesach wytwarzania oprogramowania Kanban można sprowadzić do trzech zasad:

• Wizualizacja przepływu,
• Ograniczanie pracy cząstkowej (Work In Progress Limit),
• Zarządzanie przepływem.

Manifestacją metody Kanban w IT jest tablica kanbanowa, na której zaznaczany jest przepływ zadań. Istotą tablicy Kanban jest oznaczenie limitów prac w toku na każdym etapie wytwórczym.

Lean Management (Lean; Szczupłe Zarządzanie)

Strategia dostarczania produktów zgodnych z oczekiwaniami w najprostszy z możliwych sposobów, przy założeniu, że nie może się to odbywać kosztem załogi, oraz przy nastawieniu na maksymalną likwidację wszelkich marnotrawstw. Poprzez optymalizację dąży się do zużywania jak najmniejszej ilości zasobów – czasu, wysiłku, pieniędzy, przestrzeni produkcyjnej, narzędzi, etc. Usuwane są wszystkie elementy, które nie są niezbędne do wykonania produktu o założonej jakości. Jednocześnie minimalizuje się zapasy preferując dostawy dokładnie na czas i takie projektowanie systemów, które umożliwia szybkie wykrywanie błędów.

LeSS (Large-Scale Scrum)

Framework do skalowania Scrum w dużych organizacjach, stworzony przez Craiga Larmana i Basa Vodde. LeSS opiera się na zasadach Scrum i stosuje je do pracy wielu zespołów nad jednym produktem. W LeSS kładzie się nacisk na uproszczenie struktury organizacyjnej, a także minimalizację złożoności w komunikacji między zespołami. LeSS definiuje różne role, takie jak Area Product Owner, i zapewnia wytyczne dotyczące pracy w środowisku wielozespołowym.

Load (pl. Obciążenie)

Ilość pracy, jaką Zespół Deweloperski zamierza dostarczyć w trakcie sprintu. Jest określane przez Zespół Deweloperski na podstawie Capacity oraz zakresu Backlogu Sprintu.

Metryki w Agile

Metryki w Agile to mierniki, które pomagają zespołom i interesariuszom śledzić postęp, mierzyć efektywność oraz oceniać jakość dostarczanego produktu. Stanowią one podstawę do podejmowania decyzji, planowania oraz identyfikacji obszarów wymagających usprawnień. Odpowiednio dobrane metryki wspierają transparentność i umożliwiają zrozumienie, jak zespoły radzą sobie z realizacją celów.

Minimum Viable Product (MVP; Minimalny Opłacalny Produkt)

Najprostsza wersja produktu, która spełnia podstawowe wymagania użytkowników i umożliwia zebranie maksymalnej ilości wiedzy o ich potrzebach przy minimalnym nakładzie pracy. MVP pozwala na szybkie przetestowanie hipotez i weryfikację wartości rynkowej produktu przed dalszym inwestowaniem w jego rozwój. Celem jest jak najszybsze zbudowanie produktu, który będzie na tyle funkcjonalny, aby użytkownicy mogli rozpocząć interakcję z nim i przekazać swoje opinie.

Najpopularniejsze Metryki w Agile

Velocity (Prędkość Zespołu)

Prędkość zespołu to miara ilości pracy (najczęściej wyrażana w Story Pointach lub liczbie ukończonych zadań), jaką zespół jest w stanie wykonać w trakcie jednego Sprintu. Jest wyliczana przez zsumowanie Story Pointów wszystkich zakończonych zadań z Backlogu Sprintu. Velocity pomaga zespołowi zrozumieć swoje tempo pracy i przewidywać, ile pracy będzie w stanie zrealizować w przyszłych Sprintach. Prędkość jest również przydatna w planowaniu długoterminowym.

Burn-down Chart (Wykres Spalania)

Wizualne narzędzie, które pokazuje, ile pracy pozostało do wykonania w danym Sprincie lub projekcie w stosunku do upływającego czasu. Na wykresie zobrazowana jest linia rzeczywistego spalania oraz linia idealna, która wskazuje tempo, w jakim zespół powinien realizować zadania, aby zakończyć prace na czas. Burn-down Chart pozwala monitorować postęp prac i szybko identyfikować potencjalne opóźnienia.

Burn-up Chart

Alternatywa dla Burn-down Chart. Burn-up Chart ilustruje, ile pracy zostało już ukończone w stosunku do całkowitego zakresu projektu, a także pozwala śledzić zmiany w zakresie prac (jeśli projekt rozszerza się o nowe wymagania). Dzięki temu lepiej obrazuje wpływ zmieniających się wymagań na postęp prac.

Lead Time (Czas Realizacji)

Lead Time to czas od momentu, gdy zadanie trafi do Backlogu do momentu, gdy zostanie ukończone. Mierzy cały cykl życia zadania, w tym czas oczekiwania i realizacji. Wysoki Lead Time może wskazywać na wąskie gardła w procesie, które opóźniają dostarczanie wartości. Jest istotnym wskaźnikiem w zarządzaniu przepływem pracy i optymalizacji procesu.

Cycle Time (Czas Cyklu)

Mierzy czas od momentu, gdy zespół zaczyna pracować nad zadaniem (czyli trafi do kolumny „W trakcie” w tablicy Kanban), aż do chwili jego ukończenia. Cycle Time pozwala zespołowi lepiej zrozumieć, ile czasu rzeczywiście zajmuje realizacja poszczególnych zadań i identyfikować obszary, w których proces może być usprawniony.

Cumulative Flow Diagram (Wykres Przepływu Skumulowanego)

Diagram przedstawiający stan wszystkich zadań w procesie wytwarzania oprogramowania, w podziale na poszczególne fazy (np. Do zrobienia, W trakcie, Ukończone). Pozwala na śledzenie przepływu pracy w dłuższym okresie i identyfikację wąskich gardeł w procesie. Wzrost liczby zadań w jednym z etapów wskazuje na kumulację prac, które mogą opóźniać dostarczanie wartości.

WIP (Work In Progress) Limit

Liczba zadań, nad którymi zespół pracuje równocześnie. Limit WIP jest stosowany w metodzie Kanban i pomaga zespołom uniknąć przeciążenia pracą oraz skupić się na dokańczaniu zadań, a nie rozpoczynaniu nowych. Obniżenie liczby WIP zazwyczaj prowadzi do skrócenia Cycle Time i zwiększenia efektywności zespołu.

Defect Density (Gęstość Błędów)

Wskaźnik jakości, który mierzy liczbę błędów wykrytych w oprogramowaniu na jednostkę (np. na 1000 linii kodu lub na funkcjonalność). Pomaga zespołowi ocenić, jak często wprowadzane są błędy i w których obszarach produktu mogą występować problemy z jakością.

Net Promoter Score (NPS)

Metryka używana do pomiaru satysfakcji klienta i lojalności użytkowników końcowych. NPS jest obliczany na podstawie pytania: „Na ile prawdopodobne jest, że poleciłbyś nasz produkt innym?” i pomaga zespołowi zrozumieć, jak produkt postrzegany jest przez jego użytkowników oraz czy dostarczona wartość spełnia ich oczekiwania.

Escaped Defects (Błędy Przeoczone)

Liczba błędów, które zostały wykryte po wdrożeniu oprogramowania na środowisko produkcyjne. Przeoczone błędy wskazują na obszary, gdzie należy poprawić jakość procesu testowania i weryfikacji, aby zapobiec wprowadzaniu defektów do produkcji.

Customer Satisfaction (CSAT)

Mierzy ogólne zadowolenie klientów z danego produktu lub usługi. Często stosowany w formie ankiety, w której użytkownicy końcowi oceniają swoje doświadczenie w skali od 1 do 5 (gdzie 5 oznacza „bardzo zadowolony”). CSAT jest kluczowym wskaźnikiem weryfikującym, czy dostarczona wartość odpowiada na potrzeby klienta.

Team Happiness

Metryka stosowana w celu oceny poziomu satysfakcji członków zespołu. Zespół ocenia swoje zadowolenie z pracy w skali (np. 1-5) i omawia wyniki podczas Retrospektywy. Team Happiness pomaga zrozumieć, jakie aspekty pracy zespół ocenia pozytywnie, a jakie wymagają poprawy. Monitorowanie tej metryki wspiera budowanie zdrowej kultury zespołowej.

Nexus

Framework zaprojektowany przez Kena Schwabera (współtwórcę Scrum), stosowany do koordynacji pracy wielu zespołów Scrumowych pracujących nad jednym produktem. Nexus dodaje dodatkowe role i wydarzenia, takie jak Nexus Integration Team i Nexus Daily Scrum, które pomagają zespołom skupić się na integracji i dostarczaniu działającego produktu w sposób skoordynowany.

Pillars of Scrum (Filary Scrum)

Trzy fundamentalne zasady, na których opiera się Scrum:

• Transparentność – dostępność dla wszystkich osób zaangażowanych w proces do wszystkich niezbędnych im informacji oraz jasna i wspólna dla wszystkich terminologia używa w trakcie procesu. Jeżeli dane są dostępne, ale nie są zrozumiałe nie można mówić o pełnej Transparentności.
• Inspekcja – nieustanne skupienie na procesie w celu szybkiego wyłapywania wszelkich zachodzących w nim zmian. Aby inspekcja była możliwa niezbędna jest Transparentność. Każde Spotkanie Scrumowe jest okazją do Inspekcji. Nie należy jednak mylić tego pojęcia z raportowaniem.
• Adaptacja – efekt wyciągania praktycznych wniosków z Inspekcji, czyli szybkie reagowanie na zmiany i wprowadzanie niezbędnych korekt. Aby adaptacja była możliwa niezbędna jest Inspekcja i Transparentność.

Sens pracy zwinnej polega m.in. na wykonywaniu niekończącej się pętli Inspekcji i Adaptacji.

Planning (Planowanie)

Jedno z wydarzeń (ceremonii) Scrumowych, pierwsze w Sprincie. Powinno przynieść odpowiedź na pytanie, co Zespół będzie robił w nadchodzącym Sprincie i jak będzie to robił. W tym celu Zespół Deweloperski określa, które zadania z Backlogu zrealizuje w nadchodzącym sprincie. Zadania powinny być powiązane z Celem Sprintu. Ponadto, Zespół Deweloperski ustala jak będzie realizował Cel Sprintu i zadania z Backlogu Sprintu. W razie potrzeby w trakcie tego spotkania większe zadania powinny zostać rozbite na mniejsze części oraz powinien pojawić się przynajmniej częściowy plan zrealizowania Celu Sprintu. Na koniec planowania Zespół Deweloperski powinien być w stanie wytłumaczyć, jak zamierza zrealizować swoją pracę.

Planning Poker

Jedna z metod szacowania pracochłonności i stopnia złożoności zadań z Backlogu, używana m.in. w Scrum. Zazwyczaj zadania wyceniane są w Story Points. Jest to gra karciana wykorzystująca specjalne karty z oznaczeniami punktowymi (choć można użyć także aplikacji webowych czy mobilnych). Najczęściej wykorzystuje ciąg Fibonacciego lub zmodyfikowany ciąg Fibonacciego: 1, 2, 3, 5, 8, 13, 20, 40, 100. Podczas szacowania zadania, każdy deweloper określa indywidualnie wartość punktową, jaką chce przypisać do zadania, po czym jednocześnie wszyscy ujawniają swoje oszacowanie. W wypadku rozbieżności, osoby które zadeklarowały skrajne wartości uzasadniają swoją ocenę zespołowi i rozpoczyna się dyskusja na ten temat. Następnie przeprowadzana jest kolejna runda szacowania. Jeżeli wyniki nadal nie są jednakowe, odbywa się kolejna dyskusja. Jeżeli po trzeciej sesji głosowania nadal nie ma zgodności, najczęściej przyjmuje się inną metodę przyjęcia ostatecznej wartości ustaloną przez Zespół, np. średnią, odrzucenie skrajnych ocen itp.

Product Backlog (Backlog Produktu, Rejestr Produktu)

Uporządkowany spis (rejestr) zadań do wykonania podczas pracy nad produktem, gdzie priorytetowe i najpełniej opisane zadania znajdują się na górze listy. Zadania powinny zostać poukładane w Backlogu zgodnie z wartością biznesową jaką dostarczają. Zadaniami są nie tylko wymagania funkcjonalne, ale też cała praca jaką trzeba wykonać przy produkcie – usuwanie błędów, poprawki oraz usuwanie długu technologicznego. Zadania umieszczane w Backlogu bardzo często mają postać User Stories, ale nie ma takiego formalnego wymagania. Za zarządzanie i porządkowanie Backlogu jest odpowiedzialny Product Owner. Backlogu nie należy mylić z dokumentacją projektową, ta ostatnia jest zamkniętym zestawem wymagań, a Backlog podlega stałym zmianom (żyje). Zmienia się tak długo, jak długo żyje produkt, którego dotyczy. Aby uniknąć chaosu, jedyną osobą uprawnioną do jego uzupełniania jest Product Owner.

Product Owner (PO; Właściciel Produktu)

Jedna z trzech ról w Scrum, odpowiedzialna za wartość biznesową produktu. Zawsze jest to pojedyncza osoba, nigdy komitet czy grupa osób (choć może korzystać z pomocy analityka i innych specjalistów). PO jest jedyną osobą odpowiedzialną za Backlog Produktu, priorytetyzację zadań i przełożenie wymagań biznesowych na formę zrozumiałą dla Zespołu Deweloperskiego. Kontaktuje się z biznesem i wszelkimi Interesariuszami. Powinien być dostępny dla Zespołu Deweloperskiego w takim wymiarze, w jakim Zespół go potrzebuje.

Refinement (Doskonalenie)

Działanie polegające na ulepszaniu Backlogu Produktu. Backlog stale się zmienia, zatem wymaga nieustannej pracy nad zawartymi w nim zadaniami. Działania w zakresie Refinementu polegają na wspólnej pracy PO oraz Zespołu Deweloperskiego nad uszczegóławianiem elementów Backlogu. Polega to na doprecyzowaniu i korygowaniu zadań, a także na zmianie ich priorytetyzacji. Odbywa się w trakcie trwania Sprintu w momencie dowolnie wybranym przez Zespół Scrumowy. Nie jest osobnym, wydzielonym wydarzeniem, odbywa się w zależności od potrzeb, jednak przyjmuje się, że powinien zająć nie więcej niż 10% długości Sprintu. Głównym celem Refinementu jest przygotowanie zadań z Backlogu do realizacji w nadchodzących 2-3 sprintach.

Release (Wydanie)

Oficjalna dystrybucja Przyrostu produktu udostępniona dla użytkownika docelowego, na finalnym środowisku.

SAFE-T Framework

Skrót od Sociotechnical Agile Framework for Engineering Transformation, stosowany w organizacjach do wdrażania zaawansowanych praktyk zwinnych w zespołach technicznych. SAFE-T skupia się na połączeniu zwinności z praktykami technicznymi, takimi jak Continuous Delivery, DevOps oraz na integracji z podejściami Lean. To narzędzie jest szczególnie przydatne w środowiskach wysokiej złożoności technologicznej.

Scaled Agile Framework (SAFe)

Framework zarządzania projektami Agile w dużych organizacjach. SAFe umożliwia synchronizację pracy wielu zespołów Scrumowych, tworząc wspólne płaszczyzny do planowania, realizacji i inspekcji postępów. Składa się z wielu poziomów, takich jak Portfolio, Program i Team, które pozwalają na przełożenie zasad Agile na zarządzanie całą organizacją. SAFe jest często stosowany w korporacjach i dużych przedsiębiorstwach, gdzie zespoły zwinne muszą współpracować nad jednym produktem.

Scrum

Ramy postępowania (ang. framework) z grupy technik zwinnych (ang. Agile), wykorzystywane przy zarządzaniu wytwarzaniem złożonych produktów empiryczno-adaptacyjnie i w sposób przyrostowy. Założenia opisano w Scrum Guide autorstwa Kena Schwabera i Jeffa Sutherlanda.

Ideą pracy przyrostowej jest możliwość szybkiego przygotowania działających produktów o ograniczonej funkcjonalności w krótkim czasie i częstego zbierania informacji zwrotnej od Interesariuszy i użytkowników końcowych. Często otrzymywana informacja zwrotna umożliwia natychmiastową zmianę kierunku pracy i dostarczenie dokładnie tej funkcjonalności, która jest niezbędna z punktu widzenia Interesariuszy. Aby framework działał właściwie, należy wdrożyć wszystkie jego elementy. Scrum jest oparty na następujących wartościach:

• odwaga,
• poszanowanie,
• zaangażowanie,
• skupienie,
• otwartość,
• zaufanie.

Scrum Master

Jedna z trzech ról w Scrum, odpowiedzialna za wdrażanie frameworka Scrum oraz wspierająca Zespół Deweloperski. Dba o proces, pilnuje, by praca przebiegała sprawnie, usuwa przeszkody, chroni Zespół Deweloperski przed niepożądanym wpływem z zewnątrz i wspomaga go w samodoskonaleniu. W początkującym zespole ma rolę coacha, nauczyciela. Później powinien się wycofać, aby Zespół miał możliwość samemu zadbać o siebie. Scrum Master dba także o zrozumienie i promowanie idei Scrum w organizacji. Współpracuje z Product Ownerem i wspiera go w procesie zarządzania Backlogiem od strony technicznej. Pomaga w kontaktach z Interesariuszami. Z pojęciem Scrum Mastera wiąże się pojęcie Servant Leader (pl. Lider Służebny).

Self-organization (Samoorganizacja)

W zarządzaniu: zasada zakładająca, że zespoły samodzielnie organizują swoją pracę. Samoorganizacja nie jest tożsama z samowolą i anarchią, odbywa się w ramach i zgodnie z określonymi w organizacji celami. W wypadku Scrum, Zespoły same wybierają najlepszą metodę swojej pracy oraz metodę realizacji powierzonych zadań. W razie potrzeby Zespoły mogą zasięgać porad u zewnętrznych ekspertów, ale nie są kierowane przez osoby spoza Zespołu.

Cechy charakteryzujące samoorganizującego się Zespołu:

• Wspólne podejmowanie zobowiązania odnośnie zakresu realizowanej pracy,
• Wybór najlepszego sposobu realizacji pracy,
• Skupienie się na celu,
• Współpraca przy realizowaniu zadań,
• Wzajemna, jak również samodzielna kontrola (Inspekcja),
• Wzajemne wspieranie się i motywowanie.

Servant Leader (Lider Służebny)

Lider służący swojemu zespołowi i organizacji, odróżnia on kwestię przewodzenia i wydawania poleceń. Tych ostatnich Lider Służebny w zasadzie nie wydaje. Jego rolą jest przede wszystkim budowanie Zespołu i pomoc jego członkom w rozwoju, motywowanie ich, udzielanie wsparcia i usuwanie przeszkód uniemożliwiających osiągnięcie założonego celu.

SMART

Metoda wspomagająca właściwe skonstruowanie wykonalnego Celu Sprintu. W myśl tej metody cel powinien być:

• Specifc – specyficzny – co chcemy osiągnąć? (cel jest jasno sprecyzowany),
• Measurable – mierzalny – jakie warunki muszą być spełnione, aby cel został osiągnięty? (możliwe jest jednoznaczne określenie, czy cel został osiągnięty),
• Achievable – osiągalny – czy posiadamy wszystkie niezbędne zasoby? (dostępne są wszystkie zasoby niezbędne do realizacji celu)
• Relevant – istotny – czy to co chcemy osiągnąć jest wartościowe i potrzebne? (powinien nieść za sobą konkretną i wymaganą wartość biznesową),
• Time-bound – określony w czasie – kiedy chcemy osiągnąć cel? (określony jest ostateczny termin osiągnięcia celu).

Sprint

Określonej długości okres pracy, w trakcie którego powstaje ukończony i gotowy do wydania Przyrost produktu. W trakcie pracy nad produktem długość Sprintu pozostaje zazwyczaj niezmienna. Pojedynczy Sprint może trwać od tygodnia (krótsze są nieefektywne) do miesiąca (dłuższe powodują utratę podstawowej wartości Scrum, jaką jest częsta informacja zwrotna od Interesariuszy). Na początku Sprintu (podczas Planowania) Zespół Deweloperski wybiera spośród zadań umieszczonych w Backlogu Produktu te, które jest w stanie realizować i przenosi je do Backlogu Sprintu. W trakcie Sprintu mają miejsce określone spotkania: na początku – Planning, codziennie – Daily, zależnie od potrzeb – Refinement i na końcu Review oraz Retrospective. Po zakończeniu Sprintu od razu rozpoczyna się kolejny Sprint. Efektem Sprintu jest Przyrost.

Sprint Backlog (Backlog Sprintu, Rejestr Sprintu)

Jeden z trzech artefaktów Scruma. Lista zadań wybranych z Backlogu Produktu przez Zespół Deweloperski w trakcie planowania oraz opracowany przez Zespół Deweloperski plan ich dostarczenia, czyli zamiany w Przyrost. Obejmuje całą pracą jaką Zespół Deweloperski zamierza wykonać w czasie Sprintu. Backlog Sprintu jest własnością Zespołu Deweloperskiego i tylko jego członkowie mogą dokonywać w nim zmian. Nie jest sztywnym i zamkniętym tworem i podlega zmianom tak często jak jest to konieczne.

Sprint Goal (Cel Sprintu)

Jeden z elementów tworzonych w czasie Planowania. Założenia, jakie Zespół Scrumowy planuje osiągnąć jako efekt pracy w danym Sprincie. Cel sprintu pomaga Zespołowi Deweloperskiemu zrozumieć, w jakim celu tworzy Przyrost i jaką wartość biznesową w nim zawrze. Ułatwia pracę zespołową, daje wskazówki co do możliwości innego sposobu realizacji zadania i priorytetów w Sprincie. Nie wszystkie zadania realizowane w Sprincie muszą mieć związek z Celem Sprintu.

Sprint Retrospective (Retrospektywa Sprintu, Retro)

Jedno z 4 wydarzeń w Scrum odbywające się na koniec Sprintu, w którym uczestniczy cały Zespół Scrum’owy. Spotkanie prowadzące do usprawnienia i udoskonalenia procesu wytwarzania Przyrostu produktu. Ma ono na celu podsumować zakończony Sprint w odniesieniu do procesów, ludzi, relacji i narzędzi. Pozwala na uzyskanie zwrotnej informacji na temat stanu wdrażanych elementów Scruma i na ich podstawie wyciągnięcie wniosków pozwalających je ulepszyć. Zespół ma za zadanie przedyskutować to, co się wydarzyło i znaleźć dobre i słabe punkty, oraz zaplanować, co i jak postara się poprawić w kolejnym Sprincie. Innymi słowy Zespół Scrumowy przeprowadza Inspekcję swoich działań i opracowuje plan usprawnienia. Wydarzenie to jest ograniczone do maksymalnie 3 godzin.

Sprint Review (Przegląd Sprintu)

Jedno z 4 wydarzeń w Scrum (przedostatnie spotkanie w Sprincie), w którym uczestniczy cały Zespół Scrumowy oraz Interesariusze. W trakcie spotkania następuje Inspekcja Przyrostu oraz w razie potrzeby dostosowanie Backlogu. Głównym celem jest zebranie informacji zwrotnych na temat przedstawionego rozwiązania dla produktu oraz uzyskanie wskazówek co do kolejnych pożądanych funkcjonalności. Na podstawie tych danych zespół określa kierunek dalszych prac nad produktem, a Product Owner aktualizuje Backlog. Wydarzenie to jest ograniczone do maksymalnie 4 godzin.

Stakeholder (Interesariusz)

Wszystkie osoby i podmioty będące odbiorcą końcowego produktu, najczęściej mianem tym określani są klienci, użytkownicy końcowi, management czyli wszyscy mający wpływ na to, jak będzie wyglądał produkt, ci którzy go zamawiają i za niego płacą jak również ci, którzy będą go używać.

Story Point (SP; Punkty Historyjek)

Abstrakcyjne jednostki używane do szacowania stopnia skomplikowania zadań, które można łatwo zsumować w celu oszacowania wielkość wszystkich zadań. Wartości przyjmowane przez Story Pointy to zmodyfikowany ciąg Fibonacciego (1, 2, 3, 5, 8, 13, 20, 40). Kolejne wartości są celowo niemal dwukrotnie większe, gdyż w szacowaniu chodzi o wartość przybliżoną. Nie mają przełożenia na czas czy inne wartości, określają jedynie rozmiar pracy. Zespół Deweloperski potrzebuje kilku sprintów, aby nauczyć się poprawnie szacować stopień trudności zadań i zrozumieć, co oznacza dla niego trudność na poziomie np. 5. Ta wiedza jest nieprzekładalna na inny Zespół, w tym także ten sam Zespół po wymianie jednego czy dwóch deweloperów.

Team Cognitive Load (Obciążenie Poznawcze Zespołu)

Pojęcie to odnosi się do zdolności zespołu do przetwarzania i zarządzania informacjami oraz zadaniami, które są mu przypisane. Koncepcja ta pojawia się w kontekście zwinnego zarządzania zespołami, gdyż nadmierne obciążenie poznawcze może prowadzić do spadku efektywności i zwiększenia błędów. Matthew Skelton i Manuel Pais w swojej książce Team Topologies zwracają szczególną uwagę na konieczność zarządzania obciążeniem poznawczym, sugerując tworzenie zespołów o optymalnym poziomie wiedzy domenowej oraz wspieranie ich narzędziami i platformami, które minimalizują złożoność operacyjną.

Team of Teams (Zespół Zespołów)

Koncepcja wywodząca się z podejścia opisującego sposób pracy w dużych strukturach złożonych. Pochodząca z książki generała Stanleya McChrystala Team of Teams: New Rules of Engagement for a Complex World, idea ta zakłada, że organizacje powinny przejść od modelu hierarchicznego do modelu sieciowego, gdzie różne zespoły są samodzielne, ale jednocześnie skoordynowane. W Scrumie i Agile często jest to stosowane jako sposób organizacji wielozespołowej pracy nad jednym produktem lub w ramach jednego ART w SAFe.

Technical debt (Dług Technologiczny)

Przeszkody na drodze do osiągnięcia celu powstałe w wyniku szybkiego i nieoptymalnego zaspokajania potrzeb biznesowych. Stanowią ukryty koszt przyszłych prac, czyli tego, co jest konieczne do zrobienia zanim możliwe będzie wykonanie pracy bieżącej. Przykładowo, jeżeli puszki po napojach zamiast do śmietnika wyrzucamy pod drzwi serwerowni, to gdy zajdzie potrzeba dostania się do tego pomieszczenia niezbędne będzie usunięcie wszystkich puszek. Wyrzucanie puszek pod drzwi jest znacznie prostsze niż do np. daleko położonego śmietnika, ale w ten sposób zaciągamy dług technologiczny, który kiedyś w przyszłości trzeba będzie spłacić.

Timebox (Ramy Czasowe)

Ograniczenie czasu trwania wydarzenia, mające na celu motywację do sprawnego i efektywnego przeprowadzenia zaplanowanych działań i wyeliminowanie efektu opisywanego przez prawo Parkinsona – „praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie”. Wszystkie wydarzenia w Scrumie mają określone timeboxy :

• Planning – 8 godzin dla miesięcznego Sprintu, dla krótszych proporcjonalnie mniej,
• Daily – 15 minut,
• Review – 4 godziny dla miesięcznego Sprintu, dla krótszych proporcjonalnie mniej,
• Retrospektywa – 3 godziny dla miesięcznego Sprintu, dla krótszych proporcjonalnie mniej,
• Refinement – nie więcej niż 10% czasu dostępnego w Sprincie, nie wlicza się w to indywidualnej pracy PO nad Backlogiem.

User Story – (US; Historie Użytkownika)

Popularna w Agile metoda zapisywania wymagań biznesowych polegająca na opisaniu zamawianych funkcjonalności z perspektywy użytkownika końcowego.

Typowa postać US to:

• Jako… (nazwa określająca użytkownika, z naciskiem na jego rolę),
• Chcę… (wymaganie lub funkcja produktu),
• Aby… (określenie powodu lub celu wymagania, albo końcowego efektu, jaki ma zostać osiągnięty w jego wyniku).

Taka forma zapisu wymagań zawierająca potrzebę biznesową ułatwia Zespołowi Deweloperskiego zrozumienie realnej potrzeby użytkownika i opracowanie sposobu jego realizacji.

Value Stream Management (VSM)

Nowy trend w zarządzaniu strumieniami wartości, który zyskuje na znaczeniu w organizacjach stosujących DevOps i Agile na dużą skalę. VSM skupia się na zarządzaniu i optymalizacji przepływu wartości przez cały proces dostarczania oprogramowania. Celem jest zrozumienie, jak wszystkie elementy wytwarzania oprogramowania (od koncepcji do wdrożenia) współpracują, aby dostarczyć maksymalną wartość przy minimalizacji marnotrawstw. VSM staje się popularnym podejściem w organizacjach chcących zwiększyć efektywność i skrócić czas realizacji projektów.

Velocity (Prędkość)

Średnia ilość pracy, jaką Zespół Deweloperski wykonuje w trakcie jednego Sprintu. Liczone jest na koniec Sprintu przez zsumowanie jednostek, w jakich wyceniane były zadania wzięte do realizacji w Sprincie. Do średniej służącej wyliczeniu Prędkości Zespołu wliczane są wyłącznie zadania zakończone, czyli takie które spełniają Definition of Done.

Wartość Biznesowa (Business Value)

Jedno z kluczowych pojęć w Agile, które odnosi się do korzyści, jakie organizacja, zespół lub produkt dostarcza swoim interesariuszom oraz użytkownikom końcowym. Wartość Biznesowa stanowi miarę tego, jak dobrze zespół realizuje potrzeby klientów i odpowiada na ich oczekiwania, jednocześnie wspierając strategiczne cele firmy. W Agile Wartość Biznesowa jest punktem wyjścia do priorytetyzacji prac oraz wyznaczania kierunku rozwoju produktu.

Waterfall Model (Model Kaskadowy)

Jedna z najpopularniejszych klasycznych metod wytwarzania oprogramowania. Opisana pierwszy raz przez Winstona W. Royce’a w 1970 r. Zakłada występowanie kolejno po sobie poszczególnych faz projektu:

• planowanie,
• analiza,
• projekt,
• implementacja,
• testowanie,
• wdrożenie.

Przejście do następnej fazy następuje po zakończeniu prac w poprzedniej. Do kolejnego etapu pracy trafia komplet danych wytworzonych w poprzednim etapie na zasadzie przekazywania pałeczki w sztafecie. Minusem Waterfalla jest całkowita niepodatność na zmiany wymagań i założeń początkowych na kolejnych etapach produkcji. W przypadku zmiany wymagań co do produktu końcowego projekt powinien wrócić do etapu, którego dotyczą zmiany i cały proces powinien być powtórzony od tego momentu. Przy często pojawiających się zmianach i konieczności każdorazowego wracania do wcześniejszego etapu, koszt projektu znacząco wzrasta i praktycznie w nieskończoność wydłuża się czas prac.

Waterfall jest nieelastycznym modelem zarządzania, wykluczającym zaspokojenie zmiennych wymagań. Sprawdza się jednak dobrze w wypadku projektów, w których cały zakres prac jest znany od samego początku i nie podlega zmianom, oraz takich, które ze względu na swoją specyfikę nie mogą być budowane przyrostowo.

Agile

Nasi eksperci przeprowadzą zwinną transformację Twojej organizacji, co pozwoli Ci na szybsze wprowadzanie produktów na rynek i przyspieszy realizację projektów.

Oferta Agile

Podsumowanie

Agile charakteryzuje się różnorodnością metodyk, technik i możliwości, które wciąż są rozwijane i dodawane. Jeśli w powyższym słowniku nie udało ci się znaleźć odpowiedzi na nurtujące pytania, daj nam znać w komentarzu, chętnie pomożemy i wyjaśnimy wszelkie zawiłości Zwinnego Świata!

***
Na blogu znajdziesz więcej artykułów przygotowanych przez naszych ekspertów z obszaru Agile.

***

Artykuł zaktualizowany w 10.2024. Pierwsza publikacja: 13.01.2020.