Dobre praktyki w architekturze zwinnej

Publish date:

Poznaj najlepsze praktyki i zwinne zasady pracy w zmiennych warunkach projektów IT

Rozwój oprogramowania w dynamicznym środowisku wymaga szybkiej adaptacji do zmieniających się warunków projektowych. Architektura w podejściu zwinnym wspiera ewolucyjną strategię do projektowania i architektury systemów informatycznych w celu spełnienia biznesowych potrzeb klienta zgodnie z zasadami Agile. Poniżej przedstawiamy zestaw praktyk, które zostały sprawdzone w realizacji projektów zwinnych i przygotowane na podstawie doświadczeń grupy roboczej ds. architektury zwinnej.

Read in ENG>>>

Autorzy z Software Solutions Center w Capgemini: Adam Witkowski, Krzysztof Korus, Jacek Panachida, Maksym Perevertov, Przemysław Szczuc, Szymon Stawiński

Sposób pracy zgodny z zasadami Agile

Małe zespoły składające się z trzech do pięciu osób. Małe zespoły sprzyjają mniejszemu narzutowi związanemu z komunikacją wewnątrz zespołu i pozwalają na skuteczne podejmowanie wspólnych decyzji. W małym zespole istnieje większa szansa, aby nawiązać wspólną więź i stworzyć kulturę własności (ang. ownership culture) korzystną w proaktywnym działaniu, podejmowaniu decyzji oraz rozwiązywaniu problemów. Małe zespoły mogą pracować produktywnie nad rozwojem spójnych usług w swoim obszarze oraz współdziałać z innymi zespołami w celu realizacji wspólnych procesów rozwoju oprogramowania.

Decyzje o architekturze systemów podejmowane są w zespołach deweloperskich. Klient jest włączany w rozmowy, a każdy programista rozumie i ma wpływ na podejmowane decyzje. Interesariusze biznesowi pracują ściśle z zespołem programistów, aby przedstawić wizję produktu i nadać kształt ostatecznemu rozwiązaniu. Wyjaśniają wymagania biznesowe i współpracują z programistami, aby mieć pewność, że wszyscy mają takie samo zrozumienie projektu i potrafią skutecznie zbudować odpowiednie rozwiązanie.

Przed podjęciem istotnych decyzji w sprawie projektu i jego realizacji odbywa się weryfikacja pomysłu (ang. proof of concept), bądź stworzenie produktu posiadającego tylko kluczowe funkcjonalności (ang. minimum viable product), a wyniki omawiane są z klientem. Obie metody skracają pętlę informacji zwrotnej, przyspieszają naukę oraz pozwalają zweryfikować rozwiązanie pod kątem biznesowym i/lub technicznym przy użyciu minimalnych zasobów i przy ograniczonym ryzyku.

Oprogramowanie jest projektowane tak, aby było tak proste, jak to tylko możliwe oraz modułowe. Oprogramowanie projektowane jest tak, aby w możliwie najprostszy sposób spełniło stawiane cele biznesowe, jednocześnie będąc otwartym na rozbudowę. Modułowość oprogramowania na wielu poziomach ma kluczowe znaczenie dla architektury zwinnej i powoduje znaczną poprawę utrzymania, testowalności i elastyczności systemu.

Projektowanie systemu skupia się na kontraktach i interfejsach między komponentami, po których ustanowieniu można podzielić pracę między zespołami. Interfejsy i kontrakty promują luźne powiązanie (ang. loose coupling) oraz ponowne wykorzystanie komponentów i usług. Pozwalają na równoległy rozwój wielu komponentów, zwiększają autonomię zespołów oraz zachęcają do efektywnej współpracy między stronami. Odgrywają istotną rolę w testach integracyjnych oraz kontraktowych (ang. consumer-driven contract).

Stosowanie procesów ciągłej integracji (ang. continuous integration) oraz ciągłego dostarczania (ang. continuous delivery). Oba procesy zaimplementowane jako część wczesnego testowania (ang. shift-left testing), pozwalają na zidentyfikowanie problemów na wczesnym etapie rozwoju oprogramowania, co zmniejsza koszty naprawy błędów. Zautomatyzowane procesy ciągłej integracji i dostarczania można łatwo skalować oraz utrzymywać wraz z rosnącą liczbą dokonywanych zmian lub częstotliwością wydań systemu. Pozwalają one zmniejszyć liczbę wyzwań związanych z integracją systemów oraz skrócić pętlę informacji zwrotnej.

Testowanie jest procesem ciągłym i obejmuje wysoki poziom pokrycia kodu testami jednostkowymi oraz integracyjnymi. Testowanie jest przeprowadzane wcześnie w ramach rozwoju oprogramowania, zgodnie z podejściem wczesnego testowania (ang. shift-left testing). Opiera się na automatycznych testach, zaimplementowanych jako część procesów ciągłej integracji i dostarczania. Testowanie łączy różne rodzaje metod (TDD, BDD, ATDD) w celu podniesienia jakości oprogramowania. Wysokie standardy jakości są zapewniane przez stosowanie bramek kontroli jakości (ang. quality gates).

Minimalna dokumentacja lub jej brak. Dokumentacja musi odpowiadać potrzebom projektu. Dokumentacja powinna być stworzona w formie, która najbardziej odpowiada projektowi i zespołowi. Dokumentacja powinna być tworzona „w sam raz, w samą porę”, aby dostarczyć wartość biznesową oraz ograniczyć zbędne koszty.

Dużo komunikacji w małych zespołach. Członkowie zespołów komunikują się często w celu dostarczenia działającego oprogramowania oraz pozostają w kontakcie z interesariuszami, aby mieć pewność, że tworzone rozwiązanie spełnia potrzeby interesariuszy. Używają różnych narzędzi i technik do zarządzania informacją, planowania pracy i zwiększania widoczności (ang. visibility) prowadzonych działań.

Projektowanie i rozwijanie tylko kluczowych funkcji (bez zbytniego skomplikowania lub dodawania funkcji na później itp.). Praca zespołu programistów koncentruje się na dostarczeniu rzeczywistej wartości dla klienta. Dzięki wspólnej wizji produktu, częstej komunikacji i prostoty projektowania, funkcje dostarczane są na czas, zwiększając tym samym wydajność i redukując zbędną pracę.

Wszyscy programiści są zaangażowani w projektowanie, rozwój, testowanie, wydawanie i wsparcie. Samoorganizujące i wielofunkcyjne zespoły programistyczne wybierają najlepszą drogę do osiągnięcia swojego celu od początku do końca. Uzgadniają wspólne praktyki i pracują nad tym, aby dostarczyć działające oprogramowanie tak często jak potrzeba.

Ciągłe doskonalenie techniczne produktu idzie w parze z nowymi funkcjami biznesowymi. Projektowanie ewolucyjne pozwala zespołowi programistów na sprawne reagowanie na zmiany i pracę nad rozwiązaniem, które spełnia potrzeby klienta. Zespół programistów trzyma dług techniczny pod kontrolą i aktywnie działa na rzecz jego ograniczenia.

Korzyści zwinnej metodologii pracy

  • Żaden z członków zespołu nie pracuje tylko jako architekt, a więc wszyscy architekci działają również jako menedżerowie lub jako główni lub starsi programiści itp.,
  • niewielka ilość dokumentacji do utrzymania,
  • wydaje się, że to jedyny możliwy sposób dostarczania projektów w sytuacji, gdy wymagania, priorytety, terminy i zakres często się zmieniają (np. w bankowości inwestycyjnej),
  • wielkość zespołu może być znacznie mniejsza,
  • elastyczność jest bardzo wysoka,
  • czas wprowadzenia produktu jest krótszy,
  • bardzo wysoki poziom własności i dojrzałości po stronie zespołu,
  • zespół sprawnie radzi sobie z wymianami i nowymi członkami w zespole,
  • stosunkowo niski koszt poprawy błędów,
  • poprawiona przejrzystość i przewidywalność postępu prac, jak i kształtu systemu.

Powiązane posty

Software Solutions Center

Agile Architecture: Best Practices

Date icon 2021-07-05

Explore the best practices and agile principles in IT projects

Software Solutions Center

Programy rozwojowe w Software Solutions Center w Capgemini

Date icon 2021-06-17

Jak wspierać rozwój pracowników przez dedykowane programy?