Programowanie ekstremalne (eXtreme Programming) powstało jako próba zaradzenia problemom związanym z długimi cyklami dostarczania oprogramowania i spadkiem zainteresowania inwestora zadaniem.

XP charakteryzują:
ewolucyjne podejście do projektowania i programowania oraz ekstremalnie ścisła współpraca z odbiorcą.
Zasadą są ekstremalnie krótkie iteracje w dostarczaniu kolejnych wersji oprogramowania prowadzące do szybkich odpowiedzi użytkownika.

Przy wytwarzaniu oprogramowania stosuje się programowanie w parach, ustawiczną przebudowę (refactoring) kodu źródłowego, ustawiczną integrację i testowanie połączonych modułów.

Hasła towarzyszące projektowaniu XP to:

•gra w planowanie (planning game),

•szybkie iteracje,

•porozumienie pomiędzy użytkownikiem i programistami za pomocą metafor,

•prostota kodu (brzytwa Ockhama),

•ustawiczne testowanie i integracja modułów,

•programowanie w parach,

•kolektywne posiadanie kodu,

•unikanie nadgodzin,

•komunikacja pomiędzy programistami poprzez kod źródłowy

•konstrukcja kodu źródłowego wedle zasad akceptowanych i przestrzeganych w całym zespole.

Jedna z zasad XP głosi, że nie ma uniwersalnej metody prowadzenia projektu informatycznego. Wobec tego praktyki XP powinny być przystosowywane do aktualnych potrzeb i specyfiki projektu.

W cyklu życia projektu XP wyróżnia się fazy:

•eksploracji,

• planowania,

•iteracji wykonawczych,

•przygotowania do produkcji,

•utrzymania w ruchu,

•zakończenia projektu.

W fazie eksploracji zespół projektowy zapoznaje się z tematem prac i pozyskuje podstawowe informacje od użytkownika.

Użytkownik przedstawia sposób użytkowania systemu poprzez opowiadania („story”), na podstawie których budowany jest zarys architektury systemu oraz budowana jest lista funkcjonalności. W tym czasie projektanci testują wybraną technologię tworząc niezbędne prototypy oraz zapoznają się z używanymi narzędziami.

Faza planowania.

Opowiadania przedstawione przez użytkownika są analizowane i nadawane są im priorytety. W porozumieniu z użytkownikiem zestawiana jest lista funkcjonalności, które mają być opracowane. Programiści oceniają czas realizacji zadań i ustalany jest harmonogram prac i termin zakończenia prac.

Faza iteracji wykonawczych.

Składa się z jedno lub kilkutygodniowych mini cykli implementujących kolejne właściwości systemu. Wykonywane są działania analityczne, projektowe, kodowanie i testowanie. Na końcu każdego mini cyklu wykonywane są testy oprogramowania zaplanowane przez użytkownika.

Faza przygotowania do produkcji.

W tej fazie system zawierający uzgodnioną porcję funkcjonalności jest przygotowywany do wdrożenia. Pojawiające się uwagi użytkownika są implementowane lub przeznaczane do implementacji w następnej wersji oprogramowania. Wykonywane są dodatkowe gruntowne testy.

Faza konserwacji.

Użytkownik jest wyposażony w działającą wersję oprogramowania, która wymaga opieki i nadzoru. Zespół projektowy w tym samym czasie wykonuje kolejną wersję oprogramowania. W trakcie pracy z oprogramowaniem odbiorca formułuje kolejne postulaty dla zespołu projektowego.

Wejście fazę produkcji często pociąga za sobą zmiany w zespołach projektantów i wzrost zatrudnienia. Wysiłek poświęcany na utrzymanie w ruchu wersji produkcyjnej wpływa na zmniejszenie prędkości opracowywania nowej wersji oprogramowania.

Zakończenie projektu.

Gdy użytkownik nie jest już zainteresowany dodawaniem funkcjonalności do oprogramowania, tempo współpracy z użytkownikiem spada, formułowane wnioski o rozszerzenie funkcjonalności mają charakter drugorzędny i często nie są wdrażane z powodów ekonomicznych. W tej fazie zespół projektowy podejmuje decyzję o zakończeniu projektu, blokuje zmiany w architekturze systemu i kodzie źródłowym, opracowuje dokumentację systemu i projektu, ostateczne wersje instrukcji użytkownika oraz instrukcje konserwacji.

Metodyka Scrum

Istotą metody Scrum jest adaptacyjny, samoorganizujący się proces wytwarzania oprogramowania. Nazwę zapożyczono ze strategii gry w rugby. Scrum jest w istocie techniką zarządzania projektem informatycznym, utworzoną na podstawie doświadczeń w realnych projektach. Koncentrując się na zadaniach zarządzania pozostawia wolny wybór w wyborze technik prowadzenia prac programistycznych. Zakłada jednakże ewolucyjny styl tworzenia oprogramowania. Podstawę adaptacyjności w Scrum stanowi założenie, że rozwój oprogramowania zachodzi w niestałych warunkach, na które składają się: nieprzewidywalne zmiany w wymaganiach, terminach, zasobach oraz dostępnych technologiach, wobec czego sam proces tworzenia oprogramowania jest złożony i nieprzewidywalny. Scrum zastosowane w praktyce, jak twierdzą twórcy, jest w stanie usprawnić stosowane metody produkcji oprogramowania, bo przewiduje częste działania zarządcze skupiające się na identyfikowaniu problemów i przeszkód w pracach inżynieryjnych.

Proces Scrum podzielony jest na trzy główne etapy:

•rozpoczęcie gry (pregame),

•faza produkcji (development phase),

•gra na zakończenie (postgame).

Faza rozpoczęcia obejmuje czynności planowania i opracowania zarysu architektury systemu (Architecture high level design). W trakcie tej fazy wszystkie znane wymagania są spisywane i opracowywana jest lista wymagań (Product backlog list). Lista ta jest otwarta, a zadania do realizacji dopisywane są do niej w trakcie całego procesu tworzenia oprogramowania. Źródłem wymagań są przede wszystkim użytkownicy, ale również dział marketingu i sprzedaży, dział obsługi klienta oraz sam zespół projektantów-programistów. Wymaganiom zestawionym na liście przypisywane są priorytety. Na podstawie listy opracowywana jest architektura systemu. Każdorazowo, gdy do listy dopisywane są nowe wymagania, są one rozpatrywane w ramach specjalnego spotkania (Design Review Meeting).

Rozpatrywane są również zmiany w architekturze systemu wynikłe z wprowadzenia nowych wymagań. Finalnie, w ramach oddzielnego spotkania, tworzony jest podzbiór listy wymagań. Zawarte tam wymagania przeznaczone są do realizacji w ramach aktualnej iteracji (sprint backlog list).

Każdy cykl to w istocie podprojekt kaskadowy składający się z opracowania wymagań, analizy, projektowania, kodowania i wdrożenia trwający nie dłużej niż 30 dni.

Czynności zarządcze w fazie produkcji zasadzają się na spotkaniach organizacyjnych.

•Rozpoczęcie prac związane jest ze Spotkaniem Planowania Cyklu (Sprint planning meeting),

•Zakończenie prac z nieformalnym Spotkaniem Przeglądowym (Scrum Review meeting).

•Są również Codzienne Spotkania Zespołu projektantów i programistów (Daily Scrum meeting).

Spotkanie Planowania Cyklu (Sprint planning meeting) organizowane jest przez zarządcę procesu dwukrotnie.

W pierwszym spotkaniu biorą udział użytkownicy, nabywcy, zarząd i zespół projektantów. Ustala się cele i priorytety właśnie rozpoczynającej się iteracji. Wymagania wpisuje się we wspomnianą wyżej listę (Sprint product backlog). W drugim spotkaniu biorą udział jedynie wykonawcy i Zarządca Scrum, którzy ustalają sposób przeprowadzenia prac przy implementacji wymagań. Codzienne Spotkania Scrum (Daily Scrum meeting) są krótkie, najwyżej 15 minut, mają na celu motywowanie personelu oraz śledzenie postępów prac. W trakcie spotkania omawiane są problemy oraz planowane są posunięcia z nich wynikające. W spotkaniach uczestniczy zespół projektantów i programistów oraz zarządca Scrum. Spotkanie podsumowujące (Scrum Review Meeting) odbywa się w ostatni dzień trwania iteracji produkcyjnej (iteracja nie trwa więcej niż 30 dni). Omawiane są na nim postępy prac oraz formułowane są wnioski, nowe wpisy do listy wymagań lub postulowane są generalne zmiany w architekturze systemu. Faza zakończenia projektu rozpoczyna się wraz z ustaleniem pomiędzy użytkownikiem a projektantami, że wymagania są zrealizowane (lista wymagań jest pusta). System jest przygotowany do instalacji. W tej fazie wykonywana jest ostateczna integracja modułów i testowanie, a także przygotowuje się dokumentację. Scrum wprowadza interesujące narzędzie zarządcze jest nim omawiana już lista wymagań (produkt backlog list). Opisuje ona wszystko to, co powinno się znaleźć w ostatecznej wersji oprogramowania (wedle aktualnej wiedzy). W ten sposób lista wymagań opisuje wszystko, co należy zrobić w projekcie. Lista zwykle zawiera właściwości, funkcje, usterki, defekty, żądania rozszerzeń i żądania uaktualnień technologicznych. Do zarządzania listą przeznaczony jest pracownik - Zarządca Projektu. On trzyma pieczę nad dodawaniem nowych pozycji do listy, jak i usuwaniem pozycji gdy są zrealizowane. W pragmatyce rozwoju oprogramowania „open source” taka lista nosi nazwę „to do list”. Na diagramie przebiegu projektu nie przedstawiono jednego istotnego procesu biegnącego niezależnie od procesów wytwórczych. Jest nim estymacja pracochłonności. W trakcie całego projektu równolegle z pracami projektowymi i implementacyjnymi trwa proces oceny pracochłonności postulatów zawartych w liście wymagań. W początkowych fazach projektu oceny te są zgrubne, lecz w miarę gromadzenia informacji z postępu prac implementacyjnych stają się coraz bardziej dokładne. Proces estymacji pracochłonności polega na gromadzeniu informacji statystycznych o przebiegu projektu i wyznaczaniu kosztu prac na ich podstawie. Estymacja pracochłonności nie bierze pod uwagę dużych zmian w architekturze systemu lub użytkowanej technologii. W przypadku projektu prowadzonego metodą Scrum od początku zaleca się  by użytkownik wraz z zespołem projektantów spędził kilkanaście dni nad opracowaniem listy wymagań. Muszą się w niej znaleźć zapisy dotyczące zarówno wymagań biznesowych jak
i technologicznych. Celem nadrzędnym pierwszej iteracji produkcyjnej jest pokazanie użytkownikowi jakiegoś fragmentu funkcjonalności systemu zaimplementowanego w ramach wybranej technologii. Należy przewidzieć dużą ilość pracy przy pierwszej iteracji, bo dochodzą tu prace nad opracowaniem szkieletu systemu, do którego będą dodawane funkcjonalności w ramach kolejnych iteracji. Pierwsza iteracja produkcyjna różni się od kolejnych również z tego powodu, że na jej listę wymagań wpisane są takie zadania jak: zapoznanie się z technikami Scrum, organizacje zespołów Scrum, rozdział ról w projekcie. Dalsze iteracje są prostsze i szybsze. Nowoczesne metodyki prowadzenia projektu informatycznego różnią się od tradycyjnych metod generalną ideą. Podczas gry tradycyjne metody prowadzenia projektu w zamyśle sprzedają produkt - oprogramowanie, nowe techniki zarządzania sprzedają usługę – opracowanie oprogramowania.

Właściwości:

•Wszystkie opisywane techniki zakładają ścisłą współpracę z użytkownikiem czy odbiorcą. Właściwie postuluje się włączenie użytkownika w proces projektowania oprogramowania (eXtreme Programming).

•Sprzedawana jest usługa tworzenia oprogramowania
a nie gotowy produkt -oprogramowanie, tak więc użytkownik jest tym, kto podejmuje decyzje co i w jakiej kolejności będzie w projekcie wykonywane.

•Istotną wagę przywiązuje się do poprawnego szacowania kosztów prac, tak by inwestor/użytkownik mógł świadomie planować swe wydatki na rozwój oprogramowania.

•Zobowiązuje się wytwórcę oprogramowania do tego, że każdym swym działaniem powinien udowadniać inwestorowi efektywne wykorzystanie czasu
i powierzonych mu środków.

•Sprzedając usługę programowania rezygnuje się z zysków z ponownego użycia kodu i modeli analitycznych, bo prace odniesione są do niepowtarzalnego projektu. Przy takim założeniu rozległa dokumentacja projektowa staje się zbędnym kosztem obciążającym użytkownika i unika się jej.

•Uproszczenia dokumentacyjne wymuszają specyficzny sposób porozumiewania się z użytkownikiem. W trakcie tworzenia oprogramowania często (na bieżąco) zadaje się mu pytania i prośby o potwierdzenie dotyczące niewielkiego zakresu funkcjonalności. Stąd wynikają inkrementalny sposób dostarczania oprogramowania oraz krótkie iteracje implementacyjne (XP, Scrum).

•Nie specyfikuje się formalnych punktów kontrolnych w projekcie - nie są one potrzebne, gdyż zakończenie każdej iteracji jest punktem kontrolnym samym w sobie. Z drugiej strony wprowadzenie sformalizowanych punktów kontrolnych nie we wszystkich technikach jest możliwe.

•Sekwencyjna realizacja wymagań użytkownika powoduje częste zmiany w architekturze systemu i konieczność przebudowy kodu.
W nowych metodykach zadanie przebudowy kodu postrzega się nie jako wyjątek, lecz jako regułę.