Recenzja książki — Inżynieria Wymagań w praktyce

By 17 March 2015 ITlogy

Jak­iś czas temu otrzy­mal­iśmy prośbę o recen­zję książ­ki Inżynieria wyma­gań w prak­tyce, autorstwa Bar­tosza Chrab­skiego oraz Karoliny Zmitrow­icz, a wydanej nakła­dem wydawnict­wa PWN.

Tem­at ten wydał mi się bard­zo intere­su­ją­cy – z jed­nej strony jako dawny free­lancer oraz starszy pro­gramista częs­to miałem do czynienia z definicją wyma­gań, musi­ałem pra­cow­ać z klien­tem nad ich dopre­cy­zowaniem i for­mal­iza­cją; z drugiej strony nigdy nie czy­tałem fachowej lit­er­atu­ry w tema­cie, dzi­ałałem bardziej wg intu­icji, pod­pa­tr­zonych wzor­ców i zdrowego rozsąd­ku. Tak więc dostałem książkę, znalazłem trochę cza­su i pełen oczeki­wań (na mag­iczną recep­turę współpra­cy z klien­tem ;) ) przys­tąpiłem do lektury.

Początek jest powiedzi­ałbym nawet świet­ny – autorzy pode­j­mu­ją się pró­by określe­nia pewnych pojęć, się­ga­jąc do różnych źródeł i odwołu­jąc się do przyję­tych kon­wencji. Pod koniec pier­wszego rozdzi­ału pojaw­ia się jed­nak dzwonek ostrze­gaw­czy – z rozpę­du mamy próbę przemi­anowa­nia anal­i­ty­ka (biz­ne­sowego i sys­te­mowego) na inżyniera wyma­gań. Nieste­ty, nawet najwięk­szy por­tal pra­cy na naszym rynku nie był w stanie znaleźć ofert pra­cy dla takiej oso­by. Nie mam oczy­wiś­cie nic prze­ci­wko defin­iowa­niu pojęć, i także uważam, że ‘anal­i­tyk’ jest niejed­noz­naczne, ale tworze­nie nowego wyraże­nia, które nie ist­ni­ało za bard­zo w prak­tyce wyda­je mi się przesadą ;)

To jed­nak nic w porów­na­niu z tym, co dzi­ało się przez kole­jne kil­ka rozdzi­ałów. Pomysł (i wraże­nie po prze­jrze­niu spisu treś­ci) był rewela­cyjny – przed­staw­ić pro­cesy inżynierii wyma­gań w kon­tekś­cie różnych metodyk prowadzenia pro­jek­tów. Real­iza­c­ja jed­nak woła o pom­stę – zna­jdziemy tam całe rozdzi­ały o metodykach, w których nie ma nawet słowa ‘wyma­ganie’ czy ‘anal­iza’! Do tego ma się nieod­parte wraże­nie, że ktoś zro­bił autorom dużą krzy­wdę – cokol­wiek by to nie było, zrzu­cił winę na ‘Agile’ i metody­ki zwinne. Czwarty rozdzi­ał wręcz ocieka niechę­cią do tego rodza­ju pode­jś­cia i momen­ta­mi – co z przykroś­cią muszę powiedzieć – jawną nieprawdą (np. jest powiedziane, że tylko metody­ka prefer­owana przez autorów zakła­da dopa­sowanie jej do pro­jek­tu, przy czym jest to pod­stawa zarówno metodyk zwin­nych (cytu­jąc za man­i­festem: “Indi­vid­u­als and inter­ac­tions over process­es and tools”), jak i ‘trady­cyjnych’ (np. PRINCE2 – kon­cept który w orginale jest opisy­wany jako ‘tai­lor­ing to project envi­ron­ment’ i pod­kreślanie, że jest to zbiór dobrych prak­tyk, a nie ścisłych wyty­cznych, które przewi­ja się przez cały podręcznik). Z cieka­wostek w tym miejs­cu – książ­ka prze­drukowu­je man­i­fest Agile nie zachowu­jąc warunk­ów rozpowszech­ni­a­nia (brak wzmi­an­ki o autorach i samej deklaracji o rozpowszech­ni­a­n­iu, która jest warunk­iem zgody – patrz http://www.agilemanifesto.org/iso/pl/).

Jeśli czytel­nik dotr­wa do kole­jnych rodzi­ałów, jest już dużo lep­iej – nadal są stron­nicze i co chwilę przeple­cione przy­tykiem do metodyk zwin­nych, ale znacznie więcej w nich konkret­nej wiedzy, przykładów i wartoś­ciowej teorii, nie kłu­je to już tak w oczy.

Po przeczy­ta­niu książ­ki byłem szcz­erze zaw­iedziony. Z jed­nej strony wyda­je mi się, że wyniosłem wiele, poz­woliła mi dostrzec kil­ka prob­lemów, których mogłem potenc­jal­nie uniknąć w przeszłoś­ci, uporząd­kować wiedzę i pode­jś­cie. Z drugiej, natar­czy­wa pro­moc­ja ‘jedynej słusznej dro­gi’ i mijanie się z prawdą (oczy­wiś­cie nie jestem w stanie dowieść, że celowe, ale w prze­ci­wnym razie graniczące ze skra­jną igno­rancją) naprawdę psu­je cały efekt. Recen­z­ja ta fak­ty­cznie sku­pia się bardziej na negaty­wnych aspek­tach tej książ­ki – moż­na odnieść mylne wraże­nie, że jest ona bez­nadziej­na. Nie jest. To, co psu­je całość, stanowi zaled­wie ok. 10% obję­toś­ci. Ale 90% to wiedza, która jest przed­staw­iana w sposób gen­er­al­nie skład­ny, uporząd­kowany i czytel­ny, nie ma jed­nak nic, co by zach­wyciło lub było powo­dem tylko dla którego warto kupić tą pub­likację. Nieste­ty te 10% aż krzy­czy, błyszczy i mru­ga komu­nikatem ‘nie czy­taj mnie’. Dlat­ego pole­cam je całkowicie pom­inąć, w zami­an dostaniecie naprawdę solid­ną pub­likację sze­roko i sen­sown­ie opisu­jącą tem­at inżynierii wymagań.

Pod­sumowu­jąc, ta książ­ka to naprawdę cenne źródło wiedzy. Wyr­wi­j­cie rozdzi­ał 4, a otrzy­ma­cie naprawdę sen­sowną lit­er­aturę. Wprawdzie nie z kat­e­gorii tych, które trzy­mam zawsze na biurku, ale miejsce w bib­lioteczce zde­cy­dowanie się dla niej zna­jdzie. Na plus na pewno wiedza i doświad­cze­nie autorów, fakt, że jest to rodz­i­ma pub­likac­ja (nie mamy dzi­wolągów pow­stałych po tłu­macze­niu obcego dzieła), na minus nieo­dro­bi­e­nie ‘pra­cy domowej’ (błędy mery­to­ryczne w niek­tórych obszarach, stosowanie archaicznych i/lub nieuży­wanych określeń), stron­nic­zość zakrawa­ją­ca o kpinę (pro­duk­ty pra­co­daw­cy autorów są – moim zdaniem niesłusznie i natar­czy­wie – glo­ry­fikowane na każdym kroku, włącznie z tymi, które zostały wyco­fane) nien­ajwyższych lotów redakc­ja (mnie rzu­ciło się w oczy kilka­naś­cie błędów językowych, jeszcze więcej inter­punkcyjnych, jako że nie czy­tałem specy­ficznie pod tym kątem a i sam częs­to popeł­ni­am błędy, jest ich pewnie więcej). Mając możli­wość przeczy­ta­nia tej książ­ki gorą­co ją pole­cam (poza 4 rozdzi­ałem, psu­je całe wraże­nie), nato­mi­ast nie jest to pozy­c­ja, po którą warto wybiec już ter­az do księgarni.