Narzędzia
- Wyszukiwarki
- Znajdź pracę
- Znajdź przetarg
- Ranking kantorów online
- Centrum webmastera
- Centrum Webmastera
- Newsy na Twoją stronę
KsiążkiNewsletterKsiążkiPOLECAMY |
Kierunek jakość. Jak unikać błędów w projekcie
Bardzo dobra i merytoryczna książka
Merytorycznie, bez lania wody. To się ceni, bo czasu zawsze mało :)
Świetna książka pisana przez Polską autorkę. Nie mamy tutaj do czynienia z tępym tłumaczeniem, które często zaburza postrzeganie treści.
Książka pisana przez osobę, która myśli po Polsku, zupełnie jak Wajda.
Merytorycznie dobra, przyjemni się czytać. Nic tylko polecić!
W tej książce jest zebranie wiele konceptów które pojawiały się w różnych innych na przestrzeni wielu ostatnich lat. Zbiera dobre praktyki i je w przystępny i krótki sposób opisuje. Jeżeli ktoś jest "początkujący" to może mu tutaj brakować bardziej szczegółowych wyjaśnień i przykładów, ale jeżeli ktoś ma już podstawy to ta książka pozwala sobie w głowie uporządkować wszystkie reguły wytwarzania oprogramowania wysokiej jakości.
Bardzo dobra książka, która opisuje szereg czynników wpływających na jakość projektu. Nie jest to książka czysto teoretyczna. Autorka w wielu miejscach dzieli się swoim wieloletnim doświadczeniem i obserwacjami. Zawarte tutaj porady nie tylko pomogą w tworzeniu lepszych jakościowo projektów, ale mogą również sprawić, że członkowie zespołów będą czerpać dużo większą satysfakcję ze swojej pracy. Bardzo się cieszę, że powstała książka o jakości, która bardzo mocno akcentuje te elementy, które są często pomijane lub bagatelizowane w branży IT. A są to elementy, które mają ogromny wpływ na końcowy efekt naszej pracy...
Książka, która powinna być obowiązkowa dla każdego, kto wchodzi do pracy w projekt IT. Od programisty, po testera, przez Product Ownera po Analityka zbierającego wymagania. Napisana jest prostym językiem, każdy się w niej odnajdzie. Bardzo dobrze się czyta.
Po przeczytaniu jej ma się ochotę wykrzyczeć - "czemu tego wcześniej nie zrozumiałem".
Osoby, które długo pracują w projektach IT - uporządkują swoją wiedzę lub (jak ja) zrozumieją, skąd się wzięły poważne problemy w pracy.
Lekka lektura która utwierdziła mnie w przekonaniu że programowanie jest tylko częścią wytwarzania oprogramowania.
I zachęciła do podejścia Test-driven development.
Książkę czyta się bardzo dobrze. Napisana jest przyjemnym w odbiorze językiem.
Poruszone jest wiele tematów ważnych dla jakości oprogramowania, ale również jakości "życia w IT". Podobały mi się użyte porównania i częsty sarkastyczno/żartobliwy ton.
Uważam, że ta lektura jest bardzo dobrym wstępem do rozmów o jakości w zespołach projektowych. Jest sporo rad, więc każdy znajdzie coś dla siebie.
Polecam! Ty i Twój zespół zyskacie na tym!
Bardzo dobra pozycja. Same konkrety, bez niepotrzebnego lania wody. Część tematów mogłaby być opisana trochę bardziej szczegółowo, ale i tak uważam, że jest to pozycja, która otwiera oczy na wiele aspektów procesu wytwarzania oprogramowania.
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.
Świetna książka, która pomogła mi rozpocząć usprawnianie swojej pracy, mimo iż (jeszcze), nie pracuję IT.
Gratulacje dla autorki - napisanie książki to niełatwa sprawa więc ogromny szacunek się należy.
Zacznijmy od pozytywów. Książka napisana jest lekkim językiem i bardzo dobrze się ją czyta. Dla mnie jest to język blogowy, czyli dostępny dla każdego, wiedza techniczna nie jest wymagana aby go zrozumieć. Poszczególne podrozdziały / sekcje nie sąze sobą powiązane, więc jeśli otworzysz książkę na dowolnej stronie możesz zacząć czytać bez problemu, bo rozdziały nie odnoszą się do siebie w żaden sposób. Jest to i zaleta i wada. Książka porusza wiele zagadnień dosyć luźno powiązanych z jakością oprogramowania (tak jak np. pogoda i samopoczucie zespołu ma też wpływ na jakość oprogramowania przez nich wytwarzanego), aczkolwiek w jakimś stopniu na pewno dla niej ważnych.
Książka jest zbiorem lekkich i ciekawych anegdot i historii z życia autorki (i nie tylko). Przypomniały mi się trochę książki "The Mythical Man-Month: Essays on Software Engineering" i "Joel on Software" - chociaż nie porównuję ich do tej pozycji.
Bardzo fajnym plusem są mikroporady po każdej sekcji np. "Zgłoś się do poprowadzenia kolejnego spotkania. Poszukaj ciekawych scenariuszy i zastanów się, jaki efekt chcesz osiągnąć." - to jest dla mnie najbardziej pozytywna rzecz w książce.
Co mnie mocno zdziwiło już na początku, to brak jakiegokolwiek wstępu. Nie wiadomo o czym jest książka, po co ona jest, jaką wiedzę ma przekazać i dla kogo jest. Ciężko więc jednoznacznie ocenić czy książka spełniła obietnicę - bo żadnej nie daje.
Bardzo dużo tematów poruszonych (to na plus), ale wszystkie bardzo bardzo płytko (bezpieczeństwo to tylko jedna strona - ojoj). Jak dla mnie zbyt mało szczegółów, zbyt mało praktycznych przykładów i porad.
Według mnie czytelnik tej książki nie zdobędzie praktycznej wiedzy jak dbać o jakość w projektach IT, bo brakuje trochę struktury. To co zadziałało, albo nie dla autorki niekoniecznie ma przełożenie na 90% innych projektów. Czuję też, że brakuje tutaj doświadczenia przy pracy w dużych projektach np. 500 osób i więcej. Tutaj skala problemów jest zupełnie inna i dużo porad i anegdot z książki nie sprawdzi się np. w ogoromnych projektach specjalizacja (nie generalizacja) to w zasadzie jedyna opcja. Nie ma wielu inżynierów, którzy są w stanie ogarnąć w ekspercki sposób wszystkie elementy np. samochodu (tak, duże projekty IT są jak konstrukcje samochodów albo samolotów). Tutaj każdy zna się świetnie na swojej działce np. reflektory, klamki, kierownice, itp.
Wiele anegdot i wniosków wysnuwanych przez autorkę jest kontrowersyjnych - forma książki nie pozwala na łatwą polemikę. Są to osobiste opinie autorki, ale czytelnik może je uznawać za pewniki (np. Git Blame - Git tego nie wymyślił - funkcja "annotate" istniała już w CVS - rok 1986, a pewnie jeszcze wcześniej w starszych systemach wersjonowania.) Zapisałem wiele takich uwag, ale opisanie ich wszystkich byłoby trochę nudne.
Na koniec: materiał w książce ma ogromny potencjał. Doświadczenia autorki nie sposób kwestionować. Czego mi brakuje najbardziej, to wstępu i bardziej szczegółowego podejścia do aspektu jakości oprogramowania. Tak, książka miałaby wtedy pewnie 700 stron, ale byłaby petardą.
|
Twoje narzędziaZakupy i usługiOferty pracyPodaj szczegóły pracy jakiej szukasz (zawód, miasto, stanowisko, itp.) lub wybierz branżę. |
| O serwisie . Dla prasy . Regulamin . Polityka prywatności . Reklama . Kontakt . Uwagi i błędy |
Copyright © Kasat Sp. z o.o.
,
Konrad Chmielecki
,
Przemek