Przewodnik po Scrumie | 13. Zespół programistów w Scrum

Opublikowany: 2022-04-25

Zespół Deweloperski w Scrum to interdyscyplinarna grupa składająca się ze wszystkich osób zaangażowanych w tworzenie Produktu. W dzisiejszym artykule przyjrzymy się, jakie cechy powinien mieć. Zastanowimy się również nad składem i zakresem odpowiedzialności Zespołu Deweloperskiego, który jest w stanie skutecznie realizować swoje Cele.

Zespół Deweloperski w Scrum – spis treści:

  1. Funkcje zespołu programistów
  2. Zespół programistów
  3. Obowiązki Zespołu Deweloperskiego
  4. Streszczenie

Funkcje zespołu programistów

Zespół Deweloperski pracujący zgodnie z zasadami Scrum to niezależna grupa specjalistów. Nie korzysta ze wsparcia zewnętrznych specjalistów czy podwykonawców. Ale co decyduje o tym, że Zespół jest dobrze dobrany do osiągnięcia Celu? A jakie obowiązki kryją się w zadaniach Zespołu Deweloperskiego – niezależnie od jego specjalizacji?

Aby być skutecznym, Zespół Deweloperski musi posiadać co najmniej trzy cechy: zdolność do samoorganizacji, dążenie do rozwoju oraz interdyscyplinarność.

Samoorganizacja

Mówiąc o Zespole Scrumowym, którego częścią jest Zespół Deweloperski, używamy określenia „zarządzanie sobą”. Oznacza to samozarządzanie na poziomie organizacji. Zespół Scrumowy jako całość decyduje nie tylko o tym, kto i jak wykona pracę, ale także nad czym będzie pracował. W Zespole Scrumowym duża część zadań zarządczych należy do Product Ownera i Scrum Mastera.

Development Team

Dlatego w przypadku Zespołu Deweloperskiego ważniejsza jest samoorganizacja niż samozarządzanie. Odnosi się do planowania obowiązków, czyli samodzielnego decydowania, kto będzie wykonywał określone zadania, kiedy i jak.

Dążenie do rozwoju

Kluczową cechą efektywnego Zespołu jest dążenie do wzrostu. Sposób realizacji postawionych przed nim zadań powinien być ambitny. Wynika to nie tylko z indywidualnych predyspozycji i postawy każdego członka Zespołu Deweloperskiego. Podnoszeniu kompetencji i wysiłkowi sprzyja również atmosfera w Zespole, która definiuje go jako całość.

Interdyscyplinarność

Interdyscyplinarność Zespołu oznacza, że ​​jego członkowie wspólnie powinni posiadać wszystkie umiejętności niezbędne do tworzenia wartościowego Przyrostu w każdym Sprincie. Oznacza to również, że każdy członek Zespołu wykonuje zadania niezbędne do tego Sprintu. Każdy robi to, co jest konieczne do osiągnięcia Celu. Nawet jeśli oznacza to podjęcie nowych zadań wykraczających poza kompetencje programisty. Błędem jest sztywne trzymanie się swoich kompetencji zawodowych lub roli.

development team features

Zespół programistów

Według Scrum Guide maksymalna liczba programistów to ośmiu. Tak niewielka kompozycja zachęca do komunikacji i otwartości, ponieważ członkowie Zespołu mają możliwość poznania się nawzajem. Zespół nie powinien jednak być mniejszy niż trzy osoby. Musi być wystarczająco duży, aby w każdym Sprincie dokonywać widocznych postępów biznesowych.

Deweloperzy w Scrumie nazywani są ludźmi o szerokiej gamie umiejętności i obowiązków. W żadnym wypadku nazwa nie jest zarezerwowana dla osób zajmujących się programowaniem. W skład Zespołu mogą więc wchodzić programiści i projektanci, badacze i analitycy, testerzy i naukowcy, a także inni specjaliści.

Wśród programistów nie ma hierarchii. Dlatego nie używają tytułów zawodowych ani naukowych.

Ważnym założeniem dotyczącym składu zespołu deweloperskiego jest to, że stanowi on jedność. Dlatego mniejsze zespoły pracujące nad innymi Celami nie powinny być od niego oddzielane.

Obowiązki Zespołu Deweloperskiego

Zadania Zespołu Deweloperskiego można podzielić na trzy obszary. To są:

  • Planowanie zadań
  • Praca nad produktem
  • Poprawa współpracy w zespole

Planowanie zadań

Harmonogramowanie zadań to obowiązek, który muszą spełnić wszystkie Zespoły Deweloperskie oparte na Scrumie. Polega na stworzeniu planu Sprintu i umieszczeniu go w Backlogu Sprintu, co opiszemy w osobnym artykule. Najważniejsze jest to, że Zespół Deweloperski pracuje nad tym wspólnie. W ten sposób każdy z Developerów będzie mógł realistycznie określić ilość zadań do wykonania w danym Sprincie. Na dłuższą metę pozwala to zespołowi utrzymać stałe tempo i dokładniej planować.

Równie ważne jest pilnowanie pulsu, czyli codzienne dostosowywanie planu do rzeczywistości. Jeśli pojawią się problemy, może zaistnieć potrzeba zmiany: przeorganizowania zadań, innego rozłożenia pracy lub porozmawiania ze Scrum Masterem o pojawiających się trudnościach.

Praca nad produktem

Formy pracy nad Produktem mogą się diametralnie różnić w zależności od obszaru, w którym działa dany Zespół Deweloperski. Ogólnie rzecz biorąc, celem do osiągnięcia w każdym Sprincie jest stworzenie Przyrostu, czyli cechy Produktu o wartości biznesowej.

Warto tutaj mówić bezpośrednio i stosować następującą zasadę:

Kiedy podejmujesz pracę nad Produktem, musisz pozostawić go w stanie nie tylko ulepszonym, ale nie mniej gotowym niż poprzednia wersja.

Stosowanie tej zasady oznacza, że ​​Zespół jako całość bierze odpowiedzialność za Przyrost. Jeśli Programista wykonuje zadania niedbale, powodując pogorszenie jakości Produktu, ktoś inny będzie musiał wykonać za niego pracę. Z drugiej strony, jeśli Deweloper natrafi na błędy w Produkcie, powinien je naprawić samodzielnie lub przekazać informacje o błędzie komuś, kto może to zrobić. Więcej o pracy nad Przyrostem Produktu w sprincie napiszemy w osobnym artykule.

Poprawa współpracy w zespole

Praca nad sposobem działania Zespołu polega na ciągłym podnoszeniu wydajności i efektywności poszczególnych Programistów.

Jednak to także, a może przede wszystkim, praca nad komunikacją pomiędzy Developerami. Usprawnienie polega na wypracowaniu rozwiązań umożliwiających sprawny i dokładny podział zadań. A także ćwiczenie umiejętności:

  • krytykować rozwiązania, a nie ludzi – zmiana języka, którym opisujemy pracę, prowadzi do zmiany postawy i lepszej współpracy
  • dystansowanie się od swoich pomysłów – daje to poczucie humoru i bardziej szczery feedback
  • budowanie zaufania – dzięki zaufaniu innowacyjnych pomysłów Deweloperów może być o wiele więcej bez obaw o negatywną reakcję otoczenia

Poprawa współpracy w zespole jest osiągana poprzez nieustanną refleksję nad tym, jak działa Zespół i przekazywanie informacji zwrotnych podczas wydarzeń Scrum opisanych w tym artykule.

Development Team in Scrum

Streszczenie

W dzisiejszym artykule przedstawiamy charakterystykę, skład i obowiązki Zespołu Scrum Development. Interdyscyplinarność, samoorganizacja i chęć rozwoju charakteryzują ten mały zespół. A ciągłe doskonalenie pracy zespołowej i efektywna praca nad Produktem – to zadania, które musi spełnić każdy Zespół Deweloperski.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube.

Scrum Guide | 13. Development Team in Scrum caroline becker avatar 1background

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu