Udostępnij za pośrednictwem

Scrum i najlepsze rozwiązania

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Przebieg spotkań planowania

Wiele planowania przebiegu obejmuje negocjacje między właścicielem produktu a zespołem w celu ustalenia fokusu i pracy w celu rozwiązania problemu w nadchodzącym przebiegu. Warto zaplanować spotkanie planistyczne, 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ć historie użytkowników, które mogą zostać uwzględnione w przebiegu. 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 tego spotkania zespół uczy się, co musi utworzyć.

Podczas planowania przebiegów możesz odnaleźć inne wymagania dotyczące przechwytywania i dodawania do listy prac. Upewnij się, że jest on dobrze zdefiniowany i w kolejności priorytetu.

Ponadto ustawienie celu przebiegu 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 przebiegu.

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

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

Ustawianie celów przebiegu

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

Wskazówki z rowów: Definiowanie celów przebiegu

Cel przebiegu definiuje, co właściciel produktu i zespół uważają za ostateczny cel do osiągnięcia tego przebiegu. 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 wymyśli cel przebiegu przed wybraniem wielu elementów na potrzeby następnego przebiegu. Elementy tego przebiegu 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.

Na przykład:

  • Ten przebieg skupimy się na prostym scenariuszu 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 przebieg polega na zintegrowaniu najważniejszych bram płatności, dzięki czemu możemy rozpocząć zbieranie pieniędzy.

Ustawianie celów przebiegu pomaga zespołowi skupić się. Ułatwia zdefiniowanie priorytetu zadań w przebiegu i prawdopodobnie pomaga ograniczyć liczbę zaangażowanych uczestników projektu i 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. Liczba ukończonych historii jest druga. Jeśli cel zostanie osiągnięty, przebieg zakończy się pomyślnie, nawet jeśli nie wszystkie scenariusze zostały zakończone.

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

Wskazówki na potrzeby pomyślnych spotkań klasyfikacji

Naprawianie usterek stanowi kompromis z innymi pracami. Użyj spotkania klasyfikacji, 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 sklasyfikowanych. 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 pasek błędów i dług techniczny w ramach ogólnego zestawu działań zespołu ciągłego ulepszania. Te zasoby mogą cię zainteresować:

Wskazówki 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ązywanie wszelkich znanych długów błędów każdego przebiegu

Każdy przebieg, zespół analizuje wszelkie błędy pozostałe na liście prac błędów i dedykuje pojemność, aby uzyskać ten znany zestaw usterek w dół do zera lub prawie zero. Niezależnie od tego, czy jest to jeden dzień, tydzień, czy cały przebieg, najpierw naprawiają usterki. Usterki znalezione później w przebiegu nie są uznawane za część tego początkowego zobowiązania. O ile nie mają wysokiego priorytetu, są one umieszczane na liście prac błędów na potrzeby następnego przebiegu.

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 przebiegu jest bardziej deterministyczne, zwiększając ich szansę na spełnienie zobowiązań. Wszelkie nowe usterki wykryte podczas przebiegu nie są częścią początkowego zobowiązania i można rozwiązać następny przebieg.

Zarządzanie długiem błędów w przedsiębiorstwie

Organizacja przechodząca do kultury, w której dług jest stale wyeliminowany, prawdopodobnie ma do czynienia z następującym pytaniem: Jak można uzyskać zespoły, aby zmniejszyć liczbę usterek bez informowania ich dokładnie, co 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 błędów trzech usterek 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ół jest ponad limitem, oczekuje się, że przestanie pracować nad nowymi funkcjami i dostać się pod limit usterki. Oczekuje się, że zespół będzie zawsze pod jego limitem, ale zespół decyduje, jak chce to zrobić. Limit błędów zapewnia, że zespoły nie mają zbyt długiego długu błędów. Zespół może nauczyć się od błędów, które powodują wstrzyknięcie usterek w pierwszej kolejności.

Pamiętaj, że limit błędów reprezentuje usterki na liście prac błędów. Nie obejmuje błędów znalezionych i naprawionych w przebiegu, w którym jest opracowywana funkcja. Te usterki są uważane za cofniętą 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ę, aby rozwiązać problem z długiem technicznym jako wystąpieniami pbi, historiami użytkowników lub usterkami. 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ą, trener, uczą i pomagają zespołom Scrum w odpowiednim zatrudnieniu 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.

  • Ochrona przed właścicielem produktu lub członkami zespołu przed dodaniem pracy po rozpoczęciu przebiegu.

  • Wyczyść problemy z blokowaniem, które uniemożliwiają zespołowi wprowadzanie postępów. 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, które stają się poważnymi problemami. 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, sprawi, że wartość będzie widoczna za pośrednictwem regularnej komunikacji z osobami biorącym udział w projekcie biznesowym.

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. Skoncentrowanie się pomaga zespołowi zmaksymalizować swoją zdolność do spełniania zobowiązań sprintu. Scrum Master powinien wymusić strukturę spotkania i upewnić się, że rozpoczyna się na czas i kończy się w ciągu 15 minut lub mniej.

Trzy aspekty udanych spotkań Scrum to:

  • Wszyscy wstają. Stojąc w górę pomaga zachować skupienie się na spotkaniach i skrócić.
  • Są one uruchamiane i kończą się w tym samym czasie w tej samej lokalizacji 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ę?

Uwaga

Skupienie się na spotkaniach scrum zależy od stanu pracy, która musi zostać przekazana od jednego członka zespołu do innego członka zespołu.

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

"Wczoraj zaktualizowałem klasę, aby odzwierciedlić nowy element danych, który ściągamy z bazy danych, i mam go do wyświetlenia 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 członek zespołu planuje osiągnąć, i że członek zespołu chciałby, aby niektórzy pomogli przyjrzeć się kodowi.

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 zapewnia wystarczającej ilości szczegółowych informacji o klasie, nad którą pracował, ani o składnikach interfejsu, które zostaną ukończone. W rzeczywistości słowo wykonane nigdy nie pojawiło się.

Ważne jest, aby nikt nie przerywał pracy podczas 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, ponieważ ludzie wracają do biurka lub, jeśli konieczna jest znaczna ilość konwersacji, na spotkaniu kontynuacji.

Wiele zespołów opóźnia dyskusje przy użyciu metody "wirtualnego parkingu". 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

Przeprowadź spotkania przeglądu przebiegu w ostatnim dniu przebiegu. Twój zespół demonstruje każdy element listy prac produktu, który został ukończony w przebiegu. 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 scenariusze użytkownika pozostają na liście prac produktu. Nowe scenariusze użytkownika są dodawane do listy prac. Oba zestawy scenariuszy są klasyfikowane i szacowane lub ponownie szacowane w następnym spotkaniu planowania przebiegu.

Po tym spotkaniu i spotkaniu retrospektywowym twój zespół planuje kolejny przebieg. 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 przebiegu

Retrospektywy, w przypadku przeprowadzania dobrze i w regularnych odstępach czasu, obsługują ciągłe ulepszanie.

Spotkanie retrospektywne przebiegu zwykle odbywa się w ostatnim dniu przebiegu po spotkaniu przeglądu przebiegu. W tym spotkaniu twój zespół bada jego wykonywanie Scrum 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.

Uwaga

Aby wspierać retrospektywę zespołu, rozważ zainstalowanie rozszerzenia Retrospektyw witryny Marketplace. To rozszerzenie obsługuje zbieranie opinii na temat kamieni milowych projektu, organizowanie i ustalanie priorytetów opinii oraz tworzenie i śledzenie zadań z możliwością akcji, aby pomóc zespołowi w ulepszaniu w czasie.

Przyjrzyj się tym obszarom podczas wykonywania 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, aby spowodować niekompletne elementy listy prac? 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 przebiegu. Indywidualny członek zespołu umieścił dodatkowe godziny, podczas gdy inni członkowie zespołu byli sfrustrowani, że nie mogli zrobić więcej, aby pomóc. W przyszłości zespół postanowił ćwiczyć programowanie eXtreme, aby pomóc rozwiązać ten problem w czasie.

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

W celu zaimplementowania ulepszeń może być konieczne wykonanie pewnych czynności przez zespół. Na przykład zespół, który odnalazł się negatywnie na zbyt wiele nieudanych kompilacji, 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 skok i zorganizowali pracę z resztą listy prac produktu.