29 11 2014

Poprzedni wpis o scrumie. <-

Po ostatnim odcinku Programisty Na Emigracji – Organizacja pracy, czyli scrum w praktyce, pojawiło się parę pytań.

M. in. Krystian słusznie zauważył w komentarzu na YT, że to co omawiam w filmiku to nie do końca scrum. Zgadza się. Na tyle przeistoczyliśmy ten system, tyle rzeczy robimy po swojemu, że może powinniśmy już inaczej nazywać nasz system pracy. Tutaj cały komentarz:

Na koniec Sprintu jest najpierw Review, a potem Retro. Wydaje mi się, że w swojej wypowiedzi złączyłeś te spotkania w jedno. User Story to nie opis zadania, ale wymagania i zawsze muszą być wszystkie części, łącznie z uzasadnieniem. W Scrum role są tylko 3: Product Owner, Scrum Master, Developer (3-9 sztuk 🙂 ).
Jak mówisz, że nie macie Sprint Backlog, a potem pokazujesz tablicę z zadaniami? Przecież to jest Sprint Backlog. 🙂
Fajnie, że macie małe User Stories w Sprincie. Lepiej byłoby, gdyby pierwsze z góry były ukończone zanim kolejne będą rozpoczęte.
Pomimo narzędzi takich jak Trello, Jira, Version One, Rally, Banana Scrum i inne, nadal fizyczne karteczki są preferowane. Karteczki powinny zostać na tablicy, żeby osoba biorąca kolejne zadanie wiedziała co robią inne osoby i mogła lepiej podjąć decyzję.
Lepiej by było robić Daily Scrum przy tablicy, żeby było widać jak wygląda postęp Zespołu. I nie chodzi w nim o to, żeby innym nie przeszkadzać w ciągu dnia. Jak najbardziej trzeba komunikować się poza tym spotkaniem. Po to Zespół Developerski siedzi razem. Daily Scrum to spotkanie do wspólnego planowania kolejnego dnia pracy.
Do synchronizacji Zespołów korzystamy ze Scrum of Scrums.
Polecam sięgnąć do źródeł: http://www.scrumguides.org

Jest to oczywiście wszystko zgodne z prawdą: tak powinien wyglądać scrum. Z takiego punktu też startowaliśmy z zespołem, ale po wielu retrospektywach staraliśmy się zawsze coś małego poprawić… i po paru latach działania firmy nasz system pracy wyglądał tak jak go przedstawiłem. Dlatego dzisiaj chciałbym Wam pokazać jak wyglądały role w scrumie, a raczej w „scrumie”, który przeszedł wiele modyfikacji i działa sprawnie u nas. Każdy powinien samemu śledzić efekty pracy swojego zespołu i po prostu stosować techniki, które przynoszą dobre wyniki. Nie warto się trzymać sztywno teorii scrumowej.

Czas na konkrety: w tej formie scrumu, którą aktualnie stosujemy istnieją 4 role… właściwie to 5 😉, ale 4 są najistotniejsze.

1. Product Owner

Manager. On ma cały projekt w głowie. Zakłada wszystkie user story oraz je priorytezuje. Zajmuje się też bugami w backlogu: które są najważniejsze, które mogą poczekać? W końcu zespół nie może zajmować się wszystkim jednocześnie. Product Owner jest pierwszą osobą kontaktową jeśli coś nie działa, albo są pytania do produktu. Ważne by nie przeszkadzać developerom podczas ich pracy. Najgorsze co może się zdarzyć, to osoba z marketingu, która zakłóca pracę programistów z jakimś pomysłem, zamiast najpierw iść z tym pytanie/propozycją do product ownera. Jeśli należy podjąć jakąś decyzję, to idziemy do niego. Oczywiście konsultuje on wiele spraw z resztą zespołu, ale decyzję podejmuje on. Jest to osoba do kontaktu „na zewnątrz”, czy to z szefem firmy, czy do pytań inwestorów na temat produktu.

2. Scrum Master

Moderuje on daily standup – dba o to, by procesy były zachowane: np. nie przedłużać niepotrzebnie meetingów, tylko omówić to co istotne, a szczegóły niech sobie omówią zainteresowane osoby na osobności. Moderuje on retrospektywę zbiera wnioski i przedstawia je „wyżej”, czy to szefowi/zarządowi: co można usprawnić np. przetestujmy czy programiści lepiej pracują, jeśli mają możliwość pracy na stojąco, czy przyda się może kanapa w pokoju? 😉

I teraz czas na herezję: od jakiegoś czasu rolę scrum master w zespole przejął… programista. Jest to teraz osoba, która programuje oraz zajmuje się optmalizacją/zachowaniem procesów. Może to być kontrowersyjne, ale po wielu testach różnych optymalizacji w zespole, zaczęło się to całkiem dobrze u nas sprawdzać: jest to osoba, która „siedzi” w projekcie od środka i zna problemy, które ma zespół. Są również zespoły, które mają zewnętrznego scrum mastera: bo to się u nich sprawdza. Wniosek jest taki: z zespołem należy pracować i samemu wydedukować jak on pracuje poprawnie. Akurat u nas sprawdziła się dziwna hybryda scrum mastera/programisty, może dlatego, że to odpowiednia osoba na taką rolę i ciągnie ją do tego po prostu. Nie znaczy to, że taka konfiguracja sprawdzi się w innym zespole. Eksperymentujcie , wyciągajcie wnioski i stosujecie to co działa.

3. Developer

Czyli osoba, która pracuje nad kodem źródłowym, czasami w zespole jest również grafik/designer, ewentualnie grafika jest dostarczana z zewnątrz. U nas akurat 100% to programiści, a designer jest dzielony między zespołami wewnątrz firmy. Dąży się do tego, by jeden programista mógł docelowo pracować nad każdym elementem projektu: mógł nanieść poprawkę w webserwisie, coś pogrzebać w bazie danych, aplikacji mobilnej, czy frontendzie strony www. W praktyce każdy ma swoją specjalizację: np. ja jestem od androida, ale gdy zdarzy się sprint, gdzie 90% pracy to przebudowa czegoś serwerowego, to też staram się w miarę możliwości tam pomóc. Każdy ma specjalizację, ale dąży do tego, by miał jakąś przynajmniej podstawową wiedzę z innych elementów projektu.

4. Story owner

Niestandardowa rola, którą dodaliśmy do całego procesu. Przez jakiś czas mieliśmy niedobór product ownerów (jeden PO był odpowiedzialny za 2 zespoły, przez miesiąc była nawet potrzeba zarządzania 3 zespołami, bo po prostu dwóch się zwolniło i trochę trwa zatrudnić kogoś nowego), więc stworzyliśmy nową rolę… która pozostała nawet po unormowaniu się sytuacji z product ownerami. Jest to story owner. O co tu chodzi? Chodzi o przypisanie jednej osoby (developera) do jednego story, by ten się w nią trochę zgłębił. Co ewentualnie zapomnieliśmy zdefiniować? Gdzie mogą pojawić się problemy techniczne? Zazwyczaj podczas jednego sprintu (u nas 2 tygodnie), każdy developer miał jedne story przypisane jako „jego”. Przy zespole z 6 programistami było to znaczne odciążenie product ownera. Na wgłębienie się w user story i ewentualne wyjaśnienie niejasności poświęcało się mniej więcej godzine/dwie. Nie dużo, ale przy 6 programistach odciążyliśmy product ownera o ponad jeden dzień roboczy. Proste i skuteczne. Nikogo nie chcę przekonywać, by taką rolę przypisywać do scrumu. Ot u nas takie coś działa i chciałem podzielić się z Wami tą informacją.

5. …Cookie Commissioner

Co sprint wybiera się osobę, która załatwi coś miłego dla zespołu. Czy to zorganizuje wspólny wypad na piwo/gokarty, czyli doda termin do google kalendarza i ustali kiedy każdemu pasuje, czy po prostu przyniesie ciasteczka na retrospektywę. Ot niech zrobi coś małego, miłego co poprawi nastrój w zespole. 🙂 Również rola niestandardowa.

Co dalej z kanałem JavaDevMatt? Parę informacji. Three Years Later – losowanie płyty oraz aukcja charytatywna