Scrum i najlepsze rozwiązania

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Spotkania planowania sprintu

Wiele planowania sprintu obejmuje negocjacje między właścicielem produktu a zespołem, aby ustalić cele i zadania do realizacji w nadchodzącym sprincie. Warto ustalić czas spotkania planistycznego, ograniczając je do 4 godzin lub mniej.

W pierwszej części spotkania właściciel produktu spotyka się z zespołem, aby omówić historyjki użytkownika, które mogą zostać uwzględnione w sprincie. Właściciel produktu udostępnia informacje i odpowiada na wszelkie pytania dotyczące tych historii. Ta konwersacja może ujawnić szczegóły, takie jak źródła danych i układ interfejsu użytkownika. Może też ujawnić oczekiwania dotyczące czasu odpowiedzi oraz zagadnienia dotyczące bezpieczeństwa i użyteczności. Twój zespół powinien przechwycić te szczegóły w formularzu elementów listy prac. Podczas tej części spotkania zespół poznaje, co musi utworzyć.

Podczas planowania sprintów możesz odkryć inne wymagania do uchwycenia i dodania do backlogu. Upewnij się, że jest on dobrze zdefiniowany i w kolejności priorytetu.

Ponadto ustawienie celu sprintu w ramach wysiłków związanych z planowaniem może pomóc zespołowi skupić się na tym, co jest najważniejsze dla każdego sprintu.

Po zaplanowaniu sprintu możesz podzielić się planem z kluczowymi uczestnikami projektu.

Więcej informacji można dowiedzieć się z następujących zasobów:

• Co to jest Scrum?
• Dokument planowania sprintu
• Przewodnik scrum
• Tworzenie i zarządzanie backlogiem produktu — biała księga

Ustalanie celów sprintu

Zespoły scruma używają celów sprintu, aby skupić swoje działania podczas sprintu. Często ustawiają ten cel podczas spotkania planowania sprintu. Celem zespołu jest podsumowanie, co chcą osiągnąć do końca sprintu. Jawnie określając cel, należy utworzyć wspólne zrozumienie w zespole podstawowego celu. Cel sprintu może również pomóc zespołowi w rozwiązywaniu konfliktów dotyczących priorytetów.

Porady z praktyki: Definiowanie celów sprintu

Cel sprintu definiuje, co właściciel produktu i zespół uważają za ostateczny cel do osiągnięcia w danym sprincie. Nie jest to losowy wybór elementów listy prac, które naprawdę nie mają relacji, ale krótki fragment tekstu, który przechwytuje to, co zespół powinien spróbować osiągnąć. Zwykle właściciel produktu określa cel sprintu przed wybraniem wielu elementów na potrzeby następnego sprintu. Elementy tego sprintu powinny pasować do tego wspólnego celu.

Cele przebiegu mogą być zorientowane na funkcje, ale mogą również mieć duży składnik procesu, taki jak automatyzacja wdrażania lub automatyzacja testów.

Przykład:

• W tym sprincie skupimy się na prostej historyjce użytkownika. Użyjemy go, aby udowodnić, że proponowane rozwiązanie działa.
• Ten przebieg koncentruje się wokół implementowania funkcji zabezpieczeń, które prawidłowo zabezpieczają sekcję administracyjną witryny internetowej.
• Ten sprint polega na zintegrowaniu najważniejszych bramek płatności, abyśmy mogli zacząć zbierać pieniądze.

Ustawianie celów sprintu pomaga zespołowi skupić się. Ułatwia zdefiniowanie priorytetu zadań w sprincie i prawdopodobnie pomaga ograniczyć liczbę zaangażowanych interesariuszy oraz użytkowników końcowych.

Podczas przeglądu przebiegu najważniejszym pytaniem, które należy zadać sobie, jest to, czy udało Ci się osiągnąć cel przebiegu. To, ile historii ukończyłeś, jest drugorzędne. Jeśli cel zostanie osiągnięty, sprint zakończy się pomyślnie, nawet jeśli nie wszystkie historyjki zostały zakończone.

Autor: Jesse Houwing, Visual Studio devops Ranger i starszy konsultant pracujący w Avanade Holandii.

Porady dotyczące pomyślnych spotkań triage

Naprawianie usterek stanowi kompromis z innymi pracami. Użyj spotkania triage, aby określić, jak ważne jest naprawienie każdej usterki względem innych priorytetów związanych z spełnieniem zakresu projektu, budżetu i harmonogramu.

• Ustal kryteria zespołu dotyczące oceny usterek, które należy naprawić i jak przypisać priorytet i ważność. Usterki związane z funkcjami znaczącej wartości (lub znaczącym kosztem możliwości opóźnienia) lub inne zagrożenia związane z projektem powinny mieć przypisany wyższy priorytet i ważność. Zapisz kryteria klasyfikacji z innymi dokumentami zespołu i zaktualizuj je zgodnie z potrzebami.
• Użyj kryteriów klasyfikacji, aby określić, które usterki należy naprawić i jak ustawić ich pola Stan, Priorytet, Ważność i inne.
• Dostosuj kryteria klasyfikacji na podstawie tego, gdzie jesteś w cyklu programowania. Na początku możesz zdecydować się na naprawienie większości usterek przeanalizowanych. Jednak w dalszej części cyklu można podnieść kryteria klasyfikacji, aby zmniejszyć liczbę usterek, które należy naprawić.
• Po sklasyfikowaniu usterki przypisz ją do dewelopera. Deweloper może następnie zbadać i określić, jak zaimplementować poprawkę.

Zarządzanie długiem technicznym

Rozważ zarządzanie błędami i długiem technicznym w ramach ogólnego zestawu działań ciągłego doskonalenia zespołu. Te zasoby mogą cię zainteresować:

• Dobry i zły dług techniczny (i jak TDD pomaga) Henrik Kniberg
• Zarządzanie długem technicznym opublikowanym przez Sven Johann & Eberhard Wolff

Porady z okopów: zarządzanie usterkami

Elastyczne zarządzanie usterek: nie Oxymoron
Autor: Gregg Boer, principal Program Manager, Visual Studio Cloud Services at Microsoft

Rozwiązanie wszystkich znanych zadłużeń technicznych związanych z błędami w każdym sprincie

Każdym sprintem zespół analizuje pozostające w backlogu błędów i przeznacza zasoby, aby zredukować liczbę znanych błędów do zera lub prawie zera. Niezależnie od tego, czy jest to jeden dzień, tydzień, czy cały sprint, najpierw naprawiają usterki. Usterki znalezione później w ramach sprintu nie są uznawane za część tego początkowego zobowiązania. O ile nie mają wysokiego priorytetu, są one dodawane do backlogu błędów na potrzeby następnego sprintu.

Wiele zespołów pracuje w organizacji opartej na zaangażowaniu. Często zarządzanie stawia wysoką wartość na zdolność zespołu do spełnienia swoich zobowiązań. Planowanie pojemności względem znanego zestawu usterek sprawia, że planowanie sprintu jest bardziej przewidywalne, zwiększając szanse na spełnienie zobowiązań. Te nowe usterki wykryte podczas sprintu nie są częścią początkowego zobowiązania i mogą zostać rozpatrzone w następnym sprincie.

Zarządzanie długiem technicznym związanym z błędami w przedsiębiorstwie

Organizacja przechodząca do kultury, w której dług jest stale eliminowany, prawdopodobnie mierzy się z następującym pytaniem: Jak skłonić zespoły do zmniejszenia liczby usterek bez mówienia im dokładnie, co mają zrobić? Kierownictwo chce, aby zespół zmienił się, ale daje autonomię zespołu, aby określić, jak się zmieniają. Jedną z opcji jest użycie limitu błędów.

Rozważmy na przykład limit trzech błędów na inżyniera. W związku z tym zespół 10 osób nie powinien mieć więcej niż 30 usterek na liście prac nad usterkami. Jeśli zespół przekroczy zastrzeżoną kwotę, powinien przestać pracować nad nowymi funkcjami i zejść poniżej limitu usterek. Oczekuje się, że zespół będzie zawsze poniżej limitu, ale to zespół decyduje, jak tego dokonać. Limit błędów zapewnia, że zespoły nie mają zbyt długiego długu błędów. Zespół może w pierwszej kolejności nauczyć się na błędach, które powodują pojawianie się usterek.

Pamiętaj, że limit zgłoszeń błędów reprezentuje błędy w zaległościach błędów. Nie obejmuje błędów znalezionych i naprawionych w przebiegu, w którym jest opracowywana funkcja. Te błędy są uważane za niewykonaną pracę, a nie dług.

Chociaż usterki przyczyniają się do długu technicznego, mogą nie reprezentować całego długu.

Słabe projektowanie oprogramowania, słabo napisany kod lub krótkoterminowe poprawki mogą przyczynić się do długu technicznego. Dług techniczny odzwierciedla dodatkową pracę rozwojową, która wynika ze wszystkich tych problemów.

Śledź pracę nad rozwiązywaniem długu technicznego jako PBIs, historie użytkowników lub błędy. Aby śledzić postępy zespołu w zakresie ponoszenia i rozwiązywania problemów z długiem technicznym, warto rozważyć kategoryzowanie elementu roboczego i szczegółów, które chcesz śledzić. Tagi można dodać do dowolnego elementu roboczego, aby zgrupować je w wybranej kategorii.

Rola Scrum Master

Scrum Masters pomagają tworzyć i utrzymywać zdrowe zespoły, stosując procesy Scrum. Prowadzą, trenują, uczą i pomagają zespołom Scrum w odpowiednim stosowaniu metod Scrum. Scrum Masters działa również jako agenci zmian, aby pomóc zespołom przezwyciężyć przeszkody i napędzać zespół w kierunku znacznego wzrostu produktywności.

Podstawowe obowiązki Scrum Masters obejmują:

• Obsługa zespołu w celu wdrożenia i przestrzegania procesów Scrum. Na przykład nie należy pozwolić, aby codzienne spotkanie Scrum stało się otwartą dyskusją, która trwa 45 minut.

• Zapobiegaj temu, by właściciel produktu lub członkowie zespołu dodawali pracę po rozpoczęciu sprintu.

• Rozwiąż problemy blokujące, które uniemożliwiają zespołowi postępy. Ta praca może wymagać wykonania małych zadań, takich jak zatwierdzenie zamówienia zakupu dla nowego komputera kompilacji lub rozwiązanie konfliktu w zespole.

• Pomóż zespołowi rozwiązać konflikty i problemy, które pojawiają się i uczyć się z tego procesu.

• Zadawaj pytania, które ujawniają ukryte problemy i potwierdzają, że to, co ludzie komunikują się, jest dobrze zrozumiałe dla całego zespołu.

• Identyfikowanie i zabezpieczanie zespołu przed potencjalnymi problemami, zanim staną się one poważne. Podobnie jak tańsze jest naprawienie usterki wkrótce po jego odnalezieniu, jest również łatwiejsze i mniej destrukcyjne, aby rozwiązać problem zespołu, gdy jest mały i możliwy do zarządzania.

• Uniemożliwić zespołowi prezentowanie niekompletnych historii użytkowników podczas spotkania przeglądu przebiegu.

• Zbieraj, analizuj i przedstawiaj dane uczestnikom projektu biznesowego, aby pokazać, jak zespół ulepsza i rozwija się. Jeśli na przykład twój zespół zwiększył ilość wartości dostarczonej podczas generowania mniejszej liczby usterek, spraw, aby wartość była widoczna poprzez regularną komunikację z interesariuszami biznesowymi.

Dobre Scrum Masters mają lub rozwijają doskonałą komunikację, negocjacje i umiejętności rozwiązywania konfliktów. Aktywnie słuchają słów, które ludzie mówią i piszą. Słuchają również, jak dostarczają swoje wiadomości, na przykład język ciała, wyrazy twarzy, tempo wokalne i inną komunikację niewerbalną.

Podobnie jak tańsze jest naprawienie usterki wkrótce po jego odnalezieniu, jest również łatwiejsze i mniej destrukcyjne, aby rozwiązać problem zespołu, gdy jest mały i możliwy do zarządzania, zanim dorasta do poważnego problemu.

Codzienne spotkania Scrum

Codzienne spotkania Scrum pomagają utrzymać zespół skoncentrowany na tym, co musi zrobić następnego dnia. Pozostawanie skoncentrowanym pomaga zespołowi zmaksymalizować swoją zdolność do osiągania celów sprintu. Scrum Master ma za zadanie pilnować przebiegu spotkania i upewnić się, że rozpoczyna się na czas i kończy w maksymalnie 15 minut.

Trzy aspekty udanych spotkań Scrum to:

• Wszyscy wstają. Stanie pomaga utrzymać spotkania w skupieniu i skrócić ich czas trwania.
• Zaczynają się i kończą o tym samym czasie w tym samym miejscu każdego dnia.
• Wszyscy uczestniczą, każdy członek zespołu odpowiada na trzy pytania Scrum:
  • Co udało mi się osiągnąć od najnowszego Scrum?
  • Co mogę osiągnąć przed następnym Scrum?
  • Jakie problemy lub przeszkody blokujące mogą mieć wpływ na moją pracę?

Członkowie zespołu powinni dążyć do szybkiego i zwięzłego odpowiadania na swoje pytania. Przykład:

Wczoraj zaktualizowałem klasę, aby odzwierciedlić nowy element danych, który pobieramy z bazy danych, i udało mi się go wyświetlić w interfejsie. To zadanie zostało ukończone. Obecnie upewniam się, że nowy element danych jest poprawnie obliczany przy użyciu procedury składowanej i innych elementów danych w tabeli. Wierzę, że mogę dziś wykonać to zadanie. Potrzebuję kogoś, aby przejrzeć moje obliczenia. Nie mam przeszkód ani problemów z blokowaniem".

Ta odpowiedź przekazuje, co członek zespołu osiągnął, co planuje osiągnąć oraz że chciałby uzyskać pomoc przy przeglądzie kodu.

Kontrast z tym następnym przykładem:

Wczoraj pracowałem nad klasą i to działa. Dziś pracuję nad interfejsem. Brak problemów z blokowaniem".

Członek zespołu nie podaje wystarczającej ilości szczegółowych informacji o klasie, nad którą pracował, ani o składnikach interfejsu, które ma ukończyć. W rzeczywistości słowo „dokonane” nigdy się nie pojawiło.

Ważne jest, aby nikt nie przerywał podczas przedstawiania raportów. Każda osoba musi mieć wystarczający czas, aby odpowiedzieć na trzy pytania.

Bardziej szczegółowe i dalsze dyskusje powinny odbywać się po spotkaniu, gdy ludzie wracają do biurek lub, jeśli wymagana jest znaczna liczba rozmów, na kolejnym spotkaniu.

Wiele zespołów opóźnia dyskusje, stosując metodę "wirtualnego miejsca postojowego". Jak pojawiają się tematy, że członek zespołu uważa, że potrzebuje dalszej dyskusji, mogą po cichu chodzić do tablicy lub flipchart i wymienić temat na parkingu. Na końcu spotkania zespół określa, jak będą obsługiwać wymienione elementy.

Przebieg spotkań przeglądu

Przeprowadzaj spotkania przeglądu sprintu w ostatnim dniu sprintu. Twój zespół demonstruje każdy element backlogu produktu, który został ukończony w sprincie. Właściciel produktu, klienci i osoby biorące udział w projekcie akceptują historie użytkowników spełniające ich oczekiwania i identyfikują nowe wymagania. Klienci często rozumieją swoje potrzeby bardziej w pełni po obejrzeniu pokazów i mogą identyfikować zmiany, które chcą zobaczyć.

Na podstawie tego spotkania niektóre historie użytkowników są akceptowane jako kompletne. Niekompletne historie użytkownika pozostają w backlogu produktu. Nowe historyjki użytkownika są dodawane do backlogu. Oba zestawy historii są klasyfikowane i oszacowane lub ponownie oszacowane w następnym spotkaniu planowania sprintu.

Po tym spotkaniu i spotkaniu retrospektywnym, twój zespół planuje kolejny sprint. Ponieważ potrzeby biznesowe szybko się zmieniają, możesz skorzystać z tego spotkania z właścicielem produktu, klientami i uczestnikami projektu, aby ponownie przejrzeć priorytety listy prac produktu.

Spotkania retrospektywne sprintu

Retrospektywy, kiedy są przeprowadzane dobrze i w regularnych odstępach czasu, wspierają ciągłe doskonalenie.

Spotkanie retrospektywne sprintu zwykle odbywa się w ostatnim dniu sprintu, po spotkaniu przeglądu sprintu. W tym spotkaniu twój zespół analizuje wykonywanie Scrum przez zespół i co może wymagać dostosowania.

W oparciu o dyskusje twój zespół może zmienić co najmniej jeden proces, aby poprawić własną skuteczność, wydajność, jakość i zadowolenie. To spotkanie i wynikające z tego ulepszenia mają kluczowe znaczenie dla elastycznej zasady samodzielnej organizacji.

Skup się na tych obszarach podczas retrospektyw zespołu:

• Problemy, które miały wpływ na ogólną skuteczność, produktywność i jakość twojego zespołu.

• Elementy, które miały wpływ na ogólną satysfakcję twojego zespołu i przepływ projektu.

• Co się stało, że w backlogu znalazły się niekompletne elementy? Jakie działania może podjąć zespół, aby zapobiec tym problemom w przyszłości?

  Rozważmy na przykład zespół, który miał kilka zadań, które może wykonać tylko jedna osoba w zespole. Izolowana wiedza stworzyła krytyczną ścieżkę, która zagroziła sukcesowi sprintu. Jeden z członków zespołu spędził dodatkowe godziny, podczas gdy inni byli sfrustrowani, że nie mogli zrobić więcej, aby pomóc. W przyszłości zespół postanowił stosować eXtreme Programming, aby pomóc rozwiązać ten problem z biegiem czasu.

Zespół powinien określić, czy należy dostosować jeden lub więcej procesów, aby zminimalizować występowanie problemów podczas sprintu.

W celu zaimplementowania ulepszeń może być konieczne wykonanie pewnych czynności przez zespół. ** Na przykład zespół, który znalazł się pod negatywnym wpływem z powodu zbyt wielu nieudanych buildów, postanowił zaimplementować ciągłą integrację. Ponieważ nie chcieli zakłócać procesu, skonfigurowanie kompilacji próbnej trwało kilka godzin przed włączeniem jej w kompilacji produkcyjnej. Aby przedstawić tę pracę, utworzyli prototyp i zorganizowali pracę z resztą backlogu produktu.

Treści powiązane

• Zakończenie działań sprintu
• Co to jest Scrum?
• Retrospektywy Agile: przekształcanie dobrych zespołów w świetne