Agile vs waterfall, czyli zarządzanie projektami. Jak szybko reagować na zmiany przy tworzeniu aplikacji?

Jedyną stałą rzeczą w życiu jest zmiana. Chociaż minęły stulecia, odkąd Heraklit z Efezu wypowiedział te słowa, nadal są one aktualne. I do tego świetnie charakteryzują proces budowy aplikacji.

Zmiany zachodzące na rynku, nowe trendy i technologie często powodują, że pierwotny plan trzeba dostosować do aktualnych warunków. A do tego dochodzą jeszcze zmiany wewnątrz firmy. Jak sobie z tym poradzić?

Rozwiązaniem jest rozwój oprogramowania w agile. To podejście pozwala szybko reagować na zmiany i optymalizuje pracę zespołu. Dlatego w Holdapp stosujemy go przy tworzeniu wszystkich projektów.

Dowiedz się, jak wygląda korzystanie z agile w praktyce i co warto mieć na uwadze, gdy jesteś product ownerem.

Krótka historia agile

Nie wszystkie rewolucje dokonują się na ulicach wielkich miast. Zmiana, która zrewolucjonizowała świat IT miała miejsce wśród śnieżnych stoków Utah. To tam w 2001 spotkało się kilkunastu specjalistów od oprogramowania.

Wszyscy doskonale wiedzieli, jak tworzyć projekty kaskadowo, czyli zgodnie z metodą waterfall. Wtedy panowało przekonanie, że to jedyne słuszne podejście. Tak twierdził Project Management Institute, SEI czy Rational Unified Process. I tak pracowały największe firmy na świecie.

Nasi bohaterowie jednak się od nich różnili. Ich zdaniem projekty należało rozwijać w sposób adaptacyjny. Dlatego poza jazdą na nartach, czas mijał im na burzliwych dyskusjach. W rezultacie powstała lista wartości i zasad, którymi się kierowali, nazwana Manifestem Agile.

To był pierwszy krok, który wkrótce doprowadził do rewolucji wykraczającej poza świat IT.

Główne założenia modelu agile

Manifest Agile stawia na pierwszym miejscu:

• ludzi i interakcje,
• działające oprogramowanie,
• współpracę z klientem,
• reagowanie na zmiany.

Na drugi plan odsuwa za to procesy i narzędzia, szczegółową dokumentację, negocjowanie umów oraz realizację planu.

Tak wygląda ogólne założenie, które szczegółowo przedstawia 12 zasad. Dzięki nim wiemy, na czym dokładnie polega rozwijanie projektów w duchu agile.

Jak wprowadzamy je w życie w Holdapp?

Zasady agile i ich praktyczne wykorzystanie

#1

Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.*

Zastosowanie w projekcie
Poznajemy Twój biznes – cele, klientów i branżę. To pozwala nam dostarczać wartościowe rozwiązania. Jeśli masz ustalone KPI czy OKR, przygotowałeś profil docelowego klienta albo analizę konkurencji, pokaż nam swoje materiały.

Bądź przy tym szczery i otwarty. Jesteśmy partnerami, dlatego musimy znać trudności, z jakimi mierzy się Twoja firma. Do tego na bieżąco przekazuj nam feedback, żebyśmy mogli sprawnie wprowadzać zmiany.

#2

Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.

Zastosowanie w projekcie
Praca nad podstawową wersją aplikacji (MVP) zazwyczaj trwa kilka miesięcy. Wydawanie kolejnych wersji wiąże się z dodawaniem nowych funkcjonalności, naprawą błędów, wprowadzaniem poprawek UX/UI, czy wycofywaniem nietrafionych pomysłów.

Dzięki wykorzystaniu agile możesz reagować na zmiany w sposób, który nie paraliżuje całego projektu.

#3

Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.

Zastosowanie w projekcie
Organizujemy cykliczne spotkania, podczas których prezentujemy postępy w pracy nad produktem. Pamiętaj przy tym, że nie zawsze wszystko będzie działać i wyglądać perfekcyjnie. Ważne jest, żebyśmy wspólnie rozumieli, w jakim kierunku chcemy podążać.

Pro tip Po każdym wydaniu wersji do wewnętrznych testów, zainstaluj nową wersję aplikacji i sprawdź, czy wprowadzone zmiany są zgodne z Twoimi oczekiwaniami. Taki sposób pracy pozwala szybko wykryć nieporozumienia. W ten sposób eliminujesz ryzyko, że produkt, nad którym zespół pracował przez rok, nie spełnia Twoich oczekiwań. Dzięki częstej weryfikacji postępów w najgorszym przypadku stracisz jedynie tydzień lub dwa tygodnie pracy.

#4

Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.

Zastosowanie w projekcie
Stawiamy na otwartą komunikację. Nasze zespoły powinny być responsywne. W końcu mamy wspólny cel. Wszyscy chcemy wydać jak najlepszy produkt w jak najkrótszym czasie. Dlatego komunikacja musi być płynna. Część informacji przekazujemy drogą mailową, ale kiedy potrzebujemy szybkiej odpowiedzi, takie narzędzia jak Slack sprawdzają się lepiej.

#5

Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.

Zastosowanie w projekcie
Praca z nami to praca z profesjonalistami. Nasi programiści mają od 4 do 12 lat doświadczenia, a testerzy QA minimum 3 lata. Dlatego wiemy, co robimy, gdy proponujemy bądź odradzamy pewne rozwiązania. Robimy to w trosce o dobro Twojego produktu.

Nie próbuj sztucznie przyspieszać prac. Wywieranie presji na jak najszybsze oddanie aplikacji, będzie miało wpływ na jej jakość.

#6

Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.

Zastosowanie w projekcie
Pracujemy głównie zdalnie, ale nadal chcemy mieć bezpośredni kontakt. Dlatego pamiętaj, że warto być aktywnym na spotkaniach. Włącz mikrofon i kamerę. Z naszej strony możesz liczyć na to samo. Opracowaliśmy nawet kilka wytycznych, które sprawiają, że spotkania są efektywniejsze.

#7

Działające oprogramowanie jest podstawową miarą postępu.

Zastosowanie w projekcie
Głównym celem jest stworzenie aplikacji działającej bez zarzutu. To dlatego inwestujemy czas w testy QA. W ten sposób dbamy o to, aby produkt spełniał wymagania.

Pro tip Nie twórz sztucznych miar procentowych. Często 20% funkcjonalności zapewnia 80% zysków. Nie każda zmiana jest tak samo ważna z punktu widzenia biznesu. Jak więc mierzyć sukces? Po wydaniu kolejnej wersji aplikacji zobacz, jak nowa funkcja wpływa na zachowanie klientów. Czy niej korzystają? Czy zapewniła Ci ona dodatkowy zysk? Czy przyciągasz więcej użytkowników? Do weryfikacji celów użyj narzędzi do analityki.

#8

Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.

Zastosowanie w projekcie
Brak narzucanych terminów sprzyja utrzymaniu stałego tempa pracy. Ustalaj razem z nami terminy dostarczania kolejnych wersji produktu. Dzięki temu zespół deweloperski nie będzie okresowo przeciążony zadaniami, a jego praca będzie bardziej efektywna.

#9

Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.

Zastosowanie w projekcie
Gdy rozwijamy produkt, dbamy nie tylko o dostarczanie nowych funkcjonalności, ale również o stan całego kodu aplikacji. Dlatego czasem konieczne jest wykonywanie dodatkowych zadań, takich jak refactoring kodu (czyli przepisanie części kodu). Powodem może być pojawienie się rozwiązań, które umożliwiają jego uproszczenie lub zamiana przestarzałej biblioteki na nową.

Chociaż efektów takich prac zwykle nie widać na pierwszy rzut oka, pozwalają one szybciej dostarczać kolejne wersje produktu. Usprawniają też wprowadzanie zmian.

#10

Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.

Zastosowanie w projekcie
Na początku nie omawiamy zbyt wielu pomysłów na rozszerzanie aplikacji w przyszłości. Często tylko komplikuje to rozwiązania, które inaczej mogłyby na zawsze pozostać uproszczone.

Prawda jest taka, że wiele rozszerzeń ostatecznie i tak nie wchodzi w życie. Kierujemy się zasadą “Done is better than perfect”. Zawsze będzie czas później, żeby pracować nad ulepszeniem rozwiązania.

#11

Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.

Zastosowanie w projekcie
Nasi programiści mają pełną dowolność wyboru architektury, która najbardziej pasuje do danego rozwiązania. Jeśli współpracujemy z osobami technicznymi z Twojego zespołu, pozwól na swobodny kontakt pomiędzy programistami. Dzięki temu produkty cyfrowe powstają szybciej.

#12

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.

Zastosowanie w projekcie
Każdy zespół projektowy cyklicznie bierze udział w spotkaniach, podczas których zastanawia się, jak usprawnić proces tworzenia aplikacji. W rezultacie np. zmieniamy ustalenia, które służą optymalizacji działań. Dlatego przygotuj się na to, że w czasie trwania projektu będziemy proponować nowe rozwiązania.

Dlaczego zwinnie a nie kaskadowo?

Model adaptacyjny (agile), nazywany też iteracyjnym i zwinnym, zakłada, że na początku nie wiemy wszystkiego o projekcie. W związku z tym musimy stopniowo odkrywać kolejne wymagania. Dlatego dostarczamy aplikację w krótkich cyklach – aby szybko reagować na nową wiedzę, którą otrzymujemy od klienta w formie feedbacku.

W biznesie model ten sprawdza się przy złożonych przedsięwzięciach, kiedy liczba niewiadomych jest większa niż wiadomych. Najczęściej dotyczy to tworzenia nowych produktów (w tym oprogramowania), rozwiązywania skomplikowanych problemów czy badań naukowych (R&D).

Zalety modelu adaptacyjnego

• Możliwość szybkiego dostarczania wartości dla użytkownika (np. dodawanie nowych funkcji).
• Możliwość przekazania i otrzymania informacji zwrotnej (uwag, komentarzy itp.).
• Możliwość szybkiego reagowania na informację zwrotną (np. poprzez zmianę kierunku rozwoju, priorytetów lub zaprzestanie prac).
• Otwartość na zmiany.
• Nacisk na dostarczane wartości, a nie na wykonanie planu zgodnie z harmonogramem.
• W przypadku złożonych przedsięwzięć, takich jak tworzenie aplikacji, działający produkt przekazuje sobą więcej informacji niż procent wykonania planu.
• Ograniczona liczba zależności między zadaniami i łatwiejsze planowanie.

Wady modelu adaptacyjnego

• Ciągłe utrzymywanie interdyscyplinarnego zespołu.
• Skupienie się na efektywności całego zespołu, a nie na stuprocentowym wykorzystaniu poszczególnych jego członków.
• Procesy i praktyki inżynieryjne muszą umożliwiać dostarczanie produktu w krótkich cyklach. Jeżeli testy zajmują trzy tygodnie, to nie da się dostarczyć nowej wersji w dwa. Podobnie jest w sytuacji, gdy dyrektor musi akceptować każdą decyzję o zmianie. Wtedy szanse na iteracyjny tryb pracy maleją.
• Ponieważ prace mogą trwać w nieskończoność, potrzebna jest jasna wizja tego, co chcesz osiągnąć. Niezbędne są też narzędzia pokazujące, czy zespół idzie w odpowiednim kierunku.
• Kontrakty typu stały zakres–czas–koszt (fixed price) oznaczają dla zleceniodawcy brak możliwości adaptacji. Dlatego większy sens mają umowy typu Time & Materials, które są jednak trudniejsze do wyegzekwowania. W zamian dostajesz za to większą kontrolę nad aplikacją. Nie musisz też obawiać się dodatkowych kosztów – w przeciwieństwie do modelu fixed price. Tam istnieje ryzyko dopłaty, gdy dzieje się coś nieplanowanego.

Model waterfall – alternatywa dla agile?

Model kaskadowy (waterfall)  zakłada, że można przewidzieć większość potencjalnie ryzykownych sytuacji i z góry się na nie przygotować. Inaczej mówiąc, jeżeli poświęcisz odpowiednią ilość czasu na analizę, to stworzysz plan gwarantujący sukces. Praktyka jednak pokazuje, że zwykle nie wszystko potrafimy przewidzieć. 

Dokładna analiza niestety wymaga poświęcenia dużej ilości czasu. Wtedy można ustalić szczegółowy harmonogram, wyliczyć czas i budżet. Znacząco opóźnia to jednak start projektu.

Ten model sprawdza się tylko przy powtarzalnych, przewidywalnych przedsięwzięciach, kiedy liczba niewiadomych jest mała. Zwykle dotyczy to bardzo prostych aplikacji, które mają niewiele funkcji.

Zalety modelu predykcyjnego

• Dokładna analiza zagadnienia oraz ryzyk pozwala podjąć świadomą decyzję o finansowaniu bądź zakończeniu projektu.
• Możliwość zaplanowania dostępności kluczowych osób i zasobów.
• Powstaje dokumentacja, co ułatwia przekazywanie części wiedzy o produkcie wewnątrz organizacji.
• Możliwość pracy w oparciu o kontrakty typu fixed price.

Wady modelu predykcyjnego

• W dużym stopniu opiera się na założeniu, że wszystkie informacje można zebrać na początku projektu (w formie wymagań) i na ich podstawie wycenić koszt oraz czas trwania projektu.
• Z góry zdefiniowane procesy często nie są dostosowane do specyfiki konkretnego projektu.
• Celem projektu jest zgodność z wymaganiami. W efekcie bardziej skupiasz się na zgodności z planem niż na zaspokajaniu potrzeb klientów i biznesu.
• Zmiany wiążą się z ponownym planowaniem projektu. Przez to są kosztowne i trudne do wprowadzenia. Dlatego unika się ich, nawet jeżeli niosą potencjalną korzyść dla klienta.
• Problemy ujawniają się dopiero pod koniec trwania projektu. Ponieważ w modelu fixed price relacje czas–zakres–koszt są stałe (tzw. żelazny trójkąt), ich rozwiązywanie przypada na ostatnie chwile przed oddaniem aplikacji. To odbija się zwykle na jakości produktu.
• Pracę przekazuje się pomiędzy zespołami, które odpowiadają za poszczególne fazy tworzenia produktu. To skutkuje utratą części informacji i sprawia, że specjaliści pracują nad wieloma dużymi paczkami wymagań w tym samym momencie. Rezultatem też jest często przerzucanie się nawzajem odpowiedzialnością za pojawiające się błędy.
• Projekt zwykle zajmuje o wiele więcej czasu niż to konieczne.

Agile vs. waterfall. Co wybrać?

Przy rozwiązywaniu złożonych problemów (takich jak tworzenie nowych aplikacji) odkrywasz wiele kluczowych informacji. Ewoluuje otoczenie, pojawiają się nowe możliwości biznesowe i technologiczne. Zmieniają się też ludzie pracujący przy projekcie. Powoduje to, że musisz ciągle reagować na zmiany.

Dlatego ważne jest dostosowywanie rozwiązania do pojawiających się możliwości i problemów. Właśnie to pozwala ostatecznie tworzyć produkt, z którego użytkownicy chcą korzystać. Dla biznesu oznacza to też większą liczbę konwersji i szansę na zysk z inwestycji.

Przygotowałam tabelę, żeby ułatwić Ci zrozumienie, jakich efektów możesz się spodziewać na różnych etapach pracy.

Wnioski

Podejście adaptacyjne zapewnia nieustanną kontrolę nad tworzonym produktem. Możesz obserwować tempo pracy, zmieniać priorytety i zakres funkcjonalności czy korygować wymagania.

Natomiast w podejściu predykcyjnym widzisz produkt w momencie, gdy na większość zmian jest już za późno. To często kończy się rozczarowaniem.

Zarządzanie projektem w podejściu predykcyjnym.

Ten model zmniejsza też szanse na sukces aplikacji na rynku. Bo trzeba pamiętać, że zmiana jednego z elementów żelaznego trójkąta (zakres-czas-koszt) zawsze ma wpływ na pozostałe elementy.

Kwestia rozliczeń

Wybór rodzaju kontraktu również ma znaczenie przy podejmowaniu decyzji dotyczącej modelu pracy.

W podejściu predykcyjnym zakres działań jest ustalony z góry. Na tej podstawie zespół projektowy szacuje ostateczne koszty i czas trwania projektu. Można więc bez trudu rozliczać się w oparciu o fixed price.

Natomiast w podejściu adaptacyjnym, stosując zasadę rozliczania Time & Material, zespół wyznacza zakres działań na podstawie dostępnego czasu i budżetu. To zwiększa jego elastyczność i pozwala lepiej dostosowywać się do zmian. Nic więc dziwnego, że jest takie podejście szybko zdobyło popularność.

W Holdapp również preferujemy tę opcję i rekomendujemy ją klientom, bo jest korzystna dla obu stron. Jeśli chcesz zobaczyć, jak stosujemy ją w praktyce, napisz do nas.

 

*Treść wszystkich zasad to oficjalne tłumaczenie oryginału dostępne tutaj.