Jakie są typy metodologii Agile?

W środowisku twórców oprogramowania nadal słychać sporo szumu wokół Agile. Firmy IT z ugruntowaną pozycją na rynku, takie jak itCraft, chętnie jej używają, aby eliminować zakłócenia, organizować pracę i osiągać lepsze rezultaty w zarządzaniu projektem i innych obszarach budowania aplikacji mobilnych i webowych. Cokolwiek masz w swoim produktowym backlogu, możemy użyć Agile, aby szybko dostarczać spektakularne efekty.

Spis treści

1. W itCraft kochamy Agile
2. Czym jest Agile?
3. Różne rodzaje metodologii Agile
4. Zwinne wytwarzanie oprogramowania – które podejście wybrać?
5. Zwinne treści na naszym blogu

W itCraft kochamy Agile

Gdy tylko rozpocznie się współpraca właściciela produktu i software house’u, zachodzi potrzeba kontroli wielu zasobów – dlatego wdrażane są metodologie i frameworki typu Agile. Każdy projekt zajmuje sporą ilość czasu. Wielu członków zespołu jest zaangażowanych w pracę. Każdy etap ma swoje własne zadania, które muszą zostać ukończone. Wszystko to wymaga nieprzeciętnych umiejętności zarządzania i organizacji. A Agile to w tym wypadku rozwiązanie idealne.

“Zwinność” można interpretować na wiele różnych sposobów. Jeśli kiedykolwiek słyszeliście o Agile, prawdopodobnie kojarzycie także Scrum. To jedna z głównych praktyk stosowanych w software house’ach. Jednak istnieje wiele innych sposobów na wdrożenie Agile i jego różnych metodologii, które możemy potraktować jako inspirację – postanowiliśmy więc je Wam przedstawić.

Zacznijmy od podstaw.

Czym jest Agile?

Nie musimy tego tłumaczyć po raz kolejny, gdyż definicję można znaleźć w naszym artykule o zwinnym wytwarzaniu oprogramowania:

W najbardziej ogólnym sensie zwinność, czyli “agile” reprezentuje postawę wobec zmieniających się wymagań. To umiejętność adaptacji do wciąż ewoluujących warunków i reagowania na nie ze zrozumieniem oraz opanowaniem. Wdrożenie takiego podejścia do codziennych zadań pomaga pracownikom zachować spokój i działać, nawet gdy pojawiają się stresujące sytuacje lub coś gwałtownie zaburza ich cykl pracy.

Choć Agile została stworzona przez developerów, aby mogli lepiej pracować, obecnie stosuje się ją w różnych dziedzinach biznesu jak zarządzanie projektem, podejmowanie decyzji, analiza danych i wiele innych. Powód jest prosty – każdy proces może skorzystać na zwinności. Istnieją kluczowe wartości, jakimi “zwinna” firma powinna się kierować, projektując procesy oraz zasady, których należy przestrzegać, aby mieć pewność, że wszyscy wiedzą co robić. Tylko wtedy członkowie zespołu będą dostarczać spektakularne rezultaty, których oczekują klienci.

Jakie są główne zasady Agile?

Aby zrozumieć, na czym tak naprawdę polega Agile, zalecamy sprawdzić dwa podstawowe dokumenty, które w idealny sposób opisują zasady i samą ideę zwinności. Napisaliśmy nawet artykuły, które szczegółowo je analizują. W ten sposób możesz lepiej zrozumieć, dlaczego korzystamy z Agile i jak wpływa to na naszą codzienną pracę.

Pierwszym dokumentem, który warto przeczytać, jest Manifest Agile. Cztery główne wartości w nim zawarte wyznaczają kierunek dla wszystkich firm, które chcą prowadzić projekty w sposób efektywny i nastawiony na sukces. Oto zasady Manifestu Agile:

1. Ludzie i interakcje ponad procesy i narzędzia.
2. Działające oprogramowanie ponad szczegółową dokumentację.
3. Współpracę z klientem ponad negocjacje umów.
4. Reagowanie na zmiany ponad realizację założonego planu.

W artykule dowiesz się więcej na temat każdej wartości w Manifeście Agile i w jaki sposób mogą one być stosowane w jakimkolwiek projekcie wytwarzania oprogramowania. Aby jeszcze lepiej zrozumieć Agile, warto zagłębić się w temat i zapoznać się z 12 Zasadami Agile:

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

Bardziej szczegółowe wytłumaczenie czterech wartości i 12 zasad da Ci lepszy ogląd na stosowanie Agile w procesie developmentu.

Teraz znasz podstawowe założenia Agile. Możemy omówić najpopularniejsze metodologie stosowane w software house’ach. Wielu nazywa je “smakami” Agile, bo są tak różnorodne i oferują odmienne spojrzenia. Sprawdźmy, które są najbardziej doceniane i jakie zalety oferują.

Różne rodzaje metodologii Agile

Zanim zaczniemy, warto pamiętać, że wiele firm programistycznych używa tak zwanych “hybrydowych” metodologii Agile – Ty też możesz to zrobić. Co to oznacza? Zasadniczo wybiera się zalety wielu “smaków” i tworzy się własny zwinny framework do zarządzania projektami – taki, który dostosowany będzie do naszych unikalnych potrzeb i celów.

Znajomość metodologii szeroko stosowanych w branży pozwoli Ci zrozumieć, czego możesz potrzebować i która z nich jest najbardziej dopasowana do Twojej marki. Pamiętaj o swoim stylu pracy, typach projektów, które prowadzisz oraz o oczekiwaniach zespołu. Potem wybierz zasady i koncepcje, które będą wspierać produktywność i współpracę. W ten sposób osiągniesz spektakularne rezultaty.

Oto metodologie Agile, o których warto wiedzieć. Porozmawiamy sobie o Scrum, Kanban, Lean, XP, Crystal i wielu innych. Wybierz swój ulubiony smak – lub mieszaj je tak, jak Ci pasuje.

Metodologia Agile Scrum

Nie ma metodologii, która zdobyła tyle uznania w zwinnym wytwarzaniu oprogramowania. Scrum to definitywnie faworyt, wybierany przez zespoły na całym świecie. Jest idealny w każdym projekcie wymagającym współpracy kilku zespołów, aby dostarczyć finalny efekt. Postawa wobec zmian i niepewności w Scrum pozwala członkom zespołu skupić się na wykonywaniu zadań i dostarczaniu produktu w ramach przewidzianego terminu.

Zwinne zarządzanie projektem to główny priorytet w Scrum. Właściciel produktu powinien być integralną częścią projektu – dzielić się swoją wiedzą, opiniami klientów i rozeznaniem w branży. Osoba ta staje się równym członkiem zespołu i ma swoją rolę do odegrania w procesie developmentu. Części projektu są dostarczane w ramach sprintów – to cykle pracy, które zazwyczaj trwają od dwóch tygodni do miesiąca. Iteracje organizowane są w celu przedyskutowania wszystkiego, co do tej pory zostało wykonane oraz zaplanowania pracy zespołu na kolejny sprint.

W Scrum wszystkie funkcjonalności wymagające zwinnego zaprogramowania są umieszczane w backlogu produktu. Właściciel produktu powinien mieć pewność, że wszyscy rozumieją, co się tam znajduje i jak odpowiednio dostarczyć każdą część. Zespoły mogą używać backlogu produktowego jako listy rzeczy “do zrobienia”,  które będzie wyznaczać kierunek ich aktywności. Taki backlog nie jest stosowany jedynie w metodologii Scrum, ale również w Kanban i innych smakach Agile.

Dlaczego firmy programistyczne uwielbiają Scrum?

Ponieważ pozwala on zespołom zarządzającym projektami szybko wykrywać występujące problemy i rozwiązywać je w celu doskonalenia procesu. Każdy etap developmentu jest transparentny, a dzięki codziennym spotkaniom, członkowie zespołu mogą raportować swoje postępy i rozmawiać o napotkanych trudnościach. Scrum jest często oskarżany o obsesję na punkcie widocznych rezultatów, niezależnie od ich jakości. Dobrze zorganizowany zespół wraz ze świadomym project managerem będzie w stanie poradzić sobie z tymi problemami i zastosować rozwiązania, które wspomogą go w dostarczaniu działających produktów software’owych zamiast wykonywania zadań bez kontekstu i wartości.

Wielu przedstawicieli branży twierdzi, że Scrum to rewolucyjna metodologia Agile, która odmieniła wytwarzanie oprogramowania. Podejście oparte o iteracje było remedium na chaotyczne procesy, przez które nie zawsze można było dostarczać produkty na czas. Współpraca pomiędzy zespołami i decyzyjność wszystkich ich członków także zyskały sympatię innowacyjnych firm IT. Nie wspominając już o włączenie właściciela produktu i innych interesariuszy, co dało im szansę na stanie się integralną częścią projektu i aktywne uczestniczenie w nim. To coś, co wyróżnia Scrum od innych metodologii. Oczywiście nie oznacza to, że jest on bez wad. Jak już wspominaliśmy – nieostrożne korzystanie ze Scrum może skutkować tworzeniem wadliwych produktów – tego z pewnością nie chciałby nikt.

Jest jeszcze jedna interesująca rzecz w metodologii Agile Scrum – to konkretna rola, która powinna zostać wypełniona w każdym projekcie. Nazywa się ona Scrum Master. Nie jest to zwyczajny ekspert od zarządzania projektem. Ta osoba musi znać zasady Scrum oraz edukować zespół i klienta na temat prawidłowego procesu Scrum. Project management to także jej obowiązek, ale musi mieć pewność, że wszystko jest wykonywane zgodnie z zasadami metodologii Scrum.

Zespół Scrum jest nieco inny niż zwyczajowy team. Oczywiście wszyscy jego członkowie to eksperci specjalizujący się w programowaniu, designie i zapewnieniu jakości, ale ich umiejętności miękkie i twarde powinny się nawzajem uzupełniać, co zapewni bezproblemową współpracę. Scrum Master musi dostrzegać potencjał w każdej osobie, gdy komponuje idealny zespół dla konkretnego projektu. Zazwyczaj zespół w Scrum liczy od 5 do 8 osób. Umiejętność współpracy i komunikacji będzie bezcenna – i zgodna z zasadami Scrum.

Jeśli chcesz się dowiedzieć więcej na temat Scrum, definitywnie sprawdź nasze artykuły:

Agile project management with Scrum – Wszystkie podstawy metodologii Scrum w jednym miejscu. Wszystko tłumaczymy i pomagamy zastosować Scrum w Twoim projekcie software’owym. Pracując z itCraft możesz mieć pewność, że będziesz go używać.

Retrospektywa Scrum – dobre praktyki i podejście itCraft – Retrospektywa Scrum to typ spotkania, podczas którego członkowie zespołu omawiają, co było dobrze, a co wymaga ulepszenia. Zazwyczaj ma miejsce po zakończeniu projektu. W tym poście możesz dowiedzieć się, na czym polega Retrospektywa Scrum i jakie są jej zalety.

Product Owners’ guide to Agile Scrum. Part 1 – The growing difficulty of change & Product Owner’s guide to Agile Scrum Part 2 – Single point of contact -Te dwa artykuły są pełne informacji na temat metodologii Agile Scrum. Są dedykowane naszym obecnym i przyszłym klientom, którzy chcą lepiej zrozumieć, jak nasz zespół organizuje każdy projekt software’owy.

Scrum to nasza ulubiona metodologia Agile. Stosujemy ją świadomie we wszystkich naszych współpracach. Nie oznacza to jednak, że nie zgadzamy się na modyfikacje – inne metodologie też nas inspirują. Dla nas istotne jest, aby oferowały coś, co pozwoli nam zwiększyć produktywność i efektywność. Zobaczmy inne opcje, z których możemy wybierać.

Lean Software Development

To podejście ewoluowało z Lean Manufacturing – zestawu zasad i narzędzi, które potem zostały dostosowane do realiów wytwarzania oprogramowania. Zaczęło się w latach 70. XX wieku, gdy japońskie przedsiębiorstwo Toyota zdecydowało, że ich głównym celem w procesie produkowania samochodów będzie zredukowanie wszelkiego rodzaju odpadów. Zidentyfikowali różne typy owych odpadów do wyeliminowania, a ich biznes szybko zaczął prosperować. Wkrótce wszystkie fabryki aut wdrożyły zasady Lean do swoich operacji.

Później pojawiła się książka Toma i Mary Poppendiecków, gdzie autorzy tłumaczyli, jak wdrożyć Lean Manufacturing w wytwarzanie oprogramowania. Wierzyli, że wartość produktu jest najważniejszym priorytetem i że wszystko, co się do niej nie przyczynia, nie powinno być brane pod uwagę.

Wokół Lean and Agile powstaje sporo zamieszania. Te dwie metodologie są często mylone ze sobą, a ich nazwy używane zamiennie. Mimo że Agile, Scrum, Lean i wiele metodologii łączą wspólne cele, powinniśmy pamiętać o technicznych aspektach i zasadach poszczególnych frameworków Agile.

Istnieje siedem zasad Lean:

• Eliminowanie odpadów
• Wbudowywanie jakości
• Tworzenie wiedzy
• Przekładanie zobowiązań
• Szybkie dostarczanie
• Szacunek dla ludzi
• Optymalizacja całości

Jak widzisz, ich znaczenie rezonuje z Agile i Scrum. Jakie są przykłady stosowania tych zasad w developmencie produktu? Eliminowanie odpadów oznacza usprawnianie pracy poprzez likwidowanie mniejszych, niepotrzebnych zadań oraz nieorganizowanie sesji feedbackowych, gdy nie ma takiej potrzeby. Proces developmentu powinien być oparty o testy i współpracę pomiędzy programistami, aby zapewnić jakość produktu. Każdy projekt powinien tworzyć wiedzę – dla wytwarzania oprogramowania oznacza to przechowywanie kodu w repozytoriach takich jak GitHub, aby inni mieli do niego dostęp, gdy będzie to konieczne.

Przekładanie zobowiązań to elastyczne i świadome podejście do zmian. Żadna decyzja nie powinna być ostateczna – ponieważ każdy projekt może doświadczyć nagłej ewolucji wymogów i warunków. Organizowanie sprintów Agile, gdzie zespoły mogą decydować, co powinno być priorytetem to najlepszy sposób na stosowanie tej zasady. Punkt dotyczący szybkiego dostarczania odnosi się do prototypów, budowania MVP i PoC. Możesz przeczytać więcej w naszym artykule: MVP app development – Lean and agile way to develop anything. Warto zacząć od małej, podstawowej wersji Twojego produktu i rozwijać ją na podstawie feedbacku konsumenckiego.

Jeśli chodzi o szacunek dla ludzi, chodzi przede wszystkim o równość pomiędzy członkami zespołu. Wszyscy powinni być traktowani z szacunkiem i empatią podczas procesu rekrutacji, w trakcie onboardingu, gdy rozwiązywane są konflikty, a także podczas planowania pracy. Każda osoba w teamie może wyrazić swoje zdanie na temat problemów i proponować rozwiązania. Na końcu mamy część poświęconą optymalizacji. Interdyscyplinarne i samoogranizujące się zespoły lepiej będą rozwiązywać problemy i dostosowywać swoje aktywności do ogólnego celu, który chcą osiągnąć.

Jak widzisz, Agile, Lean i Scrum mają wiele wspólnego, ale musisz pamiętać, że nie są dokładnie takie same. Na przykład, w Agile Scrum, indywidualne interakcje pomiędzy członkami zespołu są ważniejsze, podczas gdy Lean koncentruje się na zespole jako całości. W Agile i Scrum rezultat jest najważniejszy. W Lean przykłada się uwagę do procesu.

Jak już wspomnieliśmy, możesz wybierać ze wszystkich metodologii, które tutaj opisujemy i stworzyć swój zwinny system wytwarzania oprogramowania oraz zarządzania projektami.

Kanban

Kolejna metodologia Agile, która często miesza się ze Scrum i samym Agile. Także pochodzi z Japonii. Nazwa wzięła się z japońskiego słowa oznaczającego “kartę” lub “znak wizualny”. Główną zaletą Kanban jest łatwość wdrożenia – może stać się częścią istniejącego stylu pracy i nie potrzebuje skomplikowanej implementacji. Zamiast zastępować proces, dodaje do niego użyteczne poprawki.

Głównym założeniem Kanban jest kontrolowanie ilości pracy przeznaczonej dla zespołu w danych momencie. Dodawanie nowych zadań jest możliwe tylko wtedy, gdy jest na to przestrzeń. W ten sposób zespół może być produktywny bez przeciążenia. Kanban to metodologia Agile, która powstała z inspiracji supermarketami. Półki zapełniane są dobrami tak, aby odpowiedzieć na zapotrzebowanie, a produkty są dodawane tylko wtedy, gdy półka jest pusta.

Efektywność Kanban w zwinnych zespołach to zasługa konkretnej organizacji zadań przy jednoczesnym zachowaniu przestrzeni dla zmian. To transparentny proces, gdzie wszystko ma swoje miejsce. Kanban jest oparty na narzędziu nazywanym tablicą Kanban, która początkowo była fizyczną tablicą z karteczkami samoprzylepnymi, a obecnie zazwyczaj tworzy się ją w jednej z internetowych aplikacji (Jira, Trello, itp.).

Tablica Kanban jest złożona z kolumn – w najbardziej podstawowej wersji Kanban istnieją trzy kolumny: “Do zrobienia”, “W trakcie” i “Zrobione”. W projektach poświęconych wytwarzaniu programowania zazwyczaj jest więcej kolumn, które odzwierciedlają procesy produkcji. Jest więc backlog produktowy, design, kodowanie, testowanie, oczekiwanie na akceptację i wiele innych – wszystko zależy od indywidualnych potrzeb zespołu. Każda karta Kanban reprezentuje jednostkę pracy i jest przesuwana między kolumnami, gdy jej status się zmieni. Karty mogą być także oznaczone kolorami, jeśli jest taka potrzeba.

Kanban jako metodologia Agile jest łatwy do zrozumienia i może być dodany do systemu pracy w krótkim czasie. Dlatego zespoły software’owe często go używają – nawet jeśli ich głównym zwinnym frameworkiem jest Scrum lub inny smak. Z Kanban można szybko dostarczać efekty i redukować ilość odpadów do minimum.

Główne wady Kanban zazwyczaj są związane z nieumiejętnym użyciem tablicy Kanban. Powinna być ona stale aktualizowana i odpowiednio organizowana – tak, aby każde zadanie było we właściwym miejscu, przesuwane tylko wtedy, gdy nastąpi w nim zmiana. Tablice Kanban nie mają deadline’ów ani określonych ram czasowych, ważne jest więc, aby zbytnio nie przedłużać faz produkcji.

Wielką zaletą Kanban jest wizualizacja ilości pracy i umożliwienie zespołom przeglądania zadań oraz sprawdzania postępów. To pomaga także menadżerom projektu w znajdowaniu potencjalnych problemów tak szybko, jak to możliwe. Jest jedna szczególna zasada, o której zespoły Kanban powinny pamiętać – ustawianie limitów na zadania będące w trakcie. Konkretna ilość zadań może znajdować się w tej kolumnie, a dobre praktyki sugerują wybranie najmniejszej i największej liczby kart, które można tam przesuwać. W ten sposób, zwinny projekt będzie mógł skorzystać z zalet Kanban w kwestii produktywności i dostarczania efektów.

Agile, Scrum i Kanban nieco się od siebie różnią, ale mają też wiele punktów wspólnych. Zawsze pamiętaj o możliwości mieszania metodologii Agile w celu uzyskania idealnego frameworku dla swoich potrzeb. Kanban i Scrum są dla siebie stworzone.

Extreme Programming (XP)

Kolejna metodologia Agile, która może być z powodzeniem wykorzystana w każdym projekcie software’owym to Extreme Programming (XP). Jest dedykowana zespołom programistycznym i podkreśla rolę jakości produktu. W przeciwieństwie do Scrum i Kanban Extreme Programming stworzono po to, aby określić najlepsze praktyki dla wszystkich zwinnych projektów.

Kiedy XP może się okazać najlepszym wyborem? Na swojej prostej, aczkolwiek wyczerpującej stronie internetowej, autor metodologii Don Wells mówi: “W wielu środowiskach programistycznych dynamicznie zmieniające się warunki są jedyną stałą. W takich sytuacjach XP pozwala osiągnąć sukces, gdy inne metodologie zawodzą.”. Stworzył to podejście jako alternatywę dla Scrum i Crystal (którą omówimy sobie niżej). Wells twierdzi także, że Extreme Programming jest idealny dla projektów z określonym deadlinem, którego zespół nie chce przekroczyć. Będzie świetny dla małych, rozproszonych zespołów developerskich, a także wtedy, gdy produkt daje możliwość wielopoziomowego testowania. Nie mówiąc już o produktywności, która jest kluczowa w XP.

Jak widzisz, Extreme Programming (XP) pasuje do specyficznych środowisk pracy. W przeciwieństwie do zwinnych metodologii typu Scrum czy Kanban nie można zastosować go w każdym projekcie. Wciąż jednak możesz z niego skorzystać, jeśli pasujesz do kryteriów.

Istnieje pięć wartości będących trzonem XP. Są to: prostota, komunikacja, informacja zwrotna, szacunek i odwaga. Pierwsza oznacza, że zespół nie robi więcej, niż jest wymagane i małymi krokami tworzy produkt wysokiej jakości. Druga podkreśla ważność codziennej, personalnej komunikacji pomiędzy członkami zespołów i zachęca do wspólnego rozwiązywania problemów. Trzecia zasada opisuje, jak powinny wyglądać iteracje i że każdy członek zespołu powinien dostarczać działające oprogramowanie do weryfikacji i udoskonalania. Czwarta zasada nie oznacza tylko wzajemnego szacunku pomiędzy członkami zespołu, ale także wobec właściciela produktu, który może dużo zaoferować. W końcu mamy zasadę ostatnią, która zachęca zespoły do mówienia prawdy, bycia zorientowanym na sukces i dostosowywania się do zmian.

Oprócz wyżej wspomnianych wartości istnieje jeszcze kilka dobrych praktyk, które wyróżniają XP spośród metodologii Agile. Jeśli pracujesz w Scrum, możesz już znać kilka z nich, ponieważ często są wykorzystywane przez zespoły Scrum. To dowód na to, że frameworki Agile często przejmują zasady od siebie nawzajem. Dzięki temu każdy projekt software’owy może się rozwijać.

Istnieje pięć kategorii praktyk w XP: planowanie, zarządzanie, projektowanie, kodowanie i testowanie. Odpowiadają one typowym procesom produkcji w software house’ach. Opiszemy kilka najważniejszych dobrych praktyk.

Pisanie user stories

Historie użytkownika są obecne także w innych frameworkach Agile takich jak Scrum i Kanban. Każda funkcjonalność zostaje opisana krótkim zdaniem, “historią” – pozwala to zaoszczędzić sporo czasu podczas tworzenia specyfikacji. User stories mogą być umieszczone na tablicy lub w dokumencie online’owym. Mogą również symbolizować zadania do wykonania. Każda historia potrzebuje estymacji terminu wykonania i wymaganych zasobów. 

Jeśli chcesz się dowiedzieć więcej o user stories – polecamy nasz artykuł: User story – a useful tool in agile development. Tłumaczy on, jak skonstruowane są takie historie, jak poprawnie je pisać i dlaczego są tak ważne dla zwinnych zespołów.

Ciągła integracja

Nieustanna integracja oznacza, że zespół powinien aktualizować kod w jednym z repozytoriów tak często, jak to możliwe – najlepiej mniej więcej co godzinę. Wprowadzone zmiany nie powinny czekać dłużej niż jeden dzień. To świetne narzędzie dla zespołów, w których wielu developerów pracuje nad produktem, a kawałki kodu muszą być kompatybilne. Warto również wspomnieć, że w XP wszystkie części projektu są pisane przez pary programistów (tzw. pair programming). Członkowie każdej pary są jednakowo odpowiedzialni za ciągłą integrację.

Test-driven development

XP jest mocno skoncentrowany na testach. To podejście nazywa się test-driven development. Każda część kodu wymaga swojego własnego testu jednostkowego, a po zaliczeniu wszystkich, produkt może być wypuszczony na rynek. Testy akceptacyjne są zawarte w historiach użytkownika i definiują, kiedy funkcjonalność działa zgodnie z wymaganiami projektu. Za każdym razem, gdy wykryty zostanie jakiś defekt, procedury testowe zostają zaimplementowane w celu ulepszenia kodu. Test-driven development to dobra praktyka, która może być kluczowa dla sukcesu produktu.

Istnieje także osobny smak Agile nazywany Test Driven Development (TDD), który kładzie dodatkowy nacisk na wyżej opisane założenia.

Crystal

Metodologia Agile, w której zawarte są różne wersje frameworka – najpopularniejszy z nich to Crystal Clear, odpowiedni dla zespołów złożonych z mniej niż ośmiu osób. Stworzył ją Alistair Cokcburn – jeden z twórców Manifestu Agile. Nic dziwnego, że Crystal stał się rozwiniętą wersją jednej szczególnej wartości Agile.

O którą wartość dokładnie chodzi? Crystal kładzie wysoki priorytet na ludzi, nie procesy. Oznacza to, że zespoły programistyczne pracują razem nad rozwiązywaniem problemów i konfliktów, zamiast podążać za rygorystycznymi zasadami. Czym więc Crystal się różni od Scrum?

Scrum to relatywnie sztywna metodologia, gdzie wszystkie zasady dotyczą zespołu, który ją wybrał. Crystal jest bardziej elastyczny – dopasowuje się do indywidualnego stylu pracy zespołu i unikalnych wymagań projektu.

Każdy framework z tej rodziny jest odpowiedni dla zespołów o różnych rozmiarach. Crystal Clear, jak już wspomnieliśmy, stosowany jest w zespołach poniżej ośmiu osób. Potem jest Crystal Yellow dla 10-20 osób pracujących nad produktem. Crystal Orange używany jest wtedy, gdy członków zespołu jest od 20 do 50. A Crystal Red jest świetny dla dużych zespołów od 50 do 100 osób. Jak widzisz, dla każdego zwinnego projektu programistycznego istnieje odpowiednia wersja.

Komunikacja jest wszystkim w Crystal. Członkowie zespołu mogą się kontaktować pomiędzy sobą, co pozwala pozbyć się rozległego project managementu. Autonomia zespołów w Crystal pozwala im być zwinnymi – mogą szukać rozwiązań na własną rękę i stosować je w celu rozwiązywania problemów. Ta wolność będzie doceniona przez doświadczone zespoły – dla początkujących programistów, którzy nigdy się nie samoorganizowali, może być dezorientująca, co doprowadzi do opóźnień w dostarczaniu efektów.

Crystal, jako metodologia Agile, jest niezwykle elastyczny, jednak zespoły powinny być ostrożne używając go podczas pracy – bez dokumentacji i raportowania, projekt może przerodzić się w chaos. Brak struktury może być zaletą, ale również wadą.

Dynamic Systems Development Method (DSDM)

Zwinne wytwarzanie oprogramowania nie jest wolne od wad. Metodologia Dynamic Systems Development powstała właśnie z tego powodu. Może być ona używana w tworzeniu rozwiązań IT i nie tylko. Głównym celem DSDM jest walka z głównymi problemami występującymi w developmencie produktów – jak przekraczanie budżetu, opóźnianie wypuszczenia produktu na rynek czy brak metod zbierania informacji zwrotnych od konsumentów.

DSDM jest nieco bardziej rygorystycznym podejściem do Agile, gdzie uwaga skupia się głównie na cyklu życia produktu. To metodologia oparta o osiem zasad, które są dobrymi praktykami mającymi przynosić szybkie rezultaty bez marnowania budżetu i z dotrzymywaniem ustalonych terminów:

• Skup się na potrzebach biznesowych
• Dostarczaj na czas
• Współpracuj
• Nigdy nie odpuszczaj jakości
• Buduj stopniowo na mocnych fundamentach
• Twórz iteracyjnie
• Komunikuj się w sposób ciągły i jasny
• Demonstruj kontrolę

Iteracje i ciągłe zaangażowanie użytkownika i/lub klienta są niezbędne dla metodologii DSDM. Istnieje także 12 kluczowych ról, które powinny zostać wypełnione w trakcie pracy w tym frameworku. Są podzielone na trzy kategorie, aby podkreślić ich wkład w zwinny projekt, w którym uczestniczą. Jednak główną zaletą DSDM jest bardzo poważne podejście do potrzeb biznesowych – co pozwala dostarczać rezultaty posiadające prawdziwą wartość.

Implementacja DSDM może być kosztowna i wymaga sporo zasobów, co może być utrudnieniem dla mniejszych firm. Nie ma także w niej zbyt wiele miejsca dla kreatywności i inwencji zespołu, gdyż każdy produkt musi być tworzony zgodnie ze specyfikacją.

Feature Driven Development (FDD)

Jak sama nazwa wskazuje, Feature Driven Development (FDD) oznacza po prostu skupienie się na konkretnych funkcjonalnościach, które muszą być stworzone w ramach danego produktu. Ten smak Agile potrafi przyspieszyć proces kreacji dzięki pięciu etapom, na których się opiera.

Na początku zespół musi stworzyć podstawowy model, który reprezentuje szkic produktu. Potem zostaje uzgodniona lista funkcjonalności – są one podobne do historii użytkownika, które możesz znać z innych smaków jak Scrum czy XP. Cała praca w Feature Driven Development jest planowana na podstawie tej list. Potem są one projektowane i budowane jedna po drugiej według planu.

Zwinne zarządzanie projektem w FDD jest proste – skupia się na konkretnych zadaniach bez zbędnych zakłóceń. Każdy produkt jest dzielony na małe komponenty, co może być zaletą dla zespołu, bo ogranicza niepotrzebną pracę. Proces w FDD jest transparentny i nastawiony na feedback, aby dostarczać solidne rezultaty.

„Zwinne wytwarzanie oprogramowania – które podejście wybrać?

Twój produktowy backlog może być skomplikowany i pełen funkcjonalności albo może zawierać jedynie kilka pozycji. Zespoły itCraft współpracują, aby dostarczać nieprzeciętne rezultaty – nie ważne, jak duży jest Twój projekt i jakie są Twoje wymagania i oczekiwania biznesowe.

Zazwyczaj korzystamy ze Scrum jako naszej głównej zwinnej metodologii, ale jesteśmy otwarci na inne rozwiązania – takie jak Kanban i inne frameworki wspomniane wyżej. Naszym celem jest stworzyć idealny produkt, który pozwoli zabłysnąć Twojej marce i pomóc Ci stać się liderem na rynku.

W takim razie, który podejście wybrać? To zależy. Jeśli chcesz, aby Agile stało się częścią Twojej firmy, pomyśl o jej rozmiarze i najważniejszych problemach, z jakimi musi się mierzyć na co dzień. Może potrzebujesz dodatkowych struktur? Albo wręcz przeciwnie, więcej wolności? Czy zatrudniasz zespoły mniejsze niż dziesięć osób, a może zarządzasz ponad setką ludzi? Wszystko to będzie miało znaczenie przy wyborze najlepszej zwinnej metodologii dla Twojego biznesu.

Natomiast w przypadku współpracy pomiędzy Tobą jako klientem oraz software housem, pamiętaj, aby wybrać taki, który będzie używał efektywnych narzędzi i praktyk, a także będzie podchodził do projektu w elastyczny i otwarty sposób. Używanie konkretnego “smaku” to jedno, ale dostosowanie go do warunków, z którymi trzeba się zmierzyć to inna rzecz. W itCraft zbieramy to co najlepsze z Agile, Scrum, Kanban i innych frameworków i tworzymy łatwe w nawigacji środowisko, gdzie każda zaangażowana strona ma szansę dzielić się swoimi przemyśleniami, wątpliwościami i pomysłami.

Zwinne treści na naszym blogu

Zdecydowanie warto przyjrzeć się naszym artykułom o Agile. Są pełne wiedzy w tym temacie. Dowiesz się o najpopularniejszych narzędziach oraz o tym, jak wdrażamy je w nasz proces w itCraft.

Agile software development – Ten artykuł to niezbędny poradnik do zwinnego tworzenia aplikacji webowych i mobilnych.

Manifest Agile – uruchom wyobraźnię, emocje i empatię – W tym miejscu analizujemy zasady Agile.

Agile project management with Scrum – Nasz ulubiony smak Agile w szczegółowym omówieniu.

Scrum Retrospective – best practices and a fun alternative – Wszystko o spotkaniach retrospektywnych organizowanych w Agile Scrum.

User story – a useful tool in agile development – W tym poście tłumaczymy jedno z głównych zwinnych narzędzi używanych w każdym projekcie.

MVP app development – Lean and agile way to develop anything – Rozmawiamy o Minimum Viable Product – kolejnym użytecznym narzędziu w metodologiach Agile.

Product Owners’ guide to Agile Scrum – Part 1 & Part 2 – Instrukcja obsługi Agile Scrum dla naszych obecnych i przyszłych klientów, którzy lepiej chcą poznać ten framework.

Metodologia Agile5 min czytania

Retrospektywa Scrum – dobre praktyki i podejście itCraft

Metodologia Agile5 min czytania

Respektujesz zasady „Agile Manifesto” – uruchom wyobraźnię, emocje i empatię

A jeśli potrzebujesz pomocy w tworzeniu aplikacji mobilnej – nie zwlekaj i skontaktuj się z nami. Przekształcimy backlog Twojego produktu w działające oprogramowanie mobilne lub webowe, które stanie się centralnym punktem Twojej strategii rozwoju biznesowego. Sprawdź nasze usługi, aby dowiedzieć się, co możemy dla Ciebie zrobić. W zakładce portfolio możesz sprawdzić nasze poprzednie realizacje. Zacznijmy zwinną współpracę, aby osiągnąć sukces!