Co to jest Agile?

Diagram przedstawiający różne aspekty agile, które wzajemnie się uzupełniają, takie jak współpraca, rozwój oraz zautomatyzowana kontrola wersji i wdrażanie.

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. Manifesto miał na celu ustanowienie zasad prowadzących do lepszego podejścia do tworzenia oprogramowania. W swojej istocie, manifest ogłasza cztery wartości, które stanowią podstawę ruchu Agile. Zgodnie z zapisem manifest stwierdza:

Uznaliśmy za cenne:

• Osoby i interakcje dotyczące procesów i narzędzi.
• Działające oprogramowanie ponad obszerną dokumentację.
• Współpraca z klientem ważniejsza niż negocjacje kontraktowe.
• Reagowanie na zmiany zamiast ścisłego trzymania się planu.

Manifest nie sugeruje, że elementy po prawej stronie tych stwierdzeń 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 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 zmniejsza się zadłużenie integracyjne, a główna gałąź jest stale gotowa do wydania.

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, rozważ kilka rzeczy, które nie są Agilowe.

• 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. Agile wymaga zarówno definicji ukończenia, jak i jawnej wartości dostarczanej klientom w każdym sprincie. Podczas gdy Agile ceni autonomię dla osób i zespołów, podkreśla dostosowaną autonomię, aby zapewnić, że zwiększona autonomia przynosi większą wartość.
• 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 zmieniania kierunku co tydzień, sprintu lub miesiąca.
• Agile nie jest programowaniem bez specyfikacji. W każdym projekcie konieczne jest utrzymanie zespołu w zgodzie co do dlaczego i jak praca jest wykonywana. Podejście Agile do specyfikacji obejmuje zapewnienie, że specyfikacje mają odpowiedni rozmiar i odpowiednio odzwierciedlają, jak zespół ustala kolejność i realizuje pracę.
• Agile nie jest w stanie pomieścić nieplanowanej pracy i innych przerw. Ważne jest, aby ukończyć sprinty zgodnie z harmonogramem. Ale to, że pojawia się problem, który kieruje rozwój na boczny tor, nie oznacza, że sprint musi zakończyć się niepowodzeniem. Zespoły mogą planować na ewentualne zakłócenia, wyznaczając zasoby z wyprzedzeniem na problemy i nieoczekiwane kwestie. Następnie mogą rozwiązać te problemy, ale nadal kontynuują rozwój.
• 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 zarzutem jest to, że skalowalne podejścia do Agile wprowadzają struktury i metody, które ograniczają elastyczność. 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 przebudów w przyszłości.
• 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ń związanych z modelowaniem danych i wyodrębnianiem, przekształcaniem oraz ładowaniem danych (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, jak wygląda zakup oprogramowania dzisiaj w porównaniu do początku lat 2000. 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.

Diego Lo Guidice z firmy Forrester trafia w sedno 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.

Dalsze 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.