Typowy Sprint, Play-By-Play
w tym artykule wprowadzającym przyjrzymy się mechanice sprintu i sposobowi, w jaki członkowie zespołu powinni współpracować, aby uzyskać przyrost jakości wydania.
- pierwszy dzień: planowanie Sprintu
- przygotowanie
- pierwszy plan wartość, która zostanie dostarczona
- pamiętaj, aby uzgodnić cel Sprintu
- następny plan pracy
- każdego dnia, każdego dnia
- trzymaj Codzienny Scrum
- udoskonalanie zaległości produktowych
- zawsze współpracuj
- ostatni dzień: przegląd i Retrospektywa
- Wstrzymaj przegląd Sprintu
- następnie przeprowadź retrospektywę Sprintu
pierwszy dzień: planowanie Sprintu
cały zespół, w tym Właściciel Produktu, spotykają się pierwszego dnia sprintu i przeprowadzają sesję Planowania Sprintu. Jest to pierwsza rzecz, która wydarzy się zaraz po rozpoczęciu Sprintu.
przygotowanie
planowanie Sprintu powinno być przygotowane. Najważniejszym przygotowaniem jest upewnienie się, że zaległości produktowe zostały dopracowane do odpowiedniego poziomu szczegółowości, wraz z szacunkami i kryteriami akceptacji (jest to cel udoskonalenia zaległości produktowych). Następnie Właściciel Produktu powinien zlecić pracę nad zaległościami produktu i mieć ogólny pomysł, jak wynegocjować cenny cel sprintu z zespołem. Opcje negocjowania celu powinny również zostać uwzględnione podczas udoskonalania i odzwierciedlone w zamawianiu zaległości. Ponadto, zespół powinien mieć pojęcie o ich zdolności do tego Sprintu, czyli o tym, ile pracy wierzą, że mogą podjąć. Mogą być w stanie wykorzystać swoje doświadczenie z poprzednich sprintów, aby pomóc im ustalić wielkość tego budżetu.
pierwszy plan wartość, która zostanie dostarczona
każdy Sprint powinien skutkować wartościowym przyrostem ukończonej pracy, dopasowaniem i gotowością do natychmiastowego uwolnienia. Właściciel produktu jest w pełni odpowiedzialny za to, co oznacza „wartość” i powinien zamówić zaległości produktu w taki sposób, aby wartość mogła być zmaksymalizowana przez zespół, sprint po sprincie. Pierwszą rzeczą, którą zespół musi zrobić, jest zaplanowanie, nad którymi elementami z zaległości produktowych należy pracować w tym sprincie, aby uzyskać najlepszą wartość do końca.
aby to zrobić, zespół współpracuje z Product Ownerem, aby wybrać najcenniejsze przedmioty z zaległości produktowych, które pasują do ich przewidywanej pojemności na Sprint. Należy pamiętać, że każdy element zaległości produktu powinien zostać oszacowany przez zespół, więc będą wiedzieć z grubsza, ile pracy może być zaangażowanych.
pamiętaj, aby uzgodnić cel Sprintu
ten wybór pracy powinien być spójny, a nie tylko grupowanie niepowiązanych i rozbieżnych elementów. Pamiętaj, że Sprint jest okazją do osiągnięcia czegoś znaczącego. Na przykład pod koniec Sprintu może zostać dostarczona spójna funkcja lub znaczne ryzyko zostanie zminimalizowane. Cel Sprintu jest prostym wyrazem tego celu, nadrzędnego znaczenia wybranej pracy i spójności za wyborem.
dobry cel Sprintu pozwoli zespołowi zademonstrować skupienie i zaangażowanie, a także umożliwi współpracę i ponowne planowanie pracy, tak aby była spełniona.
następny plan pracy
Sprint Backlog to coś więcej niż tylko wybór pracy z myślą o ostatecznym celu. Jest to również plan na to, w jaki sposób ten cel zostanie osiągnięty i jak będzie wykonywana związana z nim praca. Można to zrobić, identyfikując i zamawiając zadania techniczne, które mogą być zaangażowane. W efekcie Backlog Sprintu to plan osiągnięcia Celu Sprintu i prognoza pracy, która będzie musiała zostać wykonana.
Właściciel Produktu nie musi być obecny w tej części Planowania Sprintu, ponieważ to zespół musi zaplanować tę prognozę na poziomie technicznym. Jednak Product Owner powinien być dostępny, nawet jeśli tylko zdalnie, aby odpowiedzieć na wszelkie pytania zespołu i udzielić wszelkich niezbędnych wyjaśnień dotyczących zakresu prac. Jeśli podczas sprintu oczekuje się więcej niż jednego wydania, należy to uzgodnić z PO i uwzględnić w zaległości Sprintu.
pod koniec Planowania Sprintu Zespół powinien mieć pewność, że sporządził dobrą prognozę pracy, która będzie potrzebna do osiągnięcia Celu Sprintu. Plan ten zostanie ujęty w zaległości Sprintu, które zespół w całości posiada. Zespół powinien być w stanie rozpocząć realizację tego planu natychmiast i z jasnym zrozumieniem – na przykład spalenie Sprintu – ile pracy pozostaje w danym momencie.
każdego dnia, każdego dnia
gdy zespół zaplanuje zaległości w sprincie, może rozpocząć pracę. Jeśli mają zaplanowane rzeczy jako zadania, będą współpracować ze sobą, jako zespół, aby upewnić się, że te zadania zostały wykonane. Będą mogli śledzić swoje postępy, korzystając z tablicy zadań i pozostałej pracy w sprincie.
każdy członek zespołu będzie na pewno aktualizował tablicę Zadań Scrum i Sprint Burndown, aby inni mogli polegać na tych informacjach. Kaloryfer informacyjny powinien zawsze mówić prawdę.
trzymaj Codzienny Scrum
każdego dnia roboczego, w tym samym czasie zespół programistów spotka się i zaplanuje, co zrobi, aby zbliżyć ich do Celu Sprintu. To spotkanie nazywa się Daily Scrum i nie powinno trwać dłużej niż 15 minut.
tylko członkowie zespołu programistycznego powinni uczestniczyć, ponieważ plan pracy należy wyłącznie do nich. Jest to ograniczona czasowo okazja do ponownego zaplanowania zaległości w sprincie w wyniku nowych odkryć i wniosków wyciągniętych podczas sprintu. Cały zespół powinien uczestniczyć. Każdy członek zespołu powinien być w stanie wyjaśnić:
- co zrobili wczoraj, aby pomóc zespołowi osiągnąć cel Sprintu
- co zamierzają zrobić dzisiaj, aby pomóc zespołowi osiągnąć cel Sprintu
- wszelkie przeszkody, które wchodzą im w drogę
pod koniec codziennego Scrum zespół powinien mieć jasny plan na następne 24 godziny i zrozumienie, w jaki sposób będą musieli współpracować, aby go osiągnąć. Powinny również mieć listę wszelkich przeszkód, które wymagają uwagi Scrum Mastera.
udoskonalanie zaległości produktowych
w Scrum udoskonalanie zaległości produktowych nie jest formalnym wydarzeniem, ale ciągłym działaniem – procesem dodawania szczegółów, zamówień i szacunków do pozycji zaległości produktowych, takich jak historie użytkowników. To od zespołów Scrumowych zależy, jak często to robić, chociaż z pewnością dobrym pomysłem jest wprowadzenie udoskonalenia do codziennej rutyny. Udoskonalenie nie powinno zająć więcej niż 10% całkowitego czasu zespołu podczas sprintu. Dla większości zespołów pół godziny dziennie może być wystarczające, chociaż niektórzy wolą spędzać godzinę lub dwie kilka razy w tygodniu. Ważne jest, aby upewnić się, że zaległości produktowe są dopracowane w odpowiednim czasie, aby planowanie Sprintu mogło nastąpić bez przeszkód. Cały zespół, w tym Product Owner, powinien uczestniczyć.
sesja udoskonalania zazwyczaj rozpoczyna się od przedstawienia zespołowi przez Product Ownera bieżących zaległości produktowych. Zaległości mogą odbywać się w wielu formach, takich jak elektroniczna tablica Scrum lub inne narzędzie współpracy, lub może to być po prostu arkusz kalkulacyjny. Projektor lub wspólny ekran może być bardzo przydatny.
zespół zaczyna od góry zaległości produktu i pracuje w dół, udoskonalając każdy element po kolei. Zbadają każdy z nich i omówią jego zakres oraz kryteria akceptacji, które będą niezbędne do jego ukończenia. Każdy przedmiot zostanie następnie oszacowany przy użyciu techniki, takiej jak planowanie pokera. Duży przedmiot można podzielić na mniejsze, które uchwycą więcej szczegółów. Epiki mogą być rozłożone na historie użytkowników, na przykład.
zespół zatrzymuje się po wyczerpaniu się ramki czasowej sesji. Będą ponownie tam, gdzie skończyli następnym razem, ostatecznie zaczynając od początku, aby zaległości były aktualizowane.
zawsze współpracuj
w praktyce agile, członkowie zespołu nigdy nie pracują w izolacji – gdyby tak było, nie byliby zespołem. W rzeczywistości praca zespołowa jest tak ważna, że rolą jest raczej zespół programistów niż programista.
oznacza to, że każdy członek zespołu programistycznego musi współpracować ze swoimi rówieśnikami przez cały dzień, ponieważ są oni wspólnie odpowiedzialni za postęp pracy. Wszelkie problemy lub porażki są współwłasnością zespołu, a także ich sukcesy. Współpraca nie jest czymś, co ogranicza się do wydarzeń takich jak codzienny Scrum, ale dotyczy wszystkiego, co zespół robi podczas każdego Sprintu.
przykłady współpracy to:
- pomaganie rówieśnikom w ukończeniu prac w toku przed wprowadzeniem nowej pracy z zaległości
- Programowanie w parze, takie jak używanie klawiatury na zmianę i pomaganie i sprawdzanie nawzajem swojej pracy
- Recenzja
- prosząc o pomoc i chętnie ją udzielając
- idąc do miejsca, w którym znajduje się praca i pomagając, zamiast czekać na przekazanie im pracy
- upewniając się, że wszystkie prace w rzeczywistości spełniają definicję done
- wywołanie Scruma w celu rozwiązania problemów, które wymagają natychmiastowej uwagi zespołu
- aktualizacja tablicy zadań Scrum i wykresu wypalenia, aby informacje były aktualne i można było polegać na
- dzielenie się umiejętnościami i wiedzą
ostatni dzień: przegląd i Retrospektywa
Wstrzymaj przegląd Sprintu
jeśli zespół współpracował efektywnie będą współpracować, aby osiągnąć cel sprintu, zarządzając wszelkimi zagrożeniami i dostosowując swoje plany w razie potrzeby. Zademonstrowali kontrolę w trakcie Sprintu poprzez równomierne spalanie pozostałej pracy, gdzie każdy członek uważał za swój osobisty obowiązek pomóc w zakończeniu prac w toku. Będą mieli cenny przyrost do zademonstrowania właścicielowi produktu i zaproszonym interesariuszom. Recenzja to coś, na co zespół powinien czekać.
to również coś, na co zespół musi się przygotować. Należy przeznaczyć wystarczająco dużo czasu na pokazanie wykonanej pracy. Zadania mogą być zaplanowane na zaległości Sprint w tym celu, aby upewnić się, że przegląd Nie sprawiedliwości do wykonanej pracy i wartość, która jest teraz dostępna. Ponadto, jeśli właściciel produktu uważa, że dobrym pomysłem byłoby zaproszenie interesariuszy, zaproszenia te powinny zostać wysłane. Przegląd jest okazją do uczczenia wykonanej pracy i zaprezentowania ich osiągnięć, więc zaufanie jest inspirowane i dalsze inwestowanie w zespół może być uzasadnione.
przegląd Sprintu jest również okazją do sprawdzenia i dostosowania. Jest to dobry moment, aby Właściciel Produktu wyjaśnił, jak dobrze produkt działa, aby uzyskać informacje zwrotne z pierwszej ręki od zaproszonych stron i wyciągnąć wszelkie wnioski, które mogą być wykorzystane do dalszej poprawy zaległości produktu. Jeśli jakiekolwiek prace nie zostały zakończone, z jakiegokolwiek powodu, zostanie to również sprawdzone i ponownie oszacowane na zaległości produktu w celu ewentualnego planowania przyszłych sprintów.
następnie przeprowadź retrospektywę Sprintu
przegląd Sprintu spojrzał na produkt i dostarczoną wartość, na pracę, która została wykonana, i szczerze i szczerze na każdą pracę, która nie została wykonana, bez względu na powód.
następnym krokiem jest przeprowadzenie retrospektywy Sprintu. Retrospektywa uwzględnia proces, który podąża zespół. Czy działają tak efektywnie, jak tylko mogą? Generalnie najlepiej jest przeprowadzić retrospektywę bezpośrednio po przeglądzie, ponieważ pierwsza może wprowadzić pomysły do rozważenia w drugiej.
cały zespół programistów, Product Owner i Scrum Master muszą uczestniczyć w retrospektywie, ponieważ wszyscy są wspólnie odpowiedzialni za sukces pracy zespołu. Bardzo ważne jest, aby mieć wolną i otwartą sesję, która dociera do sedna wszelkich problemów i identyfikuje działania, które pomogą je rozwiązać. Retrospektywne może rozpocząć się od następującej deklaracji:
„niezależnie od tego, co odkryliśmy, rozumiemy i naprawdę wierzymy, że każdy wykonał najlepszą pracę, jaką mógł, biorąc pod uwagę to, co wiedział w tym czasie, swoje umiejętności i zdolności, dostępne zasoby i sytuację.”
w „Retro” każdy ma równy głos. Jednym z podejść, które Scrum Master może ułatwić, jest zidentyfikowanie:
- to, co poszło dobrze
- to, co nie poszło tak dobrze
- pomysły na poprawę
- podziękowania dla członków zespołu, którzy zrobili coś wyjątkowego
ustalenie linii czasu może pomóc w przypomnieniu uczestnikom ważnych wydarzeń podczas sprintu.