Struktura Scrum pozwala zespo\u0142om \u0142\u0105czy\u0107 praktyki z innych framework\u00f3w, kt\u00f3re maj\u0105 dla ich \u015brodowiska znaczenie. W \u015bwiecie agilnym Scrum sta\u0142 si\u0119 wiod\u0105c\u0105 metodologi\u0105 rozwoju oprogramowania. Koncepcja Scrum jest wiarygodna i zosta\u0142a potwierdzona przez tysi\u0105ce zespo\u0142\u00f3w rozwojowych na ca\u0142ym \u015bwiecie. Scrum jest najbardziej odpowiedni dla zespo\u0142\u00f3w wielofunkcyjnych dzia\u0142aj\u0105cych w \u015brodowiskach rozwoju produkt\u00f3w, gdzie istnieje du\u017ca ilo\u015b\u0107 pracy do podzia\u0142u na wiele iteracji trwaj\u0105cych 2 do 4 tygodni.<\/p>\n
Pochodzenie Scrum<\/h2>\n
1986: Takeuchi i Nonaka opublikowali artyku\u0142 \u201eNowa gra w tworzenie nowych produkt\u00f3w\u201dNowa gra w tworzenie nowych produkt\u00f3w<\/a>\u201d w \u201eHarvard Business Review\u201d. Artyku\u0142 opisa\u0142 podej\u015bcie typu rugby, w kt\u00f3rym \u201eproces rozwoju produktu powstaje w wyniku ci\u0105g\u0142ej interakcji mi\u0119dzy starannie wybranym, wielodyscyplinarnym zespo\u0142em, kt\u00f3rego cz\u0142onkowie pracuj\u0105 razem od pocz\u0105tku do ko\u0144ca.\u201d Ten artyku\u0142 cz\u0119sto cytowany jest jako inspiracja dla frameworka Scrum.<\/p>\n Poni\u017csze zasady wspieraj\u0105 empiryczny charakter Scrum:<\/p>\n Przejrzysto\u015b\u0107<\/strong> Inspekcja<\/strong> Adaptacja<\/strong> W\u0142a\u015bciciela produktu<\/strong><\/p>\n Za W\u0142a\u015bciciela produktu<\/a> to rola odpowiedzialna za zarz\u0105dzanie backlogiem produktu w celu osi\u0105gni\u0119cia oczekiwanych wynik\u00f3w, kt\u00f3re zesp\u00f3\u0142 chce dostarczy\u0107.<\/p>\n Rola W\u0142a\u015bciciela produktu w Scrum istnieje, aby rozwi\u0105za\u0107 problem wielu sprzecznych kierunk\u00f3w lub braku kierunku, z jakim borykaj\u0105 si\u0119 zespo\u0142y rozwojowe przy decydowaniu, co nale\u017cy zbudowa\u0107.<\/p>\n Scrum Mastera<\/strong><\/p>\n Za Scrum Mastera<\/a> odpowiada za zapewnienie, \u017ce cz\u0142onkowie zespo\u0142u \u017cyj\u0105 warto\u015bciami i zasadami agilnymi oraz przestrzegaj\u0105 proces\u00f3w i praktyk, kt\u00f3re zesp\u00f3\u0142 zgadza si\u0119 stosowa\u0107.<\/p>\n Tytu\u0142 zosta\u0142 pierwotnie u\u017cywany w celu oznaczenia eksperta Scrum, kt\u00f3ry m\u00f3g\u0142 kierowa\u0107 innymi.<\/p>\n Ta rola zazwyczaj nie ma oficjalnej w\u0142adzy. Osoba w tej roli musi prowadzi\u0107 z pozycji wp\u0142ywowej, zazwyczaj przyjmuj\u0105c postaw\u0119 lidera us\u0142ugi.<\/p>\n Rozwojowy<\/strong> G\u0142\u00f3wnym obowi\u0105zkiem zespo\u0142u rozwojowego jest dostarczenie przyrostu, kt\u00f3ry tworzy warto\u015b\u0107 w ka\u017cdym Sprintie. Spos\u00f3b przydzielania pracy jest ustalany przez zesp\u00f3\u0142 na podstawie obecnych warunk\u00f3w.<\/p>\n Artefakty Scrum<\/p>\n Produktu<\/strong> W\u0142a\u015bciciel Produktu ci\u0105gle utrzymuje<\/a> Backlog Produktu, w tym jego zawarto\u015b\u0107, jasno\u015b\u0107 i uporz\u0105dkowanie.<\/p>\n Sprintu<\/strong> Przyrost<\/strong> Gotowo\u015bci<\/strong> Sprint<\/strong> Planowanie Sprintu (Planowanie Sprintu<\/a>)<\/strong> Planowanie Sprintu zwykle dzieli si\u0119 na dwie cz\u0119\u015bci. W pierwszej cz\u0119\u015bci W\u0142a\u015bciciel Produktu<\/a> i inni cz\u0142onkowie zespo\u0142u ustalaj\u0105, kt\u00f3re elementy Backlogu Produktu zostan\u0105 uwzgl\u0119dnione w Sprintie.<\/p>\n W drugiej cz\u0119\u015bci planowania Sprintu zesp\u00f3\u0142 ustala, jak pomy\u015blnie dostarczy\u0107 wybrane elementy Backlogu Produktu jako cz\u0119\u015b\u0107 potencjalnie wysy\u0142alnego przyrostu produktu. Je\u015bli tak\u0105 praktyk\u0119 stosuj\u0105, zesp\u00f3\u0142 mo\u017ce okre\u015bli\u0107 konkretne zadania wymagane do osi\u0105gni\u0119cia tego celu. Wybrane elementy Backlogu Produktu (je\u015bli dotyczy) i zidentyfikowane zadania tworz\u0105 Backlog Sprintu.<\/p>\n Gdy zesp\u00f3\u0142 i W\u0142a\u015bciciel Produktu uzgodni\u0105 zakres Sprintu na podstawie opisu element\u00f3w Backlogu Produktu, nie mo\u017cna doda\u0107 dodatkowych element\u00f3w do Backlogu Sprintu. Chroni to zesp\u00f3\u0142 przed zmianami zakresu w trakcie Sprintu.<\/p>\n Codzienna stand-up (Codzienna Scrum)<\/strong> Recenzja Sprintu<\/strong> Retrospektywa Sprintu<\/strong> Scrum to framework, kt\u00f3ry pozwala zespo\u0142om rozwojowym elastycznie reagowa\u0107 na zmieniaj\u0105ce si\u0119 warunki. Framework zapewnia wystarczaj\u0105c\u0105 liczb\u0119 punkt\u00f3w kontroli, aby zapewni\u0107, \u017ce zespo\u0142y nie odchylaj\u0105 si\u0119 od oczekiwanych wynik\u00f3w i mog\u0105 identyfikowa\u0107 i rozwi\u0105zywa\u0107 problemy oraz dostosowywa\u0107 procesy, gdy praca nadal trwa.<\/p>\n Cykl \u017cycia Scrum zaczyna si\u0119 od priorytetowego backlogu, ale nie zawiera wskaz\u00f3wek dotycz\u0105cych sposobu tworzenia lub priorytetyzacji backlogu.<\/p>\n Cykl \u017cycia Scrum sk\u0142ada si\u0119 z serii Sprint\u00f3w, kt\u00f3re ko\u0144cz\u0105 si\u0119 potencjalnie gotowym do wysy\u0142ki zwi\u0119kszeniem produktu. W tych Sprintach wszystkie dzia\u0142ania wymagane do rozwoju produktu odbywaj\u0105 si\u0119 na ma\u0142ej cz\u0119\u015bci ca\u0142ego produktu. Poni\u017cej znajduje si\u0119 opis kluczowych krok\u00f3w w cyklu \u017cycia Scrum:<\/p>\nWarto\u015bci Scrum (Warto\u015bci Scrum<\/a>)<\/h2>\n
\nZespo\u0142y musz\u0105 pracowa\u0107 w \u015brodowisku, w kt\u00f3rym wszyscy wiedz\u0105 o wyzwaniach, z jakimi borykaj\u0105 si\u0119 inni cz\u0142onkowie zespo\u0142u. Zespo\u0142y ujawniaj\u0105 problemy wewn\u0119trznie \u2014 cz\u0119sto d\u0142ugotrwa\u0142e problemy \u2014 kt\u00f3re utrudniaj\u0105 sukces zespo\u0142u.<\/p>\n
\nFramework zawiera cz\u0119ste punkty kontrolne, kt\u00f3re pozwalaj\u0105 zespo\u0142om zastanowi\u0107 si\u0119, jak dzia\u0142aj\u0105 ich procesy. Do tych punkt\u00f3w kontrolnych nale\u017c\u0105 spotkania Daily Scrum i przegl\u0105du sprintu.<\/p>\n
\nZespo\u0142y ci\u0105gle oceniaj\u0105 post\u0119py i dostosowuj\u0105 te elementy, kt\u00f3re wydaj\u0105 si\u0119 nieefektywne.<\/p>\nZesp\u00f3\u0142 rozwojowy (Zesp\u00f3\u0142 rozwojowy<\/a>)<\/h2>\n
\nDefinicja Rozwojowy<\/a> sk\u0142ada si\u0119 z tych, kt\u00f3rzy dostarczaj\u0105 przyrost produktu w trakcie Sprintu.<\/p>\n
\nDefinicja Produktu<\/a> to uporz\u0105dkowana lista wszystkich mo\u017cliwych zmian produktu. Elementy na Backlogu Produktu to opcje, a nie zobowi\u0105zania \u2014 bycie na li\u015bcie nie gwarantuje dostarczenia.<\/p>\n
\nDefinicja Sprintu<\/a> to zbi\u00f3r element\u00f3w Backlogu Produktu wybranych do dostarczenia w trakcie Sprintu, wraz z zadaniami, kt\u00f3re zesp\u00f3\u0142 uznaje za konieczne do dostarczenia tych element\u00f3w i osi\u0105gni\u0119cia celu Sprintu.<\/p>\n
\nPrzyrost to zbi\u00f3r element\u00f3w Backlogu Produktu uko\u0144czonych na ko\u0144cu Sprint<\/a> spe\u0142niaj\u0105cych definicj\u0119 gotowo\u015bci zespo\u0142u. W\u0142a\u015bciciel Produktu mo\u017ce zdecydowa\u0107 o wydaniu Przyrostu w przysz\u0142ym Sprintie lub o jego dalszym budowaniu.<\/p>\n
\nDefinicja Gotowo\u015bci<\/a> to konsensus w zespole co do kryteri\u00f3w, kt\u00f3re element Backlogu Produktu musi spe\u0142ni\u0107, zanim zostanie uznany za uko\u0144czony.<\/p>\nZdarzenia Scrum<\/h2>\n
\nZa z ograniczeniem czasowym<\/a> wydarzenie o czasie trwania do jednego miesi\u0105ca, w kt\u00f3rym zesp\u00f3\u0142 dostarcza potencjalnie wysy\u0142alny przyrost produktu. Typowe cechy Sprintu:<\/p>\n\n
\nZesp\u00f3\u0142 zaczyna Sprint, dyskutuj\u0105c, kt\u00f3re elementy z Backlogu Produktu b\u0119d\u0105 realizowane w trakcie Sprintu. Ostatecznym wynikiem planowania Sprintu jest Backlog Sprintu<\/a>.<\/p>\n
\nZesp\u00f3\u0142 Codzienna Scrum<\/a> to kr\u00f3tkie (zwykle nie d\u0142u\u017cej ni\u017c 15 minut) spotkanie, na kt\u00f3rym zesp\u00f3\u0142 koordynuje dzia\u0142ania na nast\u0119pny dzie\u0144. Codzienna Scrum nie ma na celu przedstawienie stanu post\u0119pu ani rozwi\u0105zywanie problem\u00f3w.<\/p>\n
\nNa ko\u0144cu Sprintu ca\u0142y zesp\u00f3\u0142 (w tym W\u0142a\u015bciciel Produktu) przegl\u0105da wyniki Sprintu z udzia\u0142em stakeholder\u00f3w produktu. Celem tej dyskusji jest przegl\u0105d, demonstracja i potencjalne umo\u017cliwienie stakeholderom skorzystania z przyrostu, aby wyrazi\u0107 opini\u0119. Recenzja Sprintu nie ma na celu przedstawienie stanu post\u0119pu. Opinia z recenzji Sprintu jest w\u0142\u0105czana do Backlogu Produktu do rozwa\u017cenia w przysz\u0142o\u015bci.<\/p>\n
\nPo recenzji Sprintu, na ko\u0144cu Sprintu, zesp\u00f3\u0142 (w tym W\u0142a\u015bciciel Produktu) analizuje poprzedni Sprint i identyfikuje zmiany, kt\u00f3re mog\u0105 wprowadzi\u0107 w przysz\u0142o\u015bci. Ta retrospektywa<\/a> prowadzi do co najmniej jednego dzia\u0142ania, kt\u00f3re zostanie uwzgl\u0119dnione w Backlogu Sprintu nast\u0119pnego Sprintu.<\/p>\n5 podstawowych warto\u015bci<\/h2>\n
\n
![\"What](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2021\/11\/3355-scrum-framework-1.png\")
<\/p>\nCykl \u017cycia<\/h2>\n
\n
G\u0142\u00f3wne korzy\u015bci<\/h2>\n