Czas czytania: 5 minut
Zwinne zarządzanie projektami, tzw. Agile jest metodologią, która zapewnia elastyczność, efektywność i oszczędza czas. Dlatego, na przestrzeni ostatnich lat powstało wiele zwinnych metodyk zgodnych z manifestem Agile np. Scrum, Extreme Programming (XP), Kanban, DSDM, Crystal, Scrumbun czy Lean Startup. Warto zauważyć, że badania i raporty np. State of Agile pokazują jednoznacznie, że to właśnie Scrum jest obecnie podejściem dominującym, jeśli chodzi o tworzenie i rozwój oprogramowania.
Jak wykorzystujemy Scrum w Ebicom?
W Ebicom zaczęliśmy stosować Scrum do realizacji projektów w 2019 r., wraz z wdrożeniem narzędzia wspierającego ten proces – Azure DevOps.
Obecnie z naszymi klientami współpracujemy nad wykorzystaniem Azure DevOps, aby w pełni mogli uczestniczyć w procesie tworzenia oprogramowania.
Jakie są role w Scrum?
Poznaj trzy role, tworzące zespół scrumowy:
- Product Owner – osoba, która podejmuje decyzje, co do rozwoju produktu i wykorzystaniu czasu Development Team. W realizowanych przez nas projektach w tej roli najczęściej występuje przedstawiciel klienta, który posiada szeroką wiedzę o aktualnych potrzebach dotyczących rozwoju oprogramowania.
- Development Team/zespół deweloperski – to kilka osób, które planują, organizują i realizują zlecone zadania. W naszym przypadku działają aż trzy takie zespoły.
- Scrum Master – osoba, która odpowiada za wprowadzenie Scrum w życie oraz za przestrzeganie zasad frameworka. Wspiera zespół poprzez facylitację i usuwanie przeszkód.
Poznaj charakteryzację wydarzeń w Scrum
- Sprint – to krótkie, podsumowujące spotkanie. Zespoły developerskie funkcjonują zazwyczaj w dziennych, tygodniowych lub miesięcznych sprintach. U nas sprawdzają się miesięczne.
- Sprint Planning — planowanie kolejnych sprintów odbywa się u nas w trzeciej dekadzie miesiąca, tak aby od początku kolejnego sprintu (miesiąca) zespół developerski mógł sprawnie realizować kolejne zadania. Z pewnością, w tym wydarzeniu szczególnie przydatny jest Azure DevOps, dzięki któremu planowanie sprintu odbywa się z uwzględnieniem dostępności (ang. Capacity) zespołu developerskiego.
- Daily Scrum — to codzienne spotkania Development Team’u. Podczas nich zespół sprawdza, co zostało wykonane i czy nie pojawiły się przeszkody w realizacji sprintu, które należy usunąć. Dzięki śledzeniu Burndown Trend możemy weryfikować codzienny postęp prac.
- Sprint Review — jest feedbackiem, który zbieramy pod koniec Sprintu. To za jego sprawą sprawdzamy, jak wygląda przyrost produktu, aby nasz klient otrzymał jasny obraz faktycznego postępu prac.
- Sprint Retrospective — to spotkanie pod koniec Sprintu, podczas którego przyglądamy się procesowi, narzędziom i interakcjom. Dzięki temu możemy zdecydować, jak usprawnić proces. Spotkanie odbywa się z wykorzystaniem Azure DevOps Retrospectives:
Rodzaje artefaktów w Scrum:
- Product Backlog — jest to ogólna lista rzeczy do zrobienia. To jedyne miejsce, z którego Development Team może pobierać zadania.
- Sprint Backlog —to lista rzeczy do zrobienia w danym Sprincie. Po rozpoczęciu danego sprintu za pomocą Taskbordu monitorujemy codzienny postęp prac oraz dostępność (Capacity). Zobacz, jak to wygląda:
- Product Increment — to lista wykonanych działań. Dzięki niej możemy monitorować przyrost funkcjonalności i właściwości produktu.
Jak realizujemy analizy biznesowe?
W pierwszej fazie analizy biznesowej naszym celem jest wspólna wizja produktu. Dlatego, podczas warsztatów zbieramy wymagania funkcjonalne, dzięki którym tworzymy listę funkcjonalności produktu. Każda funkcjonalność musi mieć określony priorytet oraz poziom ryzyka. W pierwszej kolejności realizujemy funkcjonalności ocenione jako najmniej ryzykowne.
Decydujemy też, na kiedy mają zostać dostarczone poszczególne funkcjonalności, dzięki temu wyznaczamy kolejność wykonywania dla nich analiz szczegółowych. Na tej podstawie przypisujemy funkcjonalności do poszczególnych sprintów.
W ramach analizy szczegółowej, dla każdej funkcjonalności, doprecyzowujemy i uszczegóławiamy wymagania. Tworzymy dokument, zawierający szczegółową specyfikację wymagań. Znajduje się w nim m.in.:
- cel realizacji – opisujemy w nim cele biznesowe (korzyści), związane z dostarczeniem funkcjonalności;
- słownik pojęć, który zawiera definicje skrótów i pojęć kluczowych użytych w dokumencie;
- opis ograniczeń i wyłączeń – jeśli występują;
- szczegółowy opis procesów biznesowych, które będą realizowane w ramach dostarczanej funkcjonalności (w tym schematy obrazujące przebieg procesów);
- opis ról, dla których będzie dostarczana funkcjonalność;
- szczegółowy zakres wymagań biznesu, czyli spis detalicznych wymagań opisujących i precyzujących sposób działania systemu/funkcjonalności, które gwarantują osiągnięcie przyjętych celów biznesowych. Wymagania precyzyjnie określają „co” ma robić i „jak” ma działać dane rozwiązanie.
Na podstawie tej specyfikacji opracowujemy projekt realizacji funkcjonalności w formie User Stories. Każde User Story wraz z wypracowanymi kryteriami akceptacji i przypadkami testowymi wymaga zatwierdzenia przez Product Ownera.
Wszystkie opisane powyżej czynności wykonywane są z wykorzystaniem Azure DevOps, dzięki czemu mogą być monitorowane i nadzorowane przez wszystkie role biorące udział w projekcie.
7 etapów tworzenia oprogramowania
Poznaj 7 etapów tworzenia oprogramowania, oparte na zwinnych metodykach oraz DevOps.
Czym jest DevOps?
DevOps łączy w sobie dwa trendy:
- zwinną infrastrukturę (agile infrastructure) lub zwinną działalność (agile operations);
- trend oparty na współpracy między programistami a zespołami operacyjnymi na wszystkich etapach rozwoju oprogramowania, podczas tworzenia i obsługi usługi czy produktu.
DevOps wpiera współpracę między różnymi specjalizacjami i stanowiskami podczas całego cyklu produkcyjnego. Składa się z 7 etapów:
Etap 1: Requirement collection and analysis
Koncepcja „Bucket size planning” umożliwia długoterminowe planowanie rozwoju systemu. Opiera się na systemie trzech koszyków (buckets), przez które muszą przejść poszczególne elementy, zanim trafią do zespołu developerskiego.
Te trzy koszyki reprezentują trzy różne etapy planu:
- 1-roczne, przeznaczone na długoterminowe cele firmy, takie jak penetracja nowego rynku czy wypuszczanie nowego produktu;
- 6-miesięczne, gdzie krystalizują się nasze główne wymagania, aby zrealizować cel długoterminowy;
- 3-miesięczne, gdzie wymagania dzielimy na jasne zadania do wykonania przez zespół projektowy. To właśnie z tego koszyka podczas spotkania planowania przypisywane są zadania do poszczególnych sprintów.
Aby wesprzeć klienta w określaniu i przygotowaniu wymagań oraz ustaleniu priorytetów, udostępniamy mu widok Azure DevOps. Przygotowane są na nim 3 kolumny (priorytet 1-3), które reprezentują poszczególne koszyki. Wygląda to tak:
Etap 2: Feasibility study:
W następnym kroku definiujemy potrzeby oprogramowania. Służy nam do tego dokument „Specyfikacja wymagań oprogramowania”. Obejmuje on wszystko, co powinno być zaprojektowane i opracowane w trakcie cyklu życia projektu.
Etap 3: Design:
W tym etapie na podstawie „Specyfikacji wymagań oprogramowania” przygotowujemy szczegółowy opis funkcjonowania systemu w formie tzw. User Stories.
Każde User Story zawiera:
- informację co użytkownik będzie mógł wykonać w systemie. Opisujemy to za pomocą sformułowania „Jako …, chcę aby …, ponieważ … .”;
- opisane i ponumerowane w dokumencie „Specyfikacja wymagań oprogramowania” konkretne wymagania. Dzięki temu, w łatwy sposób możemy zweryfikować czy obsłużyliśmy wszystkie wymagania klienta;
- precyzyjnie opisane „kryteria akceptacji”, których realizacja gwarantuje spełnienie konkretnych wymagań klienta;
- zestaw przypadków testowych, które powstały w oparciu o „kryteria akceptacji”.
Przed przejściem do kolejnej fazy nasz klient musi zatwierdzić wszystkie User Story. Służy do tego Azure DevOps. Zatwierdzony projekt możemy wyeksportować do formatu pdf, doc lub html.
Etap 4: Coding:
Gdy zakończymy fazę projektowania systemu, przechodzimy do kodowania. Dzięki temu, że nasz klient ma dostęp do Azure DevOps, może śledzić i nadzorować przebieg procesu kodowania danego projektu.
W tym procesie wykorzystujemy dobre praktyki tworzenia oprogramowania – SOLID i reguły DRY, KISS. Dbamy też o to, aby prawidłowo wykorzystywać wzorce projektowe.
W procesie uwzględniamy także niezbędny Code Review, dzięki któremu:
- unikamy typowych błędów podczas programowania;
- wymuszamy zasady i standardy pisania kodu, dzięki czemu kod jest spójny i zrozumiały dla każdego;
- zwiększamy wydajność i stabilność poprzez zasady oparte na dobrych praktykach;
- uczymy się od siebie nawzajem, dzięki czemu budujemy doświadczenie całego zespołu programistycznego;
- utrzymujemy wspólną architekturę;
- zewnętrzne biblioteki są dobrze dobrane;
- kod jest obłożony testami jednostkowymi.
Narzędzie ReSharper (zintegrowany z VisualStudio), z którego korzystamy od początku tworzenia naszych rozwiązań, pomaga nam m.in. przy:
- refaktoryzacji kodu źródłowego;
- wyłapywaniu zagrożeń w kodzie źródłowym;
- inspekcji kodu źródłowego.
Etap 5: Testing:
W kolejnym kroku przechodzimy do testowania funkcjonalności całego systemu. Podczas testów sprawdzamy, czy cała aplikacja działa zgodnie z wymaganiami klienta ujętymi w „Specyfikacji wymagań oprogramowania”.
Dzięki wykorzystaniu DevOps testowanie w naszej organizacji nie jest ostatnim etapem przed wypuszczeniem produktu na rynek, a integralną częścią każdego z etapów tworzenia oprogramowania czy aplikacji.
Jak to możliwe?
Programiści i inżynierowie otrzymują kod w środowisku odpowiednim do przeprowadzenia Continuous Integration oraz Continuous Delivery. W rezultacie, możliwe jest przeprowadzenie procesów Continuous Testing i Continuous Monitoring, w których zespoły QA i Testerski mogą potwierdzić, że zbudowano odpowiedni kod oraz sprawdzić, czy działa zgodnie z założeniami projektowymi, wymaganiami klienta i kryteriami akceptacji.
Opracowany katalog przypadków testowych pomaga nam ciągle monitorować, czy zmiany naniesione w kodzie działają zgodnie z założeniami i czy nie spowodowały uszkodzenia produktu, wpływając tym samym w niepożądany sposób na pozostałe funkcjonalności.
Równolegle prowadzimy testy manualne nowych funkcjonalności. Te realizujemy, wykorzystując Azure DevOps. Kluczową rolę odgrywa zaplanowanie i oszacowanie testów tak, aby tworzone Test Casy pokrywały wszystkie zgłoszone wymagania i kryteria akceptacji.
Ustalane są wówczas:
- kryteria wejścia (zgodnie z ISTQB), które definiują warunki pozwalające na rozpoczęcie testów na początku poziomu testów lub gdy zbiór testów jest gotowy do wykonania;
- kryteria zakończenia (zgodnie z ISTQB), których celem jest zdefiniowanie momentu zakończenia testów na danym poziomie testów lub gdy zbiór testów osiągnął określony cel.
Podejście do testów definiujemy i uszczegóławiamy w planach testów oraz w projektach testów. Zwykle zawiera ono decyzje, które podejmujemy na podstawie celów projektu oraz oceny ryzyka.
Stanowi to punkt wyjściowy do:
- planowania procesu testowania,
- wyboru technik projektowania testów i stosowanych typów testów,
- definiowania kryteriów wejścia i zakończenia,
- tworzenia Test Casów i celu, jaki ma zostać osiągnięty.
To, jakie wybierzemy podejście, zależy od kontekstu i specyfiki realizowanego projektu. Naszym typowym podejściem testowania jest to, które wykorzystuje metodyki zwinne w połączeniu z podejściem metodycznym tzn. opartym na:
- awariach (włącznie ze zgadywaniem błędów i atakami usterkowymi),
- doświadczeniu,
- tworzonych listach kontrolnych test case,
- atrybutach jakościowych, zdefiniowanych na etapie przygotowania projektu.
Istotnym elementem, na który zwracamy uwagę, to monitorowanie postępu prac testerów, które odbywa się w trakcie codziennych standupów. DevOps umożliwia monitorowanie postępu prac nad poszczególnymi User Story, a także w kontekście utworzonych do nich test caseów.
Wycinek przykładowego raportu:
Wszystkie zweryfikowane User Story, a także przetestowane i zretestowane test casy przekazujemy zgodnie z ustalonymi harmonogramami klientowi, aby ten wykonał po swojej stronie testy akceptacyjne.
Etap 6: Installation/Deployment
Częścią metodyki DevOps, którą wykorzystujemy, jest Continuous Integration (CI) oraz Continuous Delivery (CD).
Co to oznacza?
Continuous Integration (ciągła integracja) to nieustanne, automatyczne buildowanie programu na naszym chmurowym serwerze. Codziennie uruchamiany jest też zestaw testów automatycznych, które sprawdzają najważniejsze funkcje systemu i potwierdzają, że wprowadzane do kodu modyfikacje nie są przyczyną błędów w działaniu całego programu.
Continuous Delivery (ciągłe dostarczanie) to automatyczne dostarczanie działającej wersji programu do wewnętrznego środowiska EBICOM, przed oddaniem na jedno ze środowisk klienta (test/preprod/prod). Następuje zazwyczaj po pozytywnym przejściu fazy testów automatycznych. Następnie funkcjonalności trafiają na środowisko testowe klienta, który na podstawie przypadków testowych przygotowanych przez EBICOM weryfikuje je pod kątem spełnienia wymagań ujętych w „Specyfikacji wymagań oprogramowania”.
Po weryfikacji i akceptacji, za pomocą narzędzia Azure DevOps, funkcjonalności trafiają na środowisko preprodukcyjne i produkcyjne.
Etap 7: Maintenance:
Po wdrożeniu systemu i rozpoczęciu korzystania z opracowanego systemu przez klientów, wykonywane są następują czynności:
- Monitoring środowiska
Ciągłe monitorowanie aplikacji jest bardzo ważnym i niezbędnym elementem. Proponowane przez nas rozwiązanie składa się z kilku elementów monitoringu, opartych głównie o usługi Azure:
- element automatycznego monitorowania dostępności usług aplikacyjnych jak i web serwisów. Dzięki temu, odpowiednie osoby z naszej firmy śledzą dostępności oraz na bieżąco reagują, jeśli pojawiają się jakiekolwiek problemy;
- element automatycznego monitorowania obciążenia serwerów aplikacyjnych. Ten rodzaj monitoringu odpowiedzialny jest, za badanie obciążenia procesora, pamięci RAM, DTU usług, na których hostowane jest rozwiązanie. Mowa tutaj m.in. o App Service, Virtual Machine i Database;
- automatyczne monitorowanie występujących błędów w aplikacji i procesów zachodzących w bazie danych;
- ręczny monitoring m.in. logów aplikacji czy bazy danych.
- Monitoring i naprawianie błędów
W celu zgłaszania i monitorowania czasów SLA związanych z naprawą błędów, udostępniamy swoim klientom portal internetowy – Service Desk. Dodatkowo, klient może weryfikować postęp prac nad naprawą poszczególnych błędów
z poziomu Azure DevOps.
- Aktualizacja aplikacji
Aktualizacja aplikacji do nowszych wersji odbywa się z wykorzystaniem podejścia Continuous Delivery.
- Ulepszanie aplikacji
Mamy możliwość na bieżąco dodawania nowych funkcjonalności do działającej aplikacji.
Stosowanie powyższych 7 etapów podczas tworzenia i rozwijania oprogramowania pozwala monitorować każdy element prac, zaoszczędzić czas oraz zminimalizować ilość błędów. Elastyczne metodologie zarządzania odgrywają dziś kluczową rolę w tym zakresie.