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 postanowił ustanowić zasady, aby kierować lepszym podejściem do tworzenia oprogramowania. Na jej podstawie 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 oprogramowania w zakresie kompleksowej dokumentacji.
• Współpraca klientów nad negocjacjami kontraktów.
• 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 cenione.

Metody i praktyki agile

Ważne jest, aby zrozumieć, że agile nie jest rzeczą. Nie wykonujesz metody Agile. Raczej 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 przedstawia 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 najbardziej typową strukturą Agile i taką, z którą zaczyna się większość ludzi. Z drugiej strony praktyki Agile to techniki stosowane w fazach cyklu życia tworzenia oprogramowania.

• Planning Poker to praktyka szacowania współpracy, która ma na celu zachęcenie członków zespołu do dzielenia się wiedzą na temat tego, co się stało . Wiele osób uważa 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 rozwiązania, takie jak wszystkie praktyki Agile, noszą etykietę Agile , ponieważ są zgodne z zasadami w manifeście Agile.

Co to nie jest Agile

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

• Agile nie jest kodowaniem kowbojnym. Metody Agile nie należy mylić z podejściem "dowiesz się, jak idziemy" do tworzenia oprogramowania. Taki pomysł nie może być dalej od prawdy. Metoda Agile wymaga zarówno definicji gotowej , jak i jawnej wartości, która jest dostarczana klientom w każdym przebiegu. Podczas gdy autonomia wartości Agile dla osób i zespołów podkreśla dostosowaną 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 maksymalizuje 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 zmierzają, oraz wyniki, które chcą osiągnąć. Rozpoznawanie zmian w ramach procesu różni się od przestawiania w nowym kierunku co tydzień, przebieg lub miesiąc.
• Agile nie jest programowaniem bez specyfikacji. W każdym projekcie należy zachować dopasowanie zespołu do przyczyn i sposobu działania. Podejście Agile do specyfikacji obejmuje zapewnienie, że specyfikacje są odpowiednie i odzwierciedlają odpowiednio sposób działania sekwencji zespołów i zapewnia pracę.
• Agile nie jest w stanie przysługować 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 sprint 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.
• Metoda Agile nie jest nieodpowiednia dla dużych organizacji. Powszechną skargą jest to, że współpraca, kluczowy składnik metodologii Agile, jest trudna w dużych zespołach. Innym rozwiązaniem jest to, że skalowalne podejścia do metody Agile wprowadzają strukturę i metody, które zagrażają elastyczności. Pomimo tych nieporozumień można pomyślnie skalować zasady Agile. Aby uzyskać informacje o przezwyciężeniu tych trudności, zobacz Scaling Agile to large teams (Skalowanie metody Agile do dużych zespołów).
• Metoda 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 zbierać 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ądu w dół linii.
• Agile nie jest dobrym rozwiązaniem dla 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 z spójnym, ciasnym harmonogramem. Jednak dostosowując cele, deweloperzy mogą nadal korzystać z podejścia Agile. Zamiast wykonywać zadania w każdej iteracji, deweloperzy mogą skupić się na uruchamianiu eksperymentów dotyczących danych. Zamiast prezentować produkt roboczy co kilka tygodni, mogą one dążyć do lepszego zrozumienia danych.

Dlaczego agile?

Dlaczego więc ktoś rozważyłby podejście Agile? Jasne jest, że w ciągu ostatnich 10-15 lat zasady zaangażowania w zakresie tworzenia oprogramowania uległy fundamentalnej zmianie. Wiele działań wygląda podobnie, ale krajobraz i środowiska, w których je stosujemy, są zauważalnie różne.

• Porównaj, jak to jest kupić oprogramowanie dzisiaj z początku 2000 roku. Jak często ludzie jeżdżą do sklepu, aby kupić oprogramowanie biznesowe?
• Zastanów się, w jaki sposób opinie są zbierane od klientów o produktach. 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 oprogramowanie. Roczne aktualizacje nie są już możliwe w stosunku do nowoczesnej konkurencji.

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

"Wszystko zmieniło się dramatycznie. Zrównoważony rozwój, oprócz zieleni i czystości, 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

Zasady 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 ulepszania procesu DevOps. Jeden z kluczowych zagadnień koncentruje się na tym, jak programowanie Agile porównuje i kontrastuje z bieżącym podejściem organizacji.