Książka zaczyna się przydługim i nudnym wstępem, który ciągnie się przez ok. 100 stron i zawiera wypunktowane, sucho omówione punkty. Dalsza część lektury jednak bazuje na doświadczeniach autorów, które są barwnie omówione i opatrzone przykładami.

Książka omawia metodyki zwinne projektowania (agile), a składa się z omówienia różnych podejść Scrum, XP oraz Lean i Kanban. Treść jest dosyć zwarta, obrazowa i życiowa.

Autorzy odnoszą się dosyć krytycznie do programowania kaskadowego, polegającego na uprzednim planowaniu wszystkiego i zawieraniu w dokumentacji, na rzecz programowania zwinnego, gdzie decyzje odnośnie projektu podejmuje się w ostatnim sensownym momencie. Ma to oczywiście swoje wady i zalety, które są często pomijane, ponieważ po podpisaniu kontraktu często okazuje się, że klienci chcą dodawać nowe funkcjonalności lub zmieniać koncepcje. W książce brakuje mi rozwiązania tego problemu. Autorzy opisują nowe wymagania jako wartości i choć omawiają budżetowanie projektów, nie wspominają o sposobach rozwiązywania takich sytuacji.

Książka zwraca uwagę na dość istotne problemy – traktowania programistów jako maszynek do klepania kodu. Lektura pokazuje, jak stworzyć atmosferę do tego, aby zespoły same zaczęły myśleć i organizować się.

Autorzy zwracają uwagę na wiele istotnych kwestii, jak sposoby testowania oprogramowania. W przypadku XP szczególne miejsce zajmuje tu programowanie w parach, codzienne spotkania, iteracyjny sposób produkcji oprogramowania ze spotkaniami odbywającymi się co 2-4 tygodni. Odradzam jednak tę lekturę freelancerom, ponieważ głównym zadaniem książki było skupienie się na zarządzaniu zespołem.

Po przeczytaniu pozycji miałem wrażenie, że autorzy postrzegają programistów jako typowych introwertyków, zamkniętych w sobie i nie potrafiących się komunikować ze światem. Ciekawie omówiono kwestię przyrostu problemów w zespole związanych ze złą komunikacją i bezmyślnością, która może świadczyć o tym, że duże zespoły są w stanie wyprodukować niewiele więcej kodu niż freelancer.

Uzasadniając swój wniosek, mogę powiedzieć, że wokół programistów, którzy wytwarzają kod, są osoby odpowiedzialne za kontakt z klientem, niekoniecznie potrafiące przekazywać realną wartość pomysłu, o którym myślał klient. Zespół często też może nie komunikować się ze sobą dobrze i pracować nad byle jakim kodem, którego naprawę zleca młodszym pracownikom, a im z kolei znajdowanie błędów zajmuje kilka dni.

Dość frustrującym i demotywującym dla zespołu jest feedback z gatunku “klient tego nie chciał”, który wynikaja zwykle ze złego przekazu, jego braku lub stąd, że osoba kontaktowa zapomina o wymogach klienta. Należy zwrócić uwagę na to, że klienci są różni – najgorszą, ale często zdarzającą się sytuacją, jest konieczność zrobienia czegoś, nad czym klient musi się jeszcze zastanowić. Po przeczytaniu książki nasuwa mi się myśl: ile pracy, wysiłku i pieniędzy oszczędza bezpośrednie ustalanie wymagań?

OCENA

Książkę oceniam: 7/10. Nie zaspokoiła w pełni moich wymagań, ale stanowi dosyć solidną podstawę tematu zarządzania zespołem i wiele mówi o dostarczaniu wartości klientowi i użytkownikom. Ma również rozwiązania umożliwiające tworzenie środowiska, w którym zespoły są zmotywowane.

REKOMENDACJA

Książkę poleciłbym szczególnie informatycznym project managerom. Zwraca się w niej uwagę na zobowiązania i podejście do klienta.