Co to jest Agile? Dlaczego Agile? - podejście zwinne
Ze słowami Agile, metodyki zwinne, zarządzanie zwinne spotykamy się coraz częściej. Czym jest Agile i czy przynosi on aż tak duże korzyści? Czy zwinność gwarantuje sukces?
Jakie założenia zawiera Agile i jak powstało? Na te pytania znajdziesz odpowiedź w poniższym artykule.
Początki Agile
Agile zawdzięczamy ludziom, którzy postanowili zmienić sposób wytwarzania oprogramowania w branży IT. Przed Agile projekty IT nie posiadały żadnej zwinnej (szybko reagującego sposobu by odpowiedzieć na potrzeby Klienta) metodyki pracy w projekcie, więc inżynierowie musieli wymyślić jak wytwarzać oprogramowanie zgodne z potrzebami strony biznesowej. Tutaj pojawił się istotny problem po stronie programistów, którzy nie posiadali doświadczeń i praktycznych umiejętności w skutecznym porozumiewaniu się ze swoim biznesowym Klientem.
W związku z powyższym, grupa entuzjastów chcących rozwiązać wyżej opisany problem postanowiła skorzystać z najbardziej skutecznych jakie aktualnie są stosowane. Elementy LEAN management oraz PDCA stały się źródłem Agile. Niemniej jednak, aby lepiej zrozumieć zwinne zarządzanie zgodnie z Agile warto poznać tę historię od samego początku. Zacznijmy od przyjrzenia się sposobom pracy, które były popularne przed Agile.
Metodyka Waterfall – logiczna ale…
Inżynierowie wymyślili metodę Waterfall, która odnosiła się do znanego im procesu wytwarzania oprogramowanie – krok po kroku do zdefiniowane, uwaga głównie przez programistów celu. Waterfall to podejście kaskadowe, czyli takie, które dzieli się na etapy – zwykle dużo dłuższe niż w Agile. Na dodatek, interakcja z Klientem jest bardzo ograniczona – bywało, że do zaledwie kilku spotkań takich jak: podpisanie umowy, odbiór oprogramowania i reklamacje Klienta.
Poniżej opisane zostały punkty, które muszą być zawarte aby metodyka miała sens:
1. Planowanie – ten etap ma kluczowe znaczenie dla całości projektu, od niego zależy czas wykonania oraz jego jakość dlatego nie można go pominąć. Celem tego punktu jest zebranie danych, dokładnych wymagań od klienta a następnie ich analiza oraz plan przebiegu realizowanego zadania w oparciu o informację.
2. Projektowanie – jest to drugi ważny etap projektu, w tym punkcie robimy projekt działań na podstawie informacji uzyskanych w etapie planowania. Etap ten porównać można do placu budowy, bez projektu wzniesienie jakiejkolwiek budowli jest trudne, zajmuje o wiele więcej czasu. Czasami brak projektu powoduje brak możliwości wykonania zadania.
3. Programowanie – etap rzeczywistych prac nad zadaniem z wykorzystaniem projektu zadania.
4. Testowanie – etap poświęcony testom zadania od strony technicznej lub od strony klienta, w drugim przypadku dostajemy informację czy nasze zadanie odpowiada wymaganiom klienta.
5. Implementacja – w wyniku testów technicznych i klienckich przekazujemy element projektu do użytkowania przez klienta
6. Informacja zwrotna – tzw. feedback, czyli informacja zwrotna od klienta do zespołu wykonującego zadanie w celu poinformowania ich o ewentualnych błędach, których nie zauważono podczas testów. Klient może zgłosić również pomysł na usprawnienie, które wykorzystane zostanie w kolejnych cyklach.
Metodyka Waterfall w późniejszym czasie miała kilka wad – projekty trwały za długo, a Klient nie zawsze dostawał to co chciał.
Odpowiedzią na te i kilka innych problemów było Agile Manifesto. Opisywał on inne podejście do pracy nad projektami IT, cały manifest został przekazany w kilku zdaniach.
Manifest Agile
Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych.
W wyniku naszej pracy, zaczęliśmy bardziej cenić:
- Ludzi i interakcje od procesów i narzędzi
- Działające oprogramowanie od szczegółowej dokumentacji
- Współpracę z klientem od negocjacji umów
- Reagowanie na zmiany od realizacji założonego planu.
Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.
Źródło: https://agilemanifesto.org/iso/pl/manifesto.html
Te cztery zdania to podsumowanie Agile. Skupiamy się na wartościach ludzkich – interakcjach i współpracy pomiędzy ludźmi, a sensowne wyniki dostarczamy jak najszybciej.
12 zasad Agile
Zwinne podejście opiera się na 12 zasadach:
- Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania – zwinne podejście projektowe ma na celu lepszą komunikację, sprawną współpracę oraz możliwość szybkiego pokazania wyników pracy zespołu.
- Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności – rynek zmienia się bardzo szybko, a nasz klient chce pozostać na wysokim poziomie rozwoju, zmiany mogą dotyczyć nie tylko rynku ale także klienta, który podczas powstawania projektu chce doprecyzować swoje oczekiwania
- Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej – dzięki temu klient będzie w stanie szybciej skonsultować poprawki, co wpłynie korzystnie na szybkość projektu
- Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu – codziennie, przez cały okres trwania projektu informację muszą być przekazywane między zespołami, pozwoli to na uniknięcie błędów i nieścisłości.
- Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
- Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
- Działające oprogramowanie jest podstawową miarą postępu.
- Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
- Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
- Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
- Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
- W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.
