Główną zasadą agile jest uznanie wypieranej przez procesy sekwencyjne prawdy, że wymagania zmieniają się, a ich trafne i precyzyjne określenie z góry jest zwykle niemożliwe. Role, artefakty i tajemnicze rytuały agile to skuteczne sposoby narzucenia projektom staranności i dyscypliny w traktowaniu wymagań. Procesy sekwencyjne, deklarujące na papierze konieczność inżynierii wymagań, w praktyce stosują niezliczone sposoby omijania tej zasady.

Agile to pragmatyczny, dobrze działający proces wymuszający przestrzeganie w projektach szeregu mądrych zasad i dobrych praktyk inżynierii oprogramowania, w tym inżynierii wymagań. Rytuały i nowomowa agile, na pozór niepotrzebne i efekciarskie, odgrywają ważną rolę psychologiczną i społeczną w narzucaniu biznesowi i programistom zdrowej dyscypliny.

To świetnie, że popularne metody agile narzucają stosowanie dobrych praktyk inżynierii wymagań. To źle, że powszechnie przypisuje się skuteczność agile czemu innemu – rzekomej rewolucyjności, tajemniczemu duchowi zespołowemu i innym mistycyzmom, co powoduje, że wielu wyznawców i praktyków agile nie korzysta z bogatej oferty metod i technik inżynierii wymagań, które są rzekomo przestarzałe i tradycyjne.

Mylona z analizą biznesową

Analiza biznesowa to wcześniejszy etap inżynierii wymagań. Trzeba najpierw dobrze zrozumieć procesy biznesowe, żeby móc zaproponować ich ulepszenie czy wsparcie poprzez wdrożenie systemu informatycznego, dla którego potem trzeba jeszcze określić dokładniejsze wymagania.

Analiza biznesowa jest wykonywana przez osoby znające dobrze biznes firmy – na wyższych stanowiskach. To powoduje, że analitycy tworzą własny, wyższy świat, do którego aspirują wszyscy, mający na wizytówkach słowo „analityk”. Któż chciałby zostać inżynierem wymagań, skoro w roli analityka biznesowego będzie rozmawiać jak równy z równym z dyrektorami?

Efekt – dziura ozonowa. Produkty analizy biznesowej wpadają wprost do rąk programistów i mają być realizowane. Całości nie obejmuje nikt, bo nie ma inżynierów wymagań. Czasem przewinie się może ktoś z tytułem analityka systemowego, ale zwykle aspiruje raczej do tego, by jak najszybciej stać się analitykiem biznesowym, niż aby realizować nieznany zawód inżyniera wymagań. Kółko się zamyka.

W ogóle nie jest wykonywana

W psychologicznym sensie inżynieria wymagań dzieje się zawsze: nie ma możliwości działania bez wizji celu. Jednak inżynieria wymagań jako zdyscyplinowania, systematyczna działalność inżynierska jest w IT rzadkością. Albo jest tylko na górze – wówczas wymagania wysokiego rzędu, stworzone przez analizę biznesową, wpadają – nieprecyzyjne, pełne braków – wprost do rąk programistów, albo uprawia się ją jako dyscyplinę informatyczną: BDD, TDD, UML… te nazwy są modne.

Konkluzja

Kiedy inżynieria wymagań – zarówno nazwa, jak i jej procesy – wyjdzie z ukrycia, wtedy zacznie być uprawiana lepiej, skuteczniej, na czym skorzystają wszyscy. Ma wówczas szansę nastąpić skokowy wzrost wydajności IT.