Wymagania w projektach IT: Od specyfikacji do Agile

W wielu projektach, szczególnie w branży IT, kluczową rolę odgrywa dokument zwany „dokumentem wymagań„, często określany również jako „specyfikacja wymagań„. Jego znaczenie jest podkreślane w ofertach i umowach, gdzie zatwierdzenie tego dokumentu uznawane jest za istotny kamień milowy projektu. Specyfikacja ta ma za zadanie zawierać kompleksową listę wymagań, szacunki pracochłonności i terminy realizacji, a także precyzyjne kryteria odbioru. Jednak czy tradycyjne podejście do specyfikacji, polegające na jej kompletnym opracowaniu na wczesnym etapie projektu, jest zawsze optymalne? Artykuł analizuje to zagadnienie, porównując klasyczne metody z dynamicznym podejściem Agile, które zyskuje coraz większą popularność w zarządzaniu projektami IT.

Uwaga: Pierwsze, fundamentalne pytanie brzmi: kiedy wykonawca powinien dostarczyć dokument specyfikacji wymagań? Jeśli ma to nastąpić dopiero na zakończenie projektu, dokument staje się w praktyce zbędny. Z kolei próba stworzenia kompletnej i ostatecznej specyfikacji na samym początku projektu jest często nierealna. Wielu ekspertów słusznie argumentuje, że bez solidnej znajomości wymagań nie można precyzyjnie określić potrzeb klienta, a tym samym – osiągnąć sukcesu w projekcie. Wymagania stanowią przecież podstawę do:

Podkreślamy: Jednakże praktyka pokazuje, że umieszczenie w umowie klauzuli o odbiorze kompletnej specyfikacji wymagań na wstępnym etapie projektu może generować szereg problemów, zarówno dla wykonawcy, jak i dla zamawiającego. Doświadczenia zrealizowanych projektów informatycznych wskazują, że:

Ważne: Wprowadzenie do umowy klauzuli o odbiorze kompletnej specyfikacji wymagań często prowadzi do nieporozumień i sporów prawnych, angażując dodatkowe koszty związane z obsługą prawną. Zmienność wymagań (punkt b) jest fundamentalnym wyzwaniem. Od czasu, gdy profesor Barry Boehm opublikował swoje przełomowe badania, ilustrujące gwałtowny wzrost kosztów wprowadzania zmian w późniejszych fazach projektu, zwolennicy rygorystycznego zamykania fazy wymagań na początku projektu zyskali silne argumenty. Niektórzy eksperci wierzyli, że doświadczenie analityków w projektach o podobnej tematyce oraz zastosowanie zaawansowanych metodyk projektowych pozwolą na zidentyfikowanie zdecydowanej większości wymagań już w fazie analizy.

Niemniej jednak: Takie podejście leżało u podstaw wielu tradycyjnych metodologii modelowania danych i modelowania obiektowego. Niemniej jednak, rzeczywistość projektów informatycznych często odbiega od idealnych założeń, co manifestuje się poprzez:

Dodatkowo: W polskich realiach, dodatkowym czynnikiem potęgującym opisane problemy (i oraz ii) jest wciąż relatywnie niska efektywność zespołów projektowych w stosowaniu zaawansowanych technik i metodyk projektowych. Niestety, wciąż obserwuje się niedostatek wiedzy teoretycznej i doświadczenia praktycznego w tej dziedzinie. Problem ten jest dodatkowo pogłębiany przez niechęć wielu firm do inwestowania w specjalistyczne narzędzia wspomagające proces projektowy oraz w kompleksowe szkolenia dla personelu IT.

W ostatnich latach: W ostatnich latach, coraz częściej wskazuje się na metodyki Agile jako skuteczne rozwiązanie problemu zmienności wymagań w projektach IT. Różnorodne techniki i metodologie, przynależące do nurtu Agile Development, efektywnie radzą sobie z dynamicznie zmieniającymi się wymaganiami, wykorzystując koncepcję „minimalistycznej strategii wymagań” (Minimalist Requirements Strategy), której autorem jest Ken Orr, ceniony konsultant i członek rady technologii biznesu Cuttera (Fellow of Cutter Business Technology Council).

Kluczowe założenie podejścia Agile jest przekonanie, że nie ma konieczności precyzyjnego planowania wszystkich detali systemu na podstawie obszernej i z góry ustalonej specyfikacji wymagań. Deweloperzy Agile argumentują, że bardziej efektywne jest szybkie rozpoczęcie budowy oprogramowania, bazując na aktualnie dostępnej wiedzy i informacjach. Czyli, w praktyce, chodzi o budowanie oprogramowania na podstawie minimalnego, ale wystarczającego zbioru wymagań.

Następnie: Następnie, po uzyskaniu informacji zwrotnej od realnych użytkowników systemu i zidentyfikowaniu nowych lub zmodyfikowanych wymagań, następuje proces przeprojektowania systemu, modyfikacji kodu, ponownych testów i udostępnienia użytkownikom kolejnej, ulepszonej wersji prototypu. W ten sposób, poprzez serię iteracji, użytkownicy i deweloperzy wspólnie odkrywają i doprecyzowują zarówno wymagania, jak i ostateczny kształt systemu. Co istotne, proces ten, jak pokazują doświadczenia, często przebiega w czasie krótszym niż w przypadku tradycyjnych, „ciężkich” metodyk projektowych.

Charakterystyka Agile: Najbardziej charakterystyczne w podejściu Agile jest jawne przyznanie, że proces budowy każdego systemu informatycznego jest w istocie procesem ciągłego uczenia się. Rozpoczynając projekt, zawsze wkraczamy na nieznany teren! To fundamentalnie odmienne podejście w porównaniu do tradycyjnego paradygmatu tworzenia systemów informatycznych, wzorowanego na modelu idealnej inżynierii budowlanej. Stary paradygmat opierał się na założeniu istnienia „niewzruszonych” faz inżynierskich, takich jak: analiza, planowanie, projektowanie, budowanie i testowanie, gdzie po etapie planowania zasadniczo nic nie powinno ulec zmianie. Niepewność była traktowana w tym paradygmacie jako oznaka braku profesjonalizmu i dlatego była zazwyczaj ukrywana lub marginalizowana.

W nowym paradygmacie – paradygmacie Agile – proces ciągłego uczenia się jest realizowany dzięki nieustannej, intensywnej komunikacji. Komunikacja ta zachodzi między deweloperami, między deweloperami a użytkownikami (klientami) oraz pomiędzy samymi użytkownikami. Komunikacja jest kluczem w Agile.

Alistair Cockburn, uznawany za jednego z guru nowoczesnych metod wytwarzania systemów informatycznych, celnie charakteryzuje ten proces, stwierdzając: „Robienie softwaru składa się tylko z ,ukonkretniania idei w ekonomicznym kontekście” (making software consists only of making ideas concrete in an economic context). Cockburn podkreśla, że:

W kontekście specyfikacji: Powstaje jednak kluczowe pytanie: czy minimalistyczna strategia wymagań rzeczywiście rozwiązuje problem specyfikacji wymagań? Czy eliminuje dylematy związane z dokumentowaniem wymagań, zatwierdzaniem specyfikacji przez zamawiającego oraz precyzyjnym szacowaniem zakresu projektu, jego pracochłonności, kosztów i czasu trwania? Aby znaleźć odpowiedzi na pytania o zmienność wymagań, konieczność ich dokumentowania, optymalny moment na to działanie oraz efektywne metody zatwierdzania, musimy wnikliwie zrozumieć, czym tak naprawdę są wymagania w kontekście projektów IT.

W poszukiwaniu definicji i klasyfikacji wymagań, warto odwołać się do koncepcji Karla Wiegersa (K. Wiegers, „Software Requirements”, Microsoft Press 2003), który wyróżnia cztery podstawowe typy wymagań:

Problem rozrostu: Problem niekontrolowanego rozrostu wymagań (tzw. scope creep), sygnalizowany w punkcie c) na początku artykułu, dotyczy przede wszystkim wymagań użytkownika i powiązanych z nimi wymagań funkcjonalnych. Badania przeprowadzone przez Standish Group (prezentowane m.in. przez Johna Favaro na konferencji XP2001 w Villasimius na Sardynii) oraz DuPont ujawniają zaskakujący fakt: znaczna część funkcjonalności systemów informatycznych jest rzadko używana lub całkowicie nieużywana. Według Standish Group:

Potwierdzenie: Studium DuPonta potwierdza te obserwacje, wskazując, że jedynie około 25% cech funkcjonalnych systemów jest rzeczywiście potrzebnych użytkownikom. Te dane sugerują, że większość oprogramowania jest „przerośnięta” – implementuje zbyt wiele zbędnych wymagań. Jak trafnie zauważył Chet Hendrickson, jeden z guru Extreme Programmingu: „Wewnątrz każdego systemu siedzi taki mały systemik, który próbuje się wydostać”. Z tego wynika paradoksalny wniosek: zbiór wymagań może być zbyt obszerny, a w trakcie projektu konieczne jest nie tylko jego rozwijanie, ale również aktywne redukowanie zbędnych funkcjonalności! Mniej znaczy więcej w wymaganiach.

Podsumowując: Podsumowując, analiza problematyki wymagań w projektach IT prowadzi do wniosku, że w ofertach i umowach projektowych znacznie istotniejsze jest precyzyjne zdefiniowanie elastycznego procesu zarządzania wymaganiami, który będzie efektywnie funkcjonował w trakcie całego projektu. Kluczowe staje się skupienie na iteracyjnym i adaptacyjnym podejściu do wymagań, a nie na sztywnym dokumencie specyfikacji, którego aktualność szybko staje się wątpliwa w dynamicznym środowisku projektów IT.