Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule - napisali niegdyś mądrzy ludzie i zespół w tej postaci jest super. Jednakże robiąc przegląd inwentarza, możesz dojść do wniosku, że stan rzeczy rzeczy w Twoim zespole oraz zasoby, którymi dysponujesz, odbiegają od tego docelowego obrazka. Co wtedy?
W takiej konstelacji możesz się spodziewać następujących objawów:
Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:
Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):
Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.
Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.
Przykładowe zadania, w których analityk może wspierać zespół:
Co jest?
Może się dla przykładu okazać, że "dostałeś" pięciu programistów, trzech testerów, analityka oraz Scrum Mastera z nadania, który ostatnimi czasy poświęcał się wyłącznie zarządzaniu.W takiej konstelacji możesz się spodziewać następujących objawów:
- Polaryzacja między testerami a programistami; nie piszę "wrogość", lecz właśnie polaryzacja my-wy: wy zrobiliście błąd, wy skopaliście testy, my coś zaimplementowaliśmy, itp.
- Programiści mają chroniczny opór przed testowaniem
- Testerzy biorą znikomy udział w planowaniu
- Analityk nie za bardzo może znaleźć swoje miejsce w zespole
- Pojawia się zastanawiająco dużo spadów z poprzednich sprintów
Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:
Jak mogłoby być?
Długoterminowym celem mogłoby być oczywiście doprowadzenie do sytuacji, w której każdy jest wspomnianym "developerem", ale o tym na początku lepiej nie mówić głośno:)
Co pomiędzy?
Sądzę, że w takiej sytuacji kluczowe jest, nie tyle męczyć ludzi, aby byli idealnym zespołem, co wydobyć tu i teraz to, co najlepsze. Bardzo dobrym początkiem będzie przeorganizowanie sposobu planowania. Otóż:- Planujcie podgrupami dzielonymi względem testerów, np. tester+2*programista
- Każda grupa otrzymuje swoje US, które dzieli na zadania
- Analityk chodzi i doradza :)
- Wyodrębniajcie zadania: programistyczne, testerskie, analityczne
- Po zakończeniu dekomponowania grupa przedstawia swoje US, a reszta zadaje pytania kontrolne Czy uwzględniliście to, a to? i jeśli nie, to dodajemy kolejne zadania (uwaga celowo jest tu odwrócenie: grupa nie przedstawia swoich zadań, lecz odpowiada na pytania kontrolne zespołu, gdyż w przeciwnym razie zamęczycie się i zanudzicie
Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):
- Jak oceniam współpracę między testerami a programistami?
- Czy wciąż mówimy o sobie my-wy?
- Czy będziemy mieli spady w najbliższej iteracji?
- Jak dużo zadań doszło w trakcie iteracji? Jakiego rodzaju były to zadania?
Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.
Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.
Przykładowe zadania, w których analityk może wspierać zespół:
