Podstawy Scruma

3 komentarze

Niedawno miałam przyjemność uczestniczyć w bardzo ciekawym szkoleniu na temat metodyki Scrum. Dowiedziałam się m.in. jakie są podstawy Scruma.

Podstawy Scruma

Foto: moje, 2017

Podstawy Scruma

Sam Scrum pewnie znany jest większości osób, które mają styczność z wytwarzaniem oprogramowania. Myślę, że metodyka ta swoją popularność zawdzięcza głównie temu, że narzuca pewną strukturę zarządzania pracą/czasem/zespołem, jednocześnie dając wolność adaptacji do własnych potrzeb. Cechy te podkreślają filary, na których opiera się Scrum, zwłaszcza ostatni:

  • Transparency – przejrzystość
  • Inspect – inspekcja
  • Adapt – adaptacja!

Podstawową wiedzę na temat Scrum warto czerpać z oficjalnego podręcznika. Jest dostępny po polsku tutaj: http://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Polish.pdf. Kopia: [2016-Scrum-Guide-Polish]

Framework

Scrum to framework – co to oznacza w praktyce? Podręcznik przedstawia to tak: Scrum to „baza”, ramy, na których zespół buduje swoją własną „implementację”. Na bazę składa się naprawdę niewiele elementów. Są to:

  • Zespół i role: Product Owner, Scrum Master oraz zespół developerski: programiści, testerzy, graficy, analitycy biznesowi itd.,
  • Zdarzenia: Sprint (przebieg), Sprint Planning (planowanie przebiegu), Daily Scrum (jak idzie praca nad celami?), Sprint Review (demonstracja i inspekcja przyrostu pracy), Sprint Retro (czego się nauczyliśmy?),
  • Artefakty: Product Backlog, Sprint Backlog i cel Sprintu,szkolenia scrumowego
  • Reguły: łączące wszystkie elementy tej układanki.

Dodatki

Pozostałe praktyki, jakie często kojarzone są ze Scrumem, są tylko dodatkiem, implementacją, zestawem dobrych praktyk. Nie są składnikiem frameworka. Przykłady:

  • Planowanie Sprinta za pomocą kart do Scrum pokera,
  • Pozycja stojąca podczas Daily Scrum,
  • Spotkania groomingowe – backlog refinement to nie tylko spotkania, ale także praca własna nad backlogiem! Zespół powinien spędzić nad tym tematem 10% czasu, przygotowując się do kolejnego sprintu – ten czas można przeznaczyć np. na szukanie technologii do realizacji przyszłych zadań itd.

Ciekawą rzeczą, jaką wyniosłam ze szkolenia była informacja, że podczas Sprintu zespół powinien dostarczyć całą, lecz uproszczoną funkcjonalność! Niedopuszczalne jest zatem np. wykonanie części prac w bazie danych, ale niezrobienie niczego w interfejsie. Zadania powinny być zatem upraszczane, a nie dzielone. Ciekawa zasada, chyba nie zawsze jednak respektowana.

Podobne wpisy:

  1. BDD, TDD, FDD, Agile i inne metodyki
  2. Scrum kontra złożoność
  3. Czego nauczyła mnie praca w Scrumie?

Przydatny wpis? Postaw mi kawę :)

0 0 votes
Article Rating
Subscribe
Powiadom o
guest
3 komentarzy
najstarszy
najnowszy oceniany
Inline Feedbacks
View all comments
trackback
Dla kogo Scrum? | Mój skrawek Sieci
6 lat temu

[…] Niedawno podawałam garść ciekawych informacji na temat Scruma. […]

0
Odpowiedz
xpil
xpil
5 lat temu

Scrum jest fajny. Kanban też. Pracowałem wiele razy i tu i tam, i mogę z całą pewnością stwierdzić, że obydwa narzędzia są potężne i pomocne. Ze Scrumem jest trochę jak z buddyjskimi świętymi księgami: jeżeli coś się nie zgadza albo nie działa tak, jak powinno, zmieniamy księgi. (W większości innych religii zamiast tego próbujemy nakryć kocykiem niepasujący kawałek rzeczywistości i udajemy, że go nie ma, albo wręcz eliminujemy go siłowo).

Czyli, tłumacząc na nasze, jeżeli Scrum nie przynosi efektów, to znaczy, że używamy złej jego wersji. Czasem ludzie myślą, że czym więcej „książkowych” elementów Scruma wdrożymy, tym „lepszy” on będzie. A tymczasem guzik, bo nie zawsze potrzebujemy wszystkich ról czy artefaktów (jak na przykład „Sprint Commitment Meeting” – często spokojnie da się turlać bez tego, a zawsze to pół dnia w kieszeni).

Mi się najbardziej podoba to, że codziennie rano wiadomo, co się będzie robić oraz – z grubsza – co robią inni. Dzięki temu jest naprawdę dobra „widoczność”, i to z perspektywy każdego uczestnika imprezki.

0
Odpowiedz
Anna
Anna
4 lat temu

Scrum NIE JEST METODYKĄ! W Scrum Guidzie czytamy na początku „Scrum is a process framework (…). Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.” i na końcu: „Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”.

„Artefakty: Product Backlog, Sprint Backlog i cel Sprintu,szkolenia scrumowego” – no raczej nie. Artefakty to, owszem, Product Backlog i Sprint Backlog, ale twór o nazwie „cel Sprintu,szkolenia scrumowego” już nie. Trzeci artefakt to INCREMENT.

„Zespół powinien spędzić nad tym tematem 10% czasu” – nie, nie powinien. Scrum Guide mówi tylko, że „Refinement USUALLY consumes no more than 10% of the capacity of the Development Team”, ale to nie oznacza, że jest to nakaz i że tyle ma zajmować.

0
Odpowiedz