Celem codziennej pracy w sprincie jest stworzenie dostarczalnego przyrostu produktu w formie, która może być dostarczona klientowi lub użytkownikowi.
W kontekście pojedynczego sprintu, przyrost produktu lub dostarczalny przyrost oznacza, że produkt roboczy został opracowany, zintegrowany, przetestowany i udokumentowany zgodnie z definicją zakończenia projektu i uznany za gotowy do wydania.
Zespół deweloperski może, ale nie musi, wydać ten produkt na koniec sprintu – czas wydania zależy od planu wydania. Projekt może wymagać wielu sprintów, zanim produkt będzie zawierał zestaw minimalnego produktu rynkowego (MMP) niezbędnego do uzasadnienia wydania na rynek.
Aby stworzyć dostarczalną funkcjonalność, zespół deweloperski i właściciel produktu biorą udział w trzech głównych działaniach:
Opracowywanie
W projekcie zwinnym, opracowywanie to proces określania szczegółów funkcji produktu. Kiedy zespół deweloperski zajmuje się nową historią użytkownika, opracowywanie zapewnia, że wszelkie nieodpowiedziane pytania dotyczące historii użytkownika są wyjaśnione, aby proces rozwoju mógł postępować.
Właściciel produktu współpracuje z zespołem deweloperskim w celu opracowania historii użytkowników, ale zespół deweloperski powinien mieć ostatnie słowo w kwestiach decyzji projektowych. Właściciel produktu powinien być dostępny do konsultacji, jeśli zespół deweloperski potrzebuje dalszych wyjaśnień dotyczących wymagań w ciągu dnia.
Rozwój
Podczas rozwoju produktu, większość działań, naturalnie, przypada zespołowi deweloperskiemu. Właściciel produktu nadal współpracuje z zespołem deweloperskim w razie potrzeby, aby zapewnić wyjaśnienia i zatwierdzić opracowaną funkcjonalność. Podczas sprintu członkowie zespołu:
- Łącz członków zespołu deweloperskiego, aby ukończyć zadania. Dzięki temu poprawia się jakość pracy i zachęca do dzielenia się umiejętnościami.
- Przestrzegaj uzgodnionych standardów projektowych zespołu deweloperskiego. Jeśli nie możesz ich przestrzegać z jakiegokolwiek powodu, przemyśl te standardy i popraw je.
- Rozpocznij rozwój, ustawiając testy automatyczne. Więcej informacji na temat testowania automatycznego znajdziesz w następnej sekcji i w rozdziale 15. Jeśli nowe, pożądane funkcje staną się widoczne podczas rozwoju, dodaj je do backlogu produktu. Unikaj kodowania nowych funkcji, które są poza celem sprintu.
- Integruj zmiany, które zostały zakodowane w ciągu dnia, po jednej grupie na raz. Testuj pod kątem 100 procentowej poprawności. Integruj zmiany przynajmniej raz dziennie; niektóre zespoły integrują wiele razy dziennie. Przeprowadzaj przeglądy kodu, aby upewnić się, że kod przestrzega standardów rozwoju. Zidentyfikuj obszary, które wymagają poprawy. Dodaj poprawki jako zadania w backlogu sprintu.
- Twórz dokumentację techniczną w miarę pracy. Nie czekaj do końca sprintu lub, co gorsza, do końca sprintu przed wydaniem.
Weryfikacja
Weryfikacja pracy wykonanej w sprincie składa się z trzech części: testowania automatycznego, przeglądu rówieśniczego i przeglądu właściciela produktu. Zespół może przeprowadzić:
Testowanie automatyczne
Testowanie automatyczne oznacza użycie programu komputerowego do przeprowadzenia większości testów kodu za Ciebie. Dzięki testowaniu automatycznemu zespół deweloperski może szybko rozwijać i testować kod, co jest dużą korzyścią dla projektów zwinnym. Często zespoły projektowe kodują w ciągu dnia i pozwalają testom działać przez noc. Rano zespół projektowy może przejrzeć raport o defektach wygenerowany przez program testujący, zgłosić wszelkie problemy podczas codziennego scrumu i natychmiast poprawić te problemy w ciągu dnia.
- Testowanie automatyczne może obejmować następujące: Testowanie jednostkowe: Testowanie kodu źródłowego w jego najmniejszych częściach – na poziomie komponentu
- Testowanie systemowe: Testowanie kodu z resztą systemu
- Testowanie statyczne: Weryfikacja, że kod produktu spełnia standardy oparte na zasadach i najlepszych praktykach, które zespół deweloperski uzgodnił
Przegląd rówieśniczy
Przegląd rówieśniczy po prostu oznacza, że członkowie zespołu deweloperskiego przeglądają nawzajem swój kod.
Przegląd właściciela produktu
Gdy historia użytkownika została opracowana i przetestowana, zespół deweloperski przenosi historie do kolumny Akceptacja na tablicy zadań. Właściciel produktu następnie przegląda funkcjonalność i weryfikuje, że spełnia ona cele historii użytkownika, zgodnie z kryteriami akceptacji historii użytkownika. Właściciel produktu weryfikuje historie użytkowników przez cały dzień.
Podsumowanie
Zespół deweloperski raportuje postępy w zadaniach, aktualizując backlog sprintu, wskazując, które zadania zostały ukończone i ile pracy, w godzinach, pozostaje do wykonania w nowych zadaniach. W zależności od oprogramowania, które używa zespół scrumowy, dane z backlogu sprintu mogą automatycznie aktualizować wykres wypalenia sprintu.
Inne artykuły o Scrumie
- Czym jest szablon Rola-Funkcja-Powód?
- Przyrost sprintu vs potencjalny dostarczalny produkt vs MVP vs MMP
- Pisanie celów SMART i INVEST dla historii użytkowników
- Manifest Zwinny i Dwanaście Zasad
- 10 Najczęściej Wspomnianych Podstawowych Zasad w Scrumie
- Czym są wydarzenia Scrum?
- Czym są ceremonie Scrum?
- Czym jest pielęgnacja backlogu produktu?
- Czym jest sprint w Scrumie?
- Serce Scruma – Codzienny Standup
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文