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.
8 komentarzy:
Bardzo przyjemnie czyta się Twoje teksty.
Jako programista, który zna lekkie metodyki głównie z teorii a chciałby je poznać w praktyce - twoje przemyślenia są dla mnie bardzo cenne.
Pozdrawiam i czekam na więcej :)
Zgadzam się w szczególności z potrzebą modelowania. To zresztą dotyczy jak dla mnie nawet bardziej architektury systemu na wyższym poziomie niż ten potrzebny w testach jednostkowych.
I zgadza się... wcale nie chodzi o to, żeby spędzić miesiąc w twórczym szale rysując diagramy, projektując wszystko do przodu na 2 lata. Niemniej wielokrotnie jeden prosty rysunek systemu jaki jest moim celem naprowadzał mnie właściwe tory i przypominał o skupieniu się w projekcie na rzeczach "ważnych".
Polecam zarezerwowanie sobie miejsca na ścianie lub tablicy małego miejsca na taką jakże rozrzutną dokumentację projektową :-)
bardzo ciekawy blog, wpadasz w moje rssy :)
Czy ktoś z was ma doświadczenia związane np z utrzymaniem kodu wytworzonego metodyką XP? Bardzo ciekawi mnie jak wygląda strona inżynierska takiego kodu, który powstaje zazwyczaj poprzez analizę wycinków funkcjonalnych, etc.
Czy czasem np powstaje kod który w miarę szybko odzwierciedla potrzeby klienta ale zamyka dalsze drogi rozwoju... ze względu na klarownej architektury.
pluscms, dziękuje za pytania
Doświadczenie mam takie że owszem częściej spotykamy zmiany, ale po pierwsze nie mamy oporów technicznych ani społecznych przed tymi zmianami, ani nie są one dewastujące, a w efekcie prowadzą dobrego produktu. Z drugiej strony zaś mam doświadczenie produkowania dokumentów i przemyślanych szczegółowych opisów technicznych i albo implementacja ich powoduje ze odkrywam rzeczy, których nie bylem w stanie przewidziec i mimo wszystko muszę zmieniać, albo klient przychodzi i mówi ze coś inaczej ma jednak być.
Poza tym podkreślam jeszcze raz, analiza wycinków nie znaczy ze nie analizuje całości, tylko analiza całości jest odpowiednio bardzo gruboziarnista (odpowiednio do momentu w którym następuje), i następuje tylko wtedy, gdy tego potrzebuje: przed rozpoczęciem prac, iteracja zerowa, przed każdym releasem, itp. Ale troska Twoja jest jak najbardziej uzasadniona, jest to duże ryzyko.
Co do drugiego pytania to odpowiedz jest że to różnie pewnie to bywa :). Mówię za siebie, mi się zwykle udaje zachować architekturę. Zależy to pewnie w głównej mierze od umiejętności programistów i ich wrażliwości na duplikacje i inne "smells" w kodzie oraz tego czy przeprowadza potrzebne refaktoryzacje czy nie. Mam za to też kontr-przypadek, w którym coś przewidziane na początku na rozwój i rozszerzalność i generyczność (itp) okazało owszem klarowne w zamysłach, ale po implementacji i pokazaniu tego klientowi i następujących zmianach klarowność poszła w las a efekt funkcjonalny i tak był mierny.
coś przewidziane na początku na rozwój i rozszerzalność i generyczność (itp) okazało owszem klarowne w zamysłach, ale po implementacji i pokazaniu tego klientowi i następujących zmianach klarowność poszła w las a efekt funkcjonalny i tak był mierny.
No ale to od początku było pomieszanie skrajnego overengineeringu i NIH - jeśli mamy ten sam projekt na myśli. Zresztą klarowne w zamysłach też nie było chyba że uważasz kilka interfejsów posklejanych singletonami i dziwacznym service locatorem za klarowne.
partyzant, nie wiem o którym projekcie Ty mówisz, ja mówię o takim który już jest jeszcze w trakcie dewelopmentu, ale częściowo wdrożony i używany przez klienta produkcyjnie, jeśli mamy zacząć mówić konkretne nazwy to na priva proszę
partyzant, już wiem o którym radosnym projekcie mówisz :), tak to był skrajny przypadek i rzeczywiście jest co wspominać, zgadzam się z Tobą, tutaj mówiłem o jeszcze innym ;), ale dość tego chatowania na blogu ...
Prześlij komentarz