Zarządzanie projektami ze Scrum. Twórz produkty, które pokochają klienci

Recenzje ebooka: Zarządzanie projektami ze Scrum. Twórz produkty, które pokochają klienci (2) Poniższe recenzje mogły powstać po przekazaniu recenzentowi darmowego egzemplarza poszczególnych utworów bądź innej zachęty do jej napisania np. zapłaty.

1. Recenzja: gornapolka.radekwroblewski.pl

   Recenzja dotyczy produktu: ksiązka drukowana

   Czy recenzja była pomocna:

    TAK  (0)  NIE  (0)

   Ta historia rozpoczyna się prawie 70 lat temu. 5 lat po II wojnie światowej dawni sprzymierzeńcy – ZSRR i USA – stają po dwóch stronach frontu. Choć Stalin niechętnie patrzy na wysłanie do Korei armii lądowej – z głębi Chin startują rosyjskie myśliwce MiG-15. Arcydzieło techniki. 1,4 tys. km zasięgu. Pułap – 15,5 km. 1,1 tys. maksymalnej prędkości. I niesamowity ciąg 26,5  kN, dający możliwość wznoszenia o 50 metrów w ciągu sekundy. MiG-15 w każdej kategorii niemal na głowę bił F-86 Sabre, którym dysponowali Amerykanie. A jednak to Amerykanie wygrali wojnę koreańską chwaląc się m.in., że każde 10 strąconych MIGów kosztowało ich zaledwie jednego straconego F-86*.
   
   Manewruj albo giń
   Tej historii nie znajdziesz w książce „Zarządzanie projektami ze SCRUMem.”** Ale decyduje ona o tym, dlaczego  musisz poznać SCRUMa – niezależnie od tego, czy zajmujesz się produktem, finansami, czy sprzedażą.
   
   Zastanawiając się nad fenomenem – dlaczego ewidentnie słabsze amerykańskie samoloty rozniosły radzieckie MIGI – John Boyd, jeden z najbardziej znanych amerykańskich instruktorów lotnictwa doszedł do wniosku, że kluczowe znaczenie miała budowa kokpitu. Amerykańscy piloci mieli nad głowami w pełni przejrzystą owiewkę, która pozwalała im na obserwację zdecydowanie szerszego pola. Radzieckim pilotom widok do góry i na boki częściowo zasłaniały słupki. Boyd uznał, że co prawda Rosjanie mogli realizować manewry lepiej ale – z powodu ograniczeń w polu widzenia – później podejmowali decyzje o ich rozpoczęciu. W ten sposób narodziło się prawo Boyda – o sukcesie decyduje nie precyzja działania, ale tempo podejmowania zmian. Ewolucja na turbodoładowaniu. Przetrwają tylko najlepiej dostosowane produkty. Tym właśnie jest SCRUM.
   
   Właściciel produktu to nie kierownik projektu
   „Zarządzanie projektami ze SCRUMem. Twórz produkty, które pokochają klienci” Romana Pichlera w sam raz nadaje się do tego, żeby poznać SCRUM na biznesowym poziomie. Pichler należy do grupy najbardziej doświadczonych europejskich trenerów SCRUM. Urodzony w 1970 roku w Niemczech, karierę autora książek zaczął w 2007 roku tytułem „Scrum – Agiles Projektmanagement erfolgreich einsetzen”. Od prawie dekady mieszka jednak w Londynie i kolejne książki wydaje już po angielsku.
   Pichler rozpoczyna swoją książkę od opisania właściciela produktu. Osoby, która ma wizję i potrafi ją zrealizować. Jest liderem, ale takim, który nie zdusi zespołu (samoorganizujący się zespół to – obok właściciela produktu – drugi kluczowy zasób SCRUM). Komunikuje czego oczekuje, ale negocjuje jak cały zespół to osiągnie. Pichler wskazuje też dlaczego nie należy mylić właściciela produktu z kierownikiem projektu. Od kierownika projektu nikt nie oczekuje wizji. Ma być wykonawcą. W dodatku rozliczać zespoły, których nie jest członkiem. Właściciel produktu nie rozlicza, tylko dowodzi i płynie na tej samej łodzi, co reszta zespołu. Mniej miejsca Pichler poświęca SCRUM Masterowi, konsekwentnie  nazywanemu w tej książce „mistrzem młyna” (pojęcie SCRUM Master, które ugruntowało się już w biznesowo-projektowym języku także w Polsce nie pojawia się ani razu). Za to bardzo dokładnie przygląda się procesowi budowania i nieustannego poprawiania wizji produktu. W tym nieustannym poprawianiu znajduje odzwierciedlenie prawo Boyda i powiedzenie Amerykanina: „to, gdzie znajdujesz się dziś nie ma tak dużego znaczenia jak to, gdzie znajdziesz się jutro”. Pichler przestrzega więc nieustannie przed wizjonerskim zadufaniem. „Tworzenie wizji jest procesem odkrywania, pozyskiwania wiedzy i uczenia się, co wymaga eksperymentów”. Czyli nieustannego sprawdzania, czy wizja twórcy i potrzeby odbiorcy nadal się ze sobą zgadzają. Proponuje tu zresztą zastosowanie tzw. cyklu Deminga, twórcy doskonałości japońskiego przemysłu, o którym jego ojczyzna – czyli USA – przypomniała sobie dopiero gdy w latach 80-tych amerykańskie marki zaczęły tracić rynek na rzecz konkurencji zza Pacyfiku. „Wypuszczaj produkt szybko, obserwuj reakcję rynku i dostosowuj do niej swój produkt” – pisze Pichler. Truizm. Ale im genialniejszy produkt właśnie wymyśliliśmy – tym trudniej będzie zastosować radę Pichlera.
   
   Poker planistyczny i tajemnicze „story points”
   Jednym z najciekawszych rozdziałów książki „Zarządzanie projektami ze SCRUMem” jest ten poświęcony planowaniu wydania. Wydanie produktu to jego konkretna wersja. Każde nowe wydanie musi być w sposób zauważalny dla użytkowników lepsze od poprzedniego. Co nie oznacza, że musi być w całości inne. Pichler sprawnie opisuje planowanie wysiłku, który jest potrzebny na realizację wydania – i świetnie tłumaczy czym są „story points” (a z naocznego doświadczenia wiem, że nawet doświadczeni właściciele produktu miewają problem z wytłumaczeniem istoty „story points” doświadczonym menedżerom). Pichler proponuje, by kolejne nominały tej SCRUMowej waluty miały wartość 1, 2, 3, 5, 8, 13…., nie jednak nie 21 jak wskazywałby ciąg Fibonacciego, ale 20. Niestety autor nie tłumaczy skąd się bierze ta 20-stka. W startupowym towarzystwie na pewno przyda się też wiedza czym jest „poker planistyczny” i wykres spalania – to zresztą sposób kontrolowania postępu prac, który przyda się nie tylko SCRUMowcom.
   
   Książka Pichlera nie dla SCRUM Mastera
   Książka Pichlera jest na wskroś praktyczna. Nie znajdziemy w niej efektownych porównań (choć celnych zdań nie brak), ani własnych koncepcji autora dotyczących drogi rozwoju zwinnych metodyk. Nie jest to również książka dla osób, które postawiły sobie za cel zostanie (albo już zostały) SCRUM Masterem, czyli mistrzem młyna. Dla nich to co najwyżej przystawka przed głównym daniem. Ale dla stykających się ze SCRUMem menedżerów – w sam raz. A na przeczytanie wystarczy zarezerwować sobie jedne, góra dwa wieczory.
   
   W czasie, kiedy czytałem „Zarządzanie projektami ze SCRUMem” w Paryżu trwał właśnie doroczny salon samochodowy. Pierwszy, na który marki z ojczyzny Romana Pichlera przywiozły bardzo silną reprezentację aut elektrycznych. Zdążyli na ostatnią chwilę, bo odkąd zaprzyjaźniłem się ze SCRUM nie mam już wątpliwości, że auta elektryczne wygrają ze dieslami. Nie dlatego, że wymusi to jakaś norma Euro X, że są cichsze, ani że mniej się psują. Wygrają, bo można je tworzyć używają SCRUM. A to oznacza, że będą lepsze od spalinowych pod każdym względem.

2. Recenzja: Quale Karolina Zmitrowicz

   Recenzja dotyczy produktu: ksiązka drukowana

   Czy recenzja była pomocna:

    TAK  (0)  NIE  (0)

   Zachęcające słowa wstępu przytoczone przez współtwórcę Scruma Jeffa Sutherlanda i Bretta Queenera, SVP z Saleseforce pozwalają nakreślić wizję nadciągającej lektury; kwintesencja „Zarządzania projektami ze Scrumem” Romana Pichlera jest zawarta w przedmowie.
   
   Autor w krótki i przystępny sposób przedstawia cel publikacji. W zwięzłych słowach dowiadujemy się, o czym, w jakiej formie i dla kogo jest ta pozycja książkowa oraz gdzie plasuje się w uniwersum literatury fachowej o metodykach zwinnych.
   
   
   
   O samego początku uwagę zwraca pragmatyzm podejścia w postaci świadectw praktyków biznesu, tabelarycznego zestawienie klasycznego i „nowego” podejścia do zarządzania, rozgraniczenie między projektem a produktem, nazywanie rzeczy po imieniu, a przede wszystkim jasne stwierdzenie, czym to kompendium nie jest – nie dostajemy podręcznika zwinności, ale solidną porcję rad, wskazówek, a przede wszystkim doświadczenia.
   
   
   
   Czyż nie jest lepiej (a na pewno taniej) uczyć się na cudzych błędach? Autor wydaje się doskonale rozumieć to podejście i na koniec każdego rozdziału serwuje listę potencjalnych problemów. Pozwala to szerzej otworzyć oczy, spojrzeć obiektywnie na sytuację i uniknąć błędów oraz powtarzania obiegowych mitów, których nie brakuje mimo upływu lat.
   
   
   
   W pierwszym rozdziale została opisana rola właściciela produktu – człowieka o dualnej naturze: wizjonera i wykonawcy, lidera i gracza zespołowego, komunikatora i negocjatora, który inspiruje zespół i dba o zaangażowanie jego członków dzięki swej dostępności i właściwym kwalifikacjom. Poruszone zostają również istotne kwestie współpracy między uczestnikami projektu, włączając klientów.
   
   Szczególnie ciekawy jest fragment o skalowalności roli właściciela produktu w Scrum – pytania o to padają często, jeśli nie zawsze, w dużych firmach pracujących nad wysoce złożonymi projektami. Okazuje się, że nie jest to proste, ale wykonalne.
   
   
   
   Kolejny rozdział poświęcony jest wizji produktu – elemencie nierzadko zapomnianym lub niedookreślonym. Cytat z „Alicji w Krainie Czarów” doskonale wprowadza w temat. Poznamy cechy i atrybuty kompletnej wizji, która pozwoli na przygotowanie „minimalnej wersji produktu nadającej się do wypuszczenia na rynek”. Skoro mowa o atrybutach; nieco zamieszania wprowadzają podrozdziały „Obszerna i angażująca” oraz „Krótka i zwięzła” jeden pod drugim. Jednak już po pierwszych zdaniach można odszyfrować, że chodzi o zwięzłe sformułowanie szeroko nakreślonego celu – ot, chochlik na styku pracy tłumaczenia i redakcji. Na koniec zaserwowane zostały techniki tworzenia wizji z naciskiem na prostotę rozwiązań. Warto wspomnieć, że Marissa Mayer nie pracuje w Google od lipca 2012.
   
   
   
   Rozdział trzeci traktuje o pracy z kluczowym artefaktem scrumowym, a mianowicie rejestrem produktu. Dzięki przytoczonym cechom składającym się w anglojęzyczny akronim DEEP [Mike Cohn] oraz technikom tworzenia i utrzymania rejestru można znacząco uprościć sobie pracę. Struktura, jasny opis elementów, priorytety oraz analiza ryzyka i wartości dodanej pozwolą okiełznać każdy produkt.
   
   Z uwagi na fakt, że rejestr produktu jest żywym, nieustannie ewoluującym dokumentem, opisane są także sposoby pracy w ramach sprintu: szacowania, dobierania wielkości oraz dekompozycji już istniejących elementów z uwzględnieniem istotnego atrybutu – ich testowalności. Nie bez powodzenia podjęte zostaje również wyzwanie opisu wymagań niefunkcjonalnych oraz skalowalności rejestru.
   
   
   
   Przedmiotem rozdziału czwartego jest planowanie wydania . Obok porad odnośnie do wbudowanej jakości oraz częstotliwości wypustów oprogramowania czy wykresów spalania i prędkości zespołu scrumowego jedno zdanie szczególnie zasługuje na cytat: „Trzymanie się zarówno czasu, budżetu jak i funkcjonalności nie jest możliwe; przynajmniej jeden z tych elementów musi działać jak wentyl bezpieczeństwa”.
   
   
   
   Z rozdziału piątego dowiedzieć się można kolejnych przydatnych rzeczy o współpracy w trakcie spotkań planujących sprint, do których wprowadzenie miało miejsce w rozdziale 3. Na niespełna 15 stronach znalazło się rzeczowe repetytorium z metodologii okraszone cennymi spostrzeżeniami.
   
   
   
   Ostatni, szósty, rozdział prowadzi przez etap przejścia do roli właściciela produktu. Przytoczone wskazówki wydają się trywialne, bo kto nie chciałby się rozwijać pod okiem doświadczonego trenera czy wybrać właściwej osoby na dane stanowisko? Jednak – po raz kolejny – w prostocie siła. Dobre zrozumienie tej roli w realiach organizacji i przy wsparciu zarządu będzie wystarczającym fundamentem pod praktykę, obserwację i adaptację.
   
   
   
   Można zastanawiać się na organizacją informacji w poszczególne rozdziały i podrozdziały (np. planowanie sprintu rozbite pomiędzy rozdziały 3 i 5), która daje wrażenie  pociętej i zmontowanej jeszcze raz; przypomina skojarzone ze sobą wyniki wyszukiwania w przeglądarce internetowej, które w dzisiejszych czasach wydają się całkiem naturalne. Z drugiej strony nie jest to elementarz dla początkujących czytany od deski do deski.
   
   
   
   Przekładu dokonano starannie, dzięki czemu książkę czyta się płynnie i naturalnie. Kilka elementów – z „mistrzem młyna” na czele – jednak drażni. Terminu „Scrum Master” nie powinno się tłumaczyć, a w razie pokusy pozostać przy „Mistrzu Scruma”. Niespotykane są przecież publikacje o „Zarządzaniu projektami z Młynem”. Warto trzymać się tej konwencji. „Planowanie pokerowe” natomiast wydaje się dużo bardziej naturalne niż „poker planistyczny”, co oprócz praktyki zawodowej potwierdza chociażby liczba wyników wyszukiwania w Google dla obu terminów. Zabrakło natomiast angielskich odpowiedników obok polskojęzycznych tłumaczeń lub słowniczka na końcu. Sam autor odnosi się do publikacji Schwabera, aby uniknąć nieporozumień mimo stosowania języka angielskiego, na którym oparte jest tłumaczenie.
   
   
   
   Redakcja poleca lekturę tej pozycji każdemu kierownikowi projektu, który przymierza się do zwinnego rozwoju produktu według metodologii Scrum lub niedawno zaczął i poszukuje inspiracji dla usprawnień. Doświadczonym właścicielom produkty natomiast przyda się referencja celem odświeżenia i usystematyzowania wiedzy. Bardzo dobra pozycja. Pozostaje zawtórować Romanowi Pichlerowi: Twórz produkty, które pokochają klienci!
   
   
   
   Ocena redakcji – 5/6.
   
    

więcej recenzji

ukryj recenzje