Agile Vs Waterfall: jaka metodologia jest najlepsza dla twojego projektu?

agile vs waterfall which is best methodology

za pomocą czego otwieram pliki jar

Dowiedz się wszystkiego o metodologiach zwinnych i wodospadowych, różnych typach modeli SDLC i różnicach między modelami rozwoju kaskadowego i zwinnego, a także o testowaniu:

Przeczytaj ten artykuł informacyjny, aby na podstawie zalet i wad każdego z nich zdecydować, który model jest najlepszy dla Twojego projektu.

Model wodospadu i model zwinny to typy cyklu życia oprogramowania (SDLC). Są to procesy używane przez branżę oprogramowania do projektowania, rozwijania i testowania oprogramowania.

Postępując zgodnie z SDLC, możemy spełnić oczekiwania klienta, zakończyć projekt w określonych ramach czasowych i oszacować koszt.

Czego się nauczysz:

• Przepływy pracy w modelu wodospadowym i zwinnym
  • Jaki jest cykl życia oprogramowania?
  • Typy cyklu życia oprogramowania
    • 1) Model wodospadu
    • # 2) Model zwinny
    • # 3) Model spiralny
    • # 4) Model prototypowy
    • # 5) Model V i V.
• Model wodospadu
• Agile Workflow
  • Kluczowe terminologie używane w Agile
  • Kluczowe czynniki do przyjęcia metodologii Agile
  • Rodzaje metodologii Agile
• Różnica między modelami wodospadu Agile i Waterfall
• Różnice między testowaniem zwinnym a testowaniem wodospadu
• Wniosek
  • rekomendowane lektury

Przepływy pracy w modelu wodospadowym i zwinnym

W prostym języku angielskim, Agile oznacza „zdolny do szybkiego i łatwego poruszania się” i dlatego właśnie to oznacza, jeśli chodzi o Metodyka zwinnego rozwoju .

Agile to metoda zarządzania projektami, która polega na podzieleniu zadań na krótsze segmenty pracy z częstymi przeglądami i dostosowywaniem planów.

Podobnie słowo wodospad oznacza pionowy przepływ wody lub przepływ wody przez serię stromych kropli. Model kaskadowy to liniowy model sekwencyjny, w którym postęp płynie głównie w jednym kierunku w dół przez fazy gromadzenia wymagań, analizy, projektowania, programowania, testowania, wdrażania i konserwacji.

Ta sama ilustracja dotyczy koncepcji zarządzania projektami, jeśli chodzi o model wodospadu . Jest to metoda zarządzania projektem, którą reprezentują etapy i ustalony plan pracy.

(wizerunek źródło )

Przed omówieniem przepływu pracy Waterfall i Agile, przyjrzyjmy się definicji cyklu życia oprogramowania i jego wymaganiom.

Jaki jest cykl życia oprogramowania?

Systematyczne rozwijanie oprogramowania odbywa się krok po kroku. W tym celu wybieramy spośród różnych typów cykli życia oprogramowania w różnych firmach. Na podstawie wymagań wybierany jest odpowiedni cykl życia.

Model kaskadowy jest jednym z typów SDLC i jest to stary proces tworzenia oprogramowania. Model Agile jest najnowszym i zaawansowanym modelem. Agile wywodzi się z innego cyklu życia oprogramowania.

Inne SDLC obejmuje model spiralny, model V i V, model prototypowy. W oparciu o konieczność i zgodność wymagań biznesowych, dobierzemy najlepszy model rozwoju aplikacji.

(wizerunek źródło )

Dlaczego wymagany jest cykl życia oprogramowania?

SDLC jest wymagane do zarządzania projektem w zorganizowany sposób. Zapewnia pewien poziom kontroli oraz określa role i obowiązki członków zespołu. Zawiera zakres i termin dla każdej fazy w SDLC.

Jest to trochę jak przewodnik dla członków zespołu, który przedstawia wszystkie kroki w celu opracowania i dostarczenia produktu wysokiej jakości. Pomaga kierownictwu zespołu zdefiniować i ocenić cele i wymagania. Pomaga również w planowaniu i szacowaniu zadań. Tworzy linię komunikacyjną między klientem a zespołem programistycznym oraz tworzy role i obowiązki dla każdego z nich.

Typy cyklu życia oprogramowania

Zobaczmy krótkie wprowadzenie do typów SDLC używanych w procesie tworzenia oprogramowania.

1) Model wodospadu

Jak wspomniano wcześniej, model kaskadowy jest pierwszym wprowadzonym cyklem życia oprogramowania. Jest to sekwencyjny sposób tworzenia oprogramowania. Bardzo niewiele firm stosuje takie podejście. Gdy projekt jest bardzo prosty i nie ma dalszych zmian wymagań, będziemy postępować zgodnie z tym podejściem.

Omówimy więcej na temat modelu wodospadu w tym samouczku.

# 2) Model zwinny

Agile workflow to zaawansowane podejście do procesu wytwarzania oprogramowania, które jest stosowane w większości firm. Agile jest definiowany jako cykl życia oprogramowania oparty na sprincie.

W kolejnych sekcjach możemy omówić więcej na temat przepływu pracy Agile.

# 3) Model spiralny

Jest to sposób budowania i testowania oprogramowania poprzez dzielenie i dodawanie wymagań w kolejności przyrostowej. Model ten pomoże w projektach, w których wymagania ciągle się zmieniają. Ten model spiralny jest połączeniem iteracyjnego procesu rozwoju i sekwencyjnego liniowego procesu rozwoju.

Takie podejście pozwoli nam na przyrostowe wydania produktu. Tutaj nie trzeba czekać na ukończenie wszystkich modułów oprogramowania do wydania.

Liniowy model sekwencyjny oznacza, że ​​jest to systematyczne, sekwencyjne podejście do tworzenia oprogramowania, które rozpoczyna się na poziomie systemu i przechodzi przez analizę, projektowanie, kodowanie, testowanie i wsparcie.

Model iteracyjny oznacza, że ​​jest to konkretna implementacja cyklu życia oprogramowania, która koncentruje się na początkowej, uproszczonej implementacji, która następnie stopniowo staje się bardziej złożona i wprowadzana jest szersza funkcja, aż do ukończenia ostatecznego systemu.

# 4) Model prototypowy

Model ten obejmuje proces budowania i testowania oprogramowania w taki sposób, że najpierw opracowujemy model fikcyjny i jeśli jest to wykonalne i spełnia wszystkie wymagania biznesowe to wdrażamy rzeczywisty model pracy.

Tutaj najpierw zbudowaliśmy i przetestowaliśmy prototyp, a następnie zbudowaliśmy rzeczywisty model z dokładnymi specyfikacjami systemu. Prototypowanie oprogramowania to czynność polegająca na tworzeniu prototypów aplikacji.

# 5) Model V i V.

Jest to model weryfikacji i walidacji. Tutaj, podczas opracowywania oprogramowania, używaliśmy do weryfikacji i walidacji wszystkiego na każdym etapie SDLC. Model V jest uważany za rozszerzenie modelu wodospadu.

Tak więc wszystkie typy SDLC mają swoje cechy i cechy. Opierając się na wymaganiach projektu, potrzebach, wykonalności, czasie trwania, możemy wybrać konkretny cykl życia oprogramowania w celu opracowania aplikacji.

Teraz omówimy szczegółowo cykle rozwoju oprogramowania Waterfall i Agile.

Model wodospadu

W modelu wodospadu każdą fazę należy zakończyć przed rozpoczęciem kolejnej fazy. Nie możemy obsługiwać wielu faz jednocześnie. Zostało to wprowadzone w 1970 roku przez Winstona Royce'a. Model Waterfall jest podzielony na różne fazy.

(wizerunek źródło )

Model wodospadu obejmuje następujące fazy:

1. Gromadzenie wymagań
2. Studium wykonalności
3. Projekt
4. Kodowanie
5. Testowanie
6. Konserwacja

# 1) Analiza wymagań

Tutaj analityk biznesowy otrzyma specyfikację wymagań. Wymaganie będzie w formacie CRS (specyfikacji wymagań klienta). CRS wyjaśnia, jak powinien przebiegać przepływ biznesowy i jak aplikacja powinna działać zgodnie z określonymi wymaganiami. Analitycy biznesowi zmienią CRS na SRS (specyfikację wymagań oprogramowania).

Następnie analityk biznesowy szczegółowo omawia specyfikacje wymagań z zespołem programistów i testerów oraz rozumie wymaganie z punktu widzenia programowania i testowania. Jest to faza omawiania i analizy wymagań w celu zbudowania oprogramowania aplikacyjnego w oparciu o rzeczywiste wymagania.

Tutaj wszystko powinno być udokumentowane w dokumencie specyfikacji wymagań oprogramowania. W modelu kaskadowym produkt dostarczalny / wynik / wyjście każdej fazy jest źródłem wejściowym dla następnych faz.

W branży usługowej analityk biznesowy może spełnić wymagania.
W firmie opartej na produktach analityk produktu spełnia wymagania.

# 2) Studium wykonalności

Zespół zarządzający przeprowadzi studium wykonalności. Oznacza to, że zespół przeanalizuje parametry, takie jak to, czy to wymaganie / aplikacja może zostać opracowane w naszym środowisku, czy nie, dostępne zasoby są wystarczające, czy nie, koszt i wiele innych czynników jest wykonalnych lub nie, i sprawdzić, czy jesteśmy w stanie pokryć wszystkie przepływy biznesowe czy nie.

Podczas tego spotkania / analizy, w dyskusji wezmą udział Kierownik Projektu, Analityk Biznesowy, Menedżer Finansowy, HR, Kierownik Projektu.

# 3) Projekt systemu

Tutaj Architekt Projektu przygotuje projekt systemu. Określi sprzęt, wymagania systemowe i zaprojektuje architekturę aplikacji. Projekt systemu składa się z 2 części: projektu wysokiego poziomu i projektu niskiego poziomu. W projektowaniu wysokiego poziomu projektujemy różne bloki aplikacji. W projektowaniu niskopoziomowym piszemy pseudokod.

# 4) Kodowanie

Tutaj programiści rozpoczynają dokładne kodowanie każdej funkcji i interfejsu użytkownika aplikacji przy użyciu różnych metod i różnych logik. Mogą używać dowolnego języka programowania, takiego jak Java, Python lub dowolny inny język do tworzenia aplikacji.

Po zakończeniu kodowania dla każdej funkcjonalności konkretnego modułu aplikacji, programista wykona testy jednostkowe. Jeśli kod działa poprawnie, programista wdroży kod w środowisku testowym i przekaże kompilację testerowi do przetestowania.

# 5) Testowanie

Stąd zaczyna się testowanie. Do tej fazy nie będziemy mieli żadnego zadania w modelu Waterfall. W tej fazie wykonujemy wszystkie rodzaje testów. Te typy testów obejmują testy dymne, testy funkcjonalne, testy integracyjne, testy systemowe, testy akceptacyjne, testy regresji, testy ad-hoc, testy eksploracyjne i testy w różnych przeglądarkach.

Zaczniemy testować aplikację, gdy otrzymamy kompilację. Najpierw zaczniemy od testów dymu. Jeśli nie zostaną zaobserwowane żadne problemy z blokerami, będziemy kontynuować szczegółowe testy.

W testach funkcjonalnych zaczniemy testować każdy komponent aplikacji. Tutaj sprawdzamy różne komponenty, takie jak pola tekstowe, przyciski, linki, przyciski opcji, przyciski przesyłania, listy rozwijane i linki nawigacyjne.

Następnie sprawdzimy interfejs użytkownika, wygląd i sposób działania oraz testy pozytywnych i negatywnych danych wejściowych.

Następnie zaczniemy od testów integracyjnych. Tutaj sprawdzimy integrację danych. Sprawdzimy, czy te same dane są odzwierciedlane na różnych stronach, czy nie, zweryfikujemy nawigację w linkach e-mail do odpowiednich stron. Sprawdzimy integrację danych z aplikacjami firm trzecich i sprawdzimy zmiany bazy danych w aplikacji.

Następnie wykonamy testy systemu. Całość aplikacji sprawdzimy jako pojedynczą jednostkę. Sprawdzimy funkcjonalność, integrację stron, walidacje pól, komunikaty o błędach, komunikaty potwierdzające i wiele innych.

Podczas testowania aplikacji będziemy rejestrować problemy w narzędziu do śledzenia błędów. Nadamy priorytet usterce w oparciu o problemy. Po utworzeniu błędu przypiszemy go do odpowiedniego programisty w celu naprawienia problemu. Błędy zweryfikujemy, gdy programiści przypiszą je testerom po ich naprawieniu. Jeśli to działa dobrze, tester zamknie błąd, w przeciwnym razie testerzy przypiszą z powrotem do programisty, aby naprawić problem. Tak przebiega cykl życia błędu.

Następnie przechodzimy do testów akceptacyjnych. Tutaj testujemy aplikację w różnych środowiskach, takich jak staging i UAT (User Acceptance Testing). To najważniejsza faza do dokładnego przetestowania aplikacji przed przeniesieniem kodu do środowiska produkcyjnego.

Gdy testy akceptacyjne zostaną zakończone bez błędów, klient planuje wdrożyć kod na serwerze produkcyjnym i zaplanować wydanie.

# 6) Konserwacja

Po wdrożeniu kodu aplikacji na serwerze produkcyjnym powinniśmy zapewnić wsparcie / utrzymanie aplikacji klienckiej. Ta faza konserwacji polega na obserwowaniu i naprawianiu problemów produkcyjnych w czasie rzeczywistym, sprawdzaniu problemów z pamięcią, ulepszaniu aplikacji i opracowywaniu nowych zmian wymagań.

W jakich przypadkach możemy zdecydować się na model wodospadu?

• Gdy nie ma wymaganych zmian.
• Kiedy projekt jest mały i prosty.
• Gdy nie ma złożoności technologii.
• Gdy dostępnych jest więcej zasobów.

Zalety wodospadu:

• Naprzód wstecz planowanie i wdrażanie jest łatwe .
• Model wodospadu jest prosty w użyciu i łatwy do zrozumienia. Nie wymaga specjalnego szkolenia dla kierowników projektów ani pracowników. Ma łatwa krzywa uczenia się .
• Z natury jest sztywny łatwe w zarządzaniu cykl wodospadu. Każda faza ma ustalone rezultaty i proces przeglądu.
• Mniejsza złożoność ponieważ fazy nie zachodzą na siebie. Fazy ​​następują jedna po drugiej. Wykorzystuje przejrzystą strukturę w porównaniu z innymi metodologiami tworzenia oprogramowania. Projekt przechodzi przez ustalone, sekwencyjne kroki, począwszy od zebrania wymagań, a na końcu kończy się konserwacja.
• Ze względu na stopniowy rozwój dyscyplina jest egzekwowana i łatwo można dotrzymać terminów.
• Pracuje dobrze dla małych projektów gdzie mamy ustalone i przejrzyste wymagania.
• Procesy i wyniki są dobrze udokumentowane .
• Aranżowanie zadań jest łatwe.
• To jest łatwo zmierzyć postęp ponieważ początek i koniec każdej fazy są z góry określone.
• W całym projekcie nie ma prawie żadnych zmian w wymaganiach, dlatego też zadania pozostają stabilne dla programistów. Ponadto jest to łatwe dla każdego nowy programista, aby szybko się uczyć i rozpocznij pracę.
• Tam są żadnych niespodzianek finansowych . Po ustaleniu wymagań ostateczny koszt można obliczyć przed rozpoczęciem opracowywania.
• Przeznaczony dla sekwencyjny model finansowania .
• Jego szczegółowy projekt sprawia, że ​​ostateczny oczekiwany wynik jest bardzo jasny dla wszystkich.
• Specyfikacja wymagań funkcjonalnych udokumentowana w fazie zbierania wymagań daje testerom wystarczająco dużo szczegółów do projektowania scenariuszy testowych i przypadków testowych. Stąd proces testowania staje się łatwy w modelu wodospadu.

Wady wodospadu:

• Ponieważ wszystkie wymagania muszą być jasno znane przed rozpoczęciem tworzenia, to opóźnia projekt .
• Wymaga szeroko zakrojonych badań do potrzeb użytkownika.
• W początkowej fazie projektu wyzwaniem dla klienta jest jasne zdefiniowanie i konceptualizacja swoich wymagań w postaci specyfikacji funkcjonalnych. Dlatego istnieje duże prawdopodobieństwo, że po obejrzeniu produktu końcowego zmienią zdanie. Ta zmiana może również nastąpić z powodu biznes planu lub wpływu na rynek. Mała elastyczność w tym modelu sprawia, że ​​tak trudno dostosować się do takich zmian , zwłaszcza gdy produkt wymaga dużej przebudowy.
• Brak działającego modelu jest produkowany do później etap w cyklu życia wodospadu.
• Długie terminy dostaw . Klient nie może zobaczyć produktu, dopóki nie zostanie on w pełni ukończony.
• Klient nie ma możliwości wcześniejszego zapoznania się z systemem. Model wodospadu jest bardziej proces wewnętrzny i wyklucza użytkownika końcowego .
• Plik klient nie jest informowany dobrze o kondycji projektu.
• Terminy można przegapić jeśli nie jest przestrzegane ścisłe zarządzanie i regularne monitorowanie.
• Jest nie ma miejsca na zmiany nawet jeśli jest to widoczne w fazie rozwoju, ponieważ produkt nie będzie spełniał wymagań rynku.
• Testowanie opóźnień aż do zakończenia. Ponadto duże poprawki są na tym etapie bardzo kosztowne.
• Wysokie ryzyko i niepewność są zaangażowani w model wodospadu, ponieważ jest zbyt wiele miejsca, aby problemy pozostały niezauważone do czasu zakończenia projektu.
• Nie jest to odpowiedni model na długie, złożone i trwające projekty.
• Jest trudno aby mierzyć postęp w każdej fazie.
• Testerzy będą siedzieć bezczynnie na wielu etapach projektu.

Agile Workflow

Teraz zobaczymy cykl życia oprogramowania Agile. Agile to proces wykonywania pracy szybko i łatwo z większą dokładnością.

Model ten związany jest z metodą zarządzania projektami, stosowaną zwłaszcza przy tworzeniu oprogramowania. Charakteryzuje się podziałem zadań na krótkie etapy pracy oraz częstą oceną i adaptacją planów. Każdy członek zespołu powinien mieć pojęcie o podstawowych przepływach biznesowych.

(wizerunek źródło )

W Agile programiści i testerzy pracują równolegle nad rozwojem i testowaniem aplikacji. Rozwój odbywa się w trybie iteracyjnym. Każda iteracja historii użytkownika wymaga analizy, projektowania, kodowania i testowania.

Dokładnie testujemy wymaganie, aby sprawdzić, czy jest ono wolne od błędów i możliwe do wdrożenia, czy nie. Przejdź do następnej iteracji po zakończeniu każdej iteracji i postępujemy zgodnie z tym samym procesem do nowych / innych wymagań.

Zatem ten proces tworzenia i testowania bloku oprogramowania jest wykonywany w krótkim czasie z większą dokładnością i elastycznością. Więc więcej branż śledzi i przyjmuje ten proces.

Najpierw właściciel produktu doda wszystkie wymagania do rejestru produktu. Backlog produktu zawiera wszystkie historie użytkowników. Powiedzmy, że z całym projektem związanych jest od 100 do 150 historyjek użytkowników. Teraz dodaj poszczególne historie użytkowników do backlogu sprintu, które musimy wdrożyć. Następnie wszyscy programiści, QA, BA będą pracować nad elementami sprintu. Tak działa przepływ Agile.

Kluczowe terminologie używane w Agile

Jaki jest backlog sprintu?

jak odwrócić tablicę w miejscu w java?

Jest to lista historyjek użytkownika, które musimy wdrożyć w bieżącej iteracji lub sprincie.

Na przykład, w rejestrze sprintu znajduje się od 20 do 30 historyjek użytkowników. Następnie są to historyjki użytkownika, które musimy wdrożyć w bieżącym sprincie.

(wizerunek źródło )

Co to jest Sprint?

Sprint to krótki czas, w którym musimy wdrożyć wybrane historyjki użytkownika w określonym czasie. Czas trwania sprintu to około 2 do 3 tygodni. Czas jego trwania różni się w zależności od firmy.

Podczas tego sprintu zespół musi przeanalizować wymagania, zaprojektować je, wykonać kodowanie, testować, naprawiać problem, ponownie testować, testować regresję, demo i wiele innych działań.

Codzienne spotkanie Standup Scrum

Analityk biznesowy, programista, tester, kierownik projektu są częścią codziennych spotkań stand up scrum. Robi się to codziennie. Nie powinien trwać dłużej niż 15 do 30 minut.

Tutaj wszyscy członkowie zespołu będą dzielić się stanem codziennej pracy. Główne kwestie, o których tutaj rozmawiamy, to: jakie rzeczy zostały ukończone wczoraj, plan dzisiejszej pracy oraz wszelkie wyzwania lub zależności, przed którymi stoją w projekcie.

Jeśli jakikolwiek członek zespołu napotka jakiekolwiek wyzwania lub przeszkody w trakcie projektu, dana osoba będzie nad tym pracować, aby to zrobić.

Wykres spalania

Jest to obrazkowa reprezentacja czasu i pracy. Oś X reprezentuje pozostałą pracę, oś Y przedstawia pozostały czas sprintu. Zespół musi stworzyć zadania robocze dotyczące czasu dostępnego w danym sprincie. Zespół będzie codziennie spalał godziny zadań w oparciu o pracę, którą wykonał i wykonał.

(wizerunek źródło )

Wykres Kanban

Jest to karta / narzędzie zarządzania projektami. Dzięki temu możemy zarządzać zadaniami całego projektu. Możemy sprawdzić stan zaawansowania projektu oraz status prac poszczególnych osób. Pokazuje obrazową cyfrową reprezentację pozycji postępu, pozycji oczekujących i pozycji gotowych.

(wizerunek źródło )

jak czytać plik bin

Planowanie aktywności w pokerze

Jest to gra pomiędzy członkami zespołu sprinterskiego w celu oszacowania historii użytkownika. Tutaj cała drużyna będzie grać w pokera. Każdy członek zespołu ocenia ocenę na podstawie historyjki użytkownika. Na podstawie większości głosów szacunkowych zespół zadecyduje i przydzieli przedział czasowy.

Na przykład , jeden członek zespołu ds. historyjek użytkownika poda oszacowanie, takie jak 3, 5, 8, 3, 1, 3. Następnie zespół wybierze 3 jako oszacowanie. Karta aktywności w pokerze zawiera 0, 1, 3, 5, 8, 13, 20, 100, przerwa, wątpliwości? karty. Na podstawie tego zespołu członkowie zespołu zasugerują dowolną kartę kosztorysu. W ten sposób oszacujemy wszystkie historie użytkowników, które są związane z danym sprintem.

(wizerunek źródło )

• 0 numer pokera oznacza: brak zadania w tym elemencie / historyjce użytkownika
• 1, 3 liczby oznaczają: zadanie jest mniejsze
• 5, 8 liczb reprezentuje: zadania na średnim poziomie
• 13, 20 liczba oznacza: zadania na dużym poziomie
• Liczba 100 oznacza: bardzo duże zadania
• Nieskończoność reprezentuje: Zadanie jest ogromne, trzeba je podzielić na wiele zadań i historyjek użytkownika
• Break oznacza: potrzebować przerwy
• ? Reprezentuje: Wątpienie

Scrum Master

Jest osobą, która pomaga zespołowi w śledzeniu zwinnego procesu i spełnianiu wymagań projektu. Poprowadzi spotkanie, gdy będzie to wymagane, i pomoże omówić potrzeby projektu.

Scrum master działa jako pomost dla wszystkich członków zespołu w celu rozwiązania problemów i zależności, które pojawiają się w projekcie. Będzie śledził postępy projektu dotyczące każdego sprintu.

Bierze udział w spotkaniu standup, spotkaniu retrospektywnym, inspekcji, przeglądzie, demonstracji. To on prowadzi codzienne spotkania na stojąco i przyjmuje aktualizacje członków zespołu.

Właściciel Produktu

Jest osobą, która prowadzi i monitoruje produkt / projekt z biznesowego punktu widzenia. Ciągle obserwuje, czy produkt jest opracowywany zgodnie z wymaganiami biznesowymi, czy nie. To on nadaje priorytet historyjkom użytkownika i przeniósł wymagania z rejestru produktu do rejestru sprintu. Oszacuje terminy realizacji projektów.

Zawsze patrzy na produkt z punktu widzenia użytkownika. Właściciel produktu ma pełną wiedzę na temat działania aplikacji.

Historia użytkownika

To jest blok wymagań. Zawiera zestaw przypadków użycia / wymagań związanych z tym samym modułem. Tutaj definiujemy, jak powinien działać każdy składnik aplikacji i jak powinien wyglądać interfejs użytkownika. Zakres każdego komponentu jest zdefiniowany w historyjce użytkownika.

Zadania

Członkowie zespołu utworzą zadanie dla historyjki użytkownika, która jest im przypisana. Muszą utworzyć zadanie na podstawie różnych zadań, takich jak zadanie programistyczne, zadanie testowe, zadanie analizy historyjek użytkownika. Czas trwania zadania powinien zależeć od punktów historyjek użytkownika.

Jako tester stworzymy zadania do analizy historii użytkownika, przygotowania przypadków testowych, wykonania, testów regresyjnych i wielu innych.

Grooming Backlog

Ta część dotyczy zarządzania pozycjami zaległości. Czynności, które tutaj wykonujemy to nadawanie priorytetów pozycjom zaległości, rozbijanie na mniejsze pozycje, tworzenie zadania i aktualizowanie kryteriów akceptacji.

Iteracja

Iteracja to tworzenie i testowanie niektórych modułów / części aplikacji. Każda iteracja składa się z analizy produktu, projektu produktu, rozwoju produktu, testowania produktu i wersji demonstracyjnej produktu.

Kluczowe czynniki do przyjęcia metodologii Agile

• Obserwacja: Regularnie przeglądaj pracę i produkt i odpowiednio planuj działania. Tak więc proces rozwoju produktu i jakość produktu będą dobre.
• Powitalne zmiany: Zmiany są obsługiwane bardzo łatwo. Nie ma to większego wpływu na produkt, ponieważ moduły oprogramowania są opracowywane osobno i później integrowane. Nie będzie więc przeróbek, jeśli wymagania zostaną zmienione w przyszłości.
• Ramy czasowe: Podajemy ramy czasowe dla każdej jednostki aplikacji. Tak więc oszacowanie będzie dokładne w stosunku do oszacowania czasu projektu.
• Satysfakcja konsumenta: Zadowolenie klienta jest większe, ponieważ podczas całego projektu wchodzimy w interakcje z klientem i akcjonariuszem, a na każdym etapie rozwoju produktu przygotujemy prezentację. Dzięki temu regularnie otrzymujemy informacje zwrotne od klientów / klientów na temat przepływów biznesowych i postępów prac. W ten sposób praca i rozwój aplikacji są odpowiednio wykonywane.

Rodzaje metodologii Agile

• Metodyka Agile Scrum
• Lean Software Development
• Kanban
• Programowanie ekstremalne (XP)
• Kryształ
• Metoda dynamicznego rozwoju systemów (DSDM)
• Rozwój oparty na funkcjach (FDD)

Zwinne plusy:

• Jedną z największych zalet zwinnego modelu jest jego świetna zdolność adaptacji . Zdolność przystosowania się oznacza „reagowanie na zmianę”. Agile jest bardzo elastyczny w radzeniu sobie ze zmianami potrzeb i priorytetów klientów.
• Pozwala stale udoskonalaj i ponownie ustalaj priorytety dla całego rejestru produktu bez wpływu na bieżącą iterację, w której zespół koncentruje się na dostarczaniu MVP. Zmiany można zaplanować na następną iterację, co daje możliwość wprowadzenia zmian w ciągu zaledwie kilku tygodni.
• Metodologia Agile oferuje duży stopień zaangażowanie interesariuszy . Klient i zespół projektowy spotykają się przed, w trakcie i po każdym sprincie. Ponieważ klient jest stale zaangażowany w cały projekt, zespół ma więcej możliwości jasnego zrozumienia wizji klienta.
• Działające oprogramowanie jest dostarczane wcześnie i często. Zwiększa to zaufanie interesariuszy w zespole i zachęca go do tego pozostać bardzo zaangażowanym do projektu.
• Ten model daje przezroczystość . Zarówno interesariusze, jak i zespół dobrze wiedzą o tym, co się dzieje. Klient może zobaczyć postęp prac.
• Na to pozwalają stałe sprinty w harmonogramie trwające od jednego do czterech tygodni wczesna i przewidywalna dostawa . Nowe funkcje są udostępniane szybko i często w ograniczonym czasie.
• Agile jest skoncentrowany na kliencie . Nie tylko zapewnia funkcjonalność, ale także koncentruje się na dostarczaniu funkcji, która ma pewną wartość dla użytkownika. Każda historia użytkownika ma kryterium akceptacji ukierunkowane na biznes.
• Cenny opinie klientów jest zdobywany wcześnie w projekcie iw razie potrzeby można wprowadzić zmiany w produkcie.
• Nacisk kładziony jest na wartość biznesową . Najpierw dostarcza klientowi to, co najważniejsze.
• Poprawia jakość wyników . W przeciwieństwie do kaskady, testowanie jest wykonywane w sposób ciągły i często w projekcie zwinnym, co z kolei pomaga we wczesnym wykrywaniu i naprawianiu problemów.
• Zwinny obsługuje podejście TDD (Test Driven Development) co zapewnia wystarczająco dużo czasu na tworzenie testów jednostkowych dla funkcji, które mają zostać udostępnione za pośrednictwem MVP.
• Również produkując częste kompilacje wszelkie niezgodności z wymaganiami klienta można również wcześnie wykryć i naprawić.
• Jak otrzymujemy natychmiastowe opinie użytkowników po każdym wydaniu MVP plik ryzyko niepowodzenia projektu jest niskie, kiedy pracujesz w sposób zwinny.
• Zwinny promuje pracę zespołową . Wśród członków zespołu Agile panuje świetna współpraca, interakcja, harmonia i entuzjazm.
• Szacunki kosztów i harmonogramu każdego sprintu są przekazywane klientowi przed rozpoczęciem sprintu. To usprawnia podejmowanie decyzji ponieważ użytkownik może zrozumieć koszt każdej funkcji i odpowiednio ustalić priorytety.
• W zwinnym projekcie jest miejsce na ciągłe doskonalenie . Wnioski wyciągnięte z poprzednich sprintów można zastosować w nadchodzących sprintach.
• Koncentruje się na konkretnym zadaniu na każdym etapie projektu.

Wady Agile:

• Często widać, że zespoły zwinne mają rozszerzenie tendencja do zaniedbywania dokumentacji . Dzieje się tak, ponieważ manifest Agile skupia się bardziej na działającym oprogramowaniu niż na obszernej dokumentacji. Jednak zespoły powinny zachować odpowiednią równowagę między kodem a dokumentacją.
• Ponieważ wymaga dużego zaangażowania klienta, może bywa problematyczne dla klientów którzy nie mają dużo czasu i zainteresowania, aby wziąć udział w projekcie.
• Nie działa dobrze, jeśli zespołowi brakuje zaangażowania i poświęcenia. Wodospad wymaga zaangażowania, jednak Agile wymaga zaangażowania.
• Jeśli początkowa architektura i projekt są słabe, to częste refaktoryzacje jest wymagane.
• W porównaniu do wodospadu Agile jest trudne do ćwiczenia . Członkowie zespołu muszą być dobrze zaznajomieni z koncepcjami Agile. Ćwiczenie Agile wymaga dużej dyscypliny i zaangażowania.
• Z powodu zmiany priorytetów tak jest mniej przewidywalne niż to, co zostanie dostarczone na koniec sprintu.
• Ze względu na ograniczone czasowo dostawy i częste zmiany priorytetów, istnieje szansa, że ​​kilka funkcji nie zostanie dostarczonych w wyznaczonym czasie. To może prowadzić do dodatkowe sprinty i dodatkowe koszty . Może to również prowadzić do problemu mgliste ramy czasowe .
• Brak struktury w porównaniu z wodospadem wymaga zdyscyplinowanych, wysoce sprawnych i wszechstronnych zespołów . Bez tego projekt może być naprawdę trudny.
• Dostępność jest mniej planu końcowego produktu .
• Czasami zewnętrzny interesariusz nie może się oprzeć stosowaniu podejścia Agile . W takich przypadkach szkolenie i edukacja w zakresie Agile są wymagane dla szerokiego grona odbiorców.
• Wszyscy członkowie zespołu muszą być zaangażowani w zarządzanie projektem.
• Dokumentacja jest mniej szczegółowa.

Różnica między modelami wodospadu Agile i Waterfall

Poniżej wymieniono różnice między cyklem życia oprogramowania Waterfall i Agile.

Wodospad	Zwinny
Proces jest traktowany jako jeden projekt, który jest dalej podzielony na różne fazy.	Proces jest podzielony na wiele projektów, a każdy projekt składa się z różnych etapów.
Metodologia kaskadowa to model, w którym każdy etap cyklu życia produktu występuje po kolei. Postęp projektu przebiega stopniowo w dół przez te fazy, przypominając wodospad.	Metodologia zwinna to model oparty na podejściu iteracyjnym.
Ten model wierzy w jednorazową masową dostawę całości. Produkt jest dostarczany na końcu SDLC.	Ten model zakłada, że ​​dostawa obejmuje wiele małych porcji w określonych odstępach czasu. MVP (Minimum Viable Product) jest dostarczany na koniec każdego sprintu.
To tradycyjne i staromodne podejście.	To nowe i nowoczesne podejście.
Jeden cykl i pojedyncze wydanie.	Powtarzalna liczba iteracji i wiele wydań.
Dzieli cykl życia oprogramowania na różne fazy.	Dzieli cykl życia oprogramowania na sprinty.
Model ustrukturyzowany i sztywny. Trudno jest zmienić opis, specyfikację i projekt projektu.	Ten model jest znany ze swojej elastyczności. W dowolnym momencie możemy wprowadzić zmiany na każdym etapie projektu.
Skala planowania długoterminowego.	Skala planowania krótkoterminowego.
Istnieje duża odległość między klientem a deweloperem.	Istnieje niewielka odległość między klientem a deweloperem.
Długi czas między specyfikacją a wdrożeniem. Analityk biznesowy zbiera i przygotowuje zapotrzebowanie przed rozpoczęciem projektu.	Krótki czas między specyfikacją a wdrożeniem. Właściciel produktu przygotowuje wymagania i aktualizacje dla zespołu w każdym sprincie.
Odkrywanie problemów zajmuje dużo czasu.	Problemy są szybko wykrywane.
Wysokie ryzyko związane z harmonogramem projektu.	Niskie ryzyko związane z harmonogramem projektu.
Mniejsza zdolność szybkiego reagowania na zmiany.	Wysoka zdolność szybkiego reagowania na zmiany.
Faza testowania następuje dopiero po zakończeniu fazy rozwojowej.	Testowanie jest zwykle wykonywane równolegle z rozwojem, aby zapewnić stałą jakość.
Klient jest zaangażowany tylko na etapie zbierania wymagań, po czym klient nie jest zaangażowany. Pojawia się on dopiero w momencie dostawy produktu.	Klient jest zaangażowany w projekt i od czasu do czasu otrzymuje informacje zwrotne, aby zapewnić jego satysfakcję.
Nadaje się do projektów, które mają jasno określone wymagania i nie oczekują zmian.	Nadaje się do projektów, które muszą ewoluować i takich, które wymagają zmieniających się wymagań.
Proces ściśle sekwencyjny.	Wysoce oparty na współpracy proces tworzenia oprogramowania prowadzi do lepszej pracy zespołowej i szybkiego rozwiązywania problemów.
Wykazuje podejście do projektu.	Wprowadza sposób myślenia o produkcie, dzięki czemu jest bardziej zorientowany na klienta. Częścią tego procesu są wymagania i zmiany
Formalne i hierarchiczne. Kierownik projektu jest decydentem.	To jest nieformalne. Za podejmowanie decyzji odpowiedzialny jest cały zespół.
Model ten przewiduje, że w całym projekcie nie będzie zmian w wymaganiach.	Model ten oparty jest na adaptacji i obejmuje zmiany.
Konieczność ręcznego tworzenia dokumentów w celu weryfikacji statusu pracy danej osoby i postępu projektu.	Śledzi wykres Kanban i wykres spalania, aby zweryfikować postęp projektu i stan pracy poszczególnych osób.

Mamy dość dyskusji na temat różnic między metodologiami Agile i Waterfall oraz korzyści i wyzwań każdej z nich. Przyjrzyjmy się teraz różnicom między testowaniem zwinnym a testowaniem kaskadowym.

Różnice między testowaniem zwinnym a testowaniem wodospadu

Z punktu widzenia testowania oprogramowania ważne jest, abyśmy mieli rzetelne pojęcie o tym, czym testy zwinne różnią się od testów kaskadowych.

Wniosek

W tym artykule poznaliśmy dokładne różnice między nowoczesnym podejściem Agile a tradycyjną metodą Waterfall tworzenia i testowania oprogramowania z tabelą porównawczą obejmującą zalety i wady każdego modelu.

Biorąc pod uwagę wszystkie czynniki wymienione w tym artykule, możemy wybrać prawidłowy model cyklu życia oprogramowania do opracowania aplikacji. Nie ma wątpliwości, że metodologie Agile są preferowane w stosunku do modelu Waterfall. 90% firm preferuje i stosuje zwinny przepływ pracy przy tworzeniu aplikacji.

Metodyka zwinna jest dobra dla wszelkiego rodzaju projektów. Bardzo niewiele firm stosuje metodologię wodospadu. Ta metodologia jest odpowiednia tylko wtedy, gdy aplikacja jest mała, prosta i nie ma zmian w wymaganiach.

W niektórych przypadkach wybieramy również inne podejścia zwane Spiral, V i V oraz Prototyp, w zależności od potrzeb.

Mam nadzieję, że te informacje pomogą Ci zdecydować, który model jest najlepszy dla Twojego projektu. Możesz także przejść do model hybrydowy usuwający wady każdej metody - omówiony tutaj.

rekomendowane lektury

• Studium przypadku: jak wyeliminować wady kaskadowych i zwinnych procesów programistycznych za pomocą modelu hybrydowego
• Co to jest model wodospadu SDLC?
• Przegląd narzędzia Zephyr Enterprise Test Management Tool - jak używać zasobów modelu kaskadowego w narzędziu Agile
• Samouczek VersionOne: Przewodnik po narzędziu All-in-one Agile do zarządzania projektami
• Jira Portfolio Tutorial: Wtyczka do zarządzania portfelem projektów Agile dla JIRA (recenzja)
• 10 najlepszych narzędzi do zwinnego zarządzania projektami w 2021 roku
• Zwinne techniki szacowania: prawdziwe oszacowanie w zwinnym projekcie
• 4 kroki w kierunku rozwoju podejścia do testowania zwinnego w celu pomyślnego przejścia do procesu zwinnego