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 kompletnie niezrozumiała 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. Jego 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 Manifesto (pl. 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).

Burn-down chart (pl. 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 (pl. 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) scrum’owych. Codzienne spotkanie Zespołu Deweloperskiego, odbywa się każdego dnia Sprintu, zazwyczaj w tym samym miejscu i o tej samej porze; zwane też stand up’em 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; pl. 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ża 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; pl. 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 (pl. 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; pl. 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).

Elements of Scrum (pl. 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 (pl. 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.

Increment (pl. 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 o rzeczywiste zużycie 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; pl. 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.

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.

Pillars of Scrum (pl. 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 (pl. 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 (pl. 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; pl. 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 (pl. 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 (pl. Wydanie)

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

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 Ken’a Schwaber’a i Jeff’a Sutherland’a.

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 (pl. 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 (pl. 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 Backlog’u Produktu te, które jest w stanie realizować i przenosi je do Backlog’u 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 (pl. Backlog Sprintu, Rejestr Sprintu)

Jeden z trzech artefaktów Scrum’a. Lista zadań wybranych z Backlog’u 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 (pl. Cel Sprintu)

Jeden z elementów tworzonych w czasie Planowania. Założenia jakie Zespół Scrum’owy 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 (pl. 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 Scrum’a 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ół Scrum’owy przeprowadza Inspekcję swoich działań i opracowuje plan usprawnienia. Wydarzenie to jest ograniczone do maksymalnie 3 godzin.

Sprint Review (pl. Przegląd Sprintu)

Jedno z 4 wydarzeń w Scrum (przedostatnie spotkanie w Sprincie), w którym uczestniczy cały Zespół Scrum’owy oraz Interesariusze. W trakcie spotkania następuje Inspekcja Przyrostu oraz w razie potrzeby dostosowanie Backlog’u. 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 (pl. 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; pl. 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.

Technical debt (pl. 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 (pl. 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 Scrum’ie mają określone timebox’y :

• 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 Backlog’iem

User Story – (US; pl. 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.

Velocity (pl. 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.

Waterfall Model (pl. 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 Waterfall’a 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 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.