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

By 17 marca 2015ITlogy
Wpis-Header

Jakiś czas temu otrzymaliśmy prośbę o recenzję książki Inżynieria wymagań w praktyce, autorstwa Bartosza Chrabskiego oraz Karoliny Zmitrowicz, a wydanej nakładem wydawnictwa PWN.

Temat ten wydał mi się bardzo interesujący – z jednej strony jako dawny freelancer oraz starszy programista często miałem do czynienia z definicją wymagań, musiałem pracować z klientem nad ich doprecyzowaniem i formalizacją; z drugiej strony nigdy nie czytałem fachowej literatury w temacie, działałem bardziej wg intuicji, podpatrzonych wzorców i zdrowego rozsądku. Tak więc dostałem książkę, znalazłem trochę czasu i pełen oczekiwań (na magiczną recepturę współpracy z klientem ;) ) przystąpiłem do lektury.

Początek jest powiedziałbym nawet świetny – autorzy podejmują się próby określenia pewnych pojęć, sięgając do różnych źródeł i odwołując się do przyjętych konwencji. Pod koniec pierwszego rozdziału pojawia się jednak dzwonek ostrzegawczy – z rozpędu mamy próbę przemianowania analityka (biznesowego i systemowego) na inżyniera wymagań. Niestety, nawet największy portal pracy na naszym rynku nie był w stanie znaleźć ofert pracy dla takiej osoby. Nie mam oczywiście nic przeciwko definiowaniu pojęć, i także uważam, że ‘analityk’ jest niejednoznaczne, ale tworzenie nowego wyrażenia, które nie istniało za bardzo w praktyce wydaje mi się przesadą ;)

To jednak nic w porównaniu z tym, co działo się przez kolejne kilka rozdziałów. Pomysł (i wrażenie po przejrzeniu spisu treści) był rewelacyjny – przedstawić procesy inżynierii wymagań w kontekście różnych metodyk prowadzenia projektów. Realizacja jednak woła o pomstę – znajdziemy tam całe rozdziały o metodykach, w których nie ma nawet słowa ‘wymaganie’ czy ‘analiza’! Do tego ma się nieodparte wrażenie, że ktoś zrobił autorom dużą krzywdę – cokolwiek by to nie było, zrzucił winę na ‘Agile’ i metodyki zwinne. Czwarty rozdział wręcz ocieka niechęcią do tego rodzaju podejścia i momentami – co z przykrością muszę powiedzieć – jawną nieprawdą (np. jest powiedziane, że tylko metodyka preferowana przez autorów zakłada dopasowanie jej do projektu, przy czym jest to podstawa zarówno metodyk zwinnych (cytując za manifestem: “Individuals and interactions over processes and tools”), jak i ‘tradycyjnych’ (np. PRINCE2 – koncept który w orginale jest opisywany jako ‘tailoring to project environment’ i podkreślanie, że jest to zbiór dobrych praktyk, a nie ścisłych wytycznych, które przewija się przez cały podręcznik). Z ciekawostek w tym miejscu – książka przedrukowuje manifest Agile nie zachowując warunków rozpowszechniania (brak wzmianki o autorach i samej deklaracji o rozpowszechnianiu, która jest warunkiem zgody – patrz http://www.agilemanifesto.org/iso/pl/).

Jeśli czytelnik dotrwa do kolejnych rodziałów, jest już dużo lepiej – nadal są stronnicze i co chwilę przeplecione przytykiem do metodyk zwinnych, ale znacznie więcej w nich konkretnej wiedzy, przykładów i wartościowej teorii, nie kłuje to już tak w oczy.

Po przeczytaniu książki byłem szczerze zawiedziony. Z jednej strony wydaje mi się, że wyniosłem wiele, pozwoliła mi dostrzec kilka problemów, których mogłem potencjalnie uniknąć w przeszłości, uporządkować wiedzę i podejście. Z drugiej, natarczywa promocja ‘jedynej słusznej drogi’ i mijanie się z prawdą (oczywiście nie jestem w stanie dowieść, że celowe, ale w przeciwnym razie graniczące ze skrajną ignorancją) naprawdę psuje cały efekt. Recenzja ta faktycznie skupia się bardziej na negatywnych aspektach tej książki – można odnieść mylne wrażenie, że jest ona beznadziejna. Nie jest. To, co psuje całość, stanowi zaledwie ok. 10% objętości. Ale 90% to wiedza, która jest przedstawiana w sposób generalnie składny, uporządkowany i czytelny, nie ma jednak nic, co by zachwyciło lub było powodem tylko dla którego warto kupić tą publikację. Niestety te 10% aż krzyczy, błyszczy i mruga komunikatem ‘nie czytaj mnie’. Dlatego polecam je całkowicie pominąć, w zamian dostaniecie naprawdę solidną publikację szeroko i sensownie opisującą temat inżynierii wymagań.

Podsumowując, ta książka to naprawdę cenne źródło wiedzy. Wyrwijcie rozdział 4, a otrzymacie naprawdę sensowną literaturę. Wprawdzie nie z kategorii tych, które trzymam zawsze na biurku, ale miejsce w biblioteczce zdecydowanie się dla niej znajdzie. Na plus na pewno wiedza i doświadczenie autorów, fakt, że jest to rodzima publikacja (nie mamy dziwolągów powstałych po tłumaczeniu obcego dzieła), na minus nieodrobienie ‘pracy domowej’ (błędy merytoryczne w niektórych obszarach, stosowanie archaicznych i/lub nieużywanych określeń), stronniczość zakrawająca o kpinę (produkty pracodawcy autorów są – moim zdaniem niesłusznie i natarczywie – gloryfikowane na każdym kroku, włącznie z tymi, które zostały wycofane) nienajwyższych lotów redakcja (mnie rzuciło się w oczy kilkanaście błędów językowych, jeszcze więcej interpunkcyjnych, jako że nie czytałem specyficznie pod tym kątem a i sam często popełniam błędy, jest ich pewnie więcej). Mając możliwość przeczytania tej książki gorąco ją polecam (poza 4 rozdziałem, psuje całe wrażenie), natomiast nie jest to pozycja, po którą warto wybiec już teraz do księgarni.

  •  
  •  
  •  
  •  
  •