Aby nie wylecieć na tej minie stawiam sobie takie pytanie:
Które aspekty inżynierii wymagań nie są wspierane przez XP?
Rozwinę trochę to pytanie. Które z aspektów inżynierii wymagań nie są bezpośrednio wspierane lub są prawie pomijane przez praktyki XP lub inne agile'owe praktyki? Moim zdaniem poważnie pominięte lub przynajmniej potraktowane po macoszemu są takie aspekty jak
- modelowanie
- analiza jakości wymagań: kompletność, spójność
- zarządzanie: duże ilości, śledzenie
Tak wiem, wiem, modelowanie jest evil, ale to nieprawda, bo nie jest. Na początku od razu dodam, że nie jest prawdą, że XP nie wspiera w ogóle modelowania, gdyż dobrze wykonywane TDD właśnie zaczyna się od krótkiego modelowania. Zaczynam często nie od testu jednostkowego tylko od kartki i ołówka, potem test, potem implementacja. Ale problem w tym, że takie lokalne modelowanie często mi nie starczało jednak. Rzeczywistość pokazała mi boleśnie, że w wielu przypadkach bez zastosowania "niefunkcjonalnej iteracji zerowej" i bez ogólniejszych modeli zapędzę się sam w kozi róg. I tutaj jest dość ciekawy teren. Z rozmów ze Scottem Amblerem wiem np. że większość aktywistów z listy extremeprogramming@yahoogroups (skądinąd rewelacyjnej listy dyskusyjnej) zapytana na liście prost o modelowanie nie przyzna się do tego, ale tak na prawdę go robią, tylko taki trochę temat tabu się zrobił. I to niedobrze, bo to wprowadza zamęt dla nowooświeconych i osoby takie jak ja muszą to odkrywać na własnej skórze. I potrzeba było lat bym przypomniał sobie czytane kiedyś na stołówce akademickiej artykuły właśnie rzeczonego Scotta Amblera na temat modelowania robionego w sposób lekki.
Analiza jakości wymagań: kompletność, spójność
Nie doszukałem się w praktykach za bardzo elementów, które miałyby traktować na temat kompletności lub spójności wymagań. Wspomniana w poprzednim akapicie iteracja zerowa może pomóc w sprawie spójności, ale też tylko trochę. Techniki z rodziny agile mocno skupiają się na wizualizacji i transparencji procesu. To dotyczy również wymagań (spisywania kart, planowania iteracji, itp), biznes jest angażowany we wszystkie etapy. Ma to ma właśnie na celu sprawienie, by mieć najwięcej szans, by owe niespójności i braki wychwycić. Jednak znów mam doświadczenie takie, że nie bardzo to tak chce działać. Bez działań explicite adresujących te aspekty bardzo łatwo tutaj o problem, który wychodzi potem w sposób bardzo nieprzyjemny dla zespołu.
Zarządzanie: duże ilości, śledzenie
W klasycznej inżynierii wymagań zarządzanie wymaganiami składa się z różnych elementów, na przykład wsparcia dla zarządzania dużymi ilościami wymagań, ewolucji wymagań wymiarze czasowym i wymiarze wersji produktów, śledzenia owych zmian. XP z definicji jest wyjątkowo dobrze dostosowane do wspierania zmian w wymaganiach w czasie. Jednak nie tak dobrze już wygląda kwestia zarządzania dużymi ilościami wymagań, lub śledzenia ich zmian w czasie i pomiędzy rodzinami produktów. O ile to ostatnie jeszcze mnie nie dotknęło, o tyle zarządzanie poważnymi ilościami kart wymagań (User Stories) i ich zmianami w czasie już miałem okazję próbować ogarnąć. Nie jest już tak trywialnym zadaniem jak parę kart w książce Becka. Oczywiście wszystko to jest względnie niepotrzebne jak pracujemy na zasadzie time & materials, ale o tym już wspominałem i nie będę się powtarzał, moi klienci tak nie pracują, i zdziwiłbym się bardzo gdybym okazał sie w tym osamotniony.
Podsumowując minę trzecią. Wykrywanie jej polega na zadaniu sobie na początku projektu tego pytania po pierwsze, które elementy inżynierii wymagań pokrywam swoim procesem, w jakim stopniu, i jakie ryzyko wnoszą do mojego projektu te poszczególne aspekty. Pytania te są dobrym materiałem na porządną retrospekcję releasową na przykład. Następnie na podstawie odpowiedzi na te pytania należy poszukać ewentualnych akcji (ustaleń, praktyk, ...) minimalizujących dane ryzyko, które decydujemy się zmniejszyć. To już jest klasyczne zarządzanie ryzykiem. Ćwiczenie to należy następnie powtórzyć przynajmniej raz na release.
Przepraszam wszystkich stałych czytelników (wiem już, że jednego mam, bo się upomniał o nowy odcinek) za dłuższą przerwę ale c'est la vie sami rozumiecie jak to jest z czasem w dzisiejszych czasach ;). Ale doping na pewno mi pomoże zebrać się szybciej do następnego odcinka, szczególnie że ten nie okazał się za długi.
