<\/p>\n
Czym jest Scrum<\/p>\n
Kiedy Scrum ma sens, a kiedy nie<\/p>\n
Filary Scruma: przejrzysto\u015b\u0107, inspekcja i adaptacja<\/p>\n
Warto\u015bci Scruma<\/p>\n
Scrum Team<\/p>\n
Product Owner<\/p>\n
Scrum Master<\/p>\n
Developers<\/p>\n
Product Backlog<\/p>\n
Sprint Backlog<\/p>\n
Increment<\/p>\n
Product Goal, Sprint Goal i Definition of Done<\/p>\n
Sprint<\/p>\n
Sprint Planning<\/p>\n
Daily Scrum<\/p>\n
Sprint Review<\/p>\n
Sprint Retrospective<\/p>\n
Przyk\u0142ad pracy zespo\u0142u Scrum krok po kroku<\/p>\n
Najcz\u0119stsze b\u0142\u0119dy we wdra\u017caniu Scruma<\/p>\n
Prosty plan wdro\u017cenia Scruma w firmie<\/p>\n<\/li>\n<\/ol>\n
Scrum to spos\u00f3b organizowania pracy zespo\u0142u, kt\u00f3ry tworzy produkt w warunkach niepewno\u015bci. Nie jest szczeg\u00f3\u0142ow\u0105 metodyk\u0105 zarz\u0105dzania projektem, nie jest list\u0105 procedur i nie jest systemem raportowania ludzi. Scrum jest ram\u0105 pracy, czyli szkieletem, kt\u00f3ry pomaga zespo\u0142owi regularnie planowa\u0107, wykonywa\u0107, sprawdza\u0107 i poprawia\u0107 spos\u00f3b dzia\u0142ania.<\/p>\n
Najpro\u015bciej mo\u017cna powiedzie\u0107:<\/p>\n
Scrum pomaga zespo\u0142owi cz\u0119sto dostarcza\u0107 ma\u0142e, warto\u015bciowe fragmenty produktu i uczy\u0107 si\u0119 na podstawie informacji zwrotnej.<\/strong><\/p>\n W tradycyjnym podej\u015bciu cz\u0119sto pr\u00f3buje si\u0119 zaplanowa\u0107 ca\u0142y projekt od pocz\u0105tku do ko\u0144ca. Zak\u0142ada si\u0119, \u017ce wymagania s\u0105 dobrze znane, zakres jest stabilny, a zesp\u00f3\u0142 mo\u017ce dok\u0142adnie przewidzie\u0107, ile czasu zajmie ca\u0142o\u015b\u0107. W praktyce, szczeg\u00f3lnie w projektach IT, produkcyjnych, automatyzacyjnych i wdro\u017ceniowych, bardzo cz\u0119sto tak nie jest.<\/p>\n Klient zmienia zdanie. Scrum nie udaje, \u017ce ta zmienno\u015b\u0107 nie istnieje. Przeciwnie \u2014 przyjmuje j\u0105 jako normaln\u0105 cz\u0119\u015b\u0107 pracy nad z\u0142o\u017conym produktem.<\/p>\n Scrum najlepiej sprawdza si\u0119 tam, gdzie:<\/p>\n cel jest znany, ale droga doj\u015bcia nie jest w pe\u0142ni oczywista,<\/p>\n wymagania mog\u0105 si\u0119 zmienia\u0107,<\/p>\n potrzebna jest cz\u0119sta informacja zwrotna,<\/p>\n produkt mo\u017cna rozwija\u0107 przyrostowo,<\/p>\n zesp\u00f3\u0142 potrzebuje regularnego rytmu pracy,<\/p>\n wa\u017cniejsze jest dostarczanie warto\u015bci ni\u017c samo wykonywanie planu.<\/p>\n<\/li>\n<\/ul>\n Przyk\u0142ady zastosowania Scruma:<\/p>\n tworzenie aplikacji internetowej,<\/p>\n rozw\u00f3j systemu ERP, MES, WMS lub CRM,<\/p>\n wdra\u017canie nowego modu\u0142u oprogramowania,<\/p>\n rozw\u00f3j produktu cyfrowego,<\/p>\n automatyzacja proces\u00f3w biznesowych,<\/p>\n budowa platformy e-commerce,<\/p>\n rozw\u00f3j us\u0142ugi SaaS,<\/p>\n praca nad now\u0105 funkcjonalno\u015bci\u0105 dla klient\u00f3w.<\/p>\n<\/li>\n<\/ul>\n Scrum mo\u017ce by\u0107 stosowany tak\u017ce poza IT, ale trzeba uwa\u017ca\u0107, aby nie robi\u0107 tego mechanicznie. Je\u017celi praca jest bardzo powtarzalna, prosta i przewidywalna, Scrum mo\u017ce by\u0107 zbyt ci\u0119\u017cki lub niepotrzebny. Je\u017celi natomiast praca wymaga uczenia si\u0119, eksperymentowania i cz\u0119stego podejmowania decyzji, Scrum mo\u017ce by\u0107 bardzo pomocny.<\/p>\n Scrum nie zawsze b\u0119dzie dobrym rozwi\u0105zaniem.<\/p>\n Mo\u017ce nie mie\u0107 sensu, gdy:<\/p>\n praca jest w pe\u0142ni powtarzalna i proceduralna,<\/p>\n nie ma zespo\u0142u, tylko pojedyncze osoby wykonuj\u0105ce niezale\u017cne zadania,<\/p>\n organizacja nie akceptuje zmiany priorytet\u00f3w,<\/p>\n klient oczekuje sztywnego zakresu, terminu i bud\u017cetu bez miejsca na adaptacj\u0119,<\/p>\n zesp\u00f3\u0142 nie ma wp\u0142ywu na spos\u00f3b wykonania pracy,<\/p>\n Scrum ma s\u0142u\u017cy\u0107 tylko do kontroli pracownik\u00f3w.<\/p>\n<\/li>\n<\/ul>\n Scrum nie naprawia automatycznie problem\u00f3w organizacji. On je raczej ujawnia. Je\u017celi firma ma chaos decyzyjny, brak w\u0142a\u015bciciela produktu, sprzeczne priorytety i kultur\u0119 obwiniania, Scrum szybko poka\u017ce te problemy. To mo\u017ce by\u0107 bolesne, ale jest te\u017c bardzo warto\u015bciowe.<\/p>\n Scrum opiera si\u0119 na empiryzmie. Oznacza to, \u017ce decyzje podejmujemy na podstawie do\u015bwiadczenia, obserwacji i fakt\u00f3w, a nie tylko na podstawie za\u0142o\u017ce\u0144.<\/p>\n W Scrumie nie zak\u0142adamy, \u017ce na pocz\u0105tku wiemy wszystko. Zamiast tego pracujemy kr\u00f3tkimi cyklami, regularnie sprawdzamy efekty i dostosowujemy dalsze dzia\u0142ania.<\/p>\n Trzy filary empiryzmu w Scrumie to:<\/p>\n Wszyscy powinni widzie\u0107 rzeczywisty stan pracy. Nie chodzi o tworzenie \u0142adnych raport\u00f3w, tylko o prawdziwy obraz sytuacji.<\/p>\n Przejrzysto\u015b\u0107 oznacza, \u017ce wiadomo:<\/p>\n nad czym pracuje zesp\u00f3\u0142,<\/p>\n jaki jest cel Sprintu,<\/p>\n co jest gotowe,<\/p>\n co nie jest gotowe,<\/p>\n jakie s\u0105 przeszkody,<\/p>\n jakie decyzje trzeba podj\u0105\u0107.<\/p>\n<\/li>\n<\/ul>\n Bez przejrzysto\u015bci nie da si\u0119 dobrze sprawdza\u0107 post\u0119p\u00f3w.<\/p>\n Inspekcja oznacza regularne sprawdzanie tego, co si\u0119 dzieje.<\/p>\n Zesp\u00f3\u0142 sprawdza:<\/p>\n produkt,<\/p>\n post\u0119p prac,<\/p>\n jako\u015b\u0107,<\/p>\n spos\u00f3b wsp\u00f3\u0142pracy,<\/p>\n sens aktualnych priorytet\u00f3w.<\/p>\n<\/li>\n<\/ul>\n Inspekcja nie jest kontrol\u0105 ludzi. Jest sprawdzaniem rzeczywisto\u015bci.<\/p>\n Adaptacja oznacza zmian\u0119 dzia\u0142ania na podstawie tego, czego si\u0119 nauczyli\u015bmy.<\/p>\n Je\u017celi co\u015b nie dzia\u0142a, trzeba to poprawi\u0107. Bez adaptacji Scrum staje si\u0119 pustym rytua\u0142em.<\/p>\n Scrum Guide wymienia pi\u0119\u0107 warto\u015bci Scruma: zaanga\u017cowanie, skupienie, otwarto\u015b\u0107, szacunek i odwag\u0119. Warto\u015bci te maj\u0105 kierowa\u0107 zachowaniem Scrum Teamu i wspiera\u0107 przejrzysto\u015b\u0107, inspekcj\u0119 oraz adaptacj\u0119. (Scrum Guides<\/a>)<\/p>\n Zesp\u00f3\u0142 zobowi\u0105zuje si\u0119 do osi\u0105gania cel\u00f3w i wspierania siebie nawzajem. Nie chodzi o \u015blepe obiecywanie nierealnych termin\u00f3w. Chodzi o odpowiedzialne podej\u015bcie do wsp\u00f3lnego celu.<\/p>\n W Scrumie zesp\u00f3\u0142 powinien skupia\u0107 si\u0119 na celu Sprintu. To bardzo wa\u017cne, poniewa\u017c w wielu organizacjach zespo\u0142y s\u0105 rozpraszane przez dziesi\u0105tki pobocznych temat\u00f3w.<\/p>\n Skupienie oznacza: Zesp\u00f3\u0142 powinien otwarcie m\u00f3wi\u0107 o post\u0119pach, problemach, ryzykach i ograniczeniach. Bez otwarto\u015bci Scrum zamienia si\u0119 w teatr, w kt\u00f3rym wszyscy udaj\u0105, \u017ce wszystko idzie dobrze.<\/p>\n Cz\u0142onkowie zespo\u0142u traktuj\u0105 si\u0119 jak kompetentni profesjonali\u015bci. Szacunek nie oznacza braku trudnych rozm\u00f3w. Oznacza prowadzenie ich bez poni\u017cania, agresji i obwiniania.<\/p>\n Odwaga jest potrzebna, aby m\u00f3wi\u0107 prawd\u0119, kwestionowa\u0107 z\u0142e decyzje, przyznawa\u0107 si\u0119 do problem\u00f3w i proponowa\u0107 zmiany.<\/p>\n W Scrumie odwaga jest szczeg\u00f3lnie wa\u017cna, poniewa\u017c przejrzysto\u015b\u0107 cz\u0119sto pokazuje rzeczy niewygodne.<\/p>\n Podstawow\u0105 jednostk\u0105 Scruma jest Scrum Team<\/strong>. Sk\u0142ada si\u0119 on z jednej osoby pe\u0142ni\u0105cej odpowiedzialno\u015b\u0107 Product Ownera, jednej osoby pe\u0142ni\u0105cej odpowiedzialno\u015b\u0107 Scrum Mastera oraz Developers. W Scrum Teamie nie ma podzespo\u0142\u00f3w ani hierarchii wewn\u0119trznej; jest to sp\u00f3jna grupa profesjonalist\u00f3w skupiona na jednym celu produktu. (Scrum Guides<\/a>)<\/p>\n Scrum Team powinien by\u0107:<\/p>\n ma\u0142y,<\/p>\n interdyscyplinarny,<\/p>\n samozarz\u0105dzaj\u0105cy,<\/p>\n odpowiedzialny za dostarczanie warto\u015bci,<\/p>\n zdolny do tworzenia u\u017cytecznego przyrostu produktu.<\/p>\n<\/li>\n<\/ul>\n W praktyce oznacza to, \u017ce zesp\u00f3\u0142 powinien mie\u0107 wszystkie kompetencje potrzebne do wykonania pracy. Je\u017celi zesp\u00f3\u0142 stale czeka na decyzje, analizy, testy, wdro\u017cenia lub akceptacje z zewn\u0105trz, jego zdolno\u015b\u0107 do pracy w Scrumie jest ograniczona.<\/p>\n Product Owner odpowiada za maksymalizacj\u0119 warto\u015bci produktu wynikaj\u0105cej z pracy Scrum Teamu. To osoba, kt\u00f3ra dba o kierunek rozwoju produktu i zarz\u0105dza Product Backlogiem.<\/p>\n Product Owner odpowiada za:<\/p>\n wizj\u0119 produktu,<\/p>\n Product Goal,<\/p>\n kolejno\u015b\u0107 element\u00f3w w Product Backlogu,<\/p>\n jasno\u015b\u0107 wymaga\u0144,<\/p>\n kontakt z interesariuszami,<\/p>\n podejmowanie decyzji produktowych,<\/p>\n maksymalizacj\u0119 warto\u015bci.<\/p>\n<\/li>\n<\/ul>\n Product Owner nie powinien by\u0107 tylko \u201esekretarzem wymaga\u0144\u201d ani osob\u0105 przepisuj\u0105c\u0105 \u017cyczenia klient\u00f3w do listy zada\u0144. Jego zadaniem jest podejmowanie decyzji: co jest najwa\u017cniejsze, co daje najwi\u0119ksz\u0105 warto\u015b\u0107, co mo\u017cna od\u0142o\u017cy\u0107, a czego nie warto robi\u0107.<\/p>\n Dobry Product Owner umie powiedzie\u0107 \u201enie\u201d. Scrum Master odpowiada za skuteczno\u015b\u0107 Scruma. Pomaga zespo\u0142owi, Product Ownerowi i organizacji rozumie\u0107 oraz stosowa\u0107 Scrum.<\/p>\n Scrum Master nie jest kierownikiem zespo\u0142u. Nie rozdziela zada\u0144, nie pilnuje ludzi jak nadzorca i nie jest osob\u0105 od \u201eprowadzenia spotka\u0144\u201d w sensie administracyjnym.<\/p>\n Scrum Master pomaga:<\/p>\n usuwa\u0107 przeszkody,<\/p>\n usprawnia\u0107 wsp\u00f3\u0142prac\u0119,<\/p>\n chroni\u0107 zesp\u00f3\u0142 przed chaosem,<\/p>\n uczy\u0107 organizacj\u0119 Scruma,<\/p>\n wspiera\u0107 Product Ownera,<\/p>\n dba\u0107 o sens wydarze\u0144 Scrumowych,<\/p>\n rozwija\u0107 samozarz\u0105dzanie zespo\u0142u.<\/p>\n<\/li>\n<\/ul>\n Dobry Scrum Master nie pyta tylko: Pyta raczej: Developers to osoby w Scrum Teamie, kt\u00f3re tworz\u0105 przyrost produktu. W IT b\u0119d\u0105 to zwykle programi\u015bci, testerzy, analitycy, UX designerzy, DevOps, konsultanci techniczni lub inne osoby wykonuj\u0105ce prac\u0119 potrzebn\u0105 do dostarczenia produktu.<\/p>\n Nazwa \u201eDevelopers\u201d nie oznacza wy\u0142\u0105cznie programist\u00f3w. Chodzi o ludzi, kt\u00f3rzy rozwijaj\u0105 produkt.<\/p>\n Developers odpowiadaj\u0105 za:<\/p>\n planowanie pracy w Sprincie,<\/p>\n tworzenie Sprint Backlogu,<\/p>\n dostarczanie jako\u015bciowego Incrementu,<\/p>\n przestrzeganie Definition of Done,<\/p>\n codzienn\u0105 adaptacj\u0119 planu,<\/p>\n techniczny spos\u00f3b wykonania pracy.<\/p>\n<\/li>\n<\/ul>\n W dobrze dzia\u0142aj\u0105cym Scrumie Developers nie czekaj\u0105, a\u017c kto\u015b rozdzieli im zadania. Sami organizuj\u0105 prac\u0119 tak, aby osi\u0105gn\u0105\u0107 Cel Sprintu.<\/p>\n Scrum ma trzy g\u0142\u00f3wne artefakty:<\/p>\n Product Backlog<\/p>\n Sprint Backlog<\/p>\n Increment<\/p>\n<\/li>\n<\/ol>\n Ka\u017cdy artefakt zwi\u0119ksza przejrzysto\u015b\u0107 pracy. Ka\u017cdy ma te\u017c powi\u0105zane zobowi\u0105zanie: Product Backlog ma Product Goal, Sprint Backlog ma Sprint Goal, a Increment ma Definition of Done. Koncepcja Product Goal zosta\u0142a dodana w Scrum Guide 2020, aby Scrum Team skupia\u0142 si\u0119 na wi\u0119kszym, warto\u015bciowym zamierzeniu produktu. (AgileAdept.pl<\/a>)<\/p>\n Product Backlog to uporz\u0105dkowana lista tego, co mo\u017ce by\u0107 potrzebne w produkcie.<\/p>\n Mo\u017ce zawiera\u0107:<\/p>\n funkcje,<\/p>\n poprawki,<\/p>\n usprawnienia,<\/p>\n wymagania techniczne,<\/p>\n b\u0142\u0119dy,<\/p>\n eksperymenty,<\/p>\n prace badawcze,<\/p>\n zmiany wynikaj\u0105ce z informacji zwrotnej.<\/p>\n<\/li>\n<\/ul>\n Product Backlog nigdy nie jest \u201eostatecznie zamkni\u0119ty\u201d. Zmienia si\u0119 wraz z rozwojem produktu, wiedz\u0105 zespo\u0142u, potrzebami klient\u00f3w i sytuacj\u0105 biznesow\u0105.<\/p>\n Najwa\u017cniejsze elementy powinny by\u0107 najlepiej opisane, poniewa\u017c prawdopodobnie b\u0119d\u0105 realizowane najwcze\u015bniej. Elementy dalsze mog\u0105 by\u0107 mniej szczeg\u00f3\u0142owe.<\/p>\n Sprint Backlog to plan pracy na Sprint.<\/p>\n Zawiera:<\/p>\n Sprint Goal,<\/p>\n wybrane elementy Product Backlogu,<\/p>\n plan ich realizacji.<\/p>\n<\/li>\n<\/ul>\n Sprint Backlog nale\u017cy do Developers. To oni codziennie aktualizuj\u0105 plan, aby zwi\u0119kszy\u0107 szanse osi\u0105gni\u0119cia Celu Sprintu.<\/p>\n Wa\u017cne: Sprint Backlog nie jest zamro\u017con\u0105 list\u0105 zada\u0144. Mo\u017ce si\u0119 zmienia\u0107 w trakcie Sprintu, o ile zmiany pomagaj\u0105 osi\u0105gn\u0105\u0107 Cel Sprintu.<\/p>\n Increment to gotowy, u\u017cyteczny fragment produktu powsta\u0142y w trakcie Sprintu.<\/p>\n Increment powinien spe\u0142nia\u0107 Definition of Done. To znaczy, \u017ce nie jest \u201eprawie gotowy\u201d, \u201edo test\u00f3w\u201d, \u201edo akceptacji kiedy\u015b p\u00f3\u017aniej\u201d. Jest wykonany zgodnie z ustalonym standardem jako\u015bci.<\/p>\n W idealnej sytuacji Increment mo\u017ce by\u0107 wydany u\u017cytkownikom. Nie zawsze musi by\u0107 natychmiast wydany, ale powinien by\u0107 w stanie nadaj\u0105cym si\u0119 do u\u017cycia.<\/p>\n Product Goal opisuje wi\u0119kszy cel produktu. To kierunek, do kt\u00f3rego zmierza Scrum Team.<\/p>\n Przyk\u0142ad:<\/p>\n \u201eUruchomi\u0107 platform\u0119 B2B, kt\u00f3ra pozwoli klientom samodzielnie sk\u0142ada\u0107 zam\u00f3wienia i sprawdza\u0107 status realizacji.\u201d<\/p>\n Albo:<\/p>\n \u201eStworzy\u0107 modu\u0142 planowania produkcji, kt\u00f3ry pozwoli firmie uk\u0142ada\u0107 harmonogram zlece\u0144 na podstawie dost\u0119pno\u015bci maszyn i pracownik\u00f3w.\u201d<\/p>\n Sprint Goal to cel konkretnego Sprintu.<\/p>\n Dobry Sprint Goal nie brzmi:<\/p>\n \u201eZrobi\u0107 zadania 1, 2, 3, 4 i 5.\u201d<\/p>\n Lepszy Sprint Goal:<\/p>\n \u201eUmo\u017cliwi\u0107 klientowi z\u0142o\u017cenie podstawowego zam\u00f3wienia przez panel B2B.\u201d<\/p>\n Sprint Goal daje zespo\u0142owi sens i kierunek. Pomaga podejmowa\u0107 decyzje, gdy pojawiaj\u0105 si\u0119 problemy.<\/p>\n Definition of Done to wsp\u00f3lne rozumienie tego, kiedy praca jest naprawd\u0119 uko\u0144czona.<\/p>\n Przyk\u0142ad Definition of Done dla zespo\u0142u IT:<\/p>\n kod zosta\u0142 napisany,<\/p>\n kod przeszed\u0142 review,<\/p>\n testy automatyczne przechodz\u0105,<\/p>\n funkcja zosta\u0142a przetestowana,<\/p>\n dokumentacja zosta\u0142a uzupe\u0142niona,<\/p>\n nie ma znanych b\u0142\u0119d\u00f3w krytycznych,<\/p>\n funkcja jest zintegrowana z g\u0142\u00f3wn\u0105 wersj\u0105 produktu.<\/p>\n<\/li>\n<\/ul>\n Bez Definition of Done zesp\u00f3\u0142 mo\u017ce my\u015ble\u0107, \u017ce co\u015b jest gotowe, podczas gdy w rzeczywisto\u015bci wymaga jeszcze wielu dni pracy.<\/p>\n Sprint to podstawowy cykl pracy w Scrumie. Trwa maksymalnie miesi\u0105c. W praktyce cz\u0119sto stosuje si\u0119 Sprinty jedno- lub dwutygodniowe.<\/p>\n W trakcie Sprintu zesp\u00f3\u0142 pracuje nad osi\u0105gni\u0119ciem Sprint Goal i dostarczeniem Incrementu.<\/p>\n Sprint zawiera wszystkie wydarzenia Scrumowe:<\/p>\n Sprint Planning,<\/p>\n Daily Scrum,<\/p>\n Sprint Review,<\/p>\n Sprint Retrospective.<\/p>\n<\/li>\n<\/ul>\n Sprint daje zespo\u0142owi rytm. Dzi\u0119ki temu praca nie jest chaotycznym ci\u0105giem zada\u0144, ale uporz\u0105dkowanym cyklem planowania, wykonania, sprawdzania i poprawy.<\/p>\n Sprint Planning rozpoczyna Sprint.<\/p>\n Podczas Sprint Planningu zesp\u00f3\u0142 odpowiada na trzy pytania:<\/p>\n Dlaczego ten Sprint jest warto\u015bciowy?<\/p>\n Co mo\u017cna zrobi\u0107 w tym Sprincie?<\/p>\n Jak wybrana praca zostanie wykonana?<\/p>\n<\/li>\n<\/ol>\n W Scrum Guide 2020 mocniej podkre\u015blono pytanie \u201epo co\u201d, czyli zwi\u0105zek Sprint Planningu z Celem Sprintu. (AgileAdept.pl<\/a>)<\/p>\n Efektem Sprint Planningu jest Sprint Backlog.<\/p>\n Typowy przebieg Sprint Planningu:<\/p>\n Product Owner przedstawia najwa\u017cniejsze elementy Product Backlogu.<\/p>\n Zesp\u00f3\u0142 rozmawia o celu Sprintu.<\/p>\n Developers oceniaj\u0105, ile pracy s\u0105 w stanie podj\u0105\u0107.<\/p>\n Zesp\u00f3\u0142 wybiera elementy do Sprintu.<\/p>\n Developers tworz\u0105 wst\u0119pny plan realizacji.<\/p>\n Scrum Team uzgadnia Sprint Goal.<\/p>\n<\/li>\n<\/ol>\n Daily Scrum to kr\u00f3tkie, codzienne wydarzenie dla Developers. Trwa maksymalnie 15 minut.<\/p>\n Celem Daily Scrum nie jest raportowanie Scrum Masterowi. Celem jest sprawdzenie post\u0119pu wobec Sprint Goal i dostosowanie planu na najbli\u017cszy dzie\u0144.<\/p>\n Dobre Daily koncentruje si\u0119 na pytaniu:<\/p>\n Co musimy dzi\u015b ustali\u0107, \u017ceby zwi\u0119kszy\u0107 szanse osi\u0105gni\u0119cia Celu Sprintu?<\/strong><\/p>\n Z\u0142e Daily wygl\u0105da tak:<\/p>\n ka\u017cdy raportuje status,<\/p>\n nikt nikogo nie s\u0142ucha,<\/p>\n Scrum Master odpytuje ludzi,<\/p>\n problemy nie s\u0105 rozwi\u0105zywane,<\/p>\n spotkanie trwa za d\u0142ugo,<\/p>\n zesp\u00f3\u0142 nie aktualizuje planu.<\/p>\n<\/li>\n<\/ul>\n Daily powinno pomaga\u0107 zespo\u0142owi, a nie by\u0107 codzienn\u0105 kontrol\u0105 obecno\u015bci.<\/p>\n Sprint Review odbywa si\u0119 pod koniec Sprintu. Jego celem jest sprawdzenie wyniku pracy i zebranie informacji zwrotnej.<\/p>\n To nie jest tylko \u201edemo\u201d. To rozmowa o produkcie.<\/p>\n Podczas Sprint Review:<\/p>\n zesp\u00f3\u0142 pokazuje, co powsta\u0142o,<\/p>\n interesariusze przekazuj\u0105 informacj\u0119 zwrotn\u0105,<\/p>\n omawiane s\u0105 zmiany w otoczeniu biznesowym,<\/p>\n Product Backlog mo\u017ce zosta\u0107 dostosowany,<\/p>\n zesp\u00f3\u0142 i interesariusze rozmawiaj\u0105 o kolejnych krokach.<\/p>\n<\/li>\n<\/ul>\n Dobre Sprint Review pomaga odpowiedzie\u0107 na pytanie:<\/p>\n Czy idziemy w dobrym kierunku?<\/strong><\/p>\n Sprint Retrospective ko\u0144czy Sprint. To wydarzenie, podczas kt\u00f3rego Scrum Team analizuje spos\u00f3b swojej pracy i planuje usprawnienia.<\/p>\n Retrospektywa dotyczy mi\u0119dzy innymi:<\/p>\n wsp\u00f3\u0142pracy,<\/p>\n komunikacji,<\/p>\n jako\u015bci,<\/p>\n narz\u0119dzi,<\/p>\n proces\u00f3w,<\/p>\n przeszk\u00f3d,<\/p>\n relacji z interesariuszami,<\/p>\n Definition of Done.<\/p>\n<\/li>\n<\/ul>\n Dobra retrospektywa ko\u0144czy si\u0119 konkretnymi dzia\u0142aniami usprawniaj\u0105cymi.<\/p>\n Przyk\u0142ady:<\/p>\n \u201eOd nast\u0119pnego Sprintu robimy code review najp\u00f3\u017aniej dzie\u0144 po zg\u0142oszeniu.\u201d<\/p>\n \u201eProduct Owner przygotuje elementy Backlogu minimum dwa dni przed Planningiem.\u201d<\/p>\n \u201eDodajemy do Definition of Done test migracji danych.\u201d<\/p>\n \u201eOgraniczamy liczb\u0119 r\u00f3wnoleg\u0142ych zada\u0144 w toku.\u201d<\/p>\n<\/li>\n<\/ul>\n Retrospektywa bez dzia\u0142a\u0144 jest tylko rozmow\u0105. Scrum wymaga adaptacji.<\/p>\n Za\u0142\u00f3\u017cmy, \u017ce firma tworzy system do obs\u0142ugi produkcji.<\/p>\n Product Goal:<\/p>\n \u201eStworzy\u0107 modu\u0142, kt\u00f3ry pozwoli planowa\u0107 i monitorowa\u0107 zlecenia produkcyjne od przyj\u0119cia zam\u00f3wienia do zako\u0144czenia produkcji.\u201d<\/strong><\/p>\n Product Backlog zawiera mi\u0119dzy innymi:<\/p>\n rejestr zlece\u0144 produkcyjnych,<\/p>\n kart\u0119 zlecenia,<\/p>\n list\u0119 operacji technologicznych,<\/p>\n przypisywanie operacji do stanowisk,<\/p>\n statusy realizacji,<\/p>\n rejestracj\u0119 rozpocz\u0119cia i zako\u0144czenia operacji,<\/p>\n raport brak\u00f3w,<\/p>\n widok obci\u0105\u017cenia stanowisk,<\/p>\n integracj\u0119 z Subiektem,<\/p>\n podstawowy panel kierownika produkcji.<\/p>\n<\/li>\n<\/ul>\n Sprint 1 mo\u017ce mie\u0107 Sprint Goal:<\/p>\n \u201eUmo\u017cliwi\u0107 utworzenie i przegl\u0105danie podstawowego zlecenia produkcyjnego.\u201d<\/strong><\/p>\n Zesp\u00f3\u0142 wybiera do Sprintu:<\/p>\n formularz dodawania zlecenia,<\/p>\n list\u0119 zlece\u0144,<\/p>\n szczeg\u00f3\u0142y zlecenia,<\/p>\n podstawowe statusy,<\/p>\n zapis do bazy danych.<\/p>\n<\/li>\n<\/ul>\n Na Sprint Review zesp\u00f3\u0142 pokazuje dzia\u0142aj\u0105cy fragment systemu. Kierownik produkcji zauwa\u017ca, \u017ce potrzebne jest dodatkowe pole \u201epriorytet zlecenia\u201d. Product Owner aktualizuje Product Backlog.<\/p>\n Na Retrospektywie zesp\u00f3\u0142 zauwa\u017ca, \u017ce wymagania by\u0142y zbyt og\u00f3lne. Ustala, \u017ce przed kolejnym Sprint Planningiem Product Owner przygotuje przyk\u0142adowe scenariusze u\u017cycia.<\/p>\n Sprint 2 mo\u017ce mie\u0107 Sprint Goal:<\/p>\n \u201eUmo\u017cliwi\u0107 opisanie zlecenia przez operacje technologiczne.\u201d<\/strong><\/p>\n W ten spos\u00f3b produkt ro\u015bnie krok po kroku, a zesp\u00f3\u0142 regularnie uczy si\u0119 na podstawie realnych efekt\u00f3w.<\/p>\n Scrum nie s\u0142u\u017cy do codziennego odpytywania ludzi z pracy. Daily Scrum nie jest raportem dla kierownika.<\/p>\n Je\u017celi nikt nie podejmuje decyzji produktowych, Product Backlog staje si\u0119 list\u0105 \u017cycze\u0144 wszystkich interesariuszy.<\/p>\n Bez Definition of Done zesp\u00f3\u0142 dostarcza prace \u201eprawie gotowe\u201d, kt\u00f3re p\u00f3\u017aniej generuj\u0105 d\u0142ug techniczny i chaos.<\/p>\n Je\u017celi Sprint trwa zbyt d\u0142ugo, zesp\u00f3\u0142 rzadziej otrzymuje informacj\u0119 zwrotn\u0105. Kr\u00f3tszy Sprint zwykle szybciej ujawnia problemy.<\/p>\n Bez Sprint Goal Sprint staje si\u0119 przypadkowym zbiorem zada\u0144.<\/p>\n Je\u017celi po retrospektywie nic si\u0119 nie zmienia, zesp\u00f3\u0142 szybko przestaje traktowa\u0107 j\u0105 powa\u017cnie.<\/p>\n Agile to szersza filozofia pracy zwinnej. Scrum jest konkretn\u0105 ram\u0105 pracy. Mo\u017cna by\u0107 Agile bez Scruma, ale Scrum powinien realizowa\u0107 zasady zwinno\u015bci.<\/p>\n Nie zaczynaj od ca\u0142ej organizacji. Wybierz jeden produkt, modu\u0142 lub obszar pracy.<\/p>\n Okre\u015bl:<\/p>\n kto jest Product Ownerem,<\/p>\n kto jest Scrum Masterem,<\/p>\n kto nale\u017cy do Developers,<\/p>\n czy zesp\u00f3\u0142 ma kompetencje do dostarczania produktu.<\/p>\n<\/li>\n<\/ul>\n Zesp\u00f3\u0142 powinien wiedzie\u0107, do czego zmierza.<\/p>\n Nie musi by\u0107 idealny. Wa\u017cne, aby zawiera\u0142 najwa\u017cniejsze potrzeby produktu.<\/p>\n Bez tego trudno m\u00f3wi\u0107 o jako\u015bci i gotowym przyro\u015bcie.<\/p>\n Zr\u00f3b Sprint Planning, pracuj codziennie nad celem, poka\u017c efekt na Sprint Review i przeprowad\u017a Retrospektyw\u0119.<\/p>\n Scrum nie polega na tym, \u017ce od razu wszystko dzia\u0142a idealnie. Scrum polega na regularnym uczeniu si\u0119 i poprawianiu.<\/p>\n Product Owner \u2014 odpowiada za warto\u015b\u0107 i Product Backlog.<\/p>\n Scrum Master \u2014 odpowiada za skuteczno\u015b\u0107 Scruma.<\/p>\n Developers \u2014 tworz\u0105 gotowy Increment.<\/p>\n<\/li>\n<\/ul>\n Product Backlog \u2014 lista tego, co mo\u017ce by\u0107 potrzebne w produkcie.<\/p>\n Sprint Backlog \u2014 plan pracy na Sprint.<\/p>\n Increment \u2014 gotowy przyrost produktu.<\/p>\n<\/li>\n<\/ul>\n Product Goal \u2014 cel produktu.<\/p>\n Sprint Goal \u2014 cel Sprintu.<\/p>\n Definition of Done \u2014 kryterium uko\u0144czenia.<\/p>\n<\/li>\n<\/ul>\n Sprint \u2014 cykl pracy.<\/p>\n Sprint Planning \u2014 planowanie Sprintu.<\/p>\n Daily Scrum \u2014 codzienna inspekcja post\u0119pu.<\/p>\n Sprint Review \u2014 przegl\u0105d produktu i informacja zwrotna.<\/p>\n Sprint Retrospective \u2014 usprawnianie sposobu pracy.<\/p>\n<\/li>\n<\/ul>\n Scrum jest prosty do opisania, ale trudny do dobrego stosowania. Jego si\u0142a nie polega na spotkaniach, tablicach ani nazwach r\u00f3l. Si\u0142a Scruma polega na regularnym dostarczaniu warto\u015bci, przejrzysto\u015bci pracy, cz\u0119stej informacji zwrotnej i gotowo\u015bci do adaptacji.<\/p>\n Dobrze wdro\u017cony Scrum pomaga zespo\u0142owi:<\/p>\n lepiej rozumie\u0107 cel,<\/p>\n szybciej dostarcza\u0107 warto\u015b\u0107,<\/p>\n wcze\u015bniej wykrywa\u0107 problemy,<\/p>\n poprawia\u0107 jako\u015b\u0107,<\/p>\n ogranicza\u0107 chaos,<\/p>\n lepiej wsp\u00f3\u0142pracowa\u0107 z biznesem,<\/p>\n uczy\u0107 si\u0119 z ka\u017cdego Sprintu.<\/p>\n<\/li>\n<\/ul>\n \u0179le wdro\u017cony Scrum staje si\u0119 tylko zestawem spotka\u0144 i nazw. Dlatego najwa\u017cniejsze pytanie nie brzmi: Najwa\u017cniejsze pytanie brzmi:<\/p>\n Czy dzi\u0119ki Scrumowi cz\u0119\u015bciej dostarczamy warto\u015b\u0107, szybciej si\u0119 uczymy i lepiej adaptujemy do rzeczywisto\u015bci?<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Praktyczny podr\u0119cznik dla pocz\u0105tkuj\u0105cych Spis tre\u015bci Czym jest Scrum Kiedy Scrum ma sens, a kiedy nie Filary Scruma: przejrzysto\u015b\u0107, inspekcja i adaptacja Warto\u015bci Scruma Scrum Team Product Owner Scrum Master Developers Product Backlog Sprint Backlog Increment Product Goal, Sprint Goal i Definition of Done Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Przyk\u0142ad pracy… Czytaj dalej Podstawy Scrum<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/michalmoroz.info\/index.php?rest_route=\/wp\/v2\/posts\/856"}],"collection":[{"href":"http:\/\/michalmoroz.info\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/michalmoroz.info\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/michalmoroz.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/michalmoroz.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=856"}],"version-history":[{"count":1,"href":"http:\/\/michalmoroz.info\/index.php?rest_route=\/wp\/v2\/posts\/856\/revisions"}],"predecessor-version":[{"id":857,"href":"http:\/\/michalmoroz.info\/index.php?rest_route=\/wp\/v2\/posts\/856\/revisions\/857"}],"wp:attachment":[{"href":"http:\/\/michalmoroz.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=856"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/michalmoroz.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=856"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/michalmoroz.info\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=856"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Rynek si\u0119 zmienia.
U\u017cytkownicy dopiero po zobaczeniu pierwszej wersji wiedz\u0105, czego naprawd\u0119 potrzebuj\u0105.
Technologia okazuje si\u0119 trudniejsza ni\u017c zak\u0142adano.
Cz\u0119\u015b\u0107 wymaga\u0144 by\u0142a \u017ale zrozumiana.
Priorytety biznesowe zmieniaj\u0105 si\u0119 w trakcie projektu.<\/p>\n
\n2. Kiedy Scrum ma sens<\/h3>\n
\n
\n
\n3. Kiedy Scrum nie jest najlepszym wyborem<\/h3>\n
\n
\n4. Empiryzm: fundament Scruma<\/h3>\n
Przejrzysto\u015b\u0107<\/h4>\n
\n
Inspekcja<\/h4>\n
\n
Adaptacja<\/h4>\n
Je\u017celi priorytety si\u0119 zmieni\u0142y, trzeba dostosowa\u0107 plan.
Je\u017celi u\u017cytkownicy inaczej korzystaj\u0105 z produktu, trzeba wyci\u0105gn\u0105\u0107 wnioski.<\/p>\n
\n5. Warto\u015bci Scruma<\/h3>\n
Zaanga\u017cowanie<\/h4>\n
Skupienie<\/h4>\n
\u201eW tym Sprincie najwa\u017cniejsze jest to. Na tym koncentrujemy energi\u0119.\u201d<\/p>\nOtwarto\u015b\u0107<\/h4>\n
Szacunek<\/h4>\n
Odwaga<\/h4>\n
\n6. Scrum Team<\/h3>\n
\n
\n7. Product Owner<\/h3>\n
\n
Dobry Product Owner rozumie biznes.
Dobry Product Owner potrafi rozmawia\u0107 z klientami i zespo\u0142em technicznym.
Dobry Product Owner nie zmienia priorytet\u00f3w codziennie bez powodu.<\/p>\n
\n8. Scrum Master<\/h3>\n
\n
\u201eCzy Daily si\u0119 odby\u0142o?\u201d<\/p>\n
\u201eCzy Daily pomaga zespo\u0142owi osi\u0105gn\u0105\u0107 Cel Sprintu?\u201d
\u201eCzy Sprint Review daje realn\u0105 informacj\u0119 zwrotn\u0105?\u201d
\u201eCzy Retrospektywa prowadzi do konkretnych usprawnie\u0144?\u201d
\u201eCzy Product Backlog jest przejrzysty?\u201d
\u201eCzy zesp\u00f3\u0142 ma warunki do pracy?\u201d<\/p>\n
\n9. Developers<\/h3>\n
\n
\n10. Artefakty Scruma<\/h3>\n
\n
\n11. Product Backlog<\/h3>\n
\n
\n12. Sprint Backlog<\/h3>\n
\n
\n13. Increment<\/h3>\n
\n14. Product Goal, Sprint Goal i Definition of Done<\/h3>\n
Product Goal<\/h4>\n
Sprint Goal<\/h4>\n
Definition of Done<\/h4>\n
\n
\n15. Sprint<\/h3>\n
\n
\n16. Sprint Planning<\/h3>\n
\n
\n
\n17. Daily Scrum<\/h3>\n
\n
\n18. Sprint Review<\/h3>\n
\n
\n19. Sprint Retrospective<\/h3>\n
\n
\n
\n20. Przyk\u0142ad Scruma w praktyce<\/h3>\n
\n
\n
\n21. Najcz\u0119stsze b\u0142\u0119dy we wdra\u017caniu Scruma<\/h3>\n
B\u0142\u0105d 1: Scrum jako mikrozarz\u0105dzanie<\/h4>\n
B\u0142\u0105d 2: Brak prawdziwego Product Ownera<\/h4>\n
B\u0142\u0105d 3: Brak Definition of Done<\/h4>\n
B\u0142\u0105d 4: Zbyt du\u017ce Sprinty<\/h4>\n
B\u0142\u0105d 5: Brak Sprint Goal<\/h4>\n
B\u0142\u0105d 6: Retrospektywy bez efekt\u00f3w<\/h4>\n
B\u0142\u0105d 7: Mylenie Scruma z Agile<\/h4>\n
\n22. Prosty plan wdro\u017cenia Scruma w firmie<\/h3>\n
Krok 1: Wybierz produkt<\/h4>\n
Krok 2: Zbuduj Scrum Team<\/h4>\n
\n
Krok 3: Ustal Product Goal<\/h4>\n
Krok 4: Utw\u00f3rz pierwszy Product Backlog<\/h4>\n
Krok 5: Ustal Definition of Done<\/h4>\n
Krok 6: Uruchom pierwszy Sprint<\/h4>\n
Krok 7: Poprawiaj proces co Sprint<\/h4>\n
\n23. Minimalna \u015bci\u0105ga Scrum<\/h3>\n
Scrum Team<\/h4>\n
\n
Artefakty<\/h4>\n
\n
Zobowi\u0105zania<\/h4>\n
\n
Wydarzenia<\/h4>\n
\n
\n24. Podsumowanie<\/h3>\n
\n
\u201eCzy robimy Daily, Planning i Review?\u201d<\/p>\n