Trudno jest wyobrazić firmę IT, która nie wykorzystywałaby zwinnego podejścia do wytwarzania oprogramowania. Jeśli klienci firm IT mają dynamicznie reagować na potrzeby własnych klientów, to my jako firma IT musimy wiedzieć, w jaki sposób szybko dostarczyć fragment działającego kodu. Im bardziej zwinni będziemy, tym bardziej zadowoleni będą klienci. Jednym z aspektów zwinności jest łatwość z jaką potrafimy reagować na zmieniające się potrzeby naszych klientów.
W 2001 roku został ogłoszony Manifest Agile. Wśród autorów Manifestu są między innymi twórcy Scruma (1996, Jeff Sutherland, Ken Schwaber) czy Extremalnego Programowania (XP 1999, Kent Beck,Ward Cunningham, Ron Jeffries).
Manifest stał się momentem przełomowym. Na tyle atrakcyjnym i zarazem potrzebnym podejściem do wytwarzania oprogramowania, że metodyki kaskadowe (tzw. waterfall, np. Prince) starają się implementować zwinność również u siebie. Dlaczego tak się dzieje? Długi i zazwyczaj bardzo kosztowny kaskadowy proces wytwarzania oprogramowania nie przewiduje zmiany w trakcie prac. Nim oprogramowanie trafi na rynek może minąć kilkanaście miesięcy i okazać się, że jest już ono nieaktualne, ponieważ zmieniły się potrzeby rynku lub konkurencja była szybsza. Zwinne podejście, to dostarczanie oprogramowania w jak najkrótszym czasie i tylko takiej małej porcji, która wnosi realną wartość. W zwinnym podejściu produkt (oprogramowanie) buduje się przyrostowo – funkcja po funkcji, zaczynając od tzw. minimalnej wartości produktu (MVP), a następnie, po każdej iteracji (w Scrumie to np. 2 tygodniowe sprinty) rozbudowywanie jej o kolejny, przetestowany i działający fragment kodu, podnoszący wartość użytkową oprogramowania.
Wyobraźmy sobie dwie sytuacje:
- Pierwsza to kaskadowe podejście, w którym inwestor zleca wykonanie oprogramowania. Mija kilka miesięcy, program trafia na rynek i okazuje się, że połowa funkcji jest niepotrzebna. Czasu nie da się cofnąć, a za pracę programistów i testerów należy zapłacić.
- Druga to podejście zwinne (Agile). Już po miesiącu pracy zespołu programistów i testerów, fragment działającego oprogramowania trafia na rynek. Każda kolejna porcja działającego kodu pojawia się np. co dwa tygodnie. Gdyby okazało się, że wdrożona funkcja jest jednak niepotrzebna, to inwestor ponosi koszt tylko dwóch tygodni pracy zespołu. Mało tego, co dwa tygodnie może skorygować swoje plany w oparciu o faktyczne potrzeby rynku.
Waterfall (pierwszy) vs Agile (drugi). Agile zakłada dostarczanie fragmentów przetestowanego i działającego oprogramowania w jak najkrótszych odstępach czasu, podczas gdy waterfall chce od razu dostarczyć pełny zakres oprogramowania.
Manifest Agile zasadniczo zmienia podejście w relacji inwestor – wykonawca i inwestor – produkt – wykonawca. Twórcy Manifestu twierdzą, że ważna jest rozmowa, jakość oprogramowania to istotna wartość, a gotowość do zmiany jest nieodzownym elementem pracy.
Z kilkuletniego doświadczenia pracy jako Scrum Master wiem, iż pomimo wysiłku, jaki należy włożyć w zmianę własnego myślenia i przyjęcie perspektywy klienta (12 pryncypiów Manifestu Agile), na końcu zyskujemy jego zadowolenie. Uczymy się kreatywnie podchodzić do wyzwań i tworzymy zespoły, z którymi można przysłowiowe konie kraść.
Po co nam Agile?
- Aby na dynamicznie zmieniającym się rynku potrzeb nasza praca była uporządkowana.
- Aby być mądrze otwartym na zmianę.
- Aby klient zyskał pewność, że jesteśmy po jego stronie.
Bo zwinność to nie tylko umiejętność adaptacji do nowych warunków, ale także to, w jaki sposób myślimy i jakie relacje chcemy budować z klientem.
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.
Dwanaście Zasad Zwinnego Tworzenia Oprogramowania
Wyznajemy następujące zasady:
Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
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.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Podejścia zwinne:
Scrum, Extreme Programming, Feature Driven Development, Test Driven Development, Crystal Clear, Continuous Integration, Continuous Delivery, Kanban
