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

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

Mały vs duży zespół ?

Metodyki tradycyjne vs zwinne ?

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

Scrum – zwinny project management

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

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

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

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

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

Kurczaki Wszyscy nie zaangażowani bezpośrednio w projekt

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

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

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?

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

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?

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

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

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

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

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

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”

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

User Stories Użyteczny mnemonik – INVEST IndependentNegotiableValuableEstimableSmallTestable

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…

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…

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

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

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

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

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

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

Best practices dla małych zespołów

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

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

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

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

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

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

Wysoki komfort pracy Brak nadgodzin

Pytania?