Scrum - czym zajmują się członkowie zespołu podczas sprintu

33

Zatem sprint scrumowy to ustalony okres, w którym należy wdrożyć określony zestaw funkcji. Zespół scrum składa się ze wszystkich osób zaangażowanych w dostarczanie tych funkcji, z których większość to zazwyczaj programiści i testerzy.

Po ustaleniu tych zasad można się zastanawiać, jak utrzymać tych wszystkich ludzi w trakcie całego sprintu. Na początku sprintu nie ma jeszcze nic do przetestowania, a pod koniec sprintu zazwyczaj nie ma nic do dodania / naprawienia.

Widziałem 2 podejścia, aby sobie z tym poradzić, ale żadne z nich nie wydaje się prawidłowo rozwiązać problemu.

1) Pozwól członkom zespołu zdecydować, co robić, gdy nie będą wykonywać zadań.

Cons:

  • Jeśli to, co robią, nie jest dokładnie zaplanowane (tj. Poważne refaktoryzacja, przejście na nowe ramy testowe), ich praca może okazać się bezużyteczna lub utknąć
  • Z drugiej strony planowanie takiej pracy może zająć dużo czasu, a klient może być rozczarowany widokiem zespołu tracącego czas na coś, co nie przynosi natychmiastowej wartości
  • Takich zadań zwykle nie da się dokładnie oszacować, dlatego pracownicy bezproblemowi mogą łatwo spędzać czas na oglądaniu kotów na YouTube bez odzwierciedlania ich na tablicy scrumowej lub gdziekolwiek indziej

2) Zrób miejsce w sprincie tylko na rozwój i rozpocznij testowanie po zakończeniu sprintu (gdy programiści zaczną pracować nad funkcjami od następnego sprintu)

Cons:

  • Podczas opracowywania funkcji dla bieżącego sprintu programiści rozpraszają się, naprawiając błędy z poprzedniego, i mogą nie wykonać pracy, która została oszacowana podczas bieżącego sprintu
  • Potrzebne są dwie tablice Scrum: jedna dla bieżących funkcji sprintu i jedna dla poprzednich błędów sprintu

Więc moje pytanie brzmi: jak właściwie rozdzielić pracę podczas sprintu między programistów i testerów, aby nikt nie był przeciążony pracą ani nie skończył się bez zadań w dowolnym momencie? Czy istnieją sposoby na ulepszenie opisanych powyżej podejść? Czy są jakieś lepsze podejścia?

holdenmcgrohen
źródło
9
Wygląda na to, że podoba ci się mit wykorzystania
Nathan Cooper
1
@holdenmcgrohen W jaki sposób dokonywane są szacunki - planowanie pokera czy coś innego?
Robbie Dee
3
Testerzy powinni pisać przypadki testowe już pierwszego dnia. Wszystko, co muszą zrobić, to historie. Jeśli programiści mają znaczne przestoje podczas sprintu, oznacza to, że nie bierzesz wystarczającej ilości opowieści. Dodatkowo, prawdopodobnie jeśli twoi testerzy są dobrzy, utrzymują twoich programistów zajęci raportami błędów pod koniec sprintu. Ponadto, najlepiej, jeśli masz kilka najważniejszych historii w zaległościach, więc w najgorszym przypadku programiści mogą pracować nad jedną z najlepszych par zaległości.
Gort the Robot
1
@holdenmcgrohen, mamy również podobny problem w naszym projekcie. Zaczęliśmy dodawać artykuły Stretch (nie powinny być „ must have ”) jako część sprintu i są wybierane tylko wtedy, gdy programistom brakuje zadań. Teraz takie podejście pomaga nam utrzymać testera w początkowych dniach następnego sprintu.
user6005214,
1
Pamiętaj, że w większości sprintów wybierasz podzbiór zadań z zaległości . Jeśli wykonasz wszystko, do czego się zobowiązałeś, zyskujesz przewagę podczas następnego sprintu, rozpoczynając pracę nad większą liczbą elementów z zaległości - tak jak w przypadku przejechania, wyciągasz mniej elementów z zaległości w następnym sprincie, prawda? można dokończyć te, które nie zostały ukończone. Zrzuć dogmat; zdajcie sobie sprawę, że celem tego narzędzia jest służyć wam, a nie wam.
keshlam

Odpowiedzi:

49

Na początku sprintu nie ma jeszcze nic do przetestowania

Naprawdę? Nie masz żadnych wymagań do walidacji? Brak rozmów z klientem? Brak ramek do oceny? Nie planujesz testów?

pod koniec sprintu zazwyczaj nie ma nic do naprawienia / naprawienia

Nigdy nie byłem w tym miejscu w projekcie. Nie musisz już pracować? Zawsze coś jest. Czy wszystkie twoje testy są w pełni zautomatyzowane? Jak wygląda twój CI? Czy można zrefaktoryzować warstwę dostępu do bazy danych, aby była prostsza? I nigdy nie pracowałem nad niczym z pustą listą błędów i zaległościami. Co robili programiści w fazie testowania wodospadu?

Wiem, że niektórzy ludzie bardzo religijnie podchodzą do tego, co jest, a co nie jest „SCRUM”. Nie obchodzi mnie to. Ale myślę, że masz tutaj dwa problemy:

  1. „Tradycyjny” dział kontroli jakości, który testuje kod po „zakończeniu” przez programistów, zamiast współpracować z klientami i programistami, aby upewnić się, że budujesz właściwą rzecz, a także budujesz ją właściwie. Spójrz na zwinne kwadraty testowe Lisa Crispin. Najlepsi testerzy są zaangażowani na każdym etapie cyklu rozwoju oprogramowania, a najlepsi programiści piszą własne testy.

  2. Zbyt ścisłe trzymanie się harmonogramu SCRUM 1-tygodniowego / 2-tygodniowego sprintu bez priorytetowego i zwymiarowanego zaległości, który jest podzielony na zadania, które są wystarczająco łatwe do wykonania w krótkim czasie w ramach jednego sprintu. Jeśli tak, to zawsze będzie więcej pracy. Być może ostatnia funkcja, nad którą pracujesz w tym sprincie, nie wchodzi w skład tego sprintu, ale zawsze może przejść do następnej.

Na bok. Jeśli masz mały, spójny zespół, role mają mniejsze znaczenie. Zamiast kogoś z testerem etykiet, któremu nie wolno pisać kodu produkcyjnego, lub kogoś, kto uważa programistę, który uważa, że ​​jest ponad testowaniem, wszyscy powinni robić wszystko, co konieczne, aby zespół odniósł sukces, w tym przerażające zadania zarządzania projektami, gdy są niezbędne, nazywa się to zespołem cross-funkcjonalnym.

Jeden dodatkowy punkt poruszony przez @Cort Ammon w komentarzach. Zwinny manifest mówi o współpracy z klientem w zakresie negocjacji umów. Mówisz tak:

klient może być rozczarowany widokiem zespołu tracącego czas na coś, co nie przynosi natychmiastowej wartości

To może być trudne do wyjaśnienia i rozumiem, że klienci mogą być czasami bardzo trudni, ale byłaby to dla mnie duża czerwona flaga. Ufają Ci swoim kodem źródłowym / relacją z klientem / biznesem / czymkolwiek, co dla nich opracowujesz. Jeśli nie mogą ci ufać, że działasz profesjonalnie w ich najlepszym interesie, to masz problem lub tak.

Napisałem post, który mówi o twórcach oprogramowania, którzy nie są uważani za profesjonalistów. Profesjonalny lekarz, prawnik, inżynier budownictwa w obliczu klienta, który częściowo zmienił wymagania, nie tylko obniżyłby jakość i narzekał. Mówili swoim klientom, że to będzie problem. Gdyby klient naciskał, wówczas profesjonalista nie zrobiłby tego na ślepo w niebezpiecznie gorszym standardzie, ponieważ ponosiłby odpowiedzialność. Nie bierzemy profesjonalnych egzaminów wstępnych, więc nie ponosimy odpowiedzialności. To nie znaczy, że nie powinniśmy starać się być lepszymi.

Podsumowując, nie martwiłbym się zbytnio próbą zwiększenia wydajności na początku i na końcu sprintu, ale raczej postrzegam to jako przejaw szerszego problemu w zespole. Czy słyszałeś o eXtreme Programming (XP) . Powiedziałbym, że obowiązujące tu zasady z XP to komunikacja i szacunek:

  • Szanuj swój zespół, aby robił to, co uważają za najlepsze. Argumentowałbym, że jeśli jest dużo oglądania filmów o kotach, to albo masz słabych programistów, albo źle je traktujesz.
  • Komunikacja. Jeśli Twoi programiści rozmawiają ze sobą, z testerami, zarządem, klientem, wszyscy prawdopodobnie powinni dobrze wiedzieć, co będzie dalej, a jeśli nie, to mogą po prostu zapytać.
Encaitar
źródło
Tak, tak i tak. Znajdź odpowiedź pod każdym względem.
David Arno
Dobra odpowiedź - ostatni akapit wymaga pracy. Podnieś i wyjaśnij punkty tutaj, zamiast wskazywać na jakiś tom.
Robbie Dee
1
Co robili programiści w fazie testowania wodospadu? - Nie chciałem porównywać Scruma do Watefall, ale raczej do podejść podobnych do Kanban, gdzie zawsze jest lista rzeczy do zrobienia, które zostały już ocenione i uszeregowane według priorytetów. Backlog scrum zawiera funkcje, które nie zostały właściwie zbadane przez zespół, więc jeśli jeden programista (który obecnie nie ma żadnych funkcji do pracy) zdecyduje się na wdrożenie jednej z nich w trakcie sprintu, może to prowadzić do nieoczekiwanych konsekwencji .
holdenmcgrohen
@holdenmcgrohen wystarczy. Moje oszacowanie jest zawsze okropne, co staram się wyjaśnić, więc zawsze lubię mieć coś następnego. Myślę, że codzienne awarie i parowanie mogą tu pomóc, jeśli twoi programiści nie są zbyt długo pozostawieni sami sobie, nie mogą zboczyć zbyt daleko.
Encaitar
@Encaitar Świetne rzeczy +1
Robbie Dee
20

Po pierwsze, w Scrumie chodzi o optymalizację zespołu , a nie każdej osoby. Jeśli zespół jest produktywny i wydajny, nie ma znaczenia, czy ktoś jest bezczynny na początku lub na końcu zadania.

Jednak w każdym zespole, w którym pracowałem, zawsze jest mnóstwo pracy. Pozwól, że rozwiążę kilka twoich konkretnych obaw:

Na początku sprintu nie ma jeszcze nic do przetestowania,

Chociaż może to być prawda w dosłownym sensie, oznacza to, że uważasz, że jedynym zadaniem testera jest „testowanie”. Jest wiele rzeczy, które można zrobić, zanim zaczną testować. Po pierwsze, mogą spotykać się z właścicielem produktu i deweloperami, aby w pełni zrozumieć wymagania. Mogą być zajęci pracą nad planem testów, zbieraniem danych testowych i tak dalej. Jeśli mają luksus dobrego frameworka, mogą zacząć pisać automatyczne testy z wyprzedzeniem.

pod koniec sprintu zazwyczaj nie ma nic do naprawienia / naprawienia

Nie widziałem jeszcze zespołu programistów, któremu zabrakło rzeczy do naprawienia. Jednak nie to powinni robić pod koniec sprintu. Pod koniec sprintu powinni pomóc testerom przetestować produkt. Pomagają w pisaniu automatycznych testów, mogą przeglądać kod i testować urządzenia / słowa kluczowe / itp. Napisane przez testerów. Mogą współpracować z zespołem dokumentacji, aby pomóc im w zakończeniu pracy itp.

Widziałem 2 podejścia, aby sobie z tym poradzić ... 1) Pozwól członkom zespołu zdecydować, co robić, gdy nie wykonają zadania.

Wada twojego myślenia polega na tym, że ludziom brakuje zadań. Zadania należą do całego zespołu. Nie powinni wykonywać innej pracy, o ile w bieżącym sprincie pozostaną jakieś historie lub zadania dla zespołu .

Zrób miejsce w sprincie tylko na rozwój,

To podejście nie mieści się w tradycyjnej definicji scrum lub agile. Chodzi o to, że cały zespół jest zaangażowany w pracę nad wspólnym celem. Oznacza to, że wszystkie prace wymagane do ukończenia historii muszą być reprezentowane w sprincie - projektowanie, rozwój, testowanie, dokumentacja itp.

Wreszcie, nie jest to jedyne inne realne rozwiązanie. Zlekceważysz prawdziwe rozwiązanie, polegające na tym, że każdy członek zespołu powinien wziąć udział w razie potrzeby, aby ukończyć historię w sprincie.

Cel jest celem zespołu , ale piszesz tak, jakby każda osoba miała indywidualne cele („dokończ moje zadania”). Jeśli ktoś nie ma nic do roboty, może zobaczyć, nad czym obecnie pracujemy, i zaoferować pomoc. Lub mogą podjąć następne zadanie lub historię i rozpocząć pracę nad tym.

Bryan Oakley
źródło
1
+1. Zwinne procesy wymagają luzu. Aby zoptymalizować system, często trzeba dezoptymalizować podprocesy. W tym przypadku najlepiej powiedziałeś „optymalizując zespół”. Wszystko inne jest objawem błędnego wykorzystania.
CodeGnome
Na początku kariery spotkałem się z niektórymi firmami, które oczekują od kandydata pracy we wszystkich wersjach PHP, Java, C #, Desktop Apps (VB), QA (automatyczna, ręczna), Photoshop, CSS i tak dalej. W tym czasie branża uznała te firmy za mniej profesjonalne ze względu na wartość specjalizacji. Zastanawiam się, czy ten sam wzór zyskuje akceptację (a nawet staje się koniecznością) pod Agile.
kuldeep.kamboj
1

We wszystkich zwinnych sklepach, w których pracowałem, testerzy są uważani za kurczaki, więc nie są one odtwarzane w czasie sprintu, tak jak deweloperzy. Przed zapoznaniem się z oprogramowaniem testerzy powinni napisać plany i upewnić się, że środowiska są odpowiednio skonfigurowane do odbioru oprogramowania. W ramach tego powinni oni przyjrzeć się wszelkim dokumentom projektowym takim, jakie są.

Następnie powinieneś spróbować wypełnić sprint. Pod koniec sprintu nie powinno być wolnego czasu, jeśli szacunki są dobre, chociaż szacowanie jest oczywiście czarną sztuką, więc rzadko wypełnia się dokładnie .

Jeśli programista ma czas wolny na koniec sprintu, czas ten należy nadal śledzić, aby upewnić się, że stanowi on wartość dodaną (uczenie się nowego frameworka, przeprowadzanie analiz, dalsze testowanie itp.).

Naprawianie błędów jest całkowicie akceptowalną czynnością, którą można przeprowadzić w sprincie. Przyczynia się do funkcji, a tym samym dodaje wartości. Nie należy tego postrzegać jako czasu skradzionego od następnego sprintu - bardziej poprawnie kończącego funkcję.

Robbie Dee
źródło
8
Przeczytaj przewodnik Scrum . Być może znajdziesz fragment, w którym jest napisane, że podzielenie zespołu programistów na testerów i programistów jest w porządku (wskazówka, nie zrobisz tego).
Nathan Cooper
3
Dokument nie mówi, że masz członków zespołu programistów ze specjalizacjami, ale nie możesz podzielić grupy, by traktować ją jak „kurczaki”.
Nathan Cooper
5
Dla wyborców, jakiej części szkolenia zwinnego przegapiłeś, gdy określa, że ​​powinieneś przyjąć strategię, która działa dla twojego zespołu ? Zespół Robbiego Dee przyjął to, co zadziałało w ich wyjątkowych okolicznościach, z ich wyjątkowymi projektami i ograniczeniami środowiskowymi. Każda firma ma bariery środowiskowe i „szkody”, które należy rozłożyć. To wydaje się być całkowicie akceptowalnym podejściem do postawionego pytania . Pytanie nie dotyczyło najlepszego sposobu organizowania testerów i prób testowania w zespole sprintu.
wałek klonowy
4
Nie. OP konkretnie zapytał o Scruma. Nie możesz robić, co chcesz i nazywać to Scrum. Może, ale nie musi, być zwinny, ale fragmenty twojego „funkcjonalnego” zespołu traktowane jako zasoby zewnętrzne lub jako coś innego niż pierwszorzędni członkowie zespołu programistów nie są Scrumem.
CodeGnome
2
@CodeGnome ma absolutną rację i porusza kwestię, którą zawsze poruszam: zwinność jest filozofią, Scrum jest implementacją tej filozofii. Obie nie są tym samym i przestrzegają odrębnych zasad. (Tak, Scrum pojawił się pierwszy, ale później został
-2

W idealnym świecie Twój zespół byłby wielofunkcyjny . Każdy ma swoją specjalizację, ale każdy może również pracować jako inna specjalizacja. Jeśli testerzy nie potrafią zakodować najprostszych zadań, oznacza to, że nie masz zespołu międzyfunkcyjnego.

Scrum sposobem byłoby umożliwienie zespołowi być krzyż funkcjonalne. Twoi testerzy powinni posiadać umiejętności automatyzacji testów, to tylko krótki krok do kodowania niektórych mniej skomplikowanych rzeczy.

nvoigt
źródło
6
Ludzie w kształcie litery T to jedno, a testerzy piszący kod (chyba że mówimy o automatyzacji testów) to coś zupełnie innego.
Robbie Dee
2
To tylko zakłada, że ​​tylko testerzy mają przestoje w sprincie? Deweloperzy również mają przestoje.
wałek klonowy
Zakładam, że Devs mogą przeprowadzać testy bez dalszego szkolenia. Gdzie mieszkam, to część edukacji i pracy.
nvoigt