Scrum - programiści pracujący poza Sprintem

Zespół Scrumowy

• 3 x programistów
• 2 x testery
• 1 x analityk testów automatyki

Nie jesteśmy zespołem wielofunkcyjnym, ponieważ programiści nie testują, a testerzy nie rozwijają się. Uważam, że jest to główna przyczyna problemu.

Obecnie wykonujemy dwutygodniowe sprinty.

Na początku sprintu wszyscy są zajęci, programiści rozpoczynają prace programistyczne, a testerzy przygotowują testy (pisząc przypadki testowe itp.)

Po zakończeniu przygotowań testerzy czekają na zakończenie prac programistycznych LUB prace programistyczne zostały zakończone, a programiści czekają na informacje zwrotne / błędy.

Deweloperzy swędzą tutaj i zaczynają pracować nad elementami w zaległościach, które są poza bieżącym sprintem. Wywołało to dziwny efekt, w którym zawsze pracujemy nad kolejnymi sprintami w bieżącym sprincie. Dla mnie to nie wydaje się właściwe.

Z punktu widzenia zarządzania woleliby raczej, aby programiści pracowali, niż siedzieli przy biurkach i nie robili nic, ale jednocześnie uważam, że celem zespołu scrumowego jest skupienie się wyłącznie na bieżącym sprincie. Chciałbym, aby nasz zespół był wielofunkcyjny, ale niestety nie jest to możliwe. Testerzy nie mają umiejętności niezbędnych do wykonywania prac programistycznych, a większość programistów uważa, że ​​testy są pod nimi.

Czy jest to uważane za problem w scrumie? Czy jest na to rozwiązanie? Czy scrum działa tylko z zespołami wielofunkcyjnymi?

Chciałbym poznać doświadczenia innych ludzi, jeśli to możliwe :)

To dość powszechny problem powodowany przez potok . Zespół jest wielofunkcyjny, ale oczywiście istnieją wewnętrzne silosy, które zmniejszają wydajność.

Po pierwsze, chciałbym zwrócić uwagę na kilka rzeczy, które moim zdaniem są ważne:

1. Jeśli programiści opracowują iterację z wyprzedzeniem, uprzedzają spotkanie planistyczne. Kierownik produktu i zespół muszą odpowiednio omówić, co jest najcenniejsze dla następnej iteracji. Priorytety nie powinny być skutecznie wykonywane przez programistów, ponieważ nie mają nic lepszego do roboty.

2. Bez względu na to, jak dzielisz i aranżujesz iteracje, nie możesz tak naprawdę zajmować wszystkich przez cały czas i mieć jednego zespołu na jednym spotkaniu planistycznym, o ile Twój zespół ma specjalistów pracujących w silosach. Nawet przy czystym wodospadzie nadal będziesz musiał „rzucić rzeczy na ścianę” i czekać na informację zwrotną.

3. Masz również problem polegający na tym, że często jedna historia musi mieć fazę rozwoju, następnie fazę testowania, a następnie fazę naprawy błędów, a następnie ... może to naprawdę sprawić, że Twój zespół będzie nieefektywny - szczególnie, jeśli pracują wcześniej , ponieważ muszą zmienić kontekst.

Oczywiście ta sytuacja ma bardzo realny koszt: zespół nie współpracuje. Spotkałem się z tym za każdym razem, gdy zaangażowany był zespół ds. Kontroli jakości, więc miałem trochę czasu na wypróbowanie różnych rozwiązań.

Dla mnie bardzo dobrze działały te dwa narzędzia:

1. Podkreśl zasadę, że cały zespół jest odpowiedzialny za wykonanie zadań. Odrzuć historie o „dev done”, ponieważ są one dla programistów sposobem na powiedzenie „już nie mój problem”, co nie jest ani konstruktywne, ani ewidentnie fałszywe. Jeśli zespół nie dostarczy opowieści, którą zaakceptował, to cały zespół nie dostarczył.

2. Aby zająć czas zarówno programistom, jak i kontroli jakości, sparuj je . Jest to zdecydowanie najlepszy sposób dzielenia się wiedzą i domeną, jaki możesz wybrać. Programiści mogą pomóc testerom w automatyzacji ich zadań. Testerzy mogą pokazać programistom, gdzie ważne jest przetestowanie kodu, ponieważ jest on kruchy. Zarówno współpracują, jak i pracują szybciej niż nie.

Korzystając z tych dwóch technik, zespół powinien być mniej wyciszony i bardziej wydajny. Podczas gdy testerzy i programiści nie są w stanie zamieniać zadań, będą mogli pracować jako zespół i rozwiązać problem wewnętrznie, zamiast obwiniać siebie nawzajem.

Nie ma problemu ze sposobem pracy związanym z SCRUM i sprintami, pod warunkiem, że w czasie oceny będzie zapisywane, że prace programistyczne zostały ukończone w krótszym czasie (i o ile krócej) niż zaplanowano. Pozwoli to zespołowi zdobyć więcej punktów historii na następny sprint. W końcu celem sprintu jest lepsze planowanie. Oczywiście nadal masz pole do poprawy.

zawsze pracujemy nad kolejnymi sprintami w bieżącym sprincie

Zaraz! W Scrumie jest to technicznie niemożliwe. Nie wiesz, jakie elementy zaległości będą w następnym sprincie, który zostanie ustalony na początku następnego sprintu w sesji planowania sprintu.

Ciekawe jest poznawanie nowych kreatywnych sposobów wymyślania przez organizacje sabotażu Scrum.

Scrum optymalizuje dla zespołu , a nie dla osoby. Najważniejsze jest, aby zespół był skuteczny. Jeśli programiści zaczynają pracować nad rzeczami poza bieżącym sprintem, robią zespołowi krzywdę. Pokazuje również, że nie udaje ci się w procesie planowania, jeśli nie uda ci się zaplanować wystarczającej ilości pracy, aby wypełnić wiosnę.

Jeśli programistom zabrakło zadań programistycznych, absolutnie powinni się przyłączyć i pomóc testerom, pisarzom technologii lub projektantom - każdemu w zespole. Nie muszą koniecznie pisać rzeczywistych testów (choć powinni ), ale nadal mogą brać udział w procesie testowania. Mogą pisać skrypty, które pomagają testerom być bardziej wydajnym, lub po prostu dyskutować z testerami, jakie są ich wyzwania, i pomagać im w pokonywaniu tych wyzwań (np .: dodawanie atrybutów id do elementów strony internetowej, dostarczanie haków lub interfejsów API, które testerzy mogą używać w swoich testach itp.).

Myślę, że sedno problemu polega na tym, że jeśli twoi programiści nie zawsze pracują nad bieżącym sprintem, nie pracują jeszcze jako zespół. Twój mistrz scrum powinien to zauważyć i pracować nad tym, aby zespół pracował jako jednostka, a nie zbiór osób.

Sugeruję również, że jest to problem zarządzania. Jeśli wywierają presję na programistach, aby pozostali zajęci, to nie w pełni przyjęli scrum. Jest to kolejna rzecz, w której mistrz scrum może pomóc. Mogą współpracować z zarządem, aby pomóc im zrozumieć, jak działa Scrum, aby mogli wspierać i zachęcać zespoły programistów, a nie ich obalać.

Myślę, że kluczowym problemem tutaj jest:

większość programistów uważa, że ​​testy są poniżej

Sposób, w jaki poradziliśmy sobie z tym w naszej firmie, polega na tym, że zapytaliśmy programistów, jak mogą powiedzieć, że faktycznie zakończyli pracę, jeśli nie mogą tego udowodnić. Oczywiście jedynym sposobem, aby to udowodnić, jest wykazanie, że napisany przez nich kod rzeczywiście działa, a odbywa się to poprzez testowanie. Należy im przypomnieć, że jeśli zgodzą się uczestniczyć w testowaniu, wówczas testowanie zostanie przeprowadzone szybciej i będą mieli więcej czasu na kodowanie dodatkowych funkcji (które również będą musiały zostać przetestowane).

Zwróć uwagę, że testowanie twojego kodu nie znajduje się poniżej poziomu programisty. Jest integralną częścią procesu rozwoju. Nie można go oddzielić od samego kodowania. Każdy może kodować. Nie każdy może kodować i udowodnić, że to, co napisali, faktycznie działa.

Innym sposobem na zajęcie się programistami jest umożliwienie im pracy nad kodowaniem automatycznych testów funkcjonalności, które opracowali w sprincie. Testy te można by następnie wykorzystać do testów regresyjnych, które będą przeprowadzane okresowo.

Tak czy inaczej, robienie czegoś, co nie było zaplanowane na początku sprintu, jest dużym nie-nie. Lepiej nic nie robić niż robić coś, co nie zostało zaplanowane. Funkcjonalność, którą piszą w tych przypadkach, najprawdopodobniej nie spełnia kryteriów DoD (Definicja ukończenia), ponieważ prawdopodobnie nie jest dobrze przetestowana, ponieważ testerzy byli zajęci testowaniem tego, co pierwotnie zaplanowano. Jest to pewny sposób na wprowadzanie błędów i obniżanie jakości produktu, który następnie wysyła zespół w spiralę problemów regresji i zmiany kontekstu, powodując stres, zmniejszoną prędkość i ostatecznie opuszczając zespół z tego powodu.

Teoretycznie wszyscy członkowie zespołu SCRUM powinni mieć taką samą wiedzę, aby każdy członek mógł wziąć każde zadanie od każdego innego członka. Jeśli nie, powinieneś szerzyć wiedzę.

Ale w praktyce zawsze istnieje pewna specjalizacja. Oprogramowanie może być złożone, członek zespołu ma różne umiejętności itp. Podział zespołu na programistów i testerów to tylko jeden (bardzo powszechny) przykład specjalizacji.

Rozpowszechnianie wiedzy może zająć więcej czasu, niż kierownictwo chce zaakceptować.

Z mojego doświadczenia wynika, że ​​możesz zrobić kilka rzeczy:

• Nie zmniejszaj zespołu. Jeśli masz na przykład 4 programistów i 4 testerów, o wiele łatwiej jest przenieść zadanie do innego programisty lub testera, mając tylko 3/2 jak w tym przykładzie.
• Spróbuj podzielić większe zadania. Jeśli masz więcej mniejszych zadań, będziesz bardziej elastyczny.
• Zdefiniuj niektóre opcjonalne zadania, które można wykonać, jeśli pozostanie czas.

Sugestie te mogą nie być w 100% teorią SCRUM, ale najpierw musisz kontynuować pracę nad rozwojem. SCRUM to tylko zestaw narzędzi.

Wygląda na to, że musisz desychronizować swój zespół. Tak:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Jeśli rozumiem automatyzację testów, faceci muszą zacząć kilka dni wcześniej.

Ale wyczuwam problem w twoim zespole: mam problem z programistami, którzy nie testują własnego kodu. Jeśli faceci testowi przygotują test bez przeglądu kodu, prawdopodobnie wykonują tylko testy czarnej skrzynki, które nie uwzględniają punktów decyzyjnych opracowanego programu. Czy jesteś zadowolony z jakości swojego oprogramowania?