BDD, TDD, FDD, Agile i inne metodyki

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?

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:

  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

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:

  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

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

FDD (Feature Driven Development) – nacisk na funkcje.

  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

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.

Przydatny wpis? Postaw mi kawę :)

5
Dodaj komentarz

avatar
5 Comment threads
0 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
2 Comment authors
Annam. Recent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
m.
Gość

Ale jak w firmie pada pytanie odnośnie stosowanej metodyki to najlepsza odpowiedź „metodyka własna”. 😉

m.
Gość

Ale jak w firmie pada pytanie odnośnie stosowanej metodyki to najlepsza odpowiedź „metodyka własna”. 😉

trackback

[…] w aplikacji warto rozważyć piszanie testów jednostkowych tylko do nowych partii aplikacji (TDD). Przymierzając się natomiast do dużych zmian w całej aplikacji warto przygotować jak […]

trackback

[…] BDD, TDD i inne (15.05.2016) […]

Anna
Gość
Anna

1. Scrum NIE JEST metodyką. Jest „ramą postępowania”, „frameworkiem”. O różnicach definicyjnych pomiędzy jednym i drugim doczytasz chociażby w Internetach. 2. Product Backlog NIE JEST zbiorem User Stories. Jest zbiorem PBI (Product Backlog Items), których forma jest taka, na jaką zdecyduje się Product Owner. User Stories to tylko jedna z propozycji opisywania wymagań, ale nie obligatoryjna w Scrumie. 3. Sprinty nie trwają od tygodnia do miesiąca. Trwają tyle, ile odpowiada Scrum Teamowi, z założeniem, że nie dłużej niż 4 tygodnie. Nie ma wartości minimalnej, a to oznacza, że mogą trwać i 5 dni, i 1 dzień. 4. Zespół NIE SKŁADA… Czytaj więcej »