Dlaczego warto przeczytać książkę?

Co mnie urzekło w książce Oli to fakt, że jest ona praktycznie dla każdego. Programista czy programistka na poziomie junior znajdzie tam wskazówki, które od razu usprawnią ich pracę. Podobnie ktoś z dłuższym stażem oraz osoba odpowiedzialna za architekturę. Znajdziesz tam również użyteczne dla siebie porady jeśli jesteś testerką/testerem albo kierownikiem projektu.

Można rzec, że jest to katalog albo „książka kucharska” z przepisami ukierunkowanymi na polepszenie jakości Twojego produktu. Czy zastosujesz albo zrozumiesz wszystkie? Nie. Ale właśnie taka jest rola pozycji dających przegląd całego spektrum możliwości w tematach typu: „co może pójść nie tak”, „dlaczego poszło nie tak” i „jak zapewnić, żeby nie poszło nie tak”. Polecam!

Jakość niejedno ma imię, a Ola udowadnia to nie tylko stronami tej książki, ale każdą z wielu swoich inicjatyw, pokazującą jej wizję jakości.

To nie kolejna ksiażka o technologiach, frameworkach czy bibliotekach, które w cudowny sposób zapewnią jakość w Twoim projekcie. To dyskusja o całej złożoności czynników, które składają się na jakość. Począwszy od dobrych praktyk w dbaniu o jakość kodu, sposoby na efektywną komunikację w zespole, zbieranie wymagań, po analizę naszych ludzkich słabości, będących zagrożeniem dla jakości projektu.

A każdy rozdział skłania Cię do brania odpowiedzialności poprzez wskazówki co do konkretnych kroków, które możesz podjąć w stronę jakości.

Początek książki wydaje się depresyjny, bowiem przeglądamy się w lustrze własnych problemów projektowych i organizacyjnych, jak to, że jesteśmy zamknięci w jednej technologii czy, że otaczają nas wszechobecni maruderzy. Jednak z każdą stroną zaczyna być jasne, że te opisy rzeczywistości mają nam pokazać, iż zmiana na lepsze jest jednak możliwa.

I taką zmianę Autorka nam wskazuje. Nie jest to jednak "najlepsza praktyka" do zastosowana wszędzie, a po prostu praktyka, która może sprawdzić się także u Ciebie. W kolejnych rozdziałach poczytać możemy o wartości komunikacji, o pracy zespołowej i uczeniu się na własnych błędach. Nie są to jednak komunały, a ciekawe praktyki podbite własnymi doświadczeniami. 

Książka nie jest zamknięciem pewnego etapu, ale raczej wprowadzeniem do dalszych rozmów o "jakości", które mają prowadzić do jej realnego osiągnięcia w każdym z projektów.

Pełna recenzja na stronie testerzy.pl

Bardzo dobra książka omawiająca różne, także te mniej oczywiste aspekty jakości w projektach informatycznych. Super fajne w niej jest to, że zaczyna od miękkich tematów: komunikacji i współpracy w zespole, czyli od czegoś, co na pierwszy rzut oka nawet nie stało obok tak "twardego" tematu jakim jest jakość w projekcie, a jednak bez tego trudno będzie wdrożyć jakąkolwiek jakość.

Jako dość doświadczona osoba odkryłem kilka smaczków, sporo rzeczy było dla mnie znanych, ale fajnie je sobie do jakiś czas odświeżać. Bardzo fajnym rozdziałem, w którym było dla mnie dużo nowej wiedzy był "Nauka na cudzych błędach", bo o wielu trochę starszych niż wpadka GitLaba nie wiedziałem :)

Wydaje mi się, że książka super sprawdzi się dla programistów dopiero uświadamiających sobie, że istnieje takie coś jak jakość i że może faktycznie warto nad tym obszarem się trochę bardziej pochylić. A z kolei dla osób z otoczenia zespołu programistycznego (Product Ownerów, Scrum Masterów czy nawet mniej technicznych właścicieli firm, które mają jakiś dział oprogramowania) to bardzo fajne wprowadzenie w tematykę dbania o jakość, żeby potem o naszym produkcie i produkcyjnej wpadce nie pisały ogólnokrajowe media.