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:

  1. Cechy Zespołu Developerskiego
  2. Skład Zespołu Developerskiego
  3. Obowiązki Zespołu Developerskiego
  4. 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.

development team features

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.

Development Team in Scrum

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.

Scrum Guide | 13. Zespół Developerski w Scrumie caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?