W obecnym przemyśle IT koncepcja Agile stała się dość popularna. Wszyscy o tym mówią. Prawie wszystkie firmy IT przyjęły jakiś poziom agile.
Istnieje również wiele metod w ramach rozwoju agile, w tym Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM) oraz lekkie. RUP, Test Driven Development (TDD) i inne. Wśród wielu metod rozwoju agile, wdrożenie Scrum jest bardziej popularne.
Agile czy Waterfall? Zobacz Wykresy
Najświeższy raport grupy Standish obejmował projekty, które badali w latach 2013-2017. W tym okresie ogólny podział sukcesów, wyzwań i porażek przedstawiono poniżej dla agile i waterfall, przy czym projekty Agile mają około 2 razy większe szanse na sukces i 1/3 mniejsze szanse na porażkę.
(Źródło: vitalitychicago.com — Porównanie Wskaźników Sukcesu Projektów Waterfall i Agile)
Ten artykuł głównie dzieli się zrozumieniem Scrum, procesem wdrażania Scrum oraz zmianami, jakie przynosi wdrożenie Scrum, i wyjaśnia, czym jest działający Scrum.
Czym jest Scrum?
Scrum to ramy do rozwijania i utrzymywania złożonych produktów i jest to proces rozwoju inkrementalnego, iteracyjnego. W tej strukturze cały proces rozwoju składa się z kilku krótkich cykli iteracyjnych, krótkiego cyklu iteracyjnego zwanego Sprintem, a każdy Sprint trwa od 2 do 4 tygodni.
W Scrum używaj Backlogu produktu do zarządzania potrzebami produktu. Backlog produktu jest sortowany według priorytetu wdrożenia, z wartością komercyjną jako główną zasadą sortowania. W Sprincie zespół Scrum wybiera najwyższe priorytetowe wymagania z Backlogu produktu do rozwoju. Wybrane wymagania są omawiane, analizowane i szacowane na Spotkaniu Planowania Sprintu, aby uzyskać listę zadań zwaną backlogiem Sprintu. Gdy zespół Scrum zakończy wszystkie zadania na liście backlogu Sprintu, Sprint kończy się i przechodzi do następnego cyklu iteracyjnego Sprintu.
Dlaczego Scrum nie powiódł się w niektórych firmach
Scrum ma dużą wartość. Jednak wdrożenie Scrum w niektórych firmach jest trudne. Niektórzy ludzie mówią, że Scrum nie ma istotnego wpływu w ich organizacji. Dlaczego mają taki wynik? Główne powody mogą być następujące:
- Agile jest szybszy — Zespół projektowy nie ma poprawnego zrozumienia agile. Po prostu myśli, że zwinność oznacza szybkość, to znaczy, że nadąża za postępem i może być wolny od jakichkolwiek ograniczeń systemowych.
- Agile jest szybszy, albo musimy pracować w nadgodzinach — Słyszałem, że niektóre firmy muszą opracować nową funkcję. Z powodu wdrożenia scrum, zespół projektowy jest zobowiązany do pracy w nadgodzinach, a zadania rozwojowe trwające 2 tygodnie lub dłużej będą realizowane w ciągu jednego tygodnia. Wdrożenie Scrum oznacza, że zespół projektowy pracuje w nadgodzinach, co prowadzi do „strachu” w zwinności zespołu projektowego;
- Backlog produktu nie jest dobrze utrzymywany — PO nie może być kwalifikowany do pracy, nie potrafi podzielić skutecznych historii użytkowników, lub podział historii użytkownika jest nierozsądny, nie może zrealizować inkrementalnego rozwoju;
- Problem formowania zespołu — Scrum ma wysokie wymagania dotyczące zespołów samoorganizujących się, ale wielu członków zespołu czuje, że nie spełniają standardów samoorganizacji;
- Brak kultury Agile — Scrum promuje przejrzystość pracy, bieżące ukończenie projektu i uznanie zadań każdej osoby. Tablica Sprintu i wykres burndown projektu są niezakłócone, a wielu ludzi czuje się z tym niekomfortowo;
- Inspekcja i adaptacja nie są na miejscu — W procesie iteracji problem nie może być odkryty na czas, lub problem zostaje znaleziony, a problem nie może być skutecznie rozwiązany, co sprawia, że zespół projektowy czuje się sfrustrowany. i wiele więcej.
Jeśli wiedza o Scrumie utknie tylko w:
„Mam pomysł rano, zostanie zrealizowany po południu, a wieczorem będzie online.”
To jest niewłaściwe. Moim zdaniem Scrum jest zdecydowanie wartościowy. Główne funkcje Scrum obejmują:
- Scrum może zapewnić priorytetowe traktowanie rozwoju backlogu produktu, który ma wysoką wartość dla klientów i lepiej spełnia potrzeby użytkowników.
- W porównaniu z metodą rozwoju w ramach procesu waterfall, wdrażając Scrum, zespół może podwoić efektywność rozwoju i zmaksymalizować rolę zespołu;
- Scrum może skrócić cykle rozwoju i zwiększyć efektywność dostarczania projektów.
Jednak wdrożenie Scrum nie oznacza, że nie podlega zasadom i ograniczeniom projektowym. Jak więc powinna wyglądać poprawna postawa do wdrożenia Scrum?
Kroki do wdrożenia Scrum
1. Przydziel PO
PO to właściciel produktu, co jest rolą, a PO jest jedynym właścicielem listy zadań do zarządzania produktem. Oczywiście w niektórych firmach PO już istnieje jako organizacja — na przykład nasza firma wdrożyła PO jako organizację w ramach wdrożenia Scrum.
Jako właściciel musi mieć ogólny obraz; głęboko rozumieć informacje i kierunki branży; być w stanie uchwycić kierunek produktu, odpowiadać za krótkoterminowe oraz średnio- i długoterminowe planowanie i zarządzanie produktem; być w stanie przeprowadzać badania użytkowników i planowanie funkcji produktu zgodnie z wymaganiami strategicznymi firmy, śledzić zmieniające się potrzeby i nieustannie innowować produkty.
Ponadto, jeśli używasz PO jako organizacji, w projekcie rozwoju oprogramowania zespół PO może obejmować innych interesariuszy, takich jak menedżerowie produktu, użytkownicy końcowi.
2. Utwórz Zespół Rozwoju
Zespół jest realizatorem produktu i odpowiada za dostarczanie potencjalnych inkrementów gotowych do wysyłki oraz „ukończonych” inkrementów produktu na koniec każdego Sprintu.
Zespół głównie składa się z pracowników rozwoju i testów, a zespół musi być w stanie wdrożyć wizję produktu PO.
Wielkość zespołu powinna wynosić od 5 do 9 osób.
Zespół Scrum powinien być również wielofunkcyjny, a członkowie z umiejętnościami „full stack” są bardziej preferowani, nawet jeśli może być trudno wdrożyć w większości firm.
3. Wybierz Mistrza Scrum
Mistrz Scrum jest odpowiedzialny za proces Scrum i służy PO oraz zespołowi deweloperskiemu. Mistrz Scrum musi mieć poczucie rytuału i potrafić skutecznie i efektywnie organizować spotkania planowania iteracyjnego, codzienne spotkania, spotkania demonstracyjne funkcji oraz spotkania przeglądowe retrospektywne; Mistrz Scrum musi mieć wysoki stopień wykonania i utrzymywać wiarygodność, aby pomóc zespołowi. Skup się na celach dostawy i celach jakościowych, aby zapewnić, że zespoły dostarczają wysokiej jakości produkty efektywnie; prowadź zespoły do budowania efektywnych procesów, kieruj zespoły w zakresie wartości, zasad i praktyk agile; bądź odpowiedzialny za szkolenie innych członków zespołu, aby zapewnić prawidłowe stosowanie Scrum; komunikacja, zarządzanie problemami, rozwiązywanie konfliktów, pomoc zespołowi w eliminacji wszystkich przeszkód.
4. Utrzymuj backlog produktu
Product Backlog to zbiór wszystkich elementów backlogu, oparty na strategii firmy i wizji produktu. PO sortuje wszystkie elementy w backlogu produktu według kolejności priorytetów zgodnie z wartościami biznesowymi i tworzy listę priorytetowych elementów.backlog produktu może służyć jako „mapa drogowa” rozwoju produktu. Aby zrozumieć kontekst produktu, elementy backlogu produktu są najlepszym odniesieniem.
Każdego dnia stawiamy czoła nowym wymaganiom ze strony nowych konkurentów, co oznacza, że PO musi nieustannie optymalizować projekt produktu i dostosowywać priorytety backlogu produktu, aby poradzić sobie z nowymi zmianami.
W tym procesie PO powinien konsultować się ze wszystkimi interesariuszami i zespołami, aby upewnić się, że backlogi produktów odzwierciedlają prawdziwe roszczenia użytkowników.
5. Szacowanie Agile przy użyciu punktów historii
Relatywne szacowanie agile zazwyczaj odbywa się podczas planowania sprintu lub w trakcie sprintu, a backlog produktu jest oceniany przez zespół razem z osobą odpowiedzialną za rzeczywisty rozwój i prace testowe.
Aby przeprowadzić planowanie sprintu bardziej efektywnie w praktyce, PO i Scrum Master dokonają wstępnego oszacowania przed spotkaniem planującym sprint. Muszą zadać sobie takie pytania jak:
- Sprawdź, czy plan sprintu jest wykonalny?
- Czy jest wystarczająco informacji, aby zakończyć te sprawy?
- Czy podział elementu backlogu produktu jest rozsądny?
Kiedy zespół deweloperski przeprowadza oszacowanie, zaleca się porzucenie tradycyjnej metody (tj. ile godzin przypisać do zadania) i zastosowanie podejścia do szacowania agile przy użyciu punktów historii – liczby Fibonacciego (1, 2, 3, 5, 8, 13, 21…) w celu oceny wysiłku wymaganego do wdrożenia elementu.
W momencie oszacowania zespół musi najpierw zidentyfikować element backlogu, który może być w formie historii użytkownika jako odniesienie do oszacowania. Ponadto ważne jest, aby zauważyć, że gdy pojedynczy punkt historii oceny jest większy niż 21, historia użytkownika musi być podzielona ponownie, a pojedynczy punkt historii użytkownika nie może być większy niż 8, co jest stanem idealnym.
6. Spotkanie planujące sprint
To jest pierwsze prawdziwe spotkanie Scrum. Zespół, Scrum Master i PO siedzą razem, aby zaplanować treść sprintu.Jako projekt rozwoju oprogramowania, wchodząc w historię użytkownika planującego sprint, historia użytkownika powinna być podzielona, a projekt wizualny ukończony.
Cykl sprintu jest zazwyczaj stały, głównie od 2 do 4 tygodni. Zespół zaczyna od historii użytkownika o najwyższym priorytecie na liście zadań produktu, aby zobaczyć, ile można zrobić w sprincie.
Jeśli zespół już przeprowadził wiele sprintów, w odniesieniu do:
- „Punkty historii” ukończone w poprzednich iteracjach,
- Zespół może oszacować przybliżoną liczbę punktów historii dla tej iteracji.
- „Punkty historii” są równoważne prędkości zespołu.
Scrum Master i zespół powinni dążyć do zwiększenia tej liczby w każdej iteracji sprintu.
Wszyscy członkowie zespołu powinni osiągnąć konsensus co do celu sprintu, to znaczy, co należy osiągnąć w iteracji sprintu. Na spotkaniu planującym sprint, PO musi poinformować zespół o kolejności priorytetów wdrożenia historii użytkownika. Zespół obiecuje, ile historii będą w stanie ukończyć w następnej iteracji sprintu. W trakcie sprintu nikt nie może jednostronnie zmieniać treści sprintu bez autoryzacji.
7. Codzienne spotkanie Stand-up
Codzienne spotkanie Stand-up jest źródłem witalności dla Scrum. Uczestnicy zazwyczaj obejmują PO, Scrum Mastera i zespół. Zespół komunikuje się wewnętrznie w stałym miejscu i o stałej porze każdego dnia. czas to zazwyczaj poranek, czas trwania nie przekracza 15 minut, a uczestnicy stoją. Scrum Master pyta zespół członków o następujące pytania:
- Co robiłeś wczoraj?
- Jaką pracę planujesz wykonać dzisiaj?
- Jakie są przeszkody i trudności?
Znaczenie tego polega na tym, aby cały zespół jasno znał postęp każdego zadania w trakcie tego cyklu sprintu oraz czy wszystkie zadania mogą być ukończone na czas.
Zadania zespołu nie są przydzielane z góry, ale są podejmowane z własnej inicjatywy i dobrowolnie. Jeśli poprzednie zadanie nie zostało ukończone, nie możesz ubiegać się o następne zadanie, a także nie możesz zgłaszać dwóch zadań, które nie mogą być ukończone w tym samym dniu.
Scrum Master jest odpowiedzialny za eliminowanie przeszkód, z jakimi borykają się członkowie zespołu.
8. Śledzenie postępu projektu za pomocą tablicy zadań Scrum
W Scrum praca musi być przejrzysta, a najczęstszą praktyką jest wdrożenie tablicy zadań Scrum.
Niektóre zespoły dobrze radzą sobie z używaniem narzędzi firm trzecich do korzystania z elektronicznej tablicy Scrum, takich jak Visual Paradigm lub Jira; niektóre zespoły chętnie korzystają z dużych offline’owych tablic fizycznych.
Niezależnie od tego, czy używasz elektronicznej tablicy Scrum, czy fizycznej tablicy, kolumny Kanban zazwyczaj obejmują trzy części: listę zadań do wykonania, bieżące elementy i ukończone elementy. W miarę postępu iteracji zespół codziennie aktualizuje sprawy w odpowiedniej kolumnie Scrum Kanban.
9. Śledzenie postępu za pomocą wykresów wypalenia
Innym narzędziem do przejrzystości pracy jest wykres wypalenia. Na poniższym rysunku jedna oś reprezentuje obciążenie pracą, a druga czas. Każdego dnia Scrum Master zapisuje pozostałe punkty do ukończenia, a następnie rysuje je na wykresie wypalenia. Idealnie, wykres ma kształt opadającej krzywej, wypalając się do zera, gdy reszta pracy jest ukończona.
10. Demonstracja produktu
Sekcja demonstracyjna Przewodnika Scrum nazywa się Spotkaniem Przeglądowym Sprintu, które stwierdza, że powinno obejmować prezentację pracy wykonanej przez zespół deweloperski oraz odpowiedzi na pytania dotyczące przyrostu produktu. Spotkanie zazwyczaj odbywa się przed wydaniem tej iteracji.Najważniejszym zadaniem tego spotkania jest weryfikacja scenariuszy wdrożenia historii użytkowników z akceptującymi ocenami dla każdego z ukończonych elementów, aby spełnić definicję ukończenia.
To spotkanie, w którym każdy może być uczestnikiem, nie tylko PO, Scrum Master i zespół, ale także interesariusze, biznes i menedżerowie, a nawet klienci.
To jest otwarte spotkanie, w którym każdy może być uczestnikiem, nie tylko PO, Scrum Master i zespół, ale także interesariusze, biznes i menedżerowie, a nawet klienci.
Zespoły powinny pokazywać tylko te elementy, które spełniają definicję ukończenia, to znaczy wyniki, które można dostarczyć bez konieczności wykonywania dodatkowej pracy. Ten wynik może nie być kompletnym produktem, ale przynajmniej jest to kompletna i użyteczna funkcja dla końcowego użytkownika.
11. Retrospektywa sprintu
Spotkanie retrospektywne sprintu zazwyczaj odbywa się w drugim dniu po zakończeniu tego sprintu.
Spotkanie retrospektywne sprintu powinno dokładnie przeanalizować następujące pytania:
- Co się wydarzyło, co można poprawić;
- Dlaczego to się stało?
- Dlaczego wówczas to zignorowaliśmy;
- Jak możemy przyspieszyć pracę.
Aby proces retrospektywy sprintu był skuteczny, zespół musi ufać sobie nawzajem. Musimy pamiętać o dyskusji i argumentach opartych na kwestiach projektowych i technicznych:
- Nie ma absolutnie dobrego, złego ani zmartwień,
- Zachęcaj do technicznych zderzeń;
- Nie można angażować się w dyskusje na temat ataków osobistych;
- Odmów ludziom, którzy noszą kolorowe okulary, aby widzieć innych,
- Prowadź wszystkich do racjonalnej dyskusji;
- Odważnie akceptuj wyzwania innych,
- Akceptuj swoje własne niedoskonałości.
- Odpowiedzialni za swoje własne procesy i wyniki,
- Burza mózgów i poszukiwanie rozwiązań problemów. To jest kluczowe.
Na koniec zespół identyfikuje jedno z najbardziej wartościowych ulepszeń i ustawia je jako najwyższy priorytet na następny sprint. Musisz zdefiniować, co oznacza „sukces” w konkretny i wykonalny sposób, aby szybko określić, czy ulepszenia zostały wprowadzone na następnym spotkaniu przeglądowym sprintu.
Po zakończeniu ostatniego sprintu, rozpocznij nową iterację sprintu.
Podsumowanie
Scrum jest kombinacją 3355. Kluczowe koncepcje frameworku scrum można zapamiętać jako 3.3.5.5 w następujący sposób:
3 role
- Właściciel Produktu
- Zespół Deweloperski
- Scrum Master
3 Artefakty
- Backlog Produktu
- Backlog Sprintu — Lista zadań do wykonania w sprincie
- Przyrost Produktu — Potencjalny Przyrost Produktu do Wysyłki
5 wydarzeń
- Sprint
- Spotkanie Planowania Sprintu
- Codzienne Spotkanie Scrum
- Spotkanie Przeglądowe Sprintu
- Spotkanie Retrospektywne Sprintu
5 wartości
- Otwartość
- Szacunek
- Odwaga
- Skupienie
- Zaangażowanie
Cele 3355 opierają się na trzech filarach Scruma
- Przejrzystość
- Inspekcja
- Adaptacja
Definicja „Zrobione” (DoD) jest osiągana poprzez spełnienie 3 filarów za pomocą 5 wydarzeń zespołu Scrum.
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文