Niektórzy obawiają się takiego podejścia do sprawy. Wolą mieć wszystko na piśmie. Chcieliby podpisać szczegółową umowę czy dokumentację systemu do wytworzenia. W dzisiejszym zmiennym środowisku technologicznym wiąże się to jednak z jeszcze groźniejszym niebezpieczeństwem. Jakim? Już wyjaśniamy.
Co to jest Agile (Software Development)?
Agile (Software Development) to sposób tworzenia oprogramowania, który polega na nieustannej adaptacji do zmieniających się warunków. W przeciwieństwie do tradycyjnych koncepcji zakłada, że rozwój funkcjonalności systemu jest nieustannie ewoluującym procesem, który wymaga elastyczności i częstych modyfikacji.
Zgodnie z koncepcją Agile, pracę dzieli się na krótkie okresy czasu zwane iteracjami lub sprintami. Zazwyczaj trwają one od 1 do 4 tygodni. W trakcie każdej iteracji zespół programistyczny skupia się na dostarczeniu konkretnego przyrostu funkcjonalnego, co pozwala na szybkie dostosowywanie produktu do zmieniających się potrzeb biznesowych lub użytkowników.
Wartość Agile polega również na aktywnej współpracy z klientem lub interesariuszami, co umożliwia bieżącą ocenę postępu prac i szybkie wprowadzanie zmian w trakcie projektu.
Agile promuje transparentność, efektywność i dostarczanie wartościowych rozwiązań w sposób bardziej zrównoważony niż tradycyjne metodyki. Jest to jedno z najważniejszych narzędzi w arsenale firm zajmujących się tworzeniem oprogramowania.
Zagrożenie związane z odrzuceniem filozofii Agile
Tyle definicja. Prawdziwa wartość zwinnych (z ang. agile) projektów polega na wyeliminowaniu bardzo poważnego zagrożenia. Zagrożenia stagnacji.
Wśród specjalistów IT powszechna jest znajomość zjawiska połowicznego rozkładu, tj. dezaktualizacji wymagań. Chodzi o zależność podobną do erozji izotopów. Zaobserwowali ją badacze na Uniwersytecie Missouri w Stanach Zjednoczonych, którzy wskazali, że o ile w latach 80. XX wieku half-life wyników analizy przedwdrożeniowej wynosił 10-12 lat, to obecnie nie przekracza 6 miesięcy. Mówiąc wprost oznacza to, iż połowa z przyjętych założeń (związanych z zapotrzebowaniem na konkretne funkcje oprogramowania) najprawdopodobniej przestanie obowiązywać po upływie około pół roku.
Między innymi z tego powodu zwinna metodyka wdrożeniowa jest najlepszym sposobem na wytworzenie aktualnego, zgodnego z potrzebami systemu IT.
Żyjemy w bardzo dynamicznym środowisku, które kształtują: przemiany gospodarcze, postęp technologiczny, problemy socjologiczne, polityczne, a nawet kwestie zdrowia publicznego.
Wszyscy byliśmy świadkami, jak pandemia koronawirusa zmieniła naszą rzeczywistość, w tym m.in. sposób prowadzenia biznesu. Ze względów bezpieczeństwa upowszechniła się wówczas koncepcja social distancing. W wielu przypadkach skutkowało to przeniesieniem aktywności gospodarczej do przestrzeni online. Zaczęliśmy jeszcze częściej współpracować ze sobą zdalnie. Home Office stał się bardzo popularnym trybem wykonywania obowiązków służbowych. W efekcie wzrosło też zapotrzebowanie na nowy rodzaj technologii, która umożliwiała komunikację o wiele bardziej rozproszonych zespołów.
Firmy, które jeszcze na początku 2020 roku wymagały od pracowników prowadzenia papierowej dokumentacji procesu sprzedaży, rozpoczęły transformację cyfrową w przyspieszonym trybie. Wiele z nich, aby przetrwać, zdecydowało się na inwestycję w oprogramowanie sprzyjające pracy zdalnej.
Był to czas próby także dla teoretycznych założeń metodyki Agile. Na własne oczy zobaczyliśmy, jak szybko mogą zdezaktualizować się wymagania wobec systemów IT i jak niezbędne mogą okazać się zupełnie inne, wcześniej nieprzewidziane rozwiązania.
Organizacje, które już wtedy współpracowały z software house’ami czy firmami wdrożeniowymi w Scrumie, uchroniły się od kosztów związanych ze zmianą kursu. Wystarczyło rozpisać nowe User Story i nadać im wysoki priorytet. Pomysły na nieprzydatne nikomu funkcje po prostu usunięto z Backloga Produktu. Nie trzeba było renegocjować umów, a do działania przechodzono od razu.
Firmy, które przed pandemią wybrały tradycyjną drogę wdrażania systemów, zmuszone były:
- wyrzucić do kosza obszerne, pisane miesiącami dokumentacje
- rozliczyć się z zamówienia nieprzydatnych w nowej rzeczywistości funkcji oprogramowania
- zmienić koncepcję współpracy z partnerem wdrożeniowym
- podpisać nową umowę z dostawcą oprogramowania
- nauczyć się współpracy z zespołem developerskim na nowych zasadach
Wszystkie te modyfikacje wymagały oczywiście czasu, pieniędzy i zaangażowania pracowników.
O wiele bardziej opłacalna okazuje się antycypacja zmiany. Jeśli się jej spodziewamy, skutki odrzucenia przyzwyczajeń stają się zdecydowanie mniej bolesne. I chociaż nie życzymy sobie kolejnej pandemii, możemy przyjąć, że życie bywa nieprzewidywalne. Metodyka Agile pozwala zarządzać opisanym ryzykiem. A przy okazji narzuca przyjemny schemat następujących po sobie małych, acz częstych sukcesów.
Scrum, czyli sposób na małe, acz częste sukcesy
Agile to dość ogólna koncepcja, którą najlepiej jest realizować stosując się do szczegółowo opisanych reguł. Od czasu ogłoszenia The Agile Manifesto, powstało wiele frameworków porządkujących zasady zwinnej współpracy zespołów. Zaliczamy do nich: Extreme Programming (XP), Lean Software Development, Dynamic Systems Development Method (DSDM), Crystal, Feature-Driven Development (FDD), Agile Unified Process (AUP), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS). Zdecydowanie najpopularniejszy z nich to oczywiście: Scrum.
MANIFEST ZWINNEGO PROGRAMOWANIA
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.
Scrum to jeden z najpopularniejszych frameworków metodyki Agile, wykorzystywany głównie w procesie rozwoju oprogramowania, ale także w innych dziedzinach projektowania i zarządzania.
Główne założenia Scruma obejmują:
- Iteracyjność: Praca w Scrumie podzielona jest na krótkie okresy czasu nazywane sprintami. W trakcie każdego sprintu zespół pracuje nad określonym zestawem zadań i dostarcza poprawki lub nowe funkcjonalności wytwarzanego systemu
- Role: Scrum definiuje konkretne role w zespole, w tym Scrum Mastera, który dba o przestrzeganie zasad Scruma i pomaga zespołowi w rozwiązywaniu problemów, Product Ownera, który zarządza Product Backlogiem i określa priorytety, oraz Zespół Deweloperski, który jest odpowiedzialny za wytwarzanie oprogramowania.
- Spotkania: Scrum wprowadza regularne spotkania, takie jak Daily Scrum (codzienna aktualizacja postępu pracy), Sprint Planning (planowanie sprintu), Sprint Review (przegląd sprintu) i Sprint Retrospective (podsumowanie sprintu), które pomagają w zarządzaniu i doskonaleniu procesu.
- Artefakty: Scrum definiuje trzy główne artefakty: Product Backlog (lista zadań do zrealizowania), Sprint Backlog (lista zadań do zrealizowania w trakcie sprintu) i Increment/Przyrost (produkt, który jest wynikiem każdego zakończonego sprintu).
- Transparentność i inspekcja: Scrum promuje transparentność procesu, co oznacza, że wszyscy interesariusze mają dostęp do informacji na temat postępu prac. Inspekcja odbywa się na bieżąco podczas spotkań, co pozwala na dostosowywanie planów i samego produktu.
- Elastyczność i adaptacja: Scrum zakłada, że zmiany są nieodłączną częścią projektu, i daje możliwość dostosowywania się do nowych potrzeb klienta lub przekształconych warunków rynkowych.
Scrum jest często opisywany jako sposób na osiąganie małych, ale częstych sukcesów z kilku istotnych powodów.
Po pierwsze, podział projektu na krótkie iteracje, czyli sprinty, umożliwia regularne dostarczanie wartościowych fragmentów produktu. To oznacza, że zespoły pracujące w Scrum mają szansę wypracowywać i często dostarczać nowe funkcje systemu.
Po drugie, Scrum promuje ciągłe doskonalenie i adaptację. Dzięki regularnym spotkaniom Sprint Review i Sprint Retrospective, Zespół ma możliwość analizy swojej pracy, identyfikowania obszarów do poprawy i wprowadzania niezbędnych zmian. To sprawia, że Scrum jest elastyczny i może dostosowywać się do zmieniających się potrzeb biznesowych i rynkowych.
Po trzecie, Scrum zachęca do transparentności i zaangażowania interesariuszy. Dzięki widoczności postępu pracy i aktywnemu zaangażowaniu Product Ownera oraz innych interesariuszy, zespoły Scrum są w stanie lepiej zrozumieć i dostosować się do oczekiwań klientów oraz rynku. To prowadzi do dostarczania produktów, które są lepiej dopasowane do rzeczywistych potrzeb użytkowników.
Ostatecznie, Scrum jest podejściem, które nie tylko dąży do osiągnięcia sukcesów projektowych, ale także do tworzenia kultury ciągłego doskonalenia i zaangażowania w zespole. To połączenie składników, takie jak iteracyjność, elastyczność, transparentność i inspekcja, które pozwalają na osiągnięcie regularnych i zrównoważonych sukcesów w procesie rozwoju oprogramowania oraz w innych dziedzinach projektowych.
<codeSummary>
Bezpośrednia odpowiedź na pytanie, czy systemy IT można jeszcze tworzyć inaczej niż zwinnie, brzmi oczywiście: „tak”.
Można. Tylko po co?
W miarę jak technologia ewoluuje, a wymagania rynku stają się coraz bardziej zmiennymi i nieprzewidywalnymi, podejście Agile staje się normą, a nie wyjątkiem. To koncepcja, która premiuje elastyczność, współpracę i dostarczanie wartości klientowi w krótkich cyklach czasu, jest wysoce efektywne i zyskuje coraz większe uznanie w branży IT.
Tradycyjne, sztywne metodyki, takie jak model Waterfall, nadal są stosowane w niektórych projektach. Jednak tego rodzaju podejście jest obarczone ryzykiem opóźnień, nadmiernego kosztu i niewłaściwej odpowiedzi na zmieniające się potrzeby biznesowe. Przy dzisiejszym szybkim tempie rynku i konkurencji, firma, która nie jest w stanie dostosować się do zmian, może znaleźć się w trudnej sytuacji.
Podsumowując, choć istnieją inne metodyki tworzenia oprogramowania niż zwinnie, to podejście Agile, w tym powszechnie stosowany framowork o nazwie Scrum, zdają się być najskuteczniejszym sposobem na tworzenie produktów, które są lepiej dostosowane do dynamicznych potrzeb klienta i rynku.
Potrzebujesz konsultacji w temacie Open Source? Napisz do nas na adres: kontakt@codestory.pl
