W odpowiedzi na kryzys inżynierii oprogramowania starano się definiować procesy i dopracowywać metodyki. Z drugiej strony pojawia się rewolucja lekkich metod, takich jak Programowanie Ekstremalne (XP), które są interesującą odpowiedzią na zmieniające się potrzeby klientów.

Kryzys w inżynierii oprogramowania, który pojawił się przy tworzeniu pierwszych dużych systemów, takich jak OS/360, dowiódł, że metody starzeją się niewiarygodnie szybko i często już po dekadzie okazują się bezradne wobec nowych potrzeb rynku. Lata 80. i 90. to czas definiowania procesów, wprowadzania analizy strukturalnej czy inspekcji artefaktów. Ale i to nie wystarczało na długo. Syndrom LOOP (Late, Over time, Over budget, Poor quality) ciągle wisi nad głowami dostawców software'u niczym miecz Damoklesa.

W latach 70. i 80. zaczęło upowszechniać się przekonanie, że źródłem zła są samowola programistów i bałagan organizacyjny, w tym brak jasno zdefiniowanych reguł współpracy, rozmyta odpowiedzialność, brak właściwych metod kontroli i zapewniania jakości. Na gruncie takich poglądów wyrosły standardy ISO 9000 i model CMM (Capability Maturity Model) opracowany przez SEI (Software Engineering Institute). Jednak z czasem i one stały się przedmiotem krytyki. W czasach boomu internetowego, który zmienił model biznesowy wielu przedsiębiorstw, tworzenie oprogramowania za pomocą procedur i procesów okazywało się zbyt czasochłonne, nieefektywne, nieelastyczne, powodujące frustrację pracujących w nadgodzinach programistów. Dlatego przewrót był nieunikniony...

Rewolucja, jaką było pojawienie się pod koniec lat 90. ubiegłego stulecia nowych, lekkich metodyk, przywracała znaczenie kodowania, a deprecjonowała procesy, dokumentację, hierarchie. Celem stało się bardzo szybkie dostarczanie klientowi funkcjonalności potrzebnej do jego pracy, a nie ścisła realizacja specyfikacji.

Rola programisty - dotychczas zwykłego robotnika tłumaczącego specyfikację na język programowania - została znów doceniona.

Spośród lekkich metodyk największą popularność zdobyło Programowanie Ekstremalne (XP). Prowokująca nazwa sugeruje wprawdzie zupełnie nową jakość, jednak XP jest właściwie kompilacją pomysłów, które są doskonale znane, a jedynie nie były stosowane razem. Jednak to właśnie XP stało się synonimem nowych metodyk i wzbudziło - i nadal wzbudza - spore kontrowersje.

XP w pigułce

Programowanie Ekstremalne, wbrew nazwie, jest metodyką zdyscyplinowaną. Zdaniem Kenta Becka, twórcy XP, u jej podstaw leżą cztery podstawowe wartości:

• uczciwa komunikacja wewnątrz zespołu (którego członkiem jest klient)

• prostota

• informacja zwrotna od klienta

• i wreszcie odwaga, aby umieć zmieniać system i dostosowywać do potrzeb klienta.

Obszar planowania i definiowania wymagań

Planowanie ekstremalne to na pierwszy rzut oka zaprzeczenie idei planowania: jego horyzont nigdy nie wykracza poza jedno wydanie nowej wersji systemu, co trwa od kilku tygodni do kilku miesięcy. Po co bowiem tworzyć plan, skoro przedstawiciel klienta, kluczowa postać w każdym przedsięwzięciu XP, może w każdej chwili zmienić zakres prac?

Klient bowiem nie jest jedynie źródłem informacji potrzebnych do opracowania specyfikacji: to właśnie on planuje pracę i decyduje o bieżących priorytetach prac. Decyzje te zapadają podczas tzw. gry planistycznej, poprzedzającej każdą iterację i wydanie. W jej trakcie klient przedstawia programistom opis funkcji systemu w postaci tzw. opowieści użytkownika (user stories), czyli wymagań opisanych w języku naturalnym. Na tej podstawie programiści szacują pracochłonność każdej z funkcji, a klient, biorąc pod uwagę dostępny "budżet czasowy" oraz własne priorytety, decyduje o ich realizacji. Co ciekawe, klient ma pełne prawo w każdej chwili zmienić plan, dlatego gra planistyczna często jest powtarzana już w trakcie prac.