Wstęp do systemów informatycznych Scrum – praca w małych zespołach.

Prezentacja na temat: "Wstęp do systemów informatycznych Scrum – praca w małych zespołach."— Zapis prezentacji:

1 Wstęp do systemów informatycznych Scrum – praca w małych zespołach

2 Agenda Mały vs duży zespół Metodyki tradycyjne vs zwinne Scrum – zwinny project management Best practices dla małych zespołów

3 Mały vs duży zespół ?

4 Metodyki tradycyjne vs zwinne ?

5 Agile in name only Częsty problem w firmach, zwłaszcza dużych „Dorośli” planują projekt jak zwykle „Dzieci” mogą bawić się w swoje Agile Ale i tak będą rozliczane z „prawdziwego” planu

6 Scrum – zwinny project management

7 Scrum Framework, skupiający się na zarządzaniu procesem wytwarzania oprogramowania Zupełnie abstrahuje od kwestii technicznych Często „wspomagany” praktykami z XP

8 Role w Scrum Świnie Product owner Scrum master ZespółKurczaki

9 Product owner Odpowiada za zysk z przedsięwzięcia Odpowiedzialny za wizję projektu Zarządza priorytetami zadań w Product Backlog Ostateczny autorytet w sprawach wymagań Decyduje o zakończeniu/kontynuowaniu prac Odpowiada za szczęście interesariuszy Może brać udział w pracach zespołu

10 Scrum master Pilnuje przestrzegania procesu Pomaga rozwiązywać problemy Chroni zespół przed światem zewnętrznym Utrzymuje artefakty Promuje poprawę praktyk inżynierskich Pilnuje ograniczeń czasowych NIE ZARZĄDZA

11 Zepsuł^W Zespół Interdyscyplinarny Samoorganizujący się Autonomia w wyborze środków Silna współpraca Najlepiej zlokalizowany w jednym pomieszczeniu TRWAŁY 7 +/- 2 osoby

12 Kurczaki Wszyscy nie zaangażowani bezpośrednio w projekt

13

14 Proces Scrum Sprint planning meeting Daily Scrum Sprint review meeting Sprint Retrospective meeting Backlog refinement meeting

15 Sprint Planning Meeting Wybór elementów Project Backlog do realizacji w najbliższym Sprincie Product Owner określa priorytety Zespół musi określić, jak dużo będzie w stanie zrobić ! Unikać technical debt ! Dobrze jest – przynajmniej początkowo – planować ostrożnie

16 Sprint Planning Meeting Często jednocześnie będzie to Backlog Refinement Meeting Rezultatem Sprint Planning Meeting powinna być lista Sprint Tasks Maximum 8 godzin na 30-dniowy Sprint Co tu może pójść źle?

17 Daily Scrum 15 minut Na stojąco Zawsze w tym samym miejscu i czasie

18 Daily Scrum Każdy podsumowuje: Co zrobił wczoraj Co zrobi dzisiaj Jakie problemy utrudniają mu osiągnięcie celów Co tu może pójść źle?

19 Sprint Review Meeting Pokazujemy Product Owner’owi działający produkt Prezentacja na żywo a nie raport Product Owner określa, które z elementów są faktycznie zrealizowane „kompiluje się bez błędów” to nie „zrobione” „zrobione w 99%” to „nie zrobione” Elementy, które nie zostały ukończone wracają do backlogu Dobry moment na zaproszenie zainteresowanych osób spoza zespołu

20 Sprint Retrospective Meeting Wewnętrzna sprawa zespołu – tylko zespół i Scrum Master, bez Product Owner’a Analiza sukcesów, porażek, błędów itp. z ostatniego sprintu Uczestnicy muszą czuć się bezpiecznie Nie szukamy winnych, rozwiązujemy problemy

21 Backlog Refinement Meeting Doprecyzowanie elementów backlogu, szacowanie potrzebnego wysiłku. Realizowane w trakcie sprintów. Wszystkich.

22 Artefakty Scrum Product Backlog Product Backlog Item Sprint Backlog Sprint Task Sprint burndown chart Product/release burndown chart

23 Product Backlog Pożądane funkcjonalności posortowane wg. Priorytetów Dostępne dla wszystkich interesariuszy Wszyscy mogą dodawać elementy Priorytety zarządzane przez Product Owner’a Elementy na szczycie powinny być lepiej uszczegółowione Utrzymanie – Backlog Refinement Meeting

24 Product Backlog Item Konkretna pożądana funkcjonalność Ma wartość biznesową Określone kryteria akceptacji Nie powinno wprowadzać technical debt do projektu Często przedstawiane jako „user stories” Niektóre zespoły stosują zasadę „max rozmiar – 2-3 osoby, 2-3 dni” Zdecydowanie nie powinno to przekraczać kilku „osobotygodni”

25 User Stories i Epics User Story – niewielkie wymaganie funkcjonalne, mające wartość biznesową Zestaw takich user stories prowadzących zwykle do jakiegoś celu – epic User stories powinny mieć jasno określone kryteria akceptacji Kryteria akceptacji powinny zawierać też zagadnienia związane z testowaniem i refactoringiem

26 User Stories Użyteczny mnemonik – INVEST IndependentNegotiableValuableEstimableSmallTestable

27 Dobre i złe user stories Klient banku może zmienić PIN Kryteria akceptacji… Jako student mogę znaleźć swoje oceny w sieci, by nie czekać z poznaniem swoich ocen na następne zajęcia Kryteria akceptacji… Jeden poziom undo Kryteria akceptacji…

28 Dobre i złe user stories Napisać zasady gry… Nie jest niezależne, nie ma wartości biznesowej, zwykle nie jest małe Strona ma być kolorowa Nie jest niezależne, nie jest szacowalne… Jako Product Owner chcę, aby… Produkt nie jest dla Product Ownera. Kto będzie tego potrzebował Przetestować grę… Nie jest niezależne, zachęca do klasycznego cyklu opracowania…

29 Planning poker Technika szacowania pracochłonności PBI Wykorzystuje karty zawierające szacowanie „koszulkowe” – S, M, L, XL „punktowe” – najczęściej kolejne liczby Fibonacciego Jednoczesne ujawnienie szacowań Zmniejszenie wpływu innych na szacowanie Uzasadnienie szacowań w wypadku rozbieżności Ew. doprecyzowanie/podział/… PBI w razie potrzeby Kolejne szacowanie, do osiągnięcia konsensusu

30 Sprint Backlog Product Backlog Items, które zespół zobowiązał się zrealizować Stały na czas wykonania sprintu Zadania zidentyfikowane na podstawie wybranych PBI Identyfikowane podczas Sprint Planning Meeting Widoczny dla zespołu Pomoc naukowa przy Daily Scrum

31 Sprint Task Zadania „techniczne” PBI – co. Sprint Task – jak. Pozostały wysiłek jest codziennie szacowany, zwykle w godzinach Członkowie zespołu mogą podejmować się bycia odpowiedzialnym za dane zadanie Oczekiwana jest współpraca reszty zespołu

32 Sprint Task Kolejny użyteczny mnemonik – SMART SpecificMeasurableAchievableRelevantTime-boxed

33 Sprint burndown chart Określa ”wartość” w godzinach pozostałych do realizacji zadań Codziennie aktualizowany, „wartość” może pójść w górę lub w dół Może być źródłem problemów, zwłaszcza w większych organizacjach

34 Product/release burndown chart Wysiłek potrzebny do zrealizowania pozostałych elementów Product Backlog’u W elementach, Story Points itp…

35 Best practices dla małych zespołów

36 Unikać długu technicznego Dług techniczny – nieprzetestowane, niedopracowane, nie zrefactorowane elementy rozwiązania Coś co „naprawimy później” Naprawa długu technicznego to nie realizacja User Story – wątpliwa wartość biznesowa

37 Testy, testy i jeszcze raz testy Zautomatyzowane testy jednostkowe Zautomatyzowane testy funkcjonalne Testowanie ręczne

38 Wysoka jakość kodu Programowanie w parach Przeglądy projektu i kodu Refactoring Nie robienie rzeczy na zapas Brak przedwczesnej optymalizacji

39 Spikes Eksperyment – z technologią, algorytmem, pomysłem… Służy do Poprawy oszacowań Zmniejszenia ryzyka technologicznego … Realizowany w podejściu „fast and dirty” Efekt (kod) wyrzucany po zrealizowaniu

40 Współpraca Każdy może poprosić o pomoc, jeśli jej potrzebuje Powinien ją otrzymać

41 Brak własności kodu Programowanie w parach Każdy programista pracuje przy wszystkich częściach rozwiązania

42 Wysoki komfort pracy Brak nadgodzin

43 Pytania?