JavaDevMatt.pl – Mateusz Kupilas

Programista, przedsiębiorca, gamedev, bloger.

Organizacja pracy, czyli scrum w praktyce

Chciałbym podzielić się z Wami moimi doświadczeniami ze scrumem. Wiele z tego co opiszę nie ma może w 100% pokrycia z teorią, która stoi za czystym scrumem, ale chciałbym przybliżyć to, jak w praktyce wyglądała moja codzienna praca.

Scrum był w moim odczuciu często traktowany jako pewnego rodzaju ideał procesu, do którego warto dążyć, ale w praktyce nigdy się go nie osiągnie. Czy to przez różne aspekty biznesowe, czy nagłe zmiany decyzji, przez które mocno nagina się często tę metodykę.

To co chcę omówić znajduje się w moim filmie z serii “Programista Na Emigracji”, ale jeśli wolicie to w formie artykułu, to zapraszam.

 

Iteracja

To co moim zdaniem najbardziej wartościowe w scrumie: krótkie iteracje, po których można nanosić poprawki. Nie marnujemy czasu gdy zauważymy, że coś nie działa dopiero po zakończeniu całego projektu, lecz przez krótkie iteracje możemy często coś ulepszać, czy ewentualnie całkowicie coś wyrzucić jeśli uznamy to za zbędne.

  • Planujemy swoją pracę na najbliższą iterację: np. 2 tygodnie.
  • Po takiej iteracji sprawdzamy wyniki: jeśli nie jesteśmy zadowoleni ustalamy co zmieniamy podczas następnej iteracji (sprintu).
  • Owocem każdego sprintu jest mała, ale funkcjonalna część produktu, którą można już testować na potencjalnym kliencie i nanosić poprawki/wyrzucać to co zbędne, albo irytuje niepotrzebnie klienta.
  • Po zakończeniu każdego sprintu następuje retrospektywa z całym zespołem: co możemy w następnym sprincie zrobić chociaż trochę lepiej?

iteracja

User story

Zanim zaczniemy nad czymś pracować, należy zdefiniować jaką ma to korzyść dla klienta. Ustalamy:

  • Dla kogo dana funkcjonalność jest użyteczna.
  • Co to za funkcjonalność.
  • Dlaczego ta funkcjonalność dla tego konkretnego użytkownika jest użyteczna.

Korzystamy ze schematu: jako <user> chcę <nazwa nowej funkcji>, ponieważ <powód>.

Prosty przykład klienta, który korzysta z aplikacji do zamawiania jedzenia. Zakładamy, że ma już założone konto ze swoimi danymi, np. ma tam zaznaczone, że ma alergię na orzechy.  W tym momencie user story może wyglądać następująco: jako alergik, chcę mieć możliwość filtrowania dostępnych potraw ze względu na składniki, ponieważ mam na niektóre alergię (na np. orzechy). Czasami brzmi to wszystko jak “masło maślane”, ale takie szczegółowe zdefiniowanie pozwala na uniknięciu wielu błędów.

Po takim zdefiniowaniu przechodzimy do bardziej szczegółowego opisu zadania. Definiujemy co dokładnie ma być spełnione, by dana część mogła znaleźć się nowej wersji produktu. Nie zawsze znajdziemy tu dużo szczegółów implementacji technicznej, ponieważ user story ma być czytelny dla każdego np. członków zarządu, którzy chcą mieć wgląd w pracę poszczególnych zespołów.

 

Backlog

Backlog to miejsce, do którego trafiają wszystkie user story. Są one porządkowane według priorytetu oraz następuje estymacja przez zespół. Estymacja niekoniecznie musi oznaczać 5-10 dni na zadanie, lecz zazwyczaj są to wartości relatywne do siebie. Np. dane zadanie dostało 8 punktów, następnie zespół widzi, że kolejne zadanie jest bardzo podobne, więc również przydziela mu 8 punktów (ewentualnie więcej/mniej). Po paru sprintach w zespole pojawia się jakaś miara dla zespołu (velocity), czyli ile średnio punktów jest w stanie zrobić na jedną iterację. Dzięki takiemu procesowi łatwiej jest planować wydanie projektu: mając 250 punktów w backlogu, oraz średnią 25 punktów na sprint: łatwo wyliczyć, że projekt będzie gotowy za około 10 sprintów. Do backlogu trafiają również błędy programu (bugi), które dostaną przydzielony odpowiedni priorytet. Podobnie jak user story przydziela się je do sprintów. Nie przydziela się za nie punktów, ponieważ traktuje się je jako pracę, która byłą wymaga w poprzednich już opunktowanych komponentach.

Retrospektywa

Ile razy mieliście to wrażenie, że po zakończeniu jakiegoś projektu pojawia się wiele wniosków… jeśli wiedzielibyście to od początku, to wszystko można by było usprawnić i uniknąć paru komplikacji. Właśnie temu służy retrospektywa. Tutaj każdy osoba z zespołu się wypowiada: z czego jest zadowolona, co poszło nie tak, co możemy usprawnić? Przez taką retrospektywę co jedną iterację wiele błędów w procesie może zostać szybko wyłapanych i naprawionych.

Retrospektywę moderuje Scrum Master: szczegóły poszczególnych ról w scrumie pojawią się następnym artykule.

CI, czyli działająca wersja produktu

Zadania, które zostały wykonane po danej iteracji, trafiają do nowej wersji produktu. Nawet gdy jest to bardzo wczesna faza projektu, to mając gotowe takie pierwsze kroki jak logowanie i zmiana swoich danych w aplikacji, to można już tą prostą funkcjonalność przetestować z użytkownikiem i wprowadzić ewentualne poprawki, jeśli coś nie działa tak jak to zaplanowaliśmy (aplikacja jest nieintuicyjna, czy całość działa za wolno/niestabilnie).

Mając co 2 tygodnie (czy inną założoną, stałą iterację) nową wersję produktu, z paroma nowymi funkcjami można również efektywnie testować produkt, by szybko wyłapać krytyczne błędy, których koszty naprawy znacznie by wzrosły, gdyby wykryto je dopiero tuż przed premierą produktu.

Daily stand-up

To codziennie spotkanie zespołu: każdy mówi nad czym pracował, co ma za problemy, w których ktoś by musiał mu pomóc, a co poszło sprawnie.

Taka codzienna komunikacja o określonej godzinie ma jedną ogromną zaletę: programiści nie zakłócają się podczas swojej pracy w ciągu dnia. Jeśli mamy pytanie, to staramy się je zadawać właśnie podczas tego meetingu. Jeśli jest to coś dużego, przez co jesteśmy totalnie zablokowani, to oczywiście nie ma problemy pytać w ciągu dnia, ale docelowo dąży się do tego, by takie pytania zadawać właśnie podczas dialy stand-upu.

banerjd

,

3 thoughts on “Organizacja pracy, czyli scrum w praktyce

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *