Co dzieje się między sprintami?

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.

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.

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.

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