Archiwa tagu: ddd

BDD, TDD, FDD i inne

Garść terminów na temat kilku metodyk zwinnych. Pochodzą z moich notatek do egzaminów i rozmów kwalifikacyjnych:)

 

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:

  1. określenie wymagań, wykonanie ogólnego projektu całości
  2. wybór podzbioru funkcjonalności
  3. szczegółowy projekt podzbioru
  4. implementacja podzbioru
  5. testowanie podzbioru
  6. dostarczenie podzbioru
  7. 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

 

Scrum – jedna 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:

  1. 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ść).
  2. 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ół.
  3. Podczas trwania sprintu, zespół wykonuje zadania. Może kontaktować się z product ownerem w celu uzyskania dokładniejszych wyjaśnień itd.
  4. 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).
  5. Sprint kończy się spotkaniem podsumowującym (sprint review), w którym uczestniczą wszyscy zainteresowani (nawet klienci!). Prezentowana jest kolejna wersja produktu (demo).

 

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).

  1. Pisanie testu jednostkowego do żądanej funkcjonalności. Test failuje, ponieważ nie ma jeszcze kodu programu.
  2. Implementacja funkcjonalności. Test przechodzi.
  3. Refaktoryzacja kodu.

 

FDD (Feature Driven Development)

  1. Budowa ogólnego modelu
  2. Budowa listy „cech”. „Cechy” są:
    1. niewielkie
    2. użyteczne
    3. zdefiniowane jednym zdaniem (np.: „rezerwacja pokoju”).
    4. grupowane w obszary funkcjonalne (np. „system rezerwacji hoteli”).
  3. Planowanie wg cech. Wskaźniki:
    1. priorytet
    2. pracochłonność
    3. ryzyko
  4. Projekt wg cech
  5. Implementacja wg cech
  6. Kroki 4. i 5. są powtarzane iteracyjnie. Po każdej iteracji wydawana jest wersja dla klienta.

 

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.

Czytaj dalej