Ukończenie sprintu trwa dłużej niż oczekiwano. Co powinniśmy zrobić?

Co powinniśmy zrobić, jeśli przedmiot w scrumie zajmuje więcej czasu niż oczekiwano? pytam o to, ponieważ zauważyłem przedmioty, które programiści mają trudności z ukończeniem, ponieważ jest to znacznie trudniejsze niż początkowo sądzono.

W takiej sytuacji powinniśmy

• usunąć przedmiot ze sprintu z powrotem do katalogu produktów, abyśmy mogli dotrzymać osi czasu sprintu?
• przejdź do łatwiejszego elementu sprintu i zostaw problematyczny sprint do końca osi czasu
• uzasadnić podczas przeglądu sprintu, dlaczego przedmiot nie może zostać uzupełniony podczas bieżącego sprintu dla zainteresowanych stron?

Jak możemy uniknąć takiej sytuacji w przyszłości? Czy to z powodu braku planowania z góry, czy nie staraliśmy się rozbić przedmiotu sprintu na mniejszy?

Pod pojęciem „przedmiotu” myślę, że masz na myśli „zadanie”.

Optymizm planowania w oprogramowaniu jest tak stary jak samo oprogramowanie. Zaletą scrum jest to, że wkrótce staniesz przed nim i zapewnisz jego widoczność: dlatego prędkość zespołów opiera się na przeszłych danych, a nie przyszłych szacunkach.

Aby ukończyć historię, musisz również wykonać zadania, które okazują się znacznie trudniejsze niż się spodziewano. Nie ma wymówki, aby je odłożyć. (Właśnie dlatego Definicja Gotowości jest tak ważna). Jeśli to oznacza, że ​​zespół nie zdaje egzaminu, to szkoda, że ​​będziesz miał o czym porozmawiać na następnej retrospektywie. Zmniejszy się prędkość (stanie się bardziej realistyczna), a zespół nauczy się dokonywać lepszych szacunków lub pozostawiać większy margines bezpieczeństwa na nieprzewidziane zadania. Właściciel produktu uzyska bardziej realistyczny pogląd na swoje plany wydania.

Co powinniśmy zrobić, jeśli przedmiot w scrumie zajmuje więcej czasu niż oczekiwano?

Zakładając, że przez przedmiot rozumiesz historię, pod koniec sprintu zazwyczaj umieszczasz ją z powrotem w rejestrze produktów (i prawdopodobnie planujesz ją na następną iterację). Zespół zdobywa za to zero punktów w bieżącej iteracji.

Inną alternatywą, jeśli historia jest wystarczająco duża, jest przecięcie jej w pionie . Na przykład historia „wyszukiwanie katalogu produktów” może być podzielona na „wyszukiwanie według kategorii” i „wyszukiwanie pełnotekstowe”, ale nie na „formularz wyszukiwania” i „wyniki wyszukiwania”.

Jak możemy uniknąć takiej sytuacji w przyszłości?

Nie ma łatwej bezpośredniej odpowiedzi na to pytanie. W scrum robisz sprinty retrospektywne przy każdej iteracji, gdzie zwykle omawiasz tego rodzaju sprawy z zespołem. Istnieje wiele różnych możliwości:

• Zespół lub niektórzy członkowie zespołu mają zły tydzień
• Potoki twojego zespołu pracują w poziomie (np. Backend-> frontend-> QA)
• Opowieści są przez pomyłkę zbyt duże
• Zespół „pozłaca” historie, dodając dodatkową pracę, która nie jest absolutnie niezbędna do ukończenia historii.
• Opowieści są bardzo duże, potrzebujesz dłuższych sprintów (mało prawdopodobne)
• Zespół ocenia historie nieprecyzyjnie (niespójnie)
• Projekt ma dużo bazy technologicznej / zgniłego kodu, a twoja prędkość jest zbyt niska
• Nie mierzysz i nie szacujesz poprawnie swojej mocy sprintu (lub wcale).

itd itd.

Mówisz, że tego nie dokończysz, ale to nie jest złe, to tylko dane.

„Osiągnięcie linii czasu sprintu” nie jest celem. Twoim celem jest uzupełnienie historii użytkowników. Oś czasu to tylko narzędzie, które pomoże Ci zmierzyć i dowiedzieć się, ile pracy możesz wykonać w sprincie.

Jeśli jesteś pewien, że nie możesz ukończyć pracy w sprincie, jednym z rozwiązań jest przeniesienie go na dół listy priorytetów i praca nad innymi historiami w sprincie. Następnie, pozostały czas, możesz zacząć nad nim pracować. Ponownie oszacuj pracę przechodzącą do następnego sprintu i zakończ ją.

Upewnij się w retrospekcji, że omawiasz, co poszło nie tak, abyś mógł poprawić swoje prognozy w przyszłości.

Jeśli zadanie trwa dłużej, niż oczekiwano, należy je przywołać retrospektywnie i omówić. Czy we wczesnej analizie było coś pominiętego? Czy to było coś, czego zespół nie robił często? Istnieje wiele możliwych powodów, dla których coś może potrwać dłużej niż początkowo szacowano.

Zespół powinien postarać się jak najlepiej wykonać zadanie, a następnie w retrospektywnym omówieniu strategii na ten temat w przyszłości. Jeśli zespół jest całkiem nowy w posługiwaniu się Scrumem, może to być częścią wypracowania początkowej prędkości zespołu. Niektóre drużyny mogą myśleć, że mogą zdobyć 20 punktów, a niektóre drużyny mogą zdobyć 60 punktów, chodzi o to, jak konsekwentnie można osiągnąć taką samą liczbę punktów w każdym sprincie.

Stanie się tak w przyszłości, ponieważ za każdym razem, gdy zespół ma nowe zadania, których jeszcze nie wykonał, trochę czasu poświęci się wypracowaniu oszacowań. Jest to część procesu uczenia się, która nie powinna być aż tak zaskakująca.

To, co zwykle robimy w naszej firmie, gdy zadanie zaczyna trwać dłużej niż oczekiwano, dzieli je na mniejsze zadania.

W ten sposób nie obwiniamy programisty za zbyt powolne, ale uznajemy również, że zadanie zostało niepoprawnie zaprojektowane.

Inną rzeczą może być przypisanie zadania innemu członkowi zespołu programistycznego, aby uniknąć sytuacji, w której spóźniony programista kopnąłby się w dziurę. A jeśli zadanie jest naprawdę krytyczne, rozwiązaniem może być XP.