Co to jest metodyka Agile?

Agile to termin opisujący podejścia do tworzenia oprogramowania, które podkreślają przyrostowe dostarczanie, współpracę zespołową, ciągłe planowanie i ciągłe uczenie się. Termin Agile został ukuty w 2001 roku w manifeście Agile. Manifest ustanowiony w celu ustanowienia zasad w celu lepszego podejścia do tworzenia oprogramowania. W jej centrum manifest deklaruje cztery instrukcje wartości, które reprezentują podstawę ruchu Agile. Zgodnie z zapisem manifest stwierdza:

Doszliśmy do wartości:

• Osoby i interakcje dotyczące procesów i narzędzi.
• Praca nad oprogramowaniem za pośrednictwem kompleksowej dokumentacji.
• Współpraca klienta w sprawie negocjacji kontraktowych.
• Reagowanie na zmiany w porównaniu z planem.

Manifest nie oznacza, że elementy po prawej stronie tych instrukcji nie są ważne ani potrzebne. Zamiast tego elementy po lewej stronie są po prostu bardziej wyceniane.

Metody i praktyki agile

Ważne jest, aby zrozumieć, że Agile nie jest rzeczą. Nie robisz metody Agile. Zamiast tego Agile to sposób myślenia, który napędza podejście do tworzenia oprogramowania. Ponieważ nie ma jednego podejścia, które działa we wszystkich sytuacjach, termin Agile stał się reprezentujący różne metody i praktyki, które są zgodne z instrukcjami wartości w manifeście.

Metody Agile, które są często nazywane strukturami, to kompleksowe podejścia do faz cyklu życia metodyki DevOps: planowanie, programowanie, dostarczanie i operacje. Określają metodę wykonywania pracy, z jasnymi wskazówkami i zasadami.

Scrum jest najczęściej spotykaną strukturą Agile i taką, od której zaczyna się większość ludzi. Z kolei praktyki agile to techniki stosowane w fazach cyklu życia tworzenia oprogramowania.

• Planning Poker to wspólna praktyka szacowania, która ma na celu zachęcanie członków zespołu do dzielenia się zrozumieniem tego, co się stało . Wiele osób uważa ten proces za zabawę i okazało się, że pomaga wspierać pracę zespołową i lepsze szacunki.
• Ciągła integracja (CI) to powszechna praktyka inżynieryjna Agile, która obejmuje częste integrowanie zmian kodu z gałęzią główną. Automatyczna kompilacja weryfikuje zmiany. W rezultacie występuje zmniejszenie zadłużenia integracji i stale dostarczane głównej gałęzi.

Te praktyki, takie jak wszystkie praktyki Agile, noszą etykietę Agile , ponieważ są one zgodne z zasadami w manifeście Agile.

Co agile nie jest

Jak Agile zyskał popularność, wiele stereotypów i błędów interpretacji rzuciły negatywny cień na jego skuteczność. Łatwo powiedzieć: "Tak, robimy Agile", bez żadnej odpowiedzialności. Mając na uwadze ten punkt, należy wziąć pod uwagę kilka rzeczy, które nie jest agile.

• Agile nie jest kodowaniem kowbojów. Agile nie powinien być mylony z podejściem "dowiesz się, jak idziemy" do tworzenia oprogramowania. Taki pomysł nie może być dalej od prawdy. Funkcja Agile wymaga zarówno definicji gotowej , jak i jawnej wartości dostarczanej klientom w każdym przebiegu. Podczas gdy autonomia wartości Agile dla osób i zespołów podkreśla wyrównaną autonomię, aby zapewnić zwiększoną autonomię.
• Agile nie jest bez rygoru i planowania. Wręcz przeciwnie, metodologie i praktyki Agile zwykle podkreślają dyscyplinę w planowaniu. Kluczem jest ciągłe planowanie w całym projekcie, a nie tylko planowanie z góry. Ciągłe planowanie zapewnia, że zespół może uczyć się od wykonywanej pracy. Dzięki temu podejściu maksymalizują zwrot z inwestycji (ROI) planowania.

"Plany są bezwartość, ale planowanie jest wszystko." - Dwight D. Eisenhower

• Agile nie jest pretekstem do braku planu działania. To błędne przekonanie prawdopodobnie wyrządziło największą szkodę całemu ruchowi Agile. Organizacje i zespoły, które stosują podejście Agile, absolutnie wiedzą, gdzie idą, i wyniki, które chcą osiągnąć. Rozpoznawanie zmian w ramach procesu różni się od przestawiania w nowym kierunku co tydzień, przebiegu lub miesiąca.
• Agile nie jest programowaniem bez specyfikacji. W każdym projekcie należy zachować dopasowanie zespołu do tego, dlaczego i jak działa. Podejście Agile do specyfikacji obejmuje zapewnienie, że specyfikacje mają odpowiedni rozmiar i odzwierciedlają odpowiednio sposób działania sekwencji zespołów i dostarczania.
• Agile nie jest w stanie pomieścić nieplanowanej pracy i innych przerw. Ważne jest, aby ukończyć przebiegi zgodnie z harmonogramem. Ale tylko dlatego, że pojawia się problem, że programowanie sidetracks nie oznacza, że przebieg musi zakończyć się niepowodzeniem. Zespoły mogą planować przerwy, wyznaczając zasoby przed upływem czasu na problemy i nieoczekiwane problemy. Następnie mogą rozwiązać te problemy, ale pozostają na dobrej drodze do opracowywania.
• Agile nie jest nieodpowiedni dla dużych organizacji. Powszechną skargą jest to, że współpraca, kluczowy składnik metodologii Agile, jest trudna w dużych zespołach. Innym chwytem jest to, że skalowalne podejścia do metody Agile wprowadzają strukturę i metody, które zagrażają elastyczności. Pomimo tych nieporozumień możliwe jest pomyślne skalowanie zasad Agile. Aby uzyskać informacje na temat przezwyciężenia tych trudności, zobacz Scaling Agile to large teams (Skalowanie metody Agile do dużych zespołów).
• Agile nie jest nieefektywna. Aby dostosować się do zmieniających się potrzeb klientów, deweloperzy inwestują czas po każdej iteracji, aby zademonstrować działający produkt i zebrać opinie. To prawda, że te wysiłki skracają czas poświęcany na rozwój. Jednak włączenie żądań klientów na wczesnym etapie pozwala zaoszczędzić dużo czasu później. Gdy funkcje pozostają zgodne z wizją klienta, deweloperzy unikają gruntownych przeglądów w dół linii.
• Agile nie jest słabym dopasowaniem do współczesnych aplikacji, które często skupiają się na strumieniu danych. Takie projekty zwykle obejmują więcej obciążeń modelowania danych i wyodrębniania i przekształcania obciążenia (ETL) niż interfejsy użytkownika. Fakt ten sprawia, że trudno zademonstrować użyteczne oprogramowanie zgodnie ze spójnym, ścisłym harmonogramem. Jednak dostosowując cele, deweloperzy mogą nadal korzystać z podejścia Agile. Zamiast wykonywać zadania każdej iteracji, deweloperzy mogą skupić się na uruchamianiu eksperymentów danych. Zamiast prezentować produkt roboczy co kilka tygodni, może dążyć do lepszego zrozumienia danych.

Dlaczego agile?

Dlaczego więc ktoś rozważy podejście Agile? Jasne jest, że w ciągu ostatnich 10-15 lat zmieniły się zasady zaangażowania w tworzenie oprogramowania. Wiele działań wygląda podobnie, ale krajobraz i środowiska, w których je stosujemy, są znacznie inne.

• Porównaj, co to jest jak kupić oprogramowanie dzisiaj z początku 2000 roku. Jak często ludzie prowadzą do sklepu, aby kupić oprogramowanie biznesowe?
• Zastanów się, w jaki sposób opinie są zbierane od klientów na temat produktów. Jak zespół zrozumiał, co ludzie myśleli o swoim oprogramowaniu przed mediami społecznościowymi?
• Zastanów się, jak często zespół chce aktualizować i ulepszać dostarczane przez nich oprogramowanie. Roczne aktualizacje nie są już możliwe w stosunku do nowoczesnej konkurencji.

Forrester Diego Lo Guidice mówi, że najlepiej w swoim blogu, Transforming Application Delivery (październik 2020).

"Wszystko zmieniło się dramatycznie. Zrównoważony rozwój, poza zielonym i czystym, oznacza, że to, co budujemy dzisiaj, musi być łatwe i szybko zmienione jutro. Plany strategiczne są krótkoterminowe, a planowanie i zmiany są ciągłe." - Diego Lo Guidice, Forrester

Reguły uległy zmianie, a organizacje na całym świecie odpowiednio dostosowują swoje podejście do tworzenia oprogramowania. Metody i praktyki agile nie obiecują rozwiązania każdego problemu. Obiecują jednak ustanowienie kultury i środowiska, w którym rozwiązania pojawiają się poprzez współpracę, ciągłe planowanie i uczenie się oraz chęć częstszego dostarczania wysokiej jakości oprogramowania.

Następne kroki

Podjęcie decyzji o podjęciu trasy Agile do tworzenia oprogramowania może wprowadzić kilka interesujących możliwości zwiększenia procesu DevOps. Jeden z kluczowych zagadnień koncentruje się na tym, jak programowanie Agile porównuje i kontrastuje z bieżącym podejściem organizacji.