Scrum - programiści pracujący poza Sprintem

12

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 :)

agile scrum

— fml
źródło

3

Zgadzam się z zarządem. Posiadanie ludzi siedzących z powodu arbitralnego dwutygodniowego okresu to okropny pomysł. Być może obowiązki twojego zespołu są zbyt sztywne; w tak małych zespołach nierzadko wszyscy członkowie zespołu są „funkcjonalni”, pozwalając im wskoczyć w razie potrzeby w bieżącym sprincie.

— Robert Harvey

... a może nie wkładasz wystarczającej ilości sprintów, aby utrzymać zespół przez dwa tygodnie.

— Blrfl,

3

Czy połączenie hybrydowe rozwoju / testowania pary hybrydowej jest praktyczne? W pewnym sensie proces jest taki sam jak cykl testowania jednostkowego; napisz trochę testu. Nie mieliśmy tego formalnie, ale testerzy mieli zwyczaj przychodzić do nas bezpośrednio, gdy znaleziono błąd lub dwa. Nie komunikowaliśmy się za pośrednictwem formalnych zgłoszeń błędów. Zanim „mój tester” zakończył testowanie, zakończyłem naprawianie. Będąc aplikacją internetową poprawiono wydajność napraw. Ale przynajmniej eksperymentuj. I szczerze mówiąc, nawet jeśli nie jest to lepszy ani gorszy mgt dostrzeże mniej indywidualnego czasu oczekiwania.

— radarbob

3

Czy prace, które pierwotnie zaplanowano na sprint, generalnie są wykonywane z wystarczającą jakością? A może zostały ci już niedokończone historie z pierwotnego planu?

— Bart van Ingen Schenau

2

Możesz po prostu zachować swój proces, ale nazwać go „kanban” zamiast „scrum”, a wtedy nie musisz się martwić, czy proces jest poprawny w przypadku scrum. / nieco sarkastyczny, ale niezupełnie

— Eric King,

16

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:

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.
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ą.
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:

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ł.
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.

— Sklivvz
źródło

1

Dziękuję za Twoją odpowiedź. Naprawdę podoba mi się pomysł, aby połączyć programistę i zasoby kontroli jakości razem. Mam zamiar zasugerować to na naszym następnym spotkaniu i mam nadzieję, że możemy wypróbować to podczas następnego sprintu. Zaktualizuję pytanie i dam znać, jak to działa!

— fml

@ Sklivvz Zdarza się to częściej niż wtedy, gdy istnieje dział kontroli jakości. Dzieje się tak za każdym razem, gdy kontrola jakości jest rolą, którą mogą wykonywać tylko „określone osoby”. Zamiast bezczynnego zasobu odbierającego „następne” zadanie o wysokim priorytecie, programista staje się bezczynny, a następnie odbiera więcej pracy, podczas gdy QA nieustannie reaguje na wyniki programisty.

— Edwin Buck

1

Gdyby nie było to jasne powyżej, „następnym zadaniem o wysokim priorytecie byłoby„ zmniejszenie zaległości w zapewnianiu jakości, aby elementy mogły zostać wysłane ”, a nie następne zadanie programistyczne o wysokim priorytecie z zaległości.

— Edwin Buck

1

Porady, takie jak cały zespół, są odpowiedzialne, choć brzmi dobrze, w rzeczywistości nie służą zespołowi. Sugeruje to, że wszyscy są wymienni, a to oznacza brak każdego, kto się nie przyłączy. To źle. Każda osoba w SDLC ma szczególną rolę i spędził LATA doskonaląc swoje umiejętności. Poproszenie inżyniera oprogramowania o przetestowanie jest szkodliwe dla jakości, ponieważ nie mają oni wystarczającego doświadczenia w testowaniu jakości i prawdopodobnie podejmą bezmyślną próbę. Nawet jeśli inżynier QA ich mentoruje, mentoring zabiera czas na testowanie i sprawia, że praca trwa jeszcze dłużej.

— Chuck Conway,

1

@ChuckConway nikt nie sugeruje, co mówisz. Parowanie nie zastępuje ani nie zapewnia mentoringu. Najlepiej jest, gdy ufasz zespołowi, że znajdziesz najlepszy sposób na zminimalizowanie przestojów, a to może zacząć się tylko wtedy, gdy ludzie rozumieją swoje role i potrzeby. Najlepsze, najbardziej wydajne zespoły samodzielnie się organizują (prawda czy nie, to podstawowa zasada zwinności).

— Sklivvz

2

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.

— Martin Maat
źródło

3

Problem z takimi stwierdzeniami, jak „Whoa! Technicznie nie jest to możliwe w Scrumie” i „… nowych kreatywnych sposobach, które organizacje wymyślają, aby sabotować Scruma” polega na tym, że sugerują one istnienie prawidłowego sposobu „zrobienia Scruma”. Aby istniał prawidłowy sposób, Scrum musi działać prakreacyjnie, tj. Stawiać procesy przed ludźmi. Scrum nie jest więc zwinnym procesem, jeśli istnieje właściwy sposób na jego wykonanie.

— David Arno,

@David Arno To miłe, w zasadzie mówisz, że każda metodologia jest z definicji niestabilna. Nawet zwinny manifest. Zwinny byłby tylko zwykły nieprzewidywalny chaos. Ale czekaj ... kto mówi mi, żebym był chaotyczny? Poważnie teraz: zwinne adagium „ludzie przed procesami” służy rozwiązaniu konfliktu. Jeśli trzeba wybierać, należy robić to, co ma sens, niekoniecznie to, co mówią reguły. Wydaje mi się, że zespół OP mógł bez problemu przejść przez książkę Scruma. Być może tak, wydaje się, że kluczowym pytaniem jest to, jak przejrzyste są.

— Martin Maat,

1

@DavidArno faktycznie, to tylko sugeruje, że istnieją specyficzne niewłaściwe sposoby robienia Scruma, i wydaje się to niekontrowersyjne. Na przykład wszystko, co przeczy Manifestowi Agile, wydaje się obiektywnie niepoprawne.

— Sklivvz

1

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ć.

— Bryan Oakley
źródło

0

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.

— Vladimir Stokic
źródło

Powiedziałbym, że programiści testują kod, po prostu nie tworzą automatycznych testów. Jest duża różnica.

— JeffO

W tym konkretnym przypadku jestem gotów się założyć, że jedynym testem, jaki wykonują ci programiści, jest test IDE. Niewielu programistów faktycznie wbudowało rozwiązanie w pakiet instalacyjny, wdrożyło pakiet od zera, tak jak zrobiłby to użytkownik końcowy, a następnie faktycznie przetestowało rozwiązanie. W większości przypadków to nie wystarczy i jest powodem znacznego pogorszenia jakości.

— Vladimir Stokic

0

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.

— bernie
źródło

0

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?

— Lucas
źródło