Metodologia zwinna: znaczenie, zalety, wady i więcej

Metodologia zwinna to filozofia tworzenia oprogramowania, której celem jest dostarczanie klientom większej wartości poprzez stosowanie krótszych cykli rozwoju, przy jednoczesnym uwzględnieniu ciągłych poprawek.

Rozwój oprogramowania wyrósł z dziedzin matematyki i nauk ścisłych. Pierwotnie obejmował więc metody naukowe z tych dziedzin.

Metody te ewoluowały w kierunku podejścia wodospadowego w latach 1970. XX wieku, aby sprostać wymaganiom współczesności. W tamtych czasach komputery i ich oprogramowanie były duże, złożone i zaprojektowane tak, aby przetrwać dziesięciolecia. Zatem metoda wodospadowa okazała się dobrym rozwiązaniem.

Jednak pod koniec lat 1990. Internet radykalnie zmienił świat i konieczne stało się nowe podejście. Tak narodziła się metodologia zwinna.

Poniżej znajduje się bliższe spojrzenie na ten ruch w zakresie tworzenia oprogramowania oraz na to, w jaki sposób może on pomóc Tobie i Twojemu zespołowi.

Historia metodyki rozwoju Agile

Zwinne tworzenie oprogramowania wyrosło z Internetu i jego nienasyconego zapotrzebowania na aplikacje w latach boomu w latach 1990. i na początku XXI wieku.

Był to także okres, w którym wielu programistów nieposiadających wiedzy informatycznej przeszło na tworzenie stron internetowych ze względu na ogromne zapotrzebowanie na strony internetowe przeznaczone dla różnych grup i branż.

Oczywiście większość start-upów była mała. Dlatego większość prac nad rozwojem odbywała się w małych zespołach, a ostatecznym celem często było szybkie wprowadzenie produktu na rynek. Ponieważ spóźnienie oznaczało utratę udziału w rynku.

Aby przeciwdziałać ograniczeniom, jakie narzucał model kaskadowy w zakresie możliwie najszybszego wprowadzania produktów na rynek, w latach 1990. różni programiści wymyślili różne metody. Należą do nich Rapid Application Development (RAD), Scrum, Extreme Programming (XP), Kanban i inne.

Następnie, gdzieś w 2001 roku, 17 programistów, którzy praktykowali jedną lub drugą formę wczesnego zwinnego programowania, zebrało się w Utah w USA. Następnie zakończyli spotkanie publikacją „Manifestu Agile Software Development”.

Manifest ten opiera się na 4 wartościach i 12 zasadach.

4 wartości i 12 zasad rozwoju Agile

Na podstawie doświadczeń zebranych podczas spotkania 17 programistów osiągnęło porozumienie w sprawie zestawu wartości pozwalających na wydajniejsze tworzenie oprogramowania.

Te cztery wartości są następujące:

1. Osoby i interakcje nad procesami i narzędzia. Oznacza to, że ważne jest tworzenie oprogramowania za pomocą narzędzi w ramach określonego procesu. Ważniejsza jest jednak skuteczniejsza współpraca kompetentnych ludzi.
   
   
2. Działające oprogramowanie nad obszerną dokumentacją. Ten atakuje metodę kaskadową, polegającą na pierwszym projektowaniu oprogramowania i pisaniu dla niego dokumentacji przed faktycznym procesem tworzenia oprogramowania.
   
   
3. Współpraca z klientem nad negocjacjami kontraktu. Tylko dzięki ścisłej współpracy z klientem lub użytkownikiem możesz uczyć się i rozwijać dokładnie to, czego potrzebuje klient. To tworzy większą wartość.
   
   
4. Reagowanie na zmianę nad podążaniem za planem. Ważne jest przestrzeganie planu projektu. Ale plan nie może być zbyt sztywny. Musi uwzględniać zmiany, aby sprostać oczekiwaniom interesariuszy.

Powyższe wartości Manifestu Agile opierają się na 12 zasadach i są następujące:

1. Zadowolenie klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania.
2. Witamy zmieniające się wymagania, nawet na późnym etapie rozwoju.
3. Często dostarczaj działające oprogramowanie (tygodnie, a nie miesiące)
4. Bliska, codzienna współpraca pomiędzy ludźmi biznesu i programistami
5. Projekty budujemy wokół zmotywowanych osób, którym warto zaufać
6. Najlepszą formą komunikacji jest rozmowa twarzą w twarz (kolokacja)
7. Działające oprogramowanie jest podstawową miarą postępu
8. Zrównoważony rozwój, potrafiący utrzymać stałe tempo
9. Ciągła dbałość o doskonałość techniczną i dobry design
10. Prostota – sztuka maksymalizacji ilości niewykonanej pracy – jest niezbędna
11. Najlepsze architektury, wymagania i projekty powstają w wyniku samoorganizujących się zespołów
12. Zespół regularnie zastanawia się, jak zwiększyć efektywność i odpowiednio się dostosowuje

Iteracje lub sprinty

Iteracje lub sprinty w zwinnym tworzeniu oprogramowania to krótkie okresy, zwykle trwające od 1 do 4 tygodni, na które podzielona jest praca programistyczna. Ułatwia to zarządzanie, ponieważ wymaga mniej planowania.

Każdy zespół zazwyczaj składa się z członków pełniących różne funkcje, które mogą obejmować planowanie, analizę, projektowanie, kodowanie i testowanie.

Zespół pracuje nad oprogramowaniem wspólnie w każdej iteracji lub sprincie. I na koniec wytwarzają działający produkt. Według Manifestu Agile ten działający fragment oprogramowania jest miarą prawdziwego postępu.

W zależności od produktu i potrzeb klienta, produkt będący iteracją może zostać wypuszczony na rynek lub nie. Dlatego pojedyncze wydanie często wymaga wielu iteracji.

Zalety rozwoju Agile

Jak można sobie wyobrazić, metodyka zwinna niesie ze sobą wiele korzyści. Są one następujące:

1. Szybsza realizacja pomysłów
2. Większa elastyczność niż podejście kaskadowe
3. Większa produktywność dzięki zarządzanym iteracjom
4. Lepsze produkty dzięki interakcjom użytkowników
5. Błędy są szybko identyfikowane i eliminowane

Wady metodyki Agile

Praca ze zwinną metodą programowania ma również pewne wady. Mogą one obejmować:

1. Ocena całkowitych kosztów na początku może być trudna
2. Wymaga dużego wkładu klienta
3. Wymaga dużej ilości nieplanowanej pracy
4. Brak jasno określonego końca projektu

Kiedy stosować metodyki zwinne

1. Kiedy nie możesz oszacować, czego wymaga oprogramowanie
2. Masz wystarczający dostęp do klientów
3. Tworzysz aplikację internetową lub łatwy do aktualizacji system
4. Musisz szybko zdobyć udział w rynku dzięki wczesnemu wydaniu

Popularne frameworki programistyczne Agile

Istnieje wiele popularnych zwinnych frameworków programistycznych. Niektórzy zaczęli na długo przed Manifestem Agile z 2001 roku, inni przyszli później.

Celem frameworka jest po prostu zdefiniowanie reguł metody. Tak więc, chociaż najpopularniejsze frameworki są wymienione poniżej w celach informacyjnych, jest ich o wiele więcej. Możesz także stworzyć własny lub zmodyfikować istniejący framework, aby pasował do Twojego zespołu.

1. Scrum:: Ten framework jest przeznaczony dla zespołów składających się z 10 lub mniej członków. Praca podzielona jest na sprinty trwające 2-4 tygodnie z codziennymi 15-minutowymi spotkaniami.
   
   
2. Kanban:: Pochodzące od Toyoty słowo Kanban to japońskie słowo oznaczające billboard i jest bardzo pomocne dla zespołów ceniących pomoce wizualne. Zadania są przenoszone z jednego etapu na drugi za pomocą reprezentacji wizualnych, takich jak karteczki samoprzylepne lub aplikacje.
   
   
3. Szybkie tworzenie aplikacji RAD: To wyrażenie może odnosić się zarówno ogólnie do zwinnego tworzenia oprogramowania, jak i do metody Jamesa Martina. RAD koncentruje się na wymaganiach dotyczących interfejsu użytkownika i w dużej mierze opiera się na prototypowaniu.
   
   
4. Lean Startup: Ramy te są przeznaczone dla tych, którzy muszą opracować produkt lub usługę, ale najpierw muszą określić jego rentowność rynkową. Polega na eksperymentowaniu, aby zobaczyć, co działa, a co nie.

Inne godne uwagi platformy obejmują programowanie ekstremalne (XP), adaptacyjne tworzenie oprogramowania, modelowanie zwinne, metodę tworzenia systemów dynamicznych i skalowaną zwinną strukturę.

Metodologie Agile i Waterfall

Oto porównanie zwinnych i kaskadowych metod tworzenia oprogramowania. Pomocna może być wiedza o tym, jak poszczególne metody łączą się ze sobą. Dzięki temu możesz łatwo wybrać najlepsze narzędzia do swojej pracy.

Agile	Wodospad
Podejście przyrostowe i iteracyjne	Liniowy i sekwencyjny model cyklu życia
Elastyczny do zmiany	Sztywne wdrożenia
Testy i recenzje są w toku	Po zakończeniu następuje tylko jedna faza testowania
Wymagania mogą ulec zmianie	Wymagania są ustalane po zaplanowaniu
Zbiór wielu mniejszych projektów	Jeden pojedynczy projekt
Większe zaangażowanie klientów	Mniejsze zaangażowanie klientów

Rozwój adaptacyjny a rozwój predykcyjny

Celem zwinnego tworzenia oprogramowania jest dostosowywanie się do zmian w świecie rzeczywistym. A te często wynikają z potrzeb klienta lub użytkownika. Adaptacja stoi w jaskrawym kontraście z predykcyjną naturą modelu wodospadu.

Sensowne jest zatem stosowanie zwinnych metod podczas tworzenia systemów, gdy nie jesteś do końca pewien, jak wszystko się potoczy. Lub gdy w branży zachodzą ciągłe zmiany i ewolucja. Internet jest świetnym przykładem.

Inaczej, jeśli tworzysz dla systemu lub rynku, o którym wiesz wszystko i który prawie się nie zmienia lub jest odporny na zmiany. Pomocny może być wówczas przewidywalny charakter filozofii wodospadu.

Rzemiosło oprogramowania

Software Craftsmanship to kolejna filozofia opierająca się na zasadach zwinnego programowania i skupiająca się na podkreślaniu umiejętności twórców oprogramowania zaangażowanych w projekt.

Ruch Software Craftsmanship również ma manifest, który stwierdza:

Jako aspirujący rzemieślnicy oprogramowania podnosimy poprzeczkę w zakresie profesjonalnego tworzenia oprogramowania, ćwicząc je i pomagając innym w nauce rzemiosła. Dzięki tej pracy doceniliśmy: · Nie tylko działające oprogramowanie, ale także dobrze wykonane oprogramowanie · Nie tylko reagowanie na zmiany, ale także ciągłe dodawanie wartości · Nie tylko jednostki i interakcje, ale także społeczność profesjonalistów · Nie tylko klienci współpraca, ale także produktywne partnerstwo. Oznacza to, że w pogoni za elementami po lewej stronie uznaliśmy, że elementy po prawej są niezbędne.  © 2009, niżej podpisany. Niniejsze oświadczenie można dowolnie kopiować w dowolnej formie, ale wyłącznie w całości za pośrednictwem niniejszego powiadomienia

Wniosek

Kończąc nasze spojrzenie na zwinną metodologię i tworzenie oprogramowania, widać, że istnieje wiele opcji.

Każdy zespół jest inny. I tak jak różne zespoły opracowały różne metody dostosowywania się do zmieniających się czasów. Ty także będziesz musiał się dostosować, korzystając z już ustalonych ram lub dostosowując je do swojego zespołu.