1 Inżynieria oprogramowania Metodologia SCRUM WWW: http://www.fizyka.umk.pl/~jacek/dydaktyka/inzynieria/index.html Jacek Matulewski Instytut Fizyki, UMK WWW: http://www.fizyka.umk.pl/~jacek E-mail: [email protected] semestr letni 2016
2 Agile Manifesto Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić: ludzi i interakcje od procesów i narzędzi działające oprogramowanie od szczegółowej dokumentacji współpracę z klientem od negocjacji umów, reagowanie na zmiany od realizacji założonego planu. Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej. http://www.agilemanifesto.org/iso/pl/ JM: To że jesteśmy zwinni i chętni do zmian, nie oznacza, że nie każemy sobie płacić za dodatkowe godziny spędzone nad kodem.
3
4 SCRUM Scrum Guide (ok. 20 stron, także po polsku) Ken Schwaber i Jeff Sutherland http://www.scrumguides.org/ Ken Schwaber Uwaga! Słabe tłumaczenie
5 SCRUM Tradycyjne metodologie wytwarzania oprogramowania dążą do szczegółowej kontroli całego procesu, w tym kontroli przydzielania zadań członkom zespołu oraz długoterminowego planowania prac, a następnie skrupulatnego rozliczania z postępów realizacji planu (por. kontrola lotów samolotów, odpowiedzialni są kontrolerzy r. l.) Załamanie scentralizowanej kontroli i systemu przydziału zadań wraz ze wzrostem złożoności projektów informatycznych Scrum (jedna z metodologii zwinnych, agile) – zaufanie do zespołu, skrócenie okresów produkcji do sprintów (krótsza perspektywa), plan zastąpiony przez zaległości produktowe (backlog, spis zadań), zaangażowanie klienta – częste wydania z nowymi funkcjonalnościmi (por. proste zasady ruchu drogowego, odpowiedzialny jest kierowca)
6 SCRUM Empiryczna kontrola procesu wytwarzania oprogramowania sposób na poradzenie sobie ze złożonością nieprzewidywalnością Widoczność – projekt jest przejrzysty dla kierownictwa i dla klienta. Żadne problemy nie są ukrywane, jasne kryterium „zakończone”. Inspekcja – częsta kontrola wszystkich aspektów rozwijanego oprogramowania i samego procesu (np. przeglądy jakości kodu) Adaptacja – natychmiastowe wdrożenie zaleceń inspektora, aktualizowanie priorytetów przed każdym sprintem (przebiegiem) W SCRUM nie ma etapu szczegółowej analizy, przygotowywania SRS. Już do pierwszego przebiegu z klientem wybierana jest konkretna funkcjonalność, która powinna zostać zaimplementowana po msc.
7 SCRUM Struktura SCRUM = przyrostowe iteracje http://www.methodsandtools.com/archive/archive.php?id=18 Zaległości produktu wybrane do implementacji w danej iteracji Sprint (przebieg, iteracja) od 2 tyg. do miesiąca Codzienne spotkania na stojąco (daily scrum) Ich cel to zabranie się do pracy, a nie myślenie o pracy Przyrost funkcjonalności produktu (możliwy do wdrożenia) Dziennik Zaległości (sortowany według aktual. priorytetów)
8 SCRUM SCRUM to iteracyjna metoda przyrostowa wytwarzania oprogramowania Reguły SCRUM: 1. reguła sashimi – każdy przyrost będący efektem pracy zespołu podczas sprintu musi być w pełni ukończony (def. „zrobione”), co obejmuje analizy, dokumentację, testy, itd. dla tego fragmentu produktu. - Tylko działające oprogramowanie (produkt) jest miarą postępu projektu. - Klient ocenia przydatność (do jego celów biznesowych) kolejnych, w pełni funkcjonalnych wydań produktu. - Jeżeli przyrost nieukończony, to braki wpisywane są do zaległości.
9 SCRUM Dziennik zaległości (backlog) jest stale sortowany zgodnie z aktualnymi priorytetami klienta. Może być zmieniany. Nie powinno się jednak zmieniać celów aktualnego sprintu ( kryzysowe przerwanie sprintu powinno być sytuacją wyjątkową) Reguły SCRUM: 2. brak zewnętrznego wpływu na przebieg sprintu, samoorganizacja ( skupienie na ustalonej pracy) 3. możliwa zmiana priorytetów zespołu podczas planowania sprintu ( najwyżej 14-30 dni straty)
10 SCRUM Świnie i kurczaki http://www.implementingscrum.com/cartoons/
11 SCRUM Role w SCRUM (świnie): Właściciel produktu – zadania: - zbiera początkowe i ogólne wymagania, - ustala (nieostateczną) wizję gotowego produktu (zwrot inwestycji) - ustala plan wydań i akceptuje produkt wytworzony w przebiegu, - zarządza dziennikiem zaległości produktowych (w tym sortowaniem zadań zgodnie z aktualnymi priorytetami) Odpowiedzialność za: zwrot kosztów inwestycji produktu – wybór funkcjonalności, które rozwiązują problemy biznesowe klienta ( sortowanie zaległości)
12 SCRUM Role w SCRUM (świnie): Zespół – optymalnie składa się z 5-9 osób - zespół sam ustala cel przebiegu (biorąc pod uwagę priorytety), - autonomicznie rozdziela prace między siebie, - dba o jakość kodu (inspekcje, rewizje), - zmienia zaległości produktowe w nowe funkcjonalności produktu, - pod koniec przebiegu prezentuje efekty właścicielowi produktu Odpowiedzialność: Zespół jest w pełni odpowiedzialny za zarządzanie samym sobą! W zespole nie ma hierarchii lub innej struktury, która utrudniałaby komunikację. To nie znaczy, że nie uznaje się doświadczenia i stażu. Zarządzanie = przeprowadzanie inspekcji (emp. kontr.) adaptacja
13 SCRUM Role w SCRUM (świnie): Scrum Master – nie jest kierownikiem projektu (project manager) - nie kieruje zespołem – zespół sam się organizuje, - nie sprawdza postępów prac i nie rozdaje dziennych zadań, - zamiast szefa jest raczej trenerem (także właściciela produktu), - pilnuje przestrzegania zasad SCRUM, pomaga wdrażać SCRUM, - dba o warunki pracy, usuwa przeszkody (techniczne i społeczne), zarządza kryzysami i konfliktami, chroni zespół przed utrudnieniami - chroni zespół przed właścicielem produktu i działem marketingu, ale również dba o dobrą komunikację z właścicielem produktu - dba o otwartość i prawdziwość informacji o postępie prac, informuje wszystkie strony (także kurczaki) o ew. trudnościach, - dba o integrację zespołu
14 SCRUM Role w SCRUM: http://www.ioz.pwr.wroc.pl/pracownicy/kuchta/Joanna_P%C5%82askonka_Scrum.pdf Właściciel produktuScrum MasterZespół
15 SCRUM Role w SCRUM (świnie): Ken Schwaber: Ważnym zadaniem Scrum Mastera jest dbanie o to, żeby zespół i właściciel produktu skupiali się na tym, co może zostać zrobione, a nie przeżywali frustracji z powodu rzeczy, które aktualnie nie mogą być wykonane. SCRUM to „sztuka rzeczy możliwych”. Ważne jest ograniczenie perspektywy czasowej do 30 dni: - pozwala zespołowi na skupienie się na bieżących zadaniach, ogranicza chaos zadań, krótkoterminowe plany działania, - utrzymuje zainteresowanie udziałowców projektem (widzą efekty i mają wpływ na wybieranie celów kolejnych iteracji)
16 SCRUM Daily scrum – prowadzone przez Scrum Mastera codzienne spotkanie przed rozpoczęciem pracy, nie dłuższe niż kwadrans (mogą być prowadzone na stojąco przy tablicy Kanban) Scrum Master zadaje każdemu członkowi zespołu trzy pytania: 1. Co zrobiłeś od ostatniego codziennego spotkania Scrum? 2. Co zrobisz do następnego spotkania (zobowiązanie)? 3. Co przeszkadza Ci w pracy? Uwaga! To nie oznacza, że Scrum Master: 1. Sprawdza i ocenia postępy prac 2. Przydziela zadania na kolejny dzień 3. Bezpośrednio wspiera zespół w tworzeniu kodu Celem spotkania jest zabranie się do pracy, a nie myślenie o pracy W razie problemów: spotkanie w mniejszych grupach po daily scrum
17 SCRUM Kurczaki – obserwatorzy: Wszystkie osoby zainteresowane sukcesem projektu, w tym: - zarząd firmy, - dział marketingu, - klienci (finansujący projekt), - przyszli użytkownicy produktu. Nie są zaangażowani w wytwarzanie oprogramowania. W trakcie sprintu kontakt z kurczakami poprzez właściciela produktu. Plan sprintu/całego procesu: - Jakich zmian oczekują klienci po zakończeniu sprintu/procesu? - Jakie są postępy po ostatnim sprincie? - Weryfikacja opłacalności inwestycji i wiarygodności zespołu.
18 Tablica Kanban Kanban (jap.) = widoczny spis KANBAN oznacza też metodologię prowadzenia projektów (por. Toyota Management System), w której kładzie się nacisk na ograniczenie bezczynności pracowników i ograniczenie zapasów. https://pl.wikipedia.org/wiki/Tablica_kanban http://www.xqa.com.ar/visualmanagement/2009/06/kanban-boards/
19 SCRUM Raporty ze sprintów – pełna przejrzystość Wspólna dla świń i kurczaków definicja „zrobione” Po sprincie cztery raporty (mogą być zwykłe arkusze, bez opisów): 1. Lista zaległości produktu sprzed ostatniego sprintu 2. Aktualna lista zaległości produktu (po bieżącym sprincie) 3. Raport zmian (szczegółowa lista różnic 2. – 1.) 4. Wygasający raport zaległości produktowych (może być w postaci wykresu wypalania, burnout chart)
20 SCRUM Przebieg sprintu w SCRUM: 1. Planowanie sprintu 2. Sprint (w tym codzienne spotkania) 3. Przegląd sprintu 4. Retrospekcja
21 SCRUM Przebieg sprintu w SCRUM: 1. Planowanie sprintu – pierwszy dzień cyklu, maksymalnie 8 godz. a. określenie zaległości produktowych (maks. 4 godz.) b. ustalenie zaległości dla najbliższego sprintu (zobowiązanie zesp.) Obecni: właściciel, Scrum Master, zespół, zaproszone kurczaki Efekt: lista zadań do najbliższego sprintu
22 SCRUM Przebieg sprintu w SCRUM: 2. Sprint – maksymalnie 30 dni (minimum dwa tygodnie) - realizacja przez zespół zobowiązań, zakaz ingerencji - codzienne spotkania (tylko zespół i Scrum Master) Efekt: gotowy do wdrożenia produkt z nową funkcjonalnością
23 SCRUM Przebieg sprintu w SCRUM: 3. Przegląd sprintu – ostatni dzień cyklu, maksymalnie 4 godz. - przygotowanie do przeglądu – ok. 1 godz. - prezentacja właścicielowi produktu i kurczakom wykonanej funkcjonalności (prezentowane jest tylko to, co w pełni „zrobione”) - to jest czas na komentarze i krytykę udziałowców (kurczaków)
24 SCRUM Przebieg sprintu w SCRUM: 4. Retrospekcja – ostatni dzień cyklu, maksymalnie 3 godz. - tylko członkowie zespołu (już po wyjściu kurczaków) - Co poszło dobrze podczas sprintu? Co może zostać poprawione? Cel: poprawienie funkcjonowania zespołu i wdrożenia SCRUM