Garść terminów na temat kilku metodyk wytwarzania oprogramowania – metodyk zwinnych („agile„). Pochodzą z moich notatek do egzaminów i rozmów kwalifikacyjnych:)
Czy kanarki sa Agile? Foto: moje, luty 2018
Czym jest Agile?
Programowanie zwinne (Agile) – iteracyjno-przyrostowa metoda wytwarzania oprogramowania.Zakłada częsty kontakt z klientem, dostarczanie co jakiś czas kolejnych (działających!) fragmentów systemu.
Proces w Agile:
- określenie wymagań, wykonanie ogólnego projektu całości
- wybór podzbioru funkcjonalności
- szczegółowy projekt podzbioru
- implementacja podzbioru
- testowanie podzbioru
- dostarczenie podzbioru
- powrót do punktu 2. aż do zakończenia projektu.
Manifest Agile:
Ludzie i interakcje ponad procesy i narzędzia
Działające oprogramowanie ponad obszerną dokumentację
Współpracę z klientem ponad formalne ustalenia
Reagowanie na zmiany ponad podążanie za planem
Czym jest Scrum?
Scrum jest jedną z najbardziej znanych metodyk zwinnych. Podstawowe założenia:
- Czas realizacji projektu jest podzielony na mniejsze odcinki trwające od tygodnia do miesiąca (sprinty). Każdy sprint to jedna iteracja procesu, po której dostarczona zostaje kolejna wersja oprogramowania.
- Lista wymagań, spisana jest w formie user stories (jak w BDD, patrz niżej), zbiór ten to backlog.
- Zespół projektowy składa się z różnych ról: programiści, testerzy i inni wykonawcy, scrum master zarządzający procesem, product owner który zna wymagania użytkownika i jest ogniwem łączącym klienta z zespołem.
- Zespół jest samoorganizujący się. Nie ma kierowników, każdy sam wybiera sobie realizowane zadania.
Proces w Scrumie:
- Przed rozpoczęciem iteracji, zespół na sesji groomingu przegląda backlog produktu, dzieląc zadania na mniejsze fragmenty i przypisując im punkty (story points), będące miarą złożoności zadania. Mogą używać do tego kart do Sprint pokera, czyli kart ze zdefiniowaną ilością punktów (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, nieskończoność).
- Na początku iteracji zespół planuje sprint (sprint planning), wybierając funkcjonalności, które będzie realizować – przerzuca je z product backlogu do sprint backlogu. Dzięki prowadzeniu statystyk i przedstawieniu każdego zadania za pomocą punktów, wiadomo ile mniej więcej zadań może wziąć na siebie zespół.
- Podczas trwania sprintu, zespół wykonuje zadania. Może kontaktować się z product ownerem w celu uzyskania dokładniejszych wyjaśnień itd.
- Każdego dnia odbywają się maksymalnie 15-minutowe spotkania podsumowujące co udało się zrobić wczoraj, co jest planowane na dziś, jakie są problemy. (Daily Scrum / stand up).
- Sprint kończy się spotkaniem podsumowującym (sprint review), w którym uczestniczą wszyscy zainteresowani (nawet klienci!). Prezentowana jest kolejna wersja produktu (demo).
TDD
TDD (Test Driven Development) – podejście, w którym najpierw pisze się testy (jednostkowe), a następnie funkcjonalności we właściwym programie. Dzięki TDD możliwe jest uzyskanie wysokiego pokrycia testami (test coverage).
- Pisanie testu jednostkowego do żądanej funkcjonalności. Test failuje, ponieważ nie ma jeszcze kodu programu.
- Implementacja funkcjonalności. Test przechodzi.
- Refaktoryzacja kodu.
FDD
FDD (Feature Driven Development) – nacisk na funkcje.
- Budowa ogólnego modelu
- Budowa listy „cech”. „Cechy” są:
- niewielkie
- użyteczne
- zdefiniowane jednym zdaniem (np.: „rezerwacja pokoju”).
- grupowane w obszary funkcjonalne (np. „system rezerwacji hoteli”).
- Planowanie wg cech. Wskaźniki:
- priorytet
- pracochłonność
- ryzyko
- Projekt wg cech
- Implementacja wg cech
- Kroki 4. i 5. są powtarzane iteracyjnie. Po każdej iteracji wydawana jest wersja dla klienta.
BDD
BDD (Behavior Driven Development) – rozwijanie oprogramowania od strony wymagań użytkownika. Wymagania są przechowywane w postaci historyjek (user stories) w formie:
Jako powracający użytkownik
Gdy wpiszę szukany przedmiot
Pod listą wyników widzę swoje poprzednie wyszukania
Opis jest realizowany wg punktów:
given - warunki początkowe, aktor, kontekst
when - akcje, wydarzenie
then - oczekiwane rezultaty
User stories są niezwykle popularną formą przechowywania wymagań także poza BDD, o czym świadczyć może choćby popularność takich frameworków jak Cucumber, JBehave.
Inne metodyki – w skrócie:
Kanban – głównym punktem jest tablica kanbanowa, na której umieszczone są zadania w kolumnach „do zrobienia”, „w trakcie pracy”, „zrobione” (można rozszerzać tą listę o swoje statisy). Obowiązuje priorytetyzacja zadań. Metoda polecana dla zespołów, które bardziej niż dostarczaniem nowych funkcjonalności, zajmują się utrzymaniem, helpdeskiem itd. – nacisk na szybkość wykonywania zadań, brak planowania.
RUP – system ten cechuje komponentowość, projektowanie w oparciu o UML. Fazy:
- Projekt (UML)
- Opracowanie
- Kontrukcja
- Przekazanie systemu
ATDD – Acceptance Test-Driven Development – gratka dla testerów;) W tej metodyce oprogramowanie jest rozwijane w oparciu o współpracę między klientem biznesowym, developerami i testerami. Kładzie duży nacisk na testy akceptacyjne, które są z kolei pisane na podstawie kryteriów (acceptance criteria).
DDD – Domain-Driven Design – duży nacisk na projektowanie całości logiki domenowej, stosowanie wzorców projektowych.
MDE – Model Driven engineering
EDD – Example-Driven Development
SDD – Story Test-Driven Development
XP – extreme programming, brak projektu, programowanie parami, częsty kontakt z klientem, obowiązkowe testy jednostkowe.
