Przewodnik po Scrumie | 14. Błędy programistów

Opublikowany: 2022-04-26

Zespół Deweloperski to grupa niezależnych profesjonalistów. Jednak sukces realizowanego przez nich projektu zależy od ich wspólnych wysiłków. A to wymaga dużej dojrzałości i umiejętności pracy zespołowej. Jakie są najczęstsze błędy programistów? Które z nich utrudniają lub wręcz uniemożliwiają osiągnięcie Celu Produktowego?

Częste błędy programistów – spis treści:

  1. Częste błędy programistów
  2. Zbytnie przywiązanie do swoich pomysłów
  3. Samozatrudnienie
  4. Wycofanie się programisty
  5. Niezależność
  6. Ograniczenie odpowiedzialności do zakresu uprawnień
  7. Bałagan w backlogu sprintu
  8. Streszczenie

Częste błędy programistów

Wiele błędów Developerów pracujących w Scrumie ma swoje źródło w ich podejściu do pracy zespołowej. Z jednej strony to źle rozumiana niezależność i obrona własnych pomysłów przed interesami zespołu. Z drugiej strony to poleganie na innych i brak niezależności. Innym źródłem problemów może być niezrozumienie odpowiedzialności zespołu.

The most common mistakes of Developers

Zbytnie przywiązanie do swoich pomysłów

Codzienne obowiązki programistów obejmują znajdowanie innowacyjnych rozwiązań złożonych problemów. Wysiłek włożony w opracowywanie rozwiązań może spowodować, że nadmiernie przywiążą się do swoich pomysłów. To z kolei sprawia, że ​​tracą z oczu Cel Produktowy i spędzają zbyt dużo czasu na opracowywaniu rozwiązań pobocznych, które nie są przydatne z biznesowego punktu widzenia. A także mniej chętnie szukają alternatywnych rozwiązań, co zagraża zwinności Zespołu.

Samozatrudnienie

Jeśli któryś z programistów ma trudności ze zrozumieniem swojej roli w zespole, spróbuje oddzielić swoje zadania od celu sprintu. Co gorsza, zrobią je bez odniesienia do reszty zespołu. Problemem może być również samowolne wprowadzanie zmian w Backlogu Sprintu. W ten sposób niezrozumiana niezależność jednego z Developerów może wynikać z problemów komunikacyjnych.

Nadmierna chęć niezależności może wynikać z braku uznania dla indywidualnych dokonań Developera . Pojawia się, gdy jego wkład w pracę wykonywaną przez Zespół jest oceniany nieproporcjonalnie do włożonego wysiłku i trudności zadania.

Praca na własną rękę może stać się źródłem poważnego konfliktu w zespole. Dlatego tak ważne jest, aby Scrum Master jak najszybciej zareagował i rozwiązał leżący u podstaw problem. Dzieje się tak dlatego, że może się okazać, że błąd nie leży po stronie Developera, ale przy błędnej ocenie jego zaangażowania.

Wycofanie się programisty

Problem wynikający z dwóch poprzednich – samodzielnej pracy i nadmiernego przywiązania do własnych pomysłów – może być problemem braku komunikacji. Następnie ci Deweloperzy zaczynają izolować się od Zespołu. Choć wykonują swoje zadania zgodnie z Backlogiem Sprintu, wycofują się z życia Zespołu.

W takiej sytuacji Scrum Master powinien zwrócić szczególną uwagę na wycofanych Developerów. Doceń ich wkład w Zespół i zachęć ich do przyjęcia proaktywnej postawy.

Niezależność

Samoorganizacja to cecha dojrzałego, dobrze skomponowanego Zespołu Deweloperskiego , o którym pisaliśmy w poprzednim artykule. Oznacza to, że mimo trudności Deweloperzy nie polegają na innych ludziach, którzy powiedzą im, jak rozdzielać między sobą zadania, jak i kiedy je wykonać. Jednak samoorganizacja może prowadzić do nieporozumień interpersonalnych.

W takim przypadku konieczne jest, aby Scrum Master był cały czas obecny, aby upewnić się, że zadania, które należy wykonać, aby osiągnąć Cel Sprintu, są rozdzielone. Wtedy pojawia się problem zależności Deweloperów .

Ponownie, Scrum Master powinien przyjść z pomocą, zachęcając członków Zespołu Deweloperskiego do samostanowienia i wzięcia odpowiedzialności za swoje zadania.

Ograniczenie odpowiedzialności do zakresu uprawnień

Kolejnym problemem, z którym muszą się zmierzyć Deweloperzy, zwłaszcza w zespole tworzącym, jest niechęć do wykonywania zadań innych niż te należące do podstawowych kompetencji Dewelopera.

Ten błąd może doprowadzić do znacznego obniżenia efektywności Zespołu Deweloperskiego. Nie wszystkie Sprinty wykorzystują podstawowe kompetencje każdego członka Zespołu. Dlatego muszą być otwarci na wykonywanie innych, pomocniczych lub organizacyjnych zadań , które są równie istotne dla Celu Sprintu.

common mistakes

Bałagan w backlogu sprintu

Jednym z takich zadań jest utrzymanie porządku w Backlogu Sprintu. To kluczowe zadanie dla sprawnego działania Zespołu Deweloperskiego. Częstym błędem jest jednak przerzucanie odpowiedzialności za jego utrzymanie pomiędzy programistami. Utrudnia to nie tylko pracę nad Celem Sprintu, ale także rozwój Zespołu i jego ciągłe doskonalenie.

Częste błędy programistów -podsumowanie

Podsumowując, do najczęstszych błędów Developerów należą próby odcięcia się od Zespołu jako całości: samodzielna praca, forsowanie własnych pomysłów i wycofanie się. Integralności Zespołu Deweloperskiego zagrażają również problemy z rozwijaniem niezależności, bałagan w Backlogu Sprintu oraz niechęć Developerów do wykonywania obowiązków wykraczających poza ich podstawowe kompetencje.

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 | 14. Mistakes of Developers 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