Co dzieje się między sprintami?

11

Pracuję nad projektem luźno zgodnym z modelem scrum. Robimy dwutygodniowe sprinty. Coś, co nie jest jasne (i nie mam książki do skonsultowania), jest dokładnie tym, co powinno się zdarzyć między sprintami: powinien być jakiś proces „zawijania”, w którym produkt jest budowany i dostarczany, ale:

  • jak długo to zwykle trwa?
  • czy powinien być zaangażowany cały zespół?
  • czy musi to zakończyć się, zanim programiści zaczną pracę nad kolejnymi elementami sprintu?
  • czy dzieje się tak, gdy odbywa się przegląd i testowanie kodu?

Jest trzech programistów, co daje około 1 EPC. Tak więc sprinty są naprawdę bardzo krótkie.

Steve Bennett
źródło
1
Jak powiedział JW01, powinieneś spróbować zminimalizować czas między sprintami. Jest to zły nawyk / niedoskonały proces, aby zawsze mieć trochę wolnego czasu. Zawsze można jednak dodać więcej testów, uruchomić makietę GUI do następnego sprintu, może dodać przydatne komentarze do istniejącego błędu. Łatwo jednak dać się ponieść emocjom i zacząć spędzać czas na rzeczach, które menedżer niekoniecznie doceni.
Job
13
What happens between sprints?Imprezy LAN, oczywiście ...
yannis
Mam nadzieję, że weekendy.
MrFox,

Odpowiedzi:

13

Pracuję nad projektem luźno zgodnym z modelem scrum.

Wyjaśnij: Twoi menedżerowie prawdopodobnie powiedzieli ci o Scrumie, ale to, co robisz, nie jest Scrumem.

Jak długo to zazwyczaj trwa?

Spotkanie przeglądowe Sprint + spotkanie retrospektywne Sprint kończy bieżący sprint. W krótkich sprintach powinni zająć od 30 minut do 1 godziny razem. Następny dzień roboczy rozpoczyna nowy sprint od spotkania 1 i 2. w sprawie planowania sprintu. W zależności od wielkości zespołu i długości sprintu spotkanie może potrwać 2–4 godziny.

Czy powinien być zaangażowany cały zespół?

Cały zespół musi uczestniczyć w spotkaniach wymienionych w poprzedniej odpowiedzi.

Czy musi to zakończyć się, zanim programiści zaczną pracę nad kolejnymi przedmiotami sprintu?

Tak, ponieważ do czasu zakończenia spotkania przeglądowego nie wiesz, czy klient zaakceptuje wynik poprzedniego sprintu i nie wiesz, jakie historie użytkowników zostaną zaangażowane w planowanie spotkań.

Czy to wtedy, gdy odbywa się przegląd i testowanie kodu?

Nie. Przegląd i testowanie kodu jest częścią sprintu. Programiści muszą zrobić wszystko, aby dostarczyć działający kod spełniający wymagania. Może to obejmować przeglądy kodu i zawsze musi obejmować pewien rodzaj automatycznych testów sprawdzających poprawność działania kodu i działania tego, co powinno, w przeciwnym razie historia użytkownika nie może zostać uznana za wykonaną.

Główna zmiana mentalna dotyczy QA. Wielu programistów uważa, że ​​kontrola jakości ma na celu sprawdzenie, czy kod działa i robi to, co powinien. Zdecydowanie nie. To jest praca programisty.

Kontrola jakości powinna uczestniczyć w opracowywaniu produktu. Ich głównym obowiązkiem podczas sprintu powinna być komunikacja z właścicielem produktu i stworzenie automatycznych testów akceptacyjnych dla kryteriów akceptacji (definicja ukończenia), które potwierdzą, że historia użytkownika została naprawdę wykonana, a aplikacja spełnia wszystkie nowe wymagania. W małych zespołach może to być również odpowiedzialność programistów.

Kontrola jakości powinna również przeprowadzić ręczne testy, aby zachować spójność produktu i odkryć brakujące funkcje, zweryfikować wrażenia użytkownika z interfejsu użytkownika itp. Kontrola jakości nie polega na poszukiwaniu błędów i testowaniu regresji - testy regresji powinny być wysoce zautomatyzowane.

Z mojego doświadczenia wynika, że ​​większość firm przechodzących na agile nie działa.

Ladislav Mrnka
źródło
„Nie. Przegląd i testowanie kodu jest częścią sprintu”. - spoko, o to pytałem. :)
Steve Bennett,
2
Myślę, że „ musi zawierać jakiś zautomatyzowany test” jest nieco mocny. Nic nie mówi, że testy muszą być zautomatyzowane. W rzeczywistości w niektórych przypadkach po prostu nie może. Być może opracowujesz nowy arkusz stylów, a „test” musi być inspekcją wizualną. Nie można zautomatyzować „czy to wygląda dobrze?”. Tak, testy powinny być zautomatyzowane, jeśli to w ogóle możliwe, ale stwierdzenie, że muszą, to nieco zawyżone.
Bryan Oakley,
@BryanOakley: Zgadzam się. Tę część mojej odpowiedzi skierowałem tylko na podzbiór zadań programistycznych, w których możliwe są automatyczne testy.
Ladislav Mrnka
1
To nie odpowiada na pytanie.
Edward Anderson
8

Z mojego doświadczenia wynika, że ​​nie ma czasu między sprintami poza weekendem. Pod koniec sprintu zespoły, do których należałem, pracowały z właścicielem produktu, aby wykonać kilka czynności związanych z przygotowywaniem historii lub wstępnymi zmianami rozmiarów w zależności od wymagań. Obowiązek właściciela produktu polega na utrzymaniu pełnego zaległości - te historie będą nad tym, nad czym zespół będzie pracował, z pewnymi uwagami właściciela produktu dotyczącymi priorytetów. Po zakończeniu bieżącego sprintu rozpocznie się następny, wykorzystując pracę włożoną w przygotowanie historii i zadań na kolejny sprint.

Jest pewien narzut (wiele spotkań, pytania i odpowiedzi oraz oceny wymagań), ale ogólnie rzecz biorąc to działa - robimy stały postęp z niewielkim czasem przestoju. Sprinty zwykle trwały dwa lub trzy tygodnie. Kontrola jakości zwykle ma miejsce po ukończeniu historii. Jednak zespół kontroli jakości może mieć inne zadania, które mogą wykonać. Jeśli chodzi o przygotowywanie opowieści, zadania mogą należeć do starszych członków zespołu lub całego zespołu. Może się różnić w zależności od wielkości zespołu i uzgodnionego procesu. Przeglądy kodu zwykle mają miejsce podczas kontroli jakości lub pod koniec sprintu, jeśli czas jest skompresowany. A jeśli nie ma wystarczająco dużo czasu, aby ukończyć historie, w praktyce te historie zostają zepchnięte na kolejny sprint. Właściwe dobranie wielkości i oszacowanie jest tutaj bardzo ważne.

JW8
źródło
Ok, więc twoja kontrola jakości odbywa się w sprincie. Kiedy nastąpi wdrożenie? Czy czekasz, aż wszyscy deweloperzy dokonają kontroli jakości przez całą swoją pracę, a potem jedna osoba wdraża?
Steve Bennett,
Zwykle mamy co najmniej dwa wdrożenia - jeden w środkowej części sprintu, a drugi na końcu. Więcej może zostać wdrożonych do kontroli jakości po ukończeniu historii. Posiadanie krótszych historii, które mogą same stać się bardzo pomocne, bardzo pomaga. Większe historie są zwykle podzielone na mniejsze. Historie techniczne, które są wymagane, aby wszystko działało, są zwykle podpisywane przez kierownika / menedżera deweloperów - QA nie angażuje się, chyba że istnieją jakieś dane wyjściowe, które można przetestować (dzienniki, ekrany użytkownika lub inne dane wyjściowe).
JW8,
0

... a kiedy szacunek? planowanie?

Historie powinny być naprawdę łatwe, aby nie mieć czasu między sprintami.

I nie wiem, o jakim teście mówisz, ale programiści przeprowadzą testy jednostek i integracji, nic więcej.

Pracowałem nad projektem z czasem 2–3 dni między sprintami i wydaje mi się, że to dobrze. Teraz pracuję nad projektem, w którym nie ma czasu i wszystko jest rozmyte. Ostatni raz sprintu mamy wdrożenie produkcyjne i zajmuje to trochę czasu od mojego ostatniego dnia sprintu.

zurdo
źródło
W prawdziwym scrumie deweloperzy zazwyczaj nie piszą testów akceptacyjnych, ale mogą i powinni od czasu do czasu. Jakość jest obowiązkiem całego zespołu. Mimo, że są (mam nadzieję!) Specjaliści od testowania, programiści powinni się trochę przyzwyczaić. Twierdzenie, że robią „nic więcej” niż testy jednostkowe i integracyjne, nie jest prawdziwym SCRUM.
Bryan Oakley,