Co robi w pracy Scrum Master? Jak wyt\u0142umaczy\u0107 t\u0119 i wiele innych kwestii komu\u015b, kto nigdy nie zetkn\u0105\u0142 si\u0119 z ide\u0105 Agile? Pe\u0142na definicja ze wszystkimi odniesieniami b\u0119dzie zupe\u0142nie niezrozumia\u0142a, wi\u0119c zdecydowanie nie trzeba startowa\u0107 od zera i obja\u015bnia\u0107 wszystkiego. Wszystko da si\u0119 \u0142adnie upro\u015bci\u0107.<\/p>\n\n\n\n
Mistrz m\u0142yna to kto\u015b, kto zwinnie przeskakuje wodospady. To mocno niepe\u0142na, ale formalnie poprawna definicja opisuj\u0105ca, na czym polega praca Scrum Mastera. Jest niejasna dla os\u00f3b postronnych i dobrze sprawdza si\u0119 w trakcie rodzinnych sp\u0119d\u00f3w, powstrzymuj\u0105c kolejne pytania. W innych okoliczno\u015bciach zdecydowanie lepiej spr\u00f3bowa\u0107 rozwia\u0107 w\u0105tpliwo\u015bci pytaj\u0105cego w zrozumia\u0142y dla niego spos\u00f3b.<\/p>\n\n\n\n
Niniejszy s\u0142owniczek powsta\u0142 jako pomoc w \u0142atwym zorientowaniu si\u0119, o co chodzi w Agile i Scrum dla tych, kt\u00f3rzy do tej pory nie mieli wcale lub prawie wcale do czynienia z t\u0105 tematyk\u0105. Z tego powodu niekt\u00f3re sformu\u0142owania i u\u017cywane s\u0142ownictwo mog\u0105 wzbudza\u0107 kontrowersje w\u015br\u00f3d zaawansowanych praktyk\u00f3w lub\/i ortodoks\u00f3w tematyki. Uproszczone i niewyczerpuj\u0105ce tematu definicje zastosowano celowo, aby nie stwarza\u0107 dodatkowej bariery przez opisywanie niezrozumia\u0142ych poj\u0119\u0107 za pomoc\u0105 innych niezrozumia\u0142ych poj\u0119\u0107.<\/strong><\/p>\n\n\n\n Do pe\u0142nego zrozumienia danego terminu niekiedy trzeba b\u0119dzie przejrze\u0107 dwie, trzy dodatkowe definicje lub wr\u0119cz przeczyta\u0107 wszystko, zastanowi\u0107 si\u0119, a potem przeczyta\u0107 jeszcze raz, zwracaj\u0105c uwag\u0119 na fragmenty, kt\u00f3re umkn\u0119\u0142y lub by\u0142y niezrozumia\u0142e przy pierwszym podej\u015bciu. Dok\u0142adnie tak, jak z instrukcj\u0105 obs\u0142ugi dowolnego urz\u0105dzenia. Nie jest to trudne, a do tego mo\u017cna to robi\u0107 na raty (czyli jak na Agile przysta\u0142o \u2013 w modelu iteracyjnym).<\/p>\n\n\n\n Spos\u00f3b my\u015blenia i pracy zgodny z za\u0142o\u017ceniami Manifestu Agile. W uj\u0119ciu projektowym, wsp\u00f3lne okre\u015blenie zwinnych metod wytwarzania oprogramowania opartych o model iteracyjno-przyrostowy. Skupia si\u0119 na dostarczaniu produktu w spos\u00f3b ci\u0105g\u0142y przy silnym zaanga\u017cowaniu klienta w proces. W za\u0142o\u017ceniu zespo\u0142y pracuj\u0105 zwinnie, czyli szybko i elastycznie dopasowuj\u0105 si\u0119 do zmieniaj\u0105cych si\u0119 wymaga\u0144 klienta i warunk\u00f3w zewn\u0119trznych. Polecany przy projektach posiadaj\u0105cych niestabilne wymagania i brak jasnej, konkretnej i niezmiennej wizji produktu ko\u0144cowego. Umo\u017cliwia rozpocz\u0119cie dzia\u0142ania bez kompletu szczeg\u00f3\u0142owych wymaga\u0144 oraz dopuszcza mo\u017cliwo\u015b\u0107 ich zmiany bez konieczno\u015bci zaczynania pracy od nowa. Jego g\u0142\u00f3wnym celem jest podniesienie jako\u015bci produktu (rozumianej jako zadowolenie klienta oraz stopie\u0144 dopracowania produktu) tak, by odpowiada\u0142 realnym potrzebom klienta, a nie tylko pocz\u0105tkowym wymaganiom.<\/p>\n\n\n\n Osoba edukuj\u0105ca innych, czym jest Agile. G\u0142\u00f3wn\u0105 rol\u0105 jest zazwyczaj wspieranie organizacji w transformacji zwinnej oraz praca z jej cz\u0119\u015bci\u0105 biznesow\u0105 na poziomie kadry zarz\u0105dzaj\u0105cej wy\u017cszego szczebla. Mi\u0119dzy Scrum Masterem a Agile Coachem<\/a> granica jest p\u0142ynna, ale podstawowym wymogiem, aby Scrum Master zosta\u0142 Agile Coachem, jest do\u015bwiadczenie nie tylko w pracy z zespo\u0142em, ale te\u017c z ca\u0142\u0105 organizacj\u0105. Nie decyduje o sposobie i metodach wprowadzania filozofii Agile w organizacji, a skupia si\u0119 na edukacji, celem wspierania organizacji we wprowadzaniu oraz utrzymywaniu zwinno\u015bci, rozumieniu i stosowaniu obranej metodyki.<\/p>\n\n\n\n Model opisuj\u0105cy stopie\u0144 dojrza\u0142o\u015bci i efektywno\u015bci zespo\u0142\u00f3w zwinnych. Stworzony przez Jamesa Shore\u2019a i Diany Larsen, Agile Fluency Model okre\u015bla cztery poziomy p\u0142ynno\u015bci (Fluency Levels): Focusing, Delivering, Optimizing, Strengthening. Ka\u017cdy poziom opisuje stopie\u0144, w jakim zesp\u00f3\u0142 przyswoi\u0142 zasady i praktyki Agile, i jakie korzy\u015bci z tego wynikaj\u0105 dla organizacji. Model ten jest u\u017cywany przez Scrum Master\u00f3w i Agile Coach\u00f3w do oceny post\u0119p\u00f3w zespo\u0142u i planowania jego dalszego rozwoju.<\/p>\n\n\n\n Dokument opracowany w 2001 roku przez 17 praktyk\u00f3w tzw. lekkich metod (m. in. Scrum, XP, DSDM, FDD, CC) opisuj\u0105cy wsp\u00f3lne podstawy i za\u0142o\u017cenia tych metod oraz podkre\u015blaj\u0105cy warto\u015bci na jakich si\u0119 opieraj\u0105. Przy okazji opracowywania Manifestu Agile<\/a> zmieniono nazewnictwo i zamiast \u201cmetod lekkich\u201d pojawi\u0142y si\u0119 \u201czwinne\u201d (agile). <\/p>\n\n\n\n To narz\u0119dzie s\u0142u\u017c\u0105ce do oceny stopnia dojrza\u0142o\u015bci organizacji, zespo\u0142u lub jednostki w kontek\u015bcie pracy zwinnej. Umo\u017cliwia ocen\u0119, na ile dana jednostka w pe\u0142ni wdro\u017cy\u0142a zasady Agile, a tak\u017ce identyfikacj\u0119 obszar\u00f3w wymagaj\u0105cych usprawnie\u0144. Cz\u0119sto sk\u0142ada si\u0119 z kilku poziom\u00f3w (np. Pocz\u0105tkuj\u0105cy, \u015aredniozaawansowany, Zaawansowany), z kt\u00f3rych ka\u017cdy definiuje konkretne kryteria zwi\u0105zane z adaptacj\u0105 i przestrzeganiem zasad Agile, takich jak samoorganizacja, ci\u0105g\u0142e doskonalenie, adaptacja do zmieniaj\u0105cych si\u0119 warunk\u00f3w i stosowanie praktyk zwinnych.<\/p>\n\n\n\n Zesp\u00f3\u0142 pracuj\u0105cy opieraj\u0105c si\u0119 na zasadacg Agile, kt\u00f3ry charakteryzuje si\u0119 samoorganizacj\u0105, wysokim poziomem autonomii oraz wsp\u00f3\u0142odpowiedzialno\u015bci\u0105 za wynik ko\u0144cowy. Zespo\u0142y Agile cz\u0119sto sk\u0142adaj\u0105 si\u0119 z os\u00f3b posiadaj\u0105cych r\u00f3\u017cnorodne kompetencje (wielofunkcyjne), kt\u00f3re wsp\u00f3lnie d\u0105\u017c\u0105 do osi\u0105gni\u0119cia okre\u015blonych cel\u00f3w biznesowych. Cech\u0105 charakterystyczn\u0105 zespo\u0142\u00f3w Agile jest r\u00f3wnie\u017c regularna inspekcja i adaptacja sposobu pracy, tak aby proces i produkt by\u0142y dostosowywane do zmieniaj\u0105cych si\u0119 potrzeb interesariuszy.<\/p>\n\n\n\n Podej\u015bcie do wytwarzania oprogramowania, kt\u00f3re k\u0142adzie nacisk na definiowanie zachowania systemu z perspektywy u\u017cytkownika. BDD pomaga zespo\u0142om zrozumie\u0107 wymagania biznesowe i tworzy\u0107 specyfikacje w j\u0119zyku zrozumia\u0142ym zar\u00f3wno dla deweloper\u00f3w jak i interesariuszy. Jest cz\u0119sto stosowane jako rozszerzenie Test-Driven Development (TDD).<\/p>\n\n\n\n Spos\u00f3b wizualizacji, w formie wykresu, czasu i pracy pozosta\u0142ych do wykonania w danym Sprincie\/projekcie. Pionowa o\u015b wykresu to mierzalny zakres pracy (np. Story Pointy), pozioma o\u015b to czas (np. w dniach). Na wykresie zazwyczaj znajduje si\u0119 linia warto\u015bci u\u015brednionych przedstawiaj\u0105ca idealny, liniowy spadek pozosta\u0142ej do wykonania pracy. Wykres obrazuje tempo realizacji zada\u0144 w danym Sprincie, a linia idealna pokazuje w jakim tempie Zesp\u00f3\u0142 powinien pracowa\u0107, aby uko\u0144czy\u0107 za\u0142o\u017cone zadania.<\/p>\n\n\n\n Spos\u00f3b wizualizacji pracy i czasu pozosta\u0142ych do wykonania w danym Sprincie\/projekcie, w formie wykresu. Cz\u0119\u015bciej stosowany w przypadku projektu ni\u017c Sprintu. Pionowa o\u015b wykresu to mierzalny zakres pracy (np. Story Pointy), pozioma o\u015b to czas (np. iteracje). Na wykresie znajduje si\u0119 linia przedstawiaj\u0105ca zmiany w zakresie pracy (zmiana ilo\u015bci Story Point), druga linia wskazuje, ile pracy zosta\u0142o wykonane w poszczeg\u00f3lnych iteracjach. Wykres obrazuje w jakim estymowanym czasie przy bie\u017c\u0105cym tempie, prace dla wycenionych SP zostan\u0105 uko\u0144czone. Jest to mo\u017cliwe poprzez u\u015brednienie i przed\u0142u\u017cenie linii wykonanej pracy.<\/p>\n\n\n\n Estymowana praca mo\u017cliwa do wykonania przez dany Zesp\u00f3\u0142 w trakcie Sprintu. Zawsze odnosi si\u0119 do konkretnego Zespo\u0142u. Ca\u0142kowicie zale\u017cna od nieobecno\u015bci deweloper\u00f3w oraz ich zaanga\u017cowania w inne zadania. Mo\u017cliwa do okre\u015blenia na podstawie Velocity, Load oraz dost\u0119pno\u015bci poszczeg\u00f3lnych deweloper\u00f3w.<\/p>\n\n\n\n Jedno z wydarze\u0144 (ceremonii) scrumowych. Codzienne spotkanie Zespo\u0142u Deweloperskiego, odbywa si\u0119 ka\u017cdego dnia Sprintu, zazwyczaj w tym samym miejscu i o tej samej porze; zwane te\u017c stand upem z racji tego, \u017ce cz\u0119sto odbywa si\u0119 na stoj\u0105co. Czasowo ograniczony jest do 15 minut. S\u0142u\u017cy koordynacji prac na okres do nast\u0119pnego Daily, okre\u015bleniu czy istniej\u0105 problemy zagra\u017caj\u0105ce realizacji Celu Sprintu oraz sprecyzowaniu, co Zesp\u00f3\u0142 Deweloperski zamierza zrobi\u0107, aby zrealizowa\u0107 Celu Sprintu.<\/p>\n\n\n\n L<\/span>ista kryteri\u00f3w, jakie musi spe\u0142nia\u0107 ka\u017cde pojedyncze zadanie, nad kt\u00f3rym Zesp\u00f3\u0142 Deweloperski pracuje w trakcie Sprintu, po spe\u0142nieniu kt\u00f3rych wszystkie strony procesu uznaj\u0105 zadanie za zako\u0144czone. Jest tworzona w oparciu o standardy obowi\u0105zuj\u0105ce w organizacji lub w przypadku ich braku – przez Zesp\u00f3\u0142 Deweloperski. Mo\u017ce by\u0107 dyskutowana i zmieniana przez Zesp\u00f3\u0142 w trakcie Retrospektywy. Zazwyczaj im dojrzalszy Zesp\u00f3\u0142, tym bardziej rozbudowana jest DoD. Istnienie listy z jasno sprecyzowanymi wymaganiami zapewnia, \u017ce wszyscy uczestnicy procesu wiedz\u0105 co oznacza stwierdzenie, \u017ce dane zadanie jest sko\u0144czone i nie ma miejsca sytuacja, w kt\u00f3rej nast\u0119puje rozbie\u017cno\u015b\u0107 pomi\u0119dzy tym, co uwa\u017ca za sko\u0144czone Zesp\u00f3\u0142 Deweloperski, a tym, co za sko\u0144czone uwa\u017caj\u0105 Product Owner i Interesariusze. Stan uko\u0144czenia zadania jest zero-jedynkowy. Nie istniej\u0105 zadania cz\u0119\u015bciowo sko\u0144czone. W wypadku, gdy nad projektem pracuje kilka zespo\u0142\u00f3w, wszystkie powinny mie\u0107 t\u0105 sam\u0105 Definicj\u0119 Uko\u0144czenia.<\/p>\n\n\n\n L<\/span>ista kryteri\u00f3w, jakie musi spe\u0142nia\u0107 ka\u017cde pojedyncze zadanie w Backlogu, aby Zesp\u00f3\u0142 Deweloperski m\u00f3g\u0142 je realizowa\u0107 podczas Sprintu. DoR jest tworzona przez Product Ownera i ulepszana z Zespo\u0142em Deweloperskim w trakcie Retrospektywy. W przypadku Definicji Gotowo\u015bci \u201egotowy\u201d nie oznacza, \u017ce zadania w Backlogu musz\u0105 by\u0107 w 100% zdefiniowane, musz\u0105 by\u0107 \u201ewystarczaj\u0105co gotowe\u201d, aby Zesp\u00f3\u0142 Deweloperski by\u0142 przekonany, \u017ce mo\u017ce z powodzeniem przyst\u0105pi\u0107 do realizacji zadania, rozumie ryzyko biznesowe i cel klienta.<\/p>\n\n\n\n F<\/span>izyczne umiejscowienie produktu w wyznaczonym przez klienta \u015brodowisku (np. produkcyjnym).<\/p>\n\n\n\n M<\/span>etoda tw\u00f3rczego rozwi\u0105zywania problem\u00f3w, zdefiniowana po raz pierwszy na Uniwersytecie Stanforda w USA w latach 60. Zak\u0142ada, \u017ce celem jest dostarczenie innowacyjnych, dopasowanych do oczekiwa\u0144 ko\u0144cowego odbiorcy, rozwi\u0105za\u0144 poprzez wykorzystywanie metod pracy pobudzaj\u0105cych kreatywno\u015b\u0107. Metoda ta skupia si\u0119 na u\u017cytkowniku<\/a> i zrozumieniu jego potrzeb. To w\u0142a\u015bnie te realne potrzeby, nie za\u015b za\u0142o\u017cenia tworzone na podstawie wyobra\u017ce\u0144 o u\u017cytkowniku s\u0105 punktem wyj\u015bcia do pracy nad produktem. Proces tw\u00f3rczy podzielony jest na kilka etap\u00f3w:<\/p>\n\n\n\n J<\/span>edna z trzech r\u00f3l w Scrumie, grupa profesjonalist\u00f3w – od 3 do 9 os\u00f3b – kt\u00f3ra wsp\u00f3lnie posiada wystarczaj\u0105ce kompetencje do wytworzenia Przyrostu produktu. Liczebno\u015b\u0107 zespo\u0142u jest ograniczona ze wzgl\u0119du na stopie\u0144 komplikacji komunikacji w wi\u0119kszych grupach i zbyt ma\u0142\u0105 produktywno\u015b\u0107 w mniejszych grupach. W Zespole nie ma podzia\u0142u na role (tester, frontend dev, backend dev itp.) \u2013 wszyscy s\u0105 nazywani deweloperami (zwi\u0105zane jest to z kwesti\u0105 wsp\u00f3lnej odpowiedzialno\u015bci zespo\u0142u), ale to nie znaczy, \u017ce wszyscy musz\u0105 mie\u0107 kompetencje programistyczne. Zesp\u00f3\u0142 Deweloperski ma bardzo du\u017c\u0105 autonomi\u0119 i sam okre\u015bla, co robi i w jaki spos\u00f3b. Nikt nie narzuca Zespo\u0142owi sposobu, w jaki praca zostanie wykonana (wyj\u0105tkiem s\u0105 og\u00f3lne regu\u0142y organizacji). Zesp\u00f3\u0142 w ca\u0142o\u015bci ponosi odpowiedzialno\u015b\u0107 za wykonan\u0105 prac\u0119.<\/p>\n\n\n\n Skr\u00f3t od Development and Operations. Osoba \u0142\u0105cz\u0105ca w sobie kompetencje dewelopera i wdro\u017ceniowca lub osoby odpowiedzialnej za utrzymanie programu\/systemu. Niekiedy dodaje si\u0119 tak\u017ce do tego kompetencje zwi\u0105zane z testowaniem lub bezpiecze\u0144stwem (ang.<\/em> DevSecOps<\/em>). W klasycznym uk\u0142adzie te kompetencje nale\u017c\u0105 do r\u00f3\u017cnych os\u00f3b lub zespo\u0142\u00f3w. Mo\u017ce te\u017c oznacza\u0107 rodzaj kultury w skali ca\u0142ej organizacji. Wymaga to po\u0142\u0105czenia obszar\u00f3w, kt\u00f3re w firmach zazwyczaj funkcjonuj\u0105 oddzielnie: zespo\u0142u rozwijaj\u0105cego oprogramowanie (Dev) oraz zespo\u0142u operacji (Ops).<\/p>\n\n\n\n Metoda pracy, w kt\u00f3rej zesp\u00f3\u0142 jest podzielony na dwie \u015bcie\u017cki: Discovery (odkrywanie) i Delivery (dostarczenie). Discovery polega na badaniu i weryfikacji hipotez, testowaniu rozwi\u0105za\u0144 z u\u017cytkownikami, iteracyjnym projektowaniu i doprecyzowaniu wymaga\u0144. Delivery to w\u0142a\u015bciwa praca deweloperska, w ramach kt\u00f3rej zatwierdzone funkcje s\u0105 rozwijane i wdra\u017cane do produktu. Dual-Track Agile pozwala zespo\u0142om na jednoczesne eksperymentowanie i szybkie dostarczanie warto\u015bci.<\/p>\n\n\n\n W<\/span>szystkie sk\u0142adowe frameworku Scrum. Brak jednego elementu z poni\u017cszej listy wyklucza mo\u017cliwo\u015b\u0107 pracy w Scrum:<\/p>\n\n\n\n D<\/span>oktryna filozoficzna o nazwie pochodz\u0105cej od starogreckiego s\u0142owa oznaczaj\u0105cego do\u015bwiadczenie. G\u0142osi, \u017ce \u017ar\u00f3d\u0142em poznania s\u0105 bod\u017ace zmys\u0142owe docieraj\u0105ce do cz\u0142owieka, a wiedza wynika z do\u015bwiadczania i podejmowania decyzji w oparciu o to, co zosta\u0142o poznane. W zarz\u0105dzaniu projektami oznacza to, \u017ce wszelkie decyzje powinny by\u0107 oparte na obserwacji i do\u015bwiadczeniu.<\/p>\n\n\n\n Koncepcja ta koncentruje si\u0119 na mierzeniu efektywno\u015bci przep\u0142ywu pracy i identyfikacji w\u0105skich garde\u0142 w procesie dostarczania warto\u015bci. Metryki przep\u0142ywu, takie jak Flow Velocity<\/em>, Flow Efficiency<\/em>, Flow Load<\/em>, czy Flow Time<\/em>, pomagaj\u0105 zrozumie\u0107, w jaki spos\u00f3b zadania przep\u0142ywaj\u0105 przez zesp\u00f3\u0142 oraz gdzie wyst\u0119puj\u0105 przestoje. Flow Metrics s\u0105 stosowane w ramach podej\u015bcia Flow Framework\u2122<\/em>, stworzonego przez Mike\u2019a Kerstena, aby zarz\u0105dza\u0107 przep\u0142ywem pracy na poziomie organizacji.<\/p>\n\n\n\n W<\/span>szystkie zadania i elementy z Backlogu uko\u0144czone w trakcie Sprintu oraz wszystkie zadania z Backlogu uko\u0144czone w trakcie poprzednich Sprint\u00f3w. Ka\u017cdy Sprint powinien zako\u0144czy\u0107 si\u0119 stworzeniem dzia\u0142aj\u0105cego fragmentu oprogramowania\/produktu mo\u017cliwego do pokazania Interesariuszom. W pierwszym Sprincie powstaje pierwszy fragment, w ka\u017cdym kolejnym zostaje dobudowany do niego kolejny, a suma tych fragment\u00f3w tworzy Przyrost produktu.<\/p>\n\n\n\n M<\/span>etoda okre\u015blania poprawno\u015bci konstrukcji User Story. W my\u015bl tej metody US powinny by\u0107:<\/p>\n\n\n\n M<\/span>etoda stosowana w procesach wytw\u00f3rczych, w kt\u00f3rych produkcja jest uzale\u017cniona od zam\u00f3wie\u0144 odbiorc\u00f3w (nie za\u015b od planu produkcji), oparta na rzeczywistym zu\u017cyciu materia\u0142\u00f3w. Opracowana zosta\u0142a w latach ’40. XX w. na potrzeby system\u00f3w produkcyjnych Toyoty. Zapewnia ci\u0105g\u0142o\u015b\u0107 produkcyjn\u0105 przy za\u0142o\u017ceniu nieustannej optymalizacji procesu. Najbardziej efektywna jest w przypadku proces\u00f3w ci\u0105g\u0142ych, kt\u00f3rych nie da si\u0119 wygodnie i naturalnie podzieli\u0107 na iteracje, np. praca przy obs\u0142udze help-desku. Jednym z charakterystycznych element\u00f3w jest wska\u017anik Work In Progress Limit, czyli ograniczenie zada\u0144, kt\u00f3re mog\u0105 by\u0107 otwarte na jednym stanowisku.<\/p>\n\n\n\n W procesach wytwarzania oprogramowania Kanban mo\u017cna sprowadzi\u0107 do trzech zasad:<\/p>\n\n\n\n Manifestacj\u0105 metody Kanban w IT jest tablica kanbanowa, na kt\u00f3rej zaznaczany jest przep\u0142yw zada\u0144. Istot\u0105 tablicy Kanban jest oznaczenie limit\u00f3w prac w toku na ka\u017cdym etapie wytw\u00f3rczym.<\/p>\n\n\n\n S<\/span>trategia dostarczania produkt\u00f3w zgodnych z oczekiwaniami w najprostszy z mo\u017cliwych sposob\u00f3w, przy za\u0142o\u017ceniu, \u017ce nie mo\u017ce si\u0119 to odbywa\u0107 kosztem za\u0142ogi, oraz przy nastawieniu na maksymaln\u0105 likwidacj\u0119 wszelkich marnotrawstw. Poprzez optymalizacj\u0119 d\u0105\u017cy si\u0119 do zu\u017cywania jak najmniejszej ilo\u015bci zasob\u00f3w – czasu, wysi\u0142ku, pieni\u0119dzy, przestrzeni produkcyjnej, narz\u0119dzi, etc. Usuwane s\u0105 wszystkie elementy, kt\u00f3re nie s\u0105 niezb\u0119dne do wykonania produktu o za\u0142o\u017conej jako\u015bci. Jednocze\u015bnie minimalizuje si\u0119 zapasy preferuj\u0105c dostawy dok\u0142adnie na czas i takie projektowanie system\u00f3w, kt\u00f3re umo\u017cliwia szybkie wykrywanie b\u0142\u0119d\u00f3w.<\/p>\n\n\n\n Framework do skalowania Scrum w du\u017cych organizacjach, stworzony przez Craiga Larmana i Basa Vodde. LeSS opiera si\u0119 na zasadach Scrum i stosuje je do pracy wielu zespo\u0142\u00f3w nad jednym produktem. W LeSS k\u0142adzie si\u0119 nacisk na uproszczenie struktury organizacyjnej, a tak\u017ce minimalizacj\u0119 z\u0142o\u017cono\u015bci w komunikacji mi\u0119dzy zespo\u0142ami. LeSS definiuje r\u00f3\u017cne role, takie jak Area Product Owner, i zapewnia wytyczne dotycz\u0105ce pracy w \u015brodowisku wielozespo\u0142owym.<\/p>\n\n\n\n I<\/span>lo\u015b\u0107 pracy, jak\u0105 Zesp\u00f3\u0142 Deweloperski zamierza dostarczy\u0107 w trakcie sprintu. Jest okre\u015blane przez Zesp\u00f3\u0142 Deweloperski na podstawie Capacity oraz zakresu Backlogu Sprintu.<\/p>\n\n\n\n Metryki w Agile to mierniki, kt\u00f3re pomagaj\u0105 zespo\u0142om i interesariuszom \u015bledzi\u0107 post\u0119p, mierzy\u0107 efektywno\u015b\u0107 oraz ocenia\u0107 jako\u015b\u0107 dostarczanego produktu. Stanowi\u0105 one podstaw\u0119 do podejmowania decyzji, planowania oraz identyfikacji obszar\u00f3w wymagaj\u0105cych usprawnie\u0144. Odpowiednio dobrane metryki wspieraj\u0105 transparentno\u015b\u0107 i umo\u017cliwiaj\u0105 zrozumienie, jak zespo\u0142y radz\u0105 sobie z realizacj\u0105 cel\u00f3w.<\/p>\n\n\n\n Najprostsza wersja produktu, kt\u00f3ra spe\u0142nia podstawowe wymagania u\u017cytkownik\u00f3w i umo\u017cliwia zebranie maksymalnej ilo\u015bci wiedzy o ich potrzebach przy minimalnym nak\u0142adzie pracy. MVP pozwala na szybkie przetestowanie hipotez i weryfikacj\u0119 warto\u015bci rynkowej produktu przed dalszym inwestowaniem w jego rozw\u00f3j. Celem jest jak najszybsze zbudowanie produktu, kt\u00f3ry b\u0119dzie na tyle funkcjonalny, aby u\u017cytkownicy mogli rozpocz\u0105\u0107 interakcj\u0119 z nim i przekaza\u0107 swoje opinie.<\/p>\n\n\n\n Pr\u0119dko\u015b\u0107 zespo\u0142u to miara ilo\u015bci pracy (najcz\u0119\u015bciej wyra\u017cana w Story Pointach lub liczbie uko\u0144czonych zada\u0144), jak\u0105 zesp\u00f3\u0142 jest w stanie wykona\u0107 w trakcie jednego Sprintu. Jest wyliczana przez zsumowanie Story Point\u00f3w wszystkich zako\u0144czonych zada\u0144 z Backlogu Sprintu. Velocity pomaga zespo\u0142owi zrozumie\u0107 swoje tempo pracy i przewidywa\u0107, ile pracy b\u0119dzie w stanie zrealizowa\u0107 w przysz\u0142ych Sprintach. Pr\u0119dko\u015b\u0107 jest r\u00f3wnie\u017c przydatna w planowaniu d\u0142ugoterminowym.<\/p>\n\n\n\n Wizualne narz\u0119dzie, kt\u00f3re pokazuje, ile pracy pozosta\u0142o do wykonania w danym Sprincie lub projekcie w stosunku do up\u0142ywaj\u0105cego czasu. Na wykresie zobrazowana jest linia rzeczywistego spalania oraz linia idealna, kt\u00f3ra wskazuje tempo, w jakim zesp\u00f3\u0142 powinien realizowa\u0107 zadania, aby zako\u0144czy\u0107 prace na czas. Burn-down Chart pozwala monitorowa\u0107 post\u0119p prac i szybko identyfikowa\u0107 potencjalne op\u00f3\u017anienia.<\/p>\n\n\n\n Alternatywa dla Burn-down Chart. Burn-up Chart ilustruje, ile pracy zosta\u0142o ju\u017c uko\u0144czone w stosunku do ca\u0142kowitego zakresu projektu, a tak\u017ce pozwala \u015bledzi\u0107 zmiany w zakresie prac (je\u015bli projekt rozszerza si\u0119 o nowe wymagania). Dzi\u0119ki temu lepiej obrazuje wp\u0142yw zmieniaj\u0105cych si\u0119 wymaga\u0144 na post\u0119p prac.<\/p>\n\n\n\n Lead Time to czas od momentu, gdy zadanie trafi do Backlogu do momentu, gdy zostanie uko\u0144czone. Mierzy ca\u0142y cykl \u017cycia zadania, w tym czas oczekiwania i realizacji. Wysoki Lead Time mo\u017ce wskazywa\u0107 na w\u0105skie gard\u0142a w procesie, kt\u00f3re op\u00f3\u017aniaj\u0105 dostarczanie warto\u015bci. Jest istotnym wska\u017anikiem w zarz\u0105dzaniu przep\u0142ywem pracy i optymalizacji procesu.<\/p>\n\n\n\n Mierzy czas od momentu, gdy zesp\u00f3\u0142 zaczyna pracowa\u0107 nad zadaniem (czyli trafi do kolumny \u201eW trakcie\u201d w tablicy Kanban), a\u017c do chwili jego uko\u0144czenia. Cycle Time pozwala zespo\u0142owi lepiej zrozumie\u0107, ile czasu rzeczywi\u015bcie zajmuje realizacja poszczeg\u00f3lnych zada\u0144 i identyfikowa\u0107 obszary, w kt\u00f3rych proces mo\u017ce by\u0107 usprawniony.<\/p>\n\n\n\n Diagram przedstawiaj\u0105cy stan wszystkich zada\u0144 w procesie wytwarzania oprogramowania, w podziale na poszczeg\u00f3lne fazy (np. Do zrobienia, W trakcie, Uko\u0144czone). Pozwala na \u015bledzenie przep\u0142ywu pracy w d\u0142u\u017cszym okresie i identyfikacj\u0119 w\u0105skich garde\u0142 w procesie. Wzrost liczby zada\u0144 w jednym z etap\u00f3w wskazuje na kumulacj\u0119 prac, kt\u00f3re mog\u0105 op\u00f3\u017ania\u0107 dostarczanie warto\u015bci.<\/p>\n\n\n\n Liczba zada\u0144, nad kt\u00f3rymi zesp\u00f3\u0142 pracuje r\u00f3wnocze\u015bnie. Limit WIP jest stosowany w metodzie Kanban i pomaga zespo\u0142om unikn\u0105\u0107 przeci\u0105\u017cenia prac\u0105 oraz skupi\u0107 si\u0119 na doka\u0144czaniu zada\u0144, a nie rozpoczynaniu nowych. Obni\u017cenie liczby WIP zazwyczaj prowadzi do skr\u00f3cenia Cycle Time i zwi\u0119kszenia efektywno\u015bci zespo\u0142u.<\/p>\n\n\n\n Wska\u017anik jako\u015bci, kt\u00f3ry mierzy liczb\u0119 b\u0142\u0119d\u00f3w wykrytych w oprogramowaniu na jednostk\u0119 (np. na 1000 linii kodu lub na funkcjonalno\u015b\u0107). Pomaga zespo\u0142owi oceni\u0107, jak cz\u0119sto wprowadzane s\u0105 b\u0142\u0119dy i w kt\u00f3rych obszarach produktu mog\u0105 wyst\u0119powa\u0107 problemy z jako\u015bci\u0105.<\/p>\n\n\n\n Metryka u\u017cywana do pomiaru satysfakcji klienta i lojalno\u015bci u\u017cytkownik\u00f3w ko\u0144cowych. NPS jest obliczany na podstawie pytania: \u201eNa ile prawdopodobne jest, \u017ce poleci\u0142by\u015b nasz produkt innym?\u201d i pomaga zespo\u0142owi zrozumie\u0107, jak produkt postrzegany jest przez jego u\u017cytkownik\u00f3w oraz czy dostarczona warto\u015b\u0107 spe\u0142nia ich oczekiwania.<\/p>\n\n\n\n Liczba b\u0142\u0119d\u00f3w, kt\u00f3re zosta\u0142y wykryte po wdro\u017ceniu oprogramowania na \u015brodowisko produkcyjne. Przeoczone b\u0142\u0119dy wskazuj\u0105 na obszary, gdzie nale\u017cy poprawi\u0107 jako\u015b\u0107 procesu testowania i weryfikacji, aby zapobiec wprowadzaniu defekt\u00f3w do produkcji.<\/p>\n\n\n\n Mierzy og\u00f3lne zadowolenie klient\u00f3w z danego produktu lub us\u0142ugi. Cz\u0119sto stosowany w formie ankiety, w kt\u00f3rej u\u017cytkownicy ko\u0144cowi oceniaj\u0105 swoje do\u015bwiadczenie w skali od 1 do 5 (gdzie 5 oznacza \u201ebardzo zadowolony\u201d). CSAT jest kluczowym wska\u017anikiem weryfikuj\u0105cym, czy dostarczona warto\u015b\u0107 odpowiada na potrzeby klienta.<\/p>\n\n\n\n Metryka stosowana w celu oceny poziomu satysfakcji cz\u0142onk\u00f3w zespo\u0142u. Zesp\u00f3\u0142 ocenia swoje zadowolenie z pracy w skali (np. 1-5) i omawia wyniki podczas Retrospektywy. Team Happiness pomaga zrozumie\u0107, jakie aspekty pracy zesp\u00f3\u0142 ocenia pozytywnie, a jakie wymagaj\u0105 poprawy. Monitorowanie tej metryki wspiera budowanie zdrowej kultury zespo\u0142owej.<\/p>\n\n\n\n Framework zaprojektowany przez Kena Schwabera (wsp\u00f3\u0142tw\u00f3rc\u0119 Scrum), stosowany do koordynacji pracy wielu zespo\u0142\u00f3w Scrumowych pracuj\u0105cych nad jednym produktem. Nexus dodaje dodatkowe role i wydarzenia, takie jak Nexus Integration Team i Nexus Daily Scrum, kt\u00f3re pomagaj\u0105 zespo\u0142om skupi\u0107 si\u0119 na integracji i dostarczaniu dzia\u0142aj\u0105cego produktu w spos\u00f3b skoordynowany.<\/p>\n\n\n\n T<\/span>rzy fundamentalne zasady, na kt\u00f3rych opiera si\u0119 Scrum:<\/p>\n\n\n\n Sens pracy zwinnej polega m.in. na wykonywaniu nieko\u0144cz\u0105cej si\u0119 p\u0119tli Inspekcji i Adaptacji.<\/p>\n\n\n\n J<\/span>edno z wydarze\u0144 (ceremonii) Scrumowych, pierwsze w Sprincie. Powinno przynie\u015b\u0107 odpowied\u017a na pytanie, co Zesp\u00f3\u0142 b\u0119dzie robi\u0142 w nadchodz\u0105cym Sprincie i jak b\u0119dzie to robi\u0142. W tym celu Zesp\u00f3\u0142 Deweloperski okre\u015bla, kt\u00f3re zadania z Backlogu zrealizuje w nadchodz\u0105cym sprincie. Zadania powinny by\u0107 powi\u0105zane z Celem Sprintu. Ponadto, Zesp\u00f3\u0142 Deweloperski ustala jak b\u0119dzie realizowa\u0142 Cel Sprintu i zadania z Backlogu Sprintu. W razie potrzeby w trakcie tego spotkania wi\u0119ksze zadania powinny zosta\u0107 rozbite na mniejsze cz\u0119\u015bci oraz powinien pojawi\u0107 si\u0119 przynajmniej cz\u0119\u015bciowy plan zrealizowania Celu Sprintu. Na koniec planowania Zesp\u00f3\u0142 Deweloperski powinien by\u0107 w stanie wyt\u0142umaczy\u0107, jak zamierza zrealizowa\u0107 swoj\u0105 prac\u0119.<\/p>\n\n\n\n J<\/span>edna z metod szacowania pracoch\u0142onno\u015bci i stopnia z\u0142o\u017cono\u015bci zada\u0144 z Backlogu, u\u017cywana m.in. w Scrum. Zazwyczaj zadania wyceniane s\u0105 w Story Points. Jest to gra karciana wykorzystuj\u0105ca specjalne karty z oznaczeniami punktowymi (cho\u0107 mo\u017cna u\u017cy\u0107 tak\u017ce aplikacji webowych czy mobilnych). Najcz\u0119\u015bciej wykorzystuje ci\u0105g Fibonacciego lub zmodyfikowany ci\u0105g Fibonacciego: 1, 2, 3, 5, 8, 13, 20, 40, 100. Podczas szacowania zadania, ka\u017cdy deweloper okre\u015bla indywidualnie warto\u015b\u0107 punktow\u0105, jak\u0105 chce przypisa\u0107 do zadania, po czym jednocze\u015bnie wszyscy ujawniaj\u0105 swoje oszacowanie. W wypadku rozbie\u017cno\u015bci, osoby kt\u00f3re zadeklarowa\u0142y skrajne warto\u015bci uzasadniaj\u0105 swoj\u0105 ocen\u0119 zespo\u0142owi i rozpoczyna si\u0119 dyskusja na ten temat. Nast\u0119pnie przeprowadzana jest kolejna runda szacowania. Je\u017celi wyniki nadal nie s\u0105 jednakowe, odbywa si\u0119 kolejna dyskusja. Je\u017celi po trzeciej sesji g\u0142osowania nadal nie ma zgodno\u015bci, najcz\u0119\u015bciej przyjmuje si\u0119 inn\u0105 metod\u0119 przyj\u0119cia ostatecznej warto\u015bci ustalon\u0105 przez Zesp\u00f3\u0142, np. \u015bredni\u0105, odrzucenie skrajnych ocen itp.<\/p>\n\n\n\n U<\/span>porz\u0105dkowany spis (rejestr) zada\u0144 do wykonania podczas pracy nad produktem, gdzie priorytetowe i najpe\u0142niej opisane zadania znajduj\u0105 si\u0119 na g\u00f3rze listy. Zadania powinny zosta\u0107 pouk\u0142adane w Backlogu zgodnie z warto\u015bci\u0105 biznesow\u0105 jak\u0105 dostarczaj\u0105. Zadaniami s\u0105 nie tylko wymagania funkcjonalne, ale te\u017c ca\u0142a praca jak\u0105 trzeba wykona\u0107 przy produkcie \u2013 usuwanie b\u0142\u0119d\u00f3w, poprawki oraz usuwanie d\u0142ugu technologicznego. Zadania umieszczane w Backlogu bardzo cz\u0119sto maj\u0105 posta\u0107 User Stories, ale nie ma takiego formalnego wymagania. Za zarz\u0105dzanie i porz\u0105dkowanie Backlogu jest odpowiedzialny Product Owner. Backlogu nie nale\u017cy myli\u0107 z dokumentacj\u0105 projektow\u0105, ta ostatnia jest zamkni\u0119tym zestawem wymaga\u0144, a Backlog podlega sta\u0142ym zmianom (\u017cyje). Zmienia si\u0119 tak d\u0142ugo, jak d\u0142ugo \u017cyje produkt, kt\u00f3rego dotyczy. Aby unikn\u0105\u0107 chaosu, jedyn\u0105 osob\u0105 uprawnion\u0105 do jego uzupe\u0142niania jest Product Owner.<\/p>\n\n\n\n J<\/span>edna z trzech r\u00f3l w Scrum, odpowiedzialna za warto\u015b\u0107 biznesow\u0105 produktu. Zawsze jest to pojedyncza osoba, nigdy komitet czy grupa os\u00f3b (cho\u0107 mo\u017ce korzysta\u0107 z pomocy analityka i innych specjalist\u00f3w). PO jest jedyn\u0105 osob\u0105 odpowiedzialn\u0105 za Backlog Produktu, priorytetyzacj\u0119 zada\u0144 i prze\u0142o\u017cenie wymaga\u0144 biznesowych na form\u0119 zrozumia\u0142\u0105 dla Zespo\u0142u Deweloperskiego. Kontaktuje si\u0119 z biznesem i wszelkimi Interesariuszami. Powinien by\u0107 dost\u0119pny dla Zespo\u0142u Deweloperskiego w takim wymiarze, w jakim Zesp\u00f3\u0142 go potrzebuje.<\/p>\n\n\n\n D<\/span>zia\u0142anie polegaj\u0105ce na ulepszaniu Backlogu Produktu. Backlog stale si\u0119 zmienia, zatem wymaga nieustannej pracy nad zawartymi w nim zadaniami. Dzia\u0142ania w zakresie Refinementu polegaj\u0105 na wsp\u00f3lnej pracy PO oraz Zespo\u0142u Deweloperskiego nad uszczeg\u00f3\u0142awianiem element\u00f3w Backlogu. Polega to na doprecyzowaniu i korygowaniu zada\u0144, a tak\u017ce na zmianie ich priorytetyzacji. Odbywa si\u0119 w trakcie trwania Sprintu w momencie dowolnie wybranym przez Zesp\u00f3\u0142 Scrumowy. Nie jest osobnym, wydzielonym wydarzeniem, odbywa si\u0119 w zale\u017cno\u015bci od potrzeb, jednak przyjmuje si\u0119, \u017ce powinien zaj\u0105\u0107 nie wi\u0119cej ni\u017c 10% d\u0142ugo\u015bci Sprintu. G\u0142\u00f3wnym celem Refinementu jest przygotowanie zada\u0144 z Backlogu do realizacji w nadchodz\u0105cych 2-3 sprintach.<\/p>\n\n\n\n O<\/span>ficjalna dystrybucja Przyrostu produktu udost\u0119pniona dla u\u017cytkownika docelowego, na finalnym \u015brodowisku.<\/p>\n\n\n\n Skr\u00f3t od Sociotechnical Agile Framework for Engineering Transformation, stosowany w organizacjach do wdra\u017cania zaawansowanych praktyk zwinnych w zespo\u0142ach technicznych. SAFE-T skupia si\u0119 na po\u0142\u0105czeniu zwinno\u015bci z praktykami technicznymi, takimi jak Continuous Delivery, DevOps oraz na integracji z podej\u015bciami Lean. To narz\u0119dzie jest szczeg\u00f3lnie przydatne w \u015brodowiskach wysokiej z\u0142o\u017cono\u015bci technologicznej.<\/p>\n\n\n\n Framework zarz\u0105dzania projektami Agile w du\u017cych organizacjach. SAFe umo\u017cliwia synchronizacj\u0119<\/a> pracy wielu zespo\u0142\u00f3w Scrumowych, tworz\u0105c wsp\u00f3lne p\u0142aszczyzny do planowania, realizacji i inspekcji post\u0119p\u00f3w. Sk\u0142ada si\u0119 z wielu poziom\u00f3w, takich jak Portfolio, Program i Team, kt\u00f3re pozwalaj\u0105 na prze\u0142o\u017cenie zasad Agile na zarz\u0105dzanie ca\u0142\u0105 organizacj\u0105. SAFe jest cz\u0119sto stosowany w korporacjach i du\u017cych przedsi\u0119biorstwach, gdzie zespo\u0142y zwinne musz\u0105 wsp\u00f3\u0142pracowa\u0107 nad jednym produktem.<\/p>\n\n\n\nAgile<\/strong><\/h3>\n\n\n\n
Agile Coach<\/strong><\/h3>\n\n\n\n
Agile Fluency Model<\/strong><\/h2>\n\n\n\n
Agile Manifesto (Manifest Agile)<\/strong><\/h2>\n\n\n\n
Agile Maturity Model (Model Dojrza\u0142o\u015bci Zwinno\u015bci)<\/strong><\/h2>\n\n\n\n
Agile Team (Zesp\u00f3\u0142 Zwinny)<\/strong><\/h2>\n\n\n\n
BDD (Behavior-Driven Development)<\/strong><\/h2>\n\n\n\n
Burn-down chart (Wykres Spalania)<\/strong><\/h2>\n\n\n\n
Burn-up chart<\/strong><\/h2>\n\n\n\n
Capacity (Pojemno\u015b\u0107)<\/strong><\/h2>\n\n\n\n
Daily<\/strong><\/h2>\n\n\n\n
Definition of Done (DoD; Definicja Uko\u0144czenia)<\/strong><\/h2>\n\n\n\n
Definition of Ready (DoR; Definicja Gotowo\u015bci)<\/strong><\/h2>\n\n\n\n
Deployment<\/h2>\n\n\n\n
Design Thinking (my\u015blenie projektowe)<\/strong><\/h2>\n\n\n\n
\n
Development Team (Dev Team; Zesp\u00f3\u0142 Deweloperski)<\/strong><\/h2>\n\n\n\n
DevOps<\/h2>\n\n\n\n
Dual-Track Agile<\/strong><\/h2>\n\n\n\n
Elements of Scrum (Elementy Scrum)<\/strong><\/h2>\n\n\n\n
\n
Empiricism (Empiryzm)<\/strong><\/h2>\n\n\n\n
Flow Metrics (Metryki Przep\u0142ywu)<\/strong><\/h2>\n\n\n\n
Increment (Przyrost)<\/strong><\/h2>\n\n\n\n
INVEST<\/h2>\n\n\n\n
\n
Kanban<\/h2>\n\n\n\n
\n
Lean Management (Lean; Szczup\u0142e Zarz\u0105dzanie)<\/strong><\/h2>\n\n\n\n
LeSS (Large-Scale Scrum)<\/strong><\/h2>\n\n\n\n
Load (pl. Obci\u0105\u017cenie)<\/strong><\/h2>\n\n\n\n
Metryki w Agile<\/strong><\/h2>\n\n\n\n
Minimum Viable Product (MVP; Minimalny Op\u0142acalny Produkt)<\/strong><\/h2>\n\n\n\n
Najpopularniejsze Metryki w Agile<\/strong><\/h2>\n\n\n\n
Velocity (Pr\u0119dko\u015b\u0107 Zespo\u0142u)<\/strong><\/h3>\n\n\n\n
Burn-down Chart (Wykres Spalania)<\/strong><\/h3>\n\n\n\n
Burn-up Chart<\/strong><\/h3>\n\n\n\n
Lead Time (Czas Realizacji)<\/strong><\/h3>\n\n\n\n
Cycle Time (Czas Cyklu)<\/strong><\/h3>\n\n\n\n
Cumulative Flow Diagram (Wykres Przep\u0142ywu Skumulowanego)<\/strong><\/h3>\n\n\n\n
WIP (Work In Progress) Limit<\/strong><\/h3>\n\n\n\n
Defect Density (G\u0119sto\u015b\u0107 B\u0142\u0119d\u00f3w)<\/strong><\/h3>\n\n\n\n
Net Promoter Score (NPS)<\/strong><\/h3>\n\n\n\n
Escaped Defects (B\u0142\u0119dy Przeoczone)<\/strong><\/h3>\n\n\n\n
Customer Satisfaction (CSAT)<\/strong><\/h3>\n\n\n\n
Team Happiness<\/strong><\/h3>\n\n\n\n
Nexus<\/strong><\/h2>\n\n\n\n
Pillars of Scrum (Filary Scrum)<\/strong><\/h2>\n\n\n\n
\n
Planning (Planowanie)<\/strong><\/h2>\n\n\n\n
Planning Poker<\/h2>\n\n\n\n
Product Backlog (Backlog Produktu, Rejestr Produktu)<\/strong><\/h2>\n\n\n\n
Product Owner (PO; W\u0142a\u015bciciel Produktu)<\/strong><\/h2>\n\n\n\n
Refinement (Doskonalenie)<\/strong><\/h2>\n\n\n\n
Release (Wydanie)<\/strong><\/h2>\n\n\n\n
SAFE-T Framework<\/strong><\/h2>\n\n\n\n
Scaled Agile Framework (SAFe)<\/strong><\/h2>\n\n\n\n
Scrum<\/h2>\n\n\n\n