Zespół Developerski w Scrumie to interdyscyplinarna grupa składająca się ze wszystkich osób zaangażowanych w tworzenie Produktu. W dzisiejszym artykule przyjrzymy się, jakie powinien mieć cechy. Zastanowimy się też nad składem i obowiązkami Zespołu Developerskiego zdolnego do efektywnego osiągania postawionych przed nim Celów.
Zespół Developerski w Scrumie – omówione zagadnienia:
- Cechy Zespołu Developerskiego
- Skład Zespołu Developerskiego
- Obowiązki Zespołu Developerskiego
- Podumowanie
Cechy Zespołu Developerskiego
Zespół Developerski pracujący zgodnie z zasadami Scrum to samodzielna grupa specjalistów. Nie korzysta ze wsparcia zewnętrznych specjalistów ani z pomocy podwykonawców. Co jednak decyduje o tym, że Zespół jest dobrze dobrany do wykonania postawionego przed nim Celu? I jakie obowiązki wchodzą w zakres zadań Zespołu Developerskiego – niezależnie od jego specjalizacji?
Zespół Developerski, aby działać skutecznie musi posiadać co najmniej trzy cechy: zdolność do samoorganizacji, dążenie do rozwoju, oraz interdyscyplinarność.
Samoorganizacja
Gdy mówimy o Scrum Team, którego częścią jest Zespół Developerski, używamy określenia „samozarządzanie”. Oznacza ono samodzielność na poziomie organizacji. Scrum Team jako całość decyduje nie tylko o tym, kto i jak wykona pracę, lecz także o tym, nad czym będzie pracować. W Scrum Team duża część zadań związanych z zarządzaniem spoczywa na barkach Product Ownera i Scrum Mastera.
Dlatego w przypadku Zespołu Developerskiego ważniejsza od samozarządzania jest samoorganizacja. Dotyczy ona planowania obowiązków, czyli samodzielnego decydowania o tym, kto będzie wykonywał określone zadania, kiedy i jak.
Dążenie do rozwoju
Kluczową cechą skutecznego Zespołu jest dążenie do rozwoju. Sposób realizacji postawionych przed nim zadań powinien być ambitny. Wynika to nie tylko z indywidualnych predyspozycji i nastawienia każdego z członków Zespołu Developerskiego. Do podnoszenia kompetencji i wysiłku skłania także atmosfera panująca w Zespole, która określa go jako całość.
Interdyscyplinarność
Interdyscyplinarność Zespołu oznacza, że jego członkowie razem wzięci powinni mieć wszystkie umiejętności niezbędne do stworzenia w każdym Sprincie wartościowego Przyrostu. Oznacza to również, że każdy z członków Zespołu wykonuje zadania niezbędne w danym Sprincie. Każdy robi to, co niezbędne do osiągnięcia Celu. Nawet jeśli oznacza to podejmowanie nowych zadań wykraczających poza kompetencje Developera. Błędem jest sztywne trzymanie się swoich zawodowych kompetencji czy roli.
Zespół Developerski – skład
Według Scrum Guide maksymalna ilość Developerów to osiem osób. Tak niewielki skład sprzyja komunikacji i otwartości, ponieważ członkowie Zespołu mają możliwość poznania się nawzajem. Zespół nie powinien być jednak mniejszy niż trzyosobowy. Musi być bowiem wystarczająco duży, żeby w każdym Sprincie mógł wykonać postęp widoczny z biznesowego punktu widzenia.
Developerami w ramach Scrum nazywane są osoby o bardzo zróżnicowanych umiejętnościach i zakresach obowiązków. W żadnym przypadku nazwa nie jest zarezerwowana dla osób zajmujących się programowaniem. W skład Zespołu wchodzić mogą zatem programiści i projektanci, badacze i analitycy, testerzy i naukowcy, a także inni specjaliści.
Wśród Developerów nie obowiązuje hierarchia. Dlatego nie posługują się oni tytułami zawodowymi czy naukowymi.
Ważnym założeniem dotyczącym składu zespołu Developerskiego jest stwierdzenie, że stanowi on jedność. Dlatego też nie powinno się z niego wyodrębniać mniejszych zespołów pracujących nad innymi Celami.
Obowiązki Zespołu Developerskiego
Zakres obowiązków Zespołu Developerskiego można podzielić na trzy obszary. Są to:
- planowanie swoich zadań
- praca nad produktem, oraz
- doskonalenie współpracy w Zespole.
Planowanie swoich zadań
Planowanie zadań to obowiązek, który wypełniają wszystkie Zespoły Developerskie działające według zasad Scrum. Polega ono na tworzeniu planu Sprintu i ujęciu go w Sprint Backlogu, który opiszemy w osobnym artykule. Najważniejsze, aby Zespół Developerski pracował nad nim wspólnie. W ten sposób każdy z Developerów będzie w stanie realistycznie określić ilość zadań do wykonania w danym Sprincie. Pozwoli to w dłuższym horyzoncie na utrzymywanie stałego tempa pracy Zespołu i bardziej trafne planowanie.
Równie ważne jest trzymanie ręki na pulsie, czyli codzienne dostosowywanie planu do realiów. Jeśli pojawiają się problemy, może pojawić się potrzeba zmiany: przeorganizowania zadań, innego rozdzielenia prac, albo rozmowy ze Scrum Masterem na temat wyłaniających się trudności.
Praca nad produktem
Formy pracy nad produktem mogą diametralnie się różnić w zależności od obszaru, w jakim działa dany Zespół Developerski. Najogólniej rzecz biorąc, celem do zrealizowania w każdym Sprincie jest stworzenie Przyrostu, czyli wartościowej biznesowo funkcji Produktu.
Przydatne jest tutaj wypowiedzenie wprost i stosowanie następującej zasady:
Podejmując pracę nad Produktem, trzeba zostawić go w stanie nie tylko ulepszonym, ale nie mniej wykończonym niż wersja poprzednia.
Stosowanie tej zasady oznacza, że Zespół jako całość bierze odpowiedzialność za Przyrost. Jeśli Developer wykonuje zadania niedbale, co sprawia, że jakość Produktu ulega pogorszeniu, to ktoś inny będzie musiał wykonać pracę za niego. Z drugiej strony, jeśli któryś z Developerów trafia na błędy w Produkcie, powinien naprawić je samodzielnie lub przekazać informację o błędzie osobie, która może to zrobić.
Więcej na temat pracy nad Przyrostem Produktu w ramach Sprintu napiszemy w osobnym artykule.
Doskonalenie współpracy w Zespole
Praca nad sposobem działania Zespołu to nieustanne doskonalenie wydajności i skuteczności działań poszczególnych Developerów.
Jest to jednak również – a może przede wszystkim – praca nad komunikacją pomiędzy Developerami. Doskonalenie polega na wypracowywaniu rozwiązań umożliwiających sprawny i trafny podział zadań. A także na ćwiczeniu umiejętności:
- krytykowania rozwiązań, a nie ludzi – zmiana języka, którym opisujemy pracę prowadzi do zmiany nastawienia i polepszenia współpracy
- zdystansowania się od swoich pomysłów– dzięki niej tworzy się miejsce na poczucie humoru i bardziej szczerą informację zwrotną
- budowania zaufania– dzięki zaufaniu może pojawić się znacznie więcej innowacyjnych pomysłów proponowanych przez Developerów bez obaw o negatywną reakcję otoczenia
Doskonalenie współpracy w Zespole dokonuje się dzięki bieżącej refleksji nad sposobem działania Zespołu i udzielaniu informacji zwrotnych podczas Wydarzeń Scruma opisanych w tym artykule.
Podsumowanie
W dzisiejszym artykule przybliżyliśmy cechy, skład i obowiązki, jakie powinien mieć Zespół Developerski działającego według zasad Scrum. Interdyscyplinarność, samoorganizacja i dążenie do rozwoju cechujące ten niewielki, kilkuosobowy zespół – to jego najważniejsza charakterystyka. Zaś ciągłe doskonalenie zespołowej pracy i efektywna praca nad produktem – to zadania, jakie stoją przed każdym Zespołem Developerskim.
Sprawdź nasz kolejny wpis z tej serii: Najczęstsze błędy popełniane przez Developerów
Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?