Menu

Metodologia zwinna: przewodnik dla początkujących po metodach zwinnych i Scrum

agile methodology beginner s guide agile method

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Kompletny przewodnik po metodologii Agile: (ponad 20 szczegółowych samouczków metodologii Agile Scrum)

To jest przewodnik dla programistów i testerów, aby zrozumieć i rozpocząć pracę nad bardzo znanym Metodyka Agile SCRUM do tworzenia i testowania oprogramowania . Naucz się podstawowych, ale ważnych terminologii używanych w procesie Agile Scrum wraz z prawdziwym przykładem całego procesu.

Dla Twojej wygody wymieniliśmy wszystkie samouczki Agile z tej serii. Mam nadzieję, że będą ci niezmiernie pomocne.

Omówione tematy: Co to jest zwinność, co to jest Scrum, metodologia zwinna w tworzeniu i testowaniu oprogramowania, testowanie zwinne, zwinny proces Scrum, metodologia Scrum z zespołem Scrum i Scrum Master.

wprowadzenie do zwinnego rozwoju

Czego się nauczysz:

Lista samouczków metodologii Agile

Samouczek nr 1: Metodyki Agile Scrum (Ten samouczek)
Samouczek nr 2: Manifest Agile
Samouczek nr 3: Zespół Scrumowy oraz ich role i obowiązki
Samouczek nr 4: Artefakty Scruma
Samouczek nr 5: Wydarzenia Scrumowe
Samouczek nr 6: Selekcja defektów w Scrumie
Samouczek nr 7: Samowystarczalne zespoły Scrumowe
Samouczek nr 8: Trzy zasady Amigo
Samouczek nr 9: SAFe - Scaled Agile Framework
Samouczek nr 10: Agile Scrum Quiz

WIĘCEJ polecanych samouczków Agile Scrum:

Samouczek nr 11: Najlepsze techniki szacowania zwinnego
Samouczek nr 12: Zwinny model hybrydowy wodospadu
Samouczek nr 13: Kanban vs Scrum vs Agile
Samouczek nr 14: JIRA Agile Tutorial
Samouczek nr 15: Agile Retrospective Meetings
Samouczek nr 16: Rola analityków biznesowych w SCRUM
Samouczek nr 17: Rola kontroli jakości w Scrumie

Narzędzia i pytania do wywiadu:

Samouczek nr 18: Narzędzia do testowania zwinnego
Samouczek nr 19: Najlepsze narzędzia do zarządzania projektami zwinnymi
Samouczek nr 20: Najpopularniejsze pytania do wywiadów Agile
Samouczek nr 21: Najpopularniejsze pytania do wywiadów Scrum

Zacznijmy od pierwszego samouczka z tej serii - Wprowadzenie do Agile Scrum.

Wprowadzenie do Agile Development

Zwinne w tworzeniu oprogramowania:

Agile to jedna z najczęściej używanych i uznanych platform programistycznych na świecie.

Większość organizacji przyjęła je w takiej czy innej formie, ale wciąż jest długa droga do dojrzałości ich programów adopcyjnych. Jedynym celem tej serii samouczków jest wprowadzenie do świata zwinnego specjalistów ds. Technologii i osób nie zajmujących się technologią.

Poprowadzimy Cię przez podróż Agile krok po kroku, aż zrozumiesz filozofię używania Agile, jej zalety i sposób praktykowania. Ta seria ma na celu wyposażenie i umożliwienie czytelnikom zastosowania uczenia się Agile i Scrum w ich pracy.

Ten konkretny samouczek ma na celu wyjaśnienie, dlaczego istniała potrzeba Agile i jak została stworzona. Podstawą jest tutaj zrozumienie koncepcji Agile Adoption w przemyśle programistycznym.

Historia Agile

Agile narodziło się, gdy pewnego pięknego dnia, kiedy 17 osób z różnymi metodologiami rozwoju zebrało się, aby przeprowadzić burzę mózgów, czy istnieje możliwe alternatywne rozwiązanie dla rozwoju oprogramowania, które mogłoby skrócić czas tworzenia oprogramowania i byłoby mniej obciążone dokumentacją.

W tamtym czasie rozwój oprogramowania trwał tak długo, że zanim projekty były gotowe do realizacji, firma posunęła się naprzód, a wymagania uległy zmianie. Tym samym projekt nie był w stanie zaspokoić potrzeb biznesowych, nawet jeśli był w stanie spełnić określone cele.

W ten sposób mistrzowie różnych technik inżynierii oprogramowania spotkali się, a końcowym rezultatem ich spotkania było to, co nazwali „manifestem zwinnym”, który omówimy szczegółowo w następnym samouczku z tej serii.

Ale zwinność, która narodziła się tego dnia, nie jest tym, co dziś widzimy w organizacjach. Metodologia, którą uzgodnili ci eksperci, została opisana jako „lekka” i szybka. Ale główną wygraną tego spotkania była myśl, że szybsza dostawa produktu i ciągłe informacje zwrotne były kluczem do sukcesu w tworzeniu oprogramowania.

Istniejące techniki kaskadowe były zbyt uciążliwe i nie zapewniały informacji zwrotnej, dopóki produkt końcowy nie był gotowy do dostarczenia. Oznaczało to, że nie było możliwości korekty kursu, a klient nie miał wglądu w postęp, dopóki cały produkt nie był gotowy. I właśnie tego chcieli ci eksperci uniknąć.

Chcieli rozwiązania, które umożliwiałoby ciągłe przekazywanie informacji zwrotnych, aby uniknąć kosztów przeróbek na późniejszym etapie.

Zwinne wyzwania

Istniejące wówczas techniki kaskadowe były zbyt uciążliwe i nie umożliwiały uzyskania informacji zwrotnej, dopóki produkt końcowy nie był gotowy do dostarczenia. Nazwano to wodospadowym modelem rozwoju, ponieważ zespoły najpierw ukończyły jeden krok całkowicie, a dopiero potem przeszły do ​​następnego etapu.

Oznaczało to, że nie było możliwości korekty kursu, a klient nie miał wglądu w postęp, dopóki cały produkt nie był gotowy. I właśnie tego chcieli ci eksperci uniknąć. Chcieli rozwiązania, które umożliwiałoby ciągłe przekazywanie informacji zwrotnych, aby uniknąć kosztów przeróbek na późniejszym etapie.

Dlatego agile to także adaptacja i ciągłe doskonalenie, podobnie jak ciągłe sprzężenie zwrotne i szybkość dostarczania.

Co to są zwinne obietnice?

Zwinne obietnice

Agile to nie tylko stosowanie ustalonych praktyk w tworzeniu oprogramowania. Wprowadza również zmianę w nastawieniu Zespołu, co skłania ich do tworzenia lepszego oprogramowania, współpracy i ostatecznie zapewnienia im szczęśliwego Klienta.

Wartości i zasady zwinności pozwalają zespołowi zmienić punkt ciężkości i zmienić proces myślenia o tworzeniu lepszego oprogramowania.

Czym właściwie jest Agile?

Agile nie jest zbiorem reguł. Agile nie jest zbiorem wytycznych. Agile nie jest nawet metodologią. Raczej Agile to zbiór zasad, które zachęcają do elastyczności, zdolności adaptacji, komunikacji i działającego oprogramowania w stosunku do planów i procesów. Jest bardzo zwięźle ujęty w tak zwanym manifeście agile.

Zwinne tworzenie oprogramowania pozwala zespołowi wydajniej i efektywniej współpracować przy opracowywaniu złożonych projektów. Składa się z praktyk, które wykorzystują techniki iteracyjne i przyrostowe, które są łatwe do przyjęcia i dają świetne rezultaty.

Stosując Agile w działaniu, mamy różne metody i metodologie oparte na Agile. Te metody i metodologie zaspokajają wszystkie potrzeby branży programistycznej, od projektowania i architektury oprogramowania, rozwoju i testowania po zarządzanie projektami i dostawy.

Co więcej, metody i metodologie Agile otwierają również zakres doskonalenia procesów jako integralna część każdej dostawy.

Agile to podejście do tworzenia oprogramowania, w którym samowystarczalny i wielofunkcyjny zespół pracuje nad ciągłymi dostawami poprzez iteracje i ewoluuje w trakcie całego procesu, zbierając informacje zwrotne od użytkowników końcowych.

Jak ćwiczyć Agile?

Istnieją różne zwinne metodologie, które są w praktyce stosowane w różnych zróżnicowanych branżach.

zwinne metodologie

Jednak najbardziej popularne metodyki spośród nich wszystkich to:

  • Scrum
  • Kanban
  • Ekstremalne programowanie

Wszystkie te metodologie koncentrują się na rozwoju oprogramowania lean i pomagają w skutecznym i wydajnym tworzeniu lepszego oprogramowania.

To wszystko dzięki Agile Wprowadzenie. Ta część jest tak skonstruowana, aby pomóc Ci zrozumieć podstawowe wartości i zasady, które należy przyjąć, aby zespół pracował w trybie zwinnym i nastawieniu.

Zwinny Metodologia

Wprowadzenie do modeli zwinnych:

Metodyka zwinna

różnica między wyzwalaniem portów a przekierowywaniem portów

Jak wszyscy wiemy, Agile to metodologia tworzenia oprogramowania.

Dowiedzieliśmy się również o wartościach i zasadach, o których wspominali w manifeście agile założyciele agile. W naszych początkowych dyskusjach pominęliśmy również różnice między zwinnymi a tradycyjnymi modelami kaskadowymi.

W tym samouczku poznamy zalety i wady metodyki zwinnej.

Zobaczymy, co to jest scrum? i czym różni się od agile. Następnie zrozumiemy różne metodologie zwinne, które są używane przez różne organizacje i jak możemy je wdrożyć.

Będziesz także w stanie docenić różnicę, a także zalety / wady tych metodologii.

Zalety metodologii Agile

Poniżej podano różne zalety metodologii Agile:

  • Pod koniec każdej iteracji / sprintu klienci na bieżąco mogą obserwować postęp projektu.
  • Każdy sprint zapewnia klientowi działające oprogramowanie, które spełnia jego oczekiwania zgodnie z dostarczoną przez niego definicją wykonanego.
  • Zespoły programistyczne dość szybko reagują na zmieniające się wymagania i są w stanie dostosować się do zmian nawet na zaawansowanych etapach rozwoju.
  • Istnieje ciągła dwukierunkowa komunikacja, która angażuje klientów, dzięki czemu wszyscy interesariusze - biznesowi i techniczni - mają jasny wgląd w postęp projektu.
  • Projekt produktu jest wydajny i spełnia wymagania biznesowe.

Wady metodologii Agile

Chociaż metodologia Agile ma kilka zalet, wiąże się ona również z pewnymi wadami.

Oni są:

# 1) Kompleksowa dokumentacja nie jest preferowana, co może prowadzić do tego, że zespoły zwinne będą nieprawidłowo interpretować to, ponieważ zwinność nie wymaga dokumentacji. Więc rygor gubi się w dokumentacji. Należy tego unikać, ciągle zadając sobie pytanie, czy te informacje są wystarczające, aby kontynuować, czy nie.

#dwa) Czasami na początku projektów wymagania nie są jasne. Zespoły mogą kontynuować i odkryć, że wizja klientów uległa zmianie iw takich sytuacjach zespoły muszą wprowadzić wiele zmian i trudno jest również ocenić efekt końcowy.

Rodzaje metodologii Agile

Na całym świecie istnieje kilka zwinnych metodologii. Dokładniej poznamy cztery najpopularniejsze z nich.

Typy metodologii Agile

1) Scrum

Scrum można łatwo uznać za najpopularniejszy framework agile. Termin „scrum” jest przez większość praktyków uważany za synonim „agile”. Ale to błędne przekonanie. Scrum to tylko jeden z frameworków, dzięki którym można wdrożyć zwinność.

Słowo scrum pochodzi od rugby sportowego. Gdzie gracze gromadzą się razem w zablokowanej pozycji, popychając przeciwników. Każdy gracz ma określoną rolę na swojej pozycji i może grać zarówno ofensywnie, jak i defensywnie, zgodnie z wymaganiami sytuacji.

Podobnie, scrum w IT wierzy w upoważnione, samodzielnie zarządzane zespoły programistyczne z trzema konkretnymi i jasno określonymi rolami. Te role obejmują - Właściciel produktu (PO), Scrum Master (SM) oraz zespół programistów składający się z programistów i testerów . Pracują razem w iteracyjnych przedziałach czasowych zwanych sprintami.

Pierwszym krokiem jest utworzenie backlogu produktu przez PO. To lista rzeczy do zrobienia przez zespół scrumowy. Następnie zespół scrumowy wybiera elementy o najwyższym priorytecie i próbuje je ukończyć w przedziale czasowym zwanym sprintem.

Łatwiejszym sposobem na zapamiętanie tego wszystkiego jest zapamiętanie schematu 3-3-5. Oznacza to, że projekt scrumowy ma 3 role, 3 artefakty i 5 wydarzeń.

To są -

Role: PO, mistrz Scrum i zespół programistów.

Artefakty: Backlog Produktu, Backlog SprintuiPrzyrost produktu.

Wydarzenia: Sprint, planowanie sprintu, codzienny Scrum, przegląd sprintu i retrospektywa sprintu.

Ramy 3-3-5

O każdym z nich dowiemy się bardziej szczegółowo w naszych kolejnych samouczkach.

# 2) Kanban

Kanban to japoński termin oznaczający kartę. Karty te zawierają szczegółowe informacje o pracy, jaką należy wykonać w oprogramowaniu. Celem jest wizualizacja. Każdy członek zespołu jest świadomy pracy, jaką należy wykonać za pomocą tych pomocy wizualnych.

Zespoły używają tych kart Kanban do ciągłej dostawy. Podobnie jak Scrum, Kanban pomaga zespołom efektywnie pracować i promuje samodzielnie zarządzane i współpracujące zespoły.

Ale są również różnice między tymi dwoma - podobnie jak podczas sprintu scrumowego, elementy, nad którymi pracuje zespół, są naprawione i nie możemy dodawać elementów do sprintu, podczas gdy w Kanbanie możemy dodawać przedmioty, jeśli jest dostępna pojemność. Jest to szczególnie przydatne, gdy wymagania często się zmieniają.

Podobnie, inna różnica polega na tym, że chociaż scrum ma zdefiniowane role PO, Scrum Mastera i zespołów programistycznych, w Kanbanie nie ma takich predefiniowanych ról.

Inną różnicą jest to, że chociaż scrum sugeruje priorytetyzację zaległości produktowych, Kanban nie ma takiego wymagania i jest całkowicie opcjonalny. Tak więc Kanban wymaga mniejszej organizacji i unika działań nie wnoszących wartości dodanej i jest odpowiedni dla procesów, które wymagają reagowania na zmiany.

# 3) Lean

Lean to filozofia, która koncentruje się na redukcji odpadów. Jak to się dzieje?

W Lean proces dzieli się na czynności wnoszące wartość, czynności niezwiązane z wartością dodaną i niezbędne czynności niezwiązane z wartością dodaną. Każda czynność, którą można zaklasyfikować jako działalność bez wartości dodanej, jest marnotrawstwem i powinniśmy starać się usunąć te marnotrawstwo w procesie, aby uczynić go mniejszym.

Szczuplejszy proces oznacza szybsze dostarczanie i mniej wysiłku marnowanego na zadania, które nie pomagają w osiągnięciu celów zespołu. Pomaga to zoptymalizować każdy krok w cyklu tworzenia oprogramowania. Dlatego zasady Lean zostały zaadaptowane z Lean Manufacturing do rozwoju oprogramowania.

Rozwój oprogramowania Lean można wykorzystać w dowolnym projekcie IT, stosując siedem zasad Lean, które przedstawiono poniżej:

siedem zasad Lean

Są one dość oczywiste, jak sugerują ich nazwy. Eliminacja marnotrawstwa jest pierwszą i najważniejszą zasadą Lean i widzieliśmy, jak to zrobić, po prostu klasyfikujemy działania jako wartościowe i niebędące wartością dodaną.

Czynnością, która nie wnosi wartości dodanej, może być dowolna część kodu, która może uczynić go mniej niezawodnym, zwiększyć nakład pracy i zająć dużo czasu, nie dodając jednak uzasadnionej wartości biznesowej. Mogą to być również niejasne historie użytkowników, słabe testy lub dodawanie funkcji, które nie są wymagane w szerszej perspektywie.

Druga zasada wzmacniająca uczenie się jest ponownie łatwa do zrozumienia, ponieważ zespół potrzebuje różnych umiejętności, aby dostarczać produkty w szybko zmieniającym się środowisku, w którym nowe technologie pojawiają się w krótkim czasie.

Podejmowanie późnych decyzji może być satysfakcjonujące w okolicznościach, w których zmniejsza się liczba przeróbek, na przykład jeśli są oczekiwane jakiekolwiek zmiany, lepiej je opóźnić, aby zespół nie musiał powtarzać pracy, gdy zmieniają się potrzeby biznesowe.

Ale zawsze istnieje kompromis, ponieważ zespoły muszą to zrównoważyć z czwartą zasadą szybszego dostarczania. Opóźnianie decyzji nie powinno wpływać na ogólną realizację i nie może zmniejszać tempa pracy. Jedno oko powinno być zawsze skierowane na cały obraz.

Posiadanie wzmocnionych zespołów jest obecnie bardzo powszechne i jest to coś, co sugeruje nawet agile. Upoważnione zespoły są bardziej odpowiedzialne i mogą szybciej podejmować decyzje. Poczucie własności we wzmocnionym zespole prowadzi do lepszych wyników. Aby wzmocnić zespół, należy mu pozwolić na organizowanie się i samodzielne podejmowanie decyzji.

Widzimy więc, że lean i agile mają wiele wspólnego z jedną istotną różnicą - podczas gdy zespoły lean mogą pomóc udoskonalić produkt, to zespoły zwinne to te, które faktycznie tworzą produkt.

# 4) Programowanie ekstremalne (XP)

Programowanie ekstremalne to kolejna najpopularniejsza technika zwinna. Jak podaje extremeprogramming.org, pierwszy projekt XP rozpoczął się 6 marca 1996 roku. Wspomina się też, że XP wpływa na rozwój projektów oprogramowania na 5 różnych sposobów - komunikacja, prostota, informacja zwrotna, szacunek i odwaga. Nazywa się to wartościami XP.

Z tego wszystko zaczyna się od komunikacji. Zespoły XP regularnie współpracują z zespołami biznesowymi i innymi programistami i rozpoczynają tworzenie kodu od pierwszego dnia. Skupiamy się tutaj na komunikacji twarzą w twarz, tak dalece, jak to możliwe, z pomocą innych pomocy wizualnych.

Ekstremalni programiści również tworzą prosty kod i zaczynają otrzymywać informacje zwrotne na jego temat już od pierwszego dnia. Skupiamy się na tym, aby nie przesadzać ani nie przewidywać wymagań, które nie zostały podzielone. Dzięki temu projekt jest prosty i powstaje tylko minimalny produkt, który będzie spełniał wymagania.

Informacje zwrotne pomagają zespołowi ulepszyć i zapewnić lepszą jakość pracy. Pomaga im to budować wzajemny szacunek, gdy uczą się od siebie nawzajem i uczą, jak dzielić się swoimi poglądami.

Daje im to również odwagę, ponieważ wiedzą, że zebrali najlepsze pomysły wszystkich i stworzyli dobry produkt z opiniami innych. Dzięki temu nie boją się wprowadzać zmian lub otrzymywać dalszych informacji zwrotnych na temat swojej pracy.

Jest to szczególnie przydatne w projektach, w których wymagania będą się często zmieniać. Stałe informacje zwrotne pomogą zespołom odważnie wprowadzać te zmiany.

W ten sposób widzieliśmy różne zwinne metodologie, takie jak Scrum, XP, Kanban i Lean, wraz z ich zaletami i wadami.

Teraz możemy łatwo je rozróżnić, a także docenić subtelniejsze różnice między nimi. Nauczyliśmy się również podstaw każdej z tych metodologii i widzieliśmy, jak zastosować je w naszych projektach w razie potrzeby.

W następnej części zrozummy wszystko o Scrumie.

Metodologia Scruma

SCRUM to proces w metodyce zwinnej będący połączeniem modelu iteracyjnego i przyrostowego.

Jedna z głównych wad tradycji Model wodospadu polegało na tym, że do czasu zakończenia pierwszej fazy aplikacja nie przechodzi do drugiej fazy. I przypadkowo, jeśli na późniejszym etapie cyklu nastąpią jakieś zmiany, wdrożenie tych zmian staje się bardzo trudne, ponieważ wymagałoby powrotu do wcześniejszych faz i powtórzenia zmian.

Agile Scrum Testing

Niektóre z kluczowych cech SCRUM to:

  • Samoorganizujący się i skoncentrowany zespół.
  • Żadnych ogromnych dokumentów wymagań, raczej mają bardzo dokładne i na temat historie.
  • Zespoły wielofunkcyjne pracują razem jako jedna jednostka.
  • Ścisła komunikacja z przedstawicielem użytkownika w celu zrozumienia funkcji.
  • Ma określony harmonogram maksymalnie jednego miesiąca.
  • Zamiast robić całą „rzecz” na raz, Scrum robi wszystko po trochu w określonym przedziale czasu.
  • Zdolność i dostępność zasobów są brane pod uwagę przed podjęciem jakichkolwiek działań.

Aby dobrze zrozumieć tę metodologię, ważne jest zrozumienie kluczowych terminów SCRUM.

Przeczytaj także => Jak dostarczać wartościowe funkcje oprogramowania w krótkim okresie czasu przy użyciu zwinnego procesu Scrum

Ważne terminologie SCRUM

1) Zespół Scrumowy

Zespół scrumowy to zespół składający się z 7 osób z + lub - dwoma członkami. Członkowie ci to mieszanka kompetencji i składają się z programistów, testerów, osób zajmujących się bazami danych, osób wspierających itp., A także właściciela produktu i mistrza scrum.

Wszyscy ci członkowie pracują razem w ścisłej współpracy w rekurencyjnym i określonym interwale, aby opracować i wdrożyć wspomniane funkcje. Układ siedzeń zespołu SCRUM odgrywa bardzo ważną rolę w ich interakcji, nigdy nie siedzą w boksach czy kabinach, ale na ogromnym stole.

Zespół Scrumowy

2) Sprint

Sprint to predefiniowany interwał lub przedział czasowy, w którym praca musi zostać zakończona i przygotowana do przeglądu lub wdrożenia produkcyjnego. Ten przedział czasowy zwykle wynosi od 2 tygodni do 1 miesiąca.

java tworzy kopię tablicy

W naszym codziennym życiu, kiedy mówimy, że wykonujemy miesięczny cykl Sprintu, oznacza to po prostu, że przez miesiąc pracujemy nad zadaniami i przygotowujemy je do przeglądu do końca tego miesiąca.

3) Właściciel produktu

Właściciel produktu jest kluczowym interesariuszem lub głównym użytkownikiem aplikacji, która ma zostać opracowana. Właścicielem produktu jest osoba, która reprezentuje stronę klienta. On / ona ma ostateczną władzę i zawsze powinien być dostępny dla zespołu.

Powinien być osiągalny, gdy ktoś ma wątpliwości, które wymagają wyjaśnienia. Właściciel produktu musi zrozumieć i nie przypisywać żadnych nowych wymagań w trakcie sprintu lub gdy sprint już się rozpoczął.

4) Scrum Master

Scrum Master jest moderatorem zespołu scrumowego. Dba o to, aby zespół scrumowy był produktywny i postępowy. W przypadku jakichkolwiek przeszkód, Scrum Master podąża za nimi i rozwiązuje je dla zespołu. SCRUM Master jest mediatorem między PO a zespołem.

Na bieżąco informuje PO o przebiegu Sprintu. Jeśli zespół napotyka na przeszkody lub problemy, omów z zamówieniem i rozwiązuj je. Podobnie jak w przypadku Daily Standup zespołu, pojedynek Mastera SCRUM z PO ma miejsce każdego dnia.

Zalecana lektura => Jak być dobrym mentorem zespołu, trenerem i prawdziwym obrońcą zespołu w świecie testów zwinnych?

5) Analityk biznesowy (licencjat)

Analityk biznesowy odgrywa bardzo ważną rolę w SCRUM. Ta osoba jest odpowiedzialna za sfinalizowanie wymagania i sporządzenie go w dokumentacji wymagań (na podstawie której tworzone są historyjki użytkownika).

Jeśli istnieją jakiekolwiek niejasności w Historiach użytkowników / kryteriach akceptacji, to on / ona zwraca się do zespołu technicznego (SCRUM), a następnie przekazuje sprawę do zamówienia zakupu lub, jeśli to możliwe, rozwiązuje samodzielnie. W projektach na dużą skalę może być więcej niż 1 licencjat, ale w projektach na małą skalę SCRUM Master może również pełnić funkcję licencjata.

Zawsze dobrze jest mieć licencjat na początku projektu.

6) Historia użytkownika

Historie użytkownika to nic innego jak wymagania lub funkcja, którą należy zaimplementować.

W scrumie nie mamy tych ogromnych dokumentów wymagań, a raczej wymagania są zdefiniowane w pojedynczym akapicie, zwykle w formacie:

Jak
chcę
Osiągnąć

Na przykład :

Jako administrator chcę mieć blokadę hasłem na wypadek, gdyby użytkownik wprowadził nieprawidłowe hasło 3 razy z rzędu, aby ograniczyć nieautoryzowany dostęp.

Istnieje kilka cech historyjek użytkowników, których należy się trzymać. Historie użytkowników powinny być krótkie, realistyczne, możliwe do oszacowania, kompletne, negocjowalne i testowalne. Historia użytkownika nigdy nie jest zmieniana ani zmieniana w środku Sprintu.

Obowiązkiem SCRUM Master i BA (jeśli dotyczy) jest upewnienie się, że OP sporządził poprawnie Historie użytkowników z odpowiednim zestawem Kryteriów akceptacji ”. Jeśli mają zostać wprowadzone jakiekolwiek zmiany, które będą miały wpływ na zwolnienie sprintu, to takie historie są wyciągane ze sprintu lub są wykonywane zgodnie z dostępnymi godzinami.

Każda historyjka użytkownika ma kryterium akceptacji, które powinno być dobrze zdefiniowane i zrozumiane przez zespół.

Kryteria akceptacji szczegółowo opisują historyjkę użytkownika, która dostarcza dokumenty uzupełniające. Pomaga to w dalszym udoskonalaniu historii użytkownika. Każdy z zespołu może spisać kryteria akceptacji. Zespół testujący opiera swoje przypadki testowe / warunki na tych kryteriach akceptacji.

7) Eposy

Epiki to niejednoznaczne historie użytkowników lub możemy powiedzieć, że są to historie użytkowników, które nie są zdefiniowane i są przechowywane na potrzeby przyszłych sprintów.

Po prostu spróbuj odnieść to do życia, wyobraź sobie, że jedziesz na wakacje. Jadąc w przyszłym tygodniu, masz już wszystko gotowe, takie jak rezerwacje hoteli, zwiedzanie, czek podróżny itp. A co z planem wakacji na przyszły rok? Masz tylko mgliste pojęcie, że możesz udać się do miejsca XYZ, ale nie masz szczegółowego planu.

Epic jest taki jak Ty na przyszłoroczny plan wakacji, w którym po prostu wiesz, że możesz chcieć jechać, ale gdzie, kiedy, z kim, wszystkie te szczegóły, o których nie masz pojęcia w tej chwili.

W podobny sposób istnieją funkcje, które należy zaimplementować w przyszłości, których szczegóły nie są jeszcze znane. Przeważnie funkcja zaczyna się od Epic, a następnie jest podzielona na historie, które można zaimplementować.

8) Rejestr produktu

Backlog produktu to rodzaj wiadra lub źródła, w którym przechowywane są wszystkie historie użytkowników. Jest to obsługiwane przez właściciela produktu. Rejestr produktu można sobie wyobrazić jako listę życzeń właściciela produktu, który nadaje mu priorytet zgodnie z potrzebami biznesowymi.

Podczas spotkania dotyczącego planowania (patrz następna sekcja) jedna historia użytkownika jest pobierana z rejestru produktu, a następnie zespół przeprowadza burzę mózgów, rozumie ją i dopracowuje oraz wspólnie decyduje, które historie użytkownika wziąć, przy udziale właściciela produktu.

9) Backlog Sprintu

Na podstawie priorytetu historie użytkowników są pobierane z rejestru produktu pojedynczo. Zespół Scruma przeprowadza burzę mózgów na ten temat, aby określić wykonalność i decyduje o historiach do pracy nad określonym sprintem. Zbiorcza lista wszystkich historyjek użytkownika, nad którymi pracuje zespół scrumowy w danym sprincie, nazywana jest backlogiem sprintu.

Sprint Backlog

10) Punkty fabularne

Punkty fabularne są ilościowym wskaźnikiem złożoności historyjki użytkownika. Na podstawie punktu fabularnego określane są szacunki i wysiłki związane z historią.

Punkt fabularny jest względny, a nie absolutny. Aby mieć pewność, że nasze szacunki i starania są prawidłowe, ważne jest, aby sprawdzić, czy historie użytkowników nie są duże. Im dokładniejsza i mniejsza jest historia użytkownika, tym dokładniejsza będzie ocena.

Każda historia użytkownika jest przypisana do punktu opowieści opartego na serii Fibonacciego (1, 2, 3, 5, 8, 13 i 21). Im wyższa liczba, tym złożoność to historia.

Być precyzyjnym

  • Jeśli podasz 1/2/3 punkt opowieści, oznacza to, że historia jest mała i mało złożona.
  • Jeśli dasz punkty jako 5/8, jest to średni kompleks i
  • 13 i 21 są bardzo złożone.

Tutaj złożoność składa się zarówno z prac rozwojowych, jak i testowych.

Aby zdecydować o wątku fabularnym, w zespole scrum odbywa się burza mózgów, a zespół wspólnie decyduje o punkcie historii.

Może się zdarzyć, że zespół programistów przyzna punkt historii na 3 do określonej historii, ponieważ dla nich mogą to być 3 linie zmiany kodu, ale zespół testujący daje 8 punktów historii, ponieważ czują, że ta zmiana kodu wpłynie na większe moduły, więc wysiłek związany z testowaniem byłby większy. Cokolwiek opowiadasz, musisz to uzasadnić.

Tak więc w tej sytuacji dochodzi do burzy mózgów i zespół wspólnie zgadza się na jeden wątek.

Decydując się na temat fabularny, pamiętaj o poniższych czynnikach:

  • Zależność historii od innej aplikacji / modułu.
  • Zestaw umiejętności zasobu.
  • Złożoność historii.
  • Nauka historyczna.
  • Kryteria akceptacji historyjki użytkownika.

Jeśli nie znasz jakiejś historii, nie oceniaj jej.

Ilekroć historia ma = lub> 8 punktów, jest dzielona na 2 lub więcej historii.

11) Wykres spalania

Wykres spalania to wykres, który pokazuje szacowany v / s rzeczywisty wysiłek zadań scrumowych.

Jest to mechanizm śledzenia, za pomocą którego dla konkretnego sprintu codzienne zadania są śledzone, aby sprawdzić, czy historie postępują w kierunku ukończenia popełnionych punktów historii, czy nie.

Przykład : Aby to zrozumieć, spójrz na poniższy rysunek:

Wykres spalania 1

Założyłem:

  • Sprint 2 tygodnie (10 dni)
  • 2 zasoby aktualnie pracujące nad sprintem.

'Fabuła' -> Ta kolumna pokazuje historie użytkowników wzięte do sprintu.

'Zadanie' -> Ta kolumna pokazuje listę zadań związanych z historyjką użytkownika.

'Wysiłek' -> Ta kolumna pokazuje wysiłek. Teraz ta miara to całkowity wysiłek potrzebny do wykonania zadania. Nie przedstawia wysiłku włożonego przez jakąkolwiek konkretną osobę.

„Dzień 1 - Dzień 10” -> Ta kolumna (y) pokazuje godziny, które pozostały do ​​zakończenia historii. Proszę zauważyć, że ta godzina NIE jest godziną, która już minęła, ALE godzinami, które jeszcze zostały.

'Szacowany wysiłek' -> To suma wysiłku. Dla „Startu” jest to po prostu suma całego pojedynczego zadania: SUMA (C5: C15)

Łączna liczba wysiłku, który należy wykonać w ciągu 1 dnia, wynosi 70/10 = 7. Zatem na koniec dnia 1 wysiłek powinien zmniejszyć się do 70 - 7 = 63. W podobny sposób obliczany jest dla wszystkich dni do dnia 10, kiedy szacowany wysiłek powinien wynosić 0 (wiersz 16)

„Pozostały rzeczywisty wysiłek” -> Jak sama nazwa wskazuje, czy wysiłek faktycznie pozostał do ukończenia historii. Może się również zdarzyć, że rzeczywisty wysiłek wzrośnie lub zmniejszy się od szacowanego.

Możesz użyć wbudowanych funkcji i wykresu w programie Excel, aby utworzyć ten wykres postępu.

Kroki spalenia na wykresie wyglądałyby następująco:

  1. Wprowadź wszystkie historie (kolumny A5 - A15).
  2. Wprowadź wszystkie zadania (kolumny B5 - B15).
  3. Wprowadź dni (dzień 1 - dzień 10).
  4. Wprowadź wysiłki początkowe (zsumuj zadania C5 - C15).
  5. Zastosuj wzór, aby obliczyć „Szacowane wysiłki” dla każdego dnia (od dnia 1 do dnia 10). Wprowadź formułę w D15 (C16- $ C $ 16/10) i przeciągaj ją na wszystkie dni.
  6. Wprowadź rzeczywiste wysiłki każdego dnia. Wprowadź formułę w D17 (SUMA (D5: D15)), aby podsumować pozostały rzeczywisty wysiłek i przeciągnij ją dla wszystkich pozostałych dni.
  7. Wybierz go i utwórz wykres w następujący sposób:

Wykres spalania 2

12) Prędkość

Całkowita liczba punktów fabularnych, które zespół scrumowy archiwizuje podczas sprintu, nazywa się Velocity. Zespół Scrumowy jest oceniany lub odnoszony na podstawie jego szybkości. Powiedziawszy to, należy pamiętać, że celem tutaj NIE jest osiągnięcie maksymalnej liczby punktów fabularnych, ale uzyskanie wysokiej jakości produktu, z poszanowaniem poziomu komfortu zespołu scrumowego.

Na przykład : Dla konkretnego sprintu: całkowita liczba historyjek użytkownika to 8 z punktami opowieści, jak pokazano poniżej.

Prędkość Scruma

Więc tutaj prędkość będzie sumą punktów opowieści = 30

Definicja ukończenia:

Sprint jest oznaczony jako Ukończony, gdy wszystkie historie są ukończone, wszystkie zadania związane z programowaniem, badaniami i QA są oznaczone jako `` Ukończone '', wszystkie błędy są naprawione - zamknięte, a inne te, które można zrobić później (np. Nie są całkowicie powiązane lub są mniej ważne) są wyciągane i dodawane do zaległości, przegląd kodu i testy jednostkowe są zakończone, szacowane godziny odpowiadają godzinom faktycznie przeznaczonym na zadania, a co najważniejsze, PO i interesariusze otrzymali udane demo.

Działania wykonane w metodologii SCRUM

1) Planowanie spotkania

Spotkanie planistyczne jest punktem wyjścia Sprintu. Jest to spotkanie, na którym zbiera się cały zespół scrumowy, a SCRUM Master wybiera historię użytkownika na podstawie priorytetu z rejestru produktu i burzy mózgów na jego temat.

Na podstawie dyskusji zespół scrumowy decyduje o złożoności historii i dopasowuje ją do serii Fibonacciego. Zespół identyfikuje zadania wraz z wysiłkami (w godzinach), które zostałyby podjęte, aby zakończyć wdrażanie historyjki użytkownika.

Często spotkanie dotyczące planowania poprzedzone jest „spotkaniem przygotowującym do planowania”. To tak, jak praca domowa, którą zespół scrumowy wykonuje, zanim usiądzie na formalnym spotkaniu planującym. Zespół próbuje spisać zależności lub inne czynniki, które chciałby omówić na spotkaniu planującym.

# 2) Wykonywanie zadań sprinterskich

Jak sama nazwa wskazuje, są to rzeczywiste prace wykonane przez zespół scrumowy w celu wykonania zadania i przeniesienia historyjki użytkownika do stanu „Gotowe”.

# 3) Codzienna walka

Podczas cyklu sprinterskiego, każdego dnia zespół scrumowy spotyka się na nie więcej niż 15 minut (może to być stand-up call, zaleca się mieć na początku dnia) i stwierdza 3 punkty:

  1. Co członek zespołu zrobił wczoraj?
  2. Co członek zespołu planował dzisiaj zrobić?
  3. Czy są jakieś przeszkody (blokady drogowe)?

To mistrz Scrum prowadzi to spotkanie. W przypadku, gdy jakikolwiek członek zespołu napotyka jakiekolwiek trudności, Scrum Master podąża za ich rozwiązaniem. W Stand upach tablica jest również przeglądana i sama w sobie pokazuje postępy zespołu.

# 4) Spotkanie przeglądowe

Pod koniec każdego cyklu sprintu zespół SCRUM spotyka się ponownie i demonstruje właścicielowi produktu wdrożone historie użytkownika. Właściciel produktu może zweryfikować historie zgodnie z kryteriami akceptacji. Ponownie obowiązkiem mistrza Scruma jest przewodniczenie temu spotkaniu.

Również w narzędziu SCRUM Sprint jest zamknięty, a zadania oznaczone jako wykonane.

5) Spotkanie retrospektywne

Spotkanie retrospektywne odbywa się po spotkaniu przeglądowym.

Zespół SCRUM spotyka się, omawia i dokumentuje następujące punkty:

  • Co poszło dobrze podczas sprintu (najlepsze praktyki)?
  • Co nie poszło dobrze w Sprincie?
  • Zdobyta wiedza
  • Działania.

Zespół Scrumowy powinien nadal postępować zgodnie z najlepszymi praktykami, ignorować „nie najlepsze praktyki” i wdrażać wnioski wyciągnięte podczas kolejnych sprintów. Spotkanie retrospektywne pomaga wdrażać ciągłe doskonalenie procesu SCRUM.

Jak przebiega proces? Przykład!

Przeczytałem o technicznych żargonach SCRUM. spróbuję pokazać cały proces na przykładzie.

Przykład:

Krok 1 : Stwórzmy zespół SCRUM składający się z 9 osób składający się z 1 właściciela produktu, 1 mistrza Scrum, 2 testerów, 4 programistów i 1 DBA.

Krok 2 : Postanowiono, że Sprint będzie miał cykl 4-tygodniowy. Mamy więc miesięczny Sprint od 5 czerwca do 4thlipca.

Krok 3 : Właściciel produktu ma priorytetową listę historyjek użytkownika w rejestrze produktu.

Krok 4: Drużyna postanawia spotkać się 4thCzerwiec na spotkanie „Planowanie wstępne”.

  • Właściciel produktu pobiera 1 historię z rejestru produktu, opisuje ją i pozostawia zespołowi w celu przeprowadzenia burzy mózgów.
  • Cały zespół omawia i komunikuje się bezpośrednio z właścicielem produktu, aby jasno zrozumieć historię użytkownika.
  • W podobny sposób podejmowane są różne inne historie użytkowników. Jeśli to możliwe, zespół może również przejść dalej i dopasować historie.

Po zakończeniu dyskusji Poszczególni członkowie zespołu wracają na swoje stacje robocze i

  • Określ ich indywidualne zadania dla każdej historii.
  • Oblicz dokładną liczbę godzin, w których będą pracować. Sprawdźmy, jak członek kończy te godziny.

Całkowita liczba godzin pracy = 9
Minus 1 godzina na przerwę, minus 1 godzina na spotkania, minus 1 godzina na e-maile, dyskusje, rozwiązywanie problemów itp.
Czyli rzeczywisty czas pracy = 6.
Łączna liczba dni roboczych podczas Sprintu = 21 dni.
Całkowita liczba dostępnych godzin = 21 * 6 = 126.
Członek jest na urlopie przez 2 dni = 12 godzin (to zależy od każdego członka, niektórzy mogą wziąć urlop, a niektórzy nie).
Liczba rzeczywistych godzin = 126 - 12 = 114 godzin.

Oznacza to, że członek będzie faktycznie dostępny przez 114 godzin na ten sprint. Więc rozłoży swoje indywidualne zadanie sprinterskie w taki sposób, aby w sumie osiągnąć 114 godzin.

Krok 5 : W dniu 5thczerwca cały zespół Scrumowy spotyka się na „Spotkaniu Planowania”.

  • Ostateczny werdykt historyjki użytkownika z backlogu produktu jest wykonywany, a historia jest przenoszona do Backlogu Sprintu.
  • Dla każdej historii każdy członek zespołu deklaruje zidentyfikowane zadania, w razie potrzeby może omówić te zadania, może je zmienić lub zmienić (pamiętaj o serii Fibonacciego !!).
  • Mistrz Scrum lub zespół wpisują w narzędziu swoje indywidualne zadania wraz z godzinami poświęconymi na każdą historię.
  • Po ukończeniu wszystkich historii Scrum master odnotowuje początkową prędkość i formalnie rozpoczyna Sprint.

Krok 6 : Po rozpoczęciu Sprintu, na podstawie przydzielonych zadań, każdy członek zespołu rozpoczyna pracę nad tymi zadaniami.

Krok 7 : Zespół spotyka się codziennie przez 15 minut i omawia 3 kwestie:

  • Co robili wczoraj?
  • Co planują dzisiaj zrobić?
  • Czy są jakieś przeszkody (blokady drogowe)?

Krok 8 : Scrum master codziennie śledzi postępy za pomocą „Burn down chart”.

Krok 9 : W przypadku jakichkolwiek przeszkód, Scrum Master podejmuje kroki, aby je rozwiązać.

Krok 10 : Włącz 4thW lipcu zespół spotyka się ponownie na spotkaniu przeglądowym. Członek demonstruje zaimplementowaną historię użytkownika właścicielowi produktu.

Krok 11 : Włączona 5thW lipcu zespół spotyka się ponownie na retrospektywę, gdzie dyskutują

  • Co poszło dobrze?
  • Co nie poszło dobrze?
  • Działania.

Krok 12 : W 6thW lipcu Drużyna ponownie spotyka się na spotkaniu przygotowawczym do następnego sprintu i cykl trwa.

proces metodologii agile scrum

Narzędzia aktywności SCRUM

Istnieje kilka narzędzi, które mogą być szeroko stosowane do śledzenia działań scrumowych.

Niektóre z nich to:

W nadchodzącym samouczku będziemy rzucać światło na Manifest Agile, który jest ideą, która napędza efektywne Zespoły Agile.

Następny samouczek

O Autorach: Ta seria została napisana przez następujących członków zespołu STH: Shruti Shrivastava - Professional Scrum Master z 9-letnim doświadczeniem w domenach BFSI, E-commerce i B2B. Shruti jest ekspertem w dziedzinie testowania automatyzacji i prowadzi zespoły scrumowe.

Anshul Kumar Srivastava - zorientowany na wyniki profesjonalista w zakresie zarządzania produktami i praktyka Agile z 7-letnim doświadczeniem w sektorach BFSI i Telecom.

rekomendowane lektury

^