Kiedy myślisz o organizacji osiągającej wysoką wydajność, czy kiedykolwiek zastanawiałeś się, jakie najlepsze praktyki stosuje, aby osiągnąć ten poziom? Czy skłania się ona ku podejściom Agile czy DevOps?
Aby osiągać swoje cele, organizacje te często polegają na połączeniu narzędzi Agile do zarządzania iteracyjnym rozwojem i adaptacyjnym planowaniem oraz narzędzi DevOps, które usprawniają automatyzację, ciągłą integrację i wdrażanie.
Celem procesu rozwoju i operacji jest pomoc firmie w spełnianiu jej wymagań, wsparcie członków zespołu we współpracy i przełamywaniu silosów w celu usuwania blokad oraz ostateczne ukończenie projektów/funkcji, nad którymi pracują, aby mogli zwiększać dzienną lub miesięczną liczbę aktywnych użytkowników – lub, w przypadku aplikacji korporacyjnych, zwiększać zakres funkcjonalności swoich aplikacji.
Kiedy zespoły pracują w silosach, prowadzi to do luk w komunikacji, które z kolei powodują chaos. Natomiast gdy zespoły pracują wspólnie, są bardziej skuteczne.
W ramach tego artykułu omówię podejścia Agile i DevOps, przykłady sytuacji, w których warto przyjąć określone metodyki, oraz wpływ testowania na każdy z tych scenariuszy.
Praktyki zwinnego tworzenia oprogramowania
W porównaniu z kaskadowym procesem tworzenia oprogramowania podejście zwinne koncentruje się na jednej z podstawowych zasad, która zakłada wczesne zaspokajanie potrzeb klientów w ramach procesu oraz poprzez ciągłe dostarczanie. Ciągłe dostarczanie jest możliwe tylko wtedy, gdy zaangażujemy zespół ds. jakości na wczesnym etapie procesu i będziemy z nim regularnie współpracować.
Obecnie niektóre małe i średnie firmy znajdują się w sytuacji, w której nie stosują w pełni ani podejścia zwinnego, ani kaskadowego, lecz połączenie obu. Ci tak zwani członkowie zwinnych zespołów poświęcają tak dużo energii na szczegółowe procesy, takie jak 30-minutowe spotkania codzienne i 60-minutowe spotkania retrospektywne, że zapominają o zwrocie z inwestycji, jaki przynoszą, co ostatecznie prowadzi do sytuacji, w której na produkcji wykrywa się wiele błędów.
Have an account? Log In
Czy branża rzeczywiście odeszła od podejścia kaskadowego?
Czy kiedykolwiek byłeś częścią organizacji (która, jak sądziłeś, stosowała zwinne procesy tworzenia oprogramowania), aby dopiero później zdać sobie sprawę, że zespół ds. jakości jest zaangażowany w testowanie dopiero po zakończeniu prac programistycznych?
W tym przykładzie nadal określali to jako zwinne, ponieważ członkowie zespołu programistycznego pracowali jednocześnie nad wieloma gałęziami (lub funkcjami), w sposób iteracyjny. Jednak gdy musieli przetestować swoje funkcje, czekali na zakończenie całego procesu tworzenia — co stanowi istotę metodyki kaskadowej. Ponieważ jednak firmy chcą działać szybciej, aby móc poszerzać bazę klientów, zespoły najczęściej kończą z narastającym długiem technologicznym.
Najlepszym sposobem rozwiązania tego problemu jest całkowite przekształcenie organizacji w zwinną oraz iteracyjna współpraca ramię w ramię z zespołem ds. jakości. Obejmuje to współpracę ze wszystkimi interesariuszami, aby upewnić się, że rozumieją konsekwencje nieprzejścia na nowe podejście oraz to, jak może ono wpłynąć na doświadczenia użytkowników końcowych.
Zwinne struktury i ich odmiany
W ramach tego artykułu omówię dwa najpopularniejsze zwinne struktury:
- Scrum
- Kanban
Scrum to zwinna metodyka stosowana w tworzeniu oprogramowania, oparta na procesach iteracyjnych i przyrostowych. Polega na przestrzeganiu ograniczonego czasowo procesu tworzenia zwanego sprintami. Czas trwania sprintów różni się w zależności od organizacji — od tygodnia, przez miesiąc, aż po kwartał.
Najpierw odbywa się sesja planowania sprintu, następnie sprint, podczas którego realizowane są implementacja i testowanie, w tym codzienne spotkania, a całość kończy się sesją retrospektywną.
Scrum jest zwykle wdrażany w zespołach zajmujących się tworzeniem produktów, w których członkowie muszą ograniczać czas pracy nad zadaniami, aby dotrzymywać terminów klientów. Najczęściej ma zastosowanie w aplikacjach B2C, ponieważ jeśli będziesz czekać zbyt długo, Twoja funkcja nie będzie już nowa — ktoś mógł już ją zaimplementować!
W aplikacjach B2B, które są najczęściej wykorzystywane przez firmy korporacyjne, powszechnie stosuje się zmodyfikowaną wersję zwinnej metodyki o nazwie SaFe — skalowalna struktura zwinna.
Większość projektów w firmach korporacyjnych należy do jednej z następujących kategorii:
- Poziom zespołu
- Poziom programu
- Poziom portfela
Projekty na poziomie zespołu to rozwój oparty na funkcjach, w ramach którego każdy członek zespołu jest odpowiedzialny za swój projekt i procesy. Zespoły te zwykle korzystają ze Scruma lub Kanbana, zależnie od charakteru swojej pracy.
Jeśli zespoły podlegają organizacjom badawczo-rozwojowym lub zajmują się automatyzacją testów, koniecznie muszą stosować Kanban, który jest mniej sztywny, a jego celem jest raczej ukończenie bieżącego zadania niż przechodzenie do kolejnego atrakcyjnego tematu! Jeśli zespoły są częścią organizacji zajmującej się rozwojem produktu, zwykle korzystają z procesów scrumowych.
Projekty na poziomie programu obejmują wiele zespołów pracujących nad konkretnym celem, takim jak migracja do AWS. Mimo że projekt ten może zostać zaklasyfikowany jako projekt na poziomie portfela, argumentowałbym, że niekoniecznie wpłynąłby on na zespoły HR lub księgowości.
W tym przypadku projekt migracji do AWS może trwać miesiącami z powodu nieprzewidzianych problemów, dlatego koncentrujemy się na pomyślnym ukończeniu migracji do AWS, dzieląc ją jednocześnie na uzasadnione sprinty.
Projekty na poziomie portfela obejmują różne organizacje w ramach firmy; przykładem może być wdrożenie JIRA. Każda organizacja wymagałaby innego wdrożenia przepływów pracy JIRA, zależnie od swoich potrzeb. Zespoły zasobów ludzkich nie wymagają testowania; koncentrują się głównie na obsłudze konkretnych próśb pracowników, a po ich zrealizowaniu zadanie jest oznaczane jako „ukończone”.
Metodyki zwinne powinny być stosowane przez organizacje, w których zachodzą ciągłe zmiany. Zmiany te nadal muszą jednak przejść cykl testowania i naprawiania błędów, a testowanie niekoniecznie jest zautomatyzowane, co prowadzi do wydłużenia czasu trwania procesów.
Wreszcie, gdy funkcje są gotowe do wdrożenia, przekazuje się je zespołowi odpowiedzialnemu za kompilację i operacje. Testowanie odbywa się więc iteracyjnie w porównaniu z podejściem kaskadowym, ale nie przesuwa się znacznie w lewo, ponieważ nacisk nie jest kładziony na ciągłe testowanie i dostarczanie. Stąd potrzeba podejścia DevOps!
Podejście DevOps
Podejście DevOps koncentruje się na aspektach wykraczających poza programowanie i testowanie oraz promuje w pełni zautomatyzowany potok CI/CD wraz z możliwościami monitorowania. Podczas gdy metodyki zwinne uwzględniają zmiany, podejście DevOps koncentruje się na ciągłym testowaniu i dostarczaniu, aby zapewnić pomyślność częstych wydań dla użytkowników końcowych.
Celem zespołu operacji IT jest skalowanie procesu tworzenia oprogramowania w celu przyspieszenia pisania i aktualizowania kodu odpowiedzialnego za tworzenie nowych aplikacji i usług oraz aktualizowanie funkcji w ramach zespołu IT.
Obecnie nawet pod względem organizacji zespołów zespoły ds. jakości i operacji IT należą do tej samej organizacji, dzięki czemu mogą ściśle współpracować. W rzeczywistości wprowadzono nową rolę o nazwie TestOps, która koncentruje się konkretnie na konfigurowaniu potoków CI/CD, w których zautomatyzowane testy są uruchamiane dla żądań ściągnięcia, zapewniając natychmiastową informację zwrotną zespołom programistycznym.
Testowanie automatyczne jest niezbędne do skalowania działań testowych, a jego wartość zostaje utracona, jeśli nie jest częścią ciągłego testowania i ciągłego cyklu wdrażania wydań. Dlatego pracownicy TestOps zawsze mają pełne ręce pracy przy utrzymaniu infrastruktury testów automatycznych.
Dzięki temu członkowie zespołu operacyjnego mogą koncentrować się na dostarczaniu światowej klasy infrastruktury do tworzenia oprogramowania, bez rozpraszania się infrastrukturą testową.
Obecnie dostępnych jest wiele narzędzi i praktyk DevOps, które usprawniają cały proces.
- Plik stanu Terraform odnosi się do zestawu infrastruktur zdefiniowanych i zarządzanych jako jedna jednostka — w ten sposób definiuje się i zarządza różnymi środowiskami testowymi i programistycznymi. Terraform pomaga konfigurować serwery, ale potrzebujemy infrastruktury do uruchamiania tych serwerów.
- AWS zapewnia infrastrukturę za pośrednictwem instancji EC2, które są obecnie najbardziej opłacalnym sposobem konfigurowania i uruchamiania tych serwerów. Idąc o krok dalej, jeśli stos technologiczny zawiera wiele mikrousług, za pomocą docker compose można definiować i uruchamiać wiele środowisk kontenerów Docker.
- Ansible automatyzuje proces konfigurowania maszyn do uruchamiania dowolnych procesów lub serwerów.
- Kubernetes pomaga zarządzać klastrem tych instancji EC2 jako podami i planuje uruchamianie kontenerów w tym klastrze na podstawie dostępnych zasobów obliczeniowych.
Czy należy stosować metodykę Agile czy DevOps?
Chociaż porównanie podejścia Agile do tworzenia oprogramowania z podejściem DevOps jest przedmiotem nieustannej debaty w organizacjach, najlepszym sposobem spojrzenia na tę kwestię jest zadanie sobie następujących pytań:
- Jak duża jest zdolność naszej organizacji do adaptacji w obliczu nowych technologii?
- Czy jesteśmy w stanie konkurować z naszymi rywalami pod względem jakości naszych produktów?
- Czy klienci będą skłonni korzystać z naszych produktów, skoro spełniają one ich oczekiwania?
Jeśli odpowiedzi na powyższe pytania zawierają jakąś formę negacji, nadszedł czas, aby w większym stopniu skupić się na połączeniu obu podejść i dostosować je do naszych potrzeb.
Idealna metodyka tworzenia oprogramowania
Kluczowa różnica między procesami tworzenia oprogramowania opartymi na Agile i DevOps polega na tym, że pierwsze z nich koncentrują się bardziej na uwzględnianiu ciągłych zmian, podczas gdy drugie skupiają się na ciągłym testowaniu, dostarczaniu i wdrażaniu. Współpraca między zespołami programistycznym i operacyjnym ma kluczowe znaczenie, aby zespół programistyczny nie był blokowany.
Dlatego moim zdaniem idealny proces tworzenia oprogramowania powinien obejmować:
- Uwzględnianie person klientów/użytkowników i uwzględnianie opinii klientów
- Koncentrowanie się na najlepszych praktykach, aby zapobiegać narastaniu długu technicznego
- Ciągłe doskonalenie, ciągłe testowanie, ciągła integracja, ciągłe dostarczanie, ciągłe wdrażanie i monitorowanie
Tak wyglądałby ten proces:
Uwzględnianie różnych person klientów nie ogranicza się do zespołów zarządzania produktem. Ostatecznie, dlaczego tworzymy te produkty? Jaki jest cel tych produktów, jeśli klienci z nich nie korzystają?
Weźmy klasyczny przykład firmy Nokia — gdy firma nadal gromadziła dług techniczny, nie nadążając za trendami rynkowymi, a zwłaszcza za innowacjami swojego konkurenta, firmy Apple. Skupiła się na przestrzeganiu rygorystycznych cykli sprintów, aby ostatecznie zostać zapomnianą!
Wszystkie firmy powinny rozumieć, dlaczego opracowywane są ich funkcje i jakim klientom służą. Dzięki temu będziemy tworzyć funkcje zorientowane na użytkownika.
Gdy wydawany jest nowy produkt, niezależnie od tego, czy jest to aplikacja mobilna, czy internetowa, zawsze należy zapewnić klientom możliwość przekazywania opinii. Nie wszystkie firmy stosują ścisły proces bliskiej współpracy z działem obsługi klienta.
More Articles
CI/CD
Na koniec warto promować ciągłą integrację i ciągłe dostarczanie oparte na AI/ML. Gdy projekt kończy się niepowodzeniem, nie musi to oznaczać braku umiejętności członków zespołu; jest to raczej skutek niewystarczającego testowania i niezdolności do wcześniejszego wykrycia problemów w trakcie tworzenia oprogramowania.
Czasami jednak, nawet przy odpowiednim testowaniu i automatyzacji, coś idzie nie tak — gdyby więc istniał system rekomendacji identyfikujący, kiedy wydać produkt, a kiedy tego nie robić, być może można byłoby zapobiec tak katastrofalnym awariom.
Częste iteracje pomagają zespołowi programistycznemu zrozumieć, co działa, a co nie, oraz ułatwiają myślenie o skalowalności. Wadą jest to, że zajmują dużo czasu! Gdyby inny system rekomendacji/predykcji mógł gromadzić dane o klientach i przewidywać, czy konkretna funkcja pomoże zyskać popularność, czy poniesie porażkę jeszcze przed rozpoczęciem prac nad nią, usprawniłoby to proces tworzenia wysokiej jakości produktu od pierwszego dnia!
Ogólnym celem jest zapewnienie, aby wpływ na działalność firmy rósł szybciej, gdy te najlepsze praktyki zostaną przyjęte jako część procesu tworzenia oprogramowania.
Przemyślenia końcowe
Ostatecznie zarówno Agile, jak i DevOps odgrywają kluczową rolę we współczesnym tworzeniu oprogramowania, ale właściwy wybór zależy od celów organizacji, struktury zespołu, opcji cenowych i potrzeb projektu.
Metodyka Agile koncentruje się na iteracyjnym tworzeniu oprogramowania i elastyczności, podczas gdy DevOps kładzie nacisk na ciągłe dostarczanie, automatyzację oraz współpracę między zespołami deweloperskimi i operacyjnymi. Wiele organizacji odnosi sukces, łącząc oba podejścia w celu maksymalizacji wydajności i jakości. Niezależnie od wybranej ścieżki kluczowe jest dostosowanie narzędzi i procesów, aby napędzać innowacje i szybciej dostarczać wartość.
Aby uzyskać więcej informacji na temat optymalizacji przepływów pracy związanych z tworzeniem oprogramowania i wyprzedzania trendów branżowych, zasubskrybuj biuletyn The CTO Club.
