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

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?

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

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.

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

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.