Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00495 009013 7434553 na godz. na dobę w sumie
Mapowanie historyjek użytkownika. Przepis na produkt idealny - ebook/pdf
Mapowanie historyjek użytkownika. Przepis na produkt idealny - ebook/pdf
Autor: Liczba stron: 256
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-2062-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> agile - programowanie
Porównaj ceny (książka, ebook (-20%), audiobook).
Podczas projektowania wielu procesów produkcyjnych, łącznie z budową oprogramowania, za kluczowe kryteria uznaje się szybkość wykonywania zadań, wydajność czy niskie koszty. Tymczasem opracowanie produktu o wyjątkowej wartości rynkowej wymaga nieco innego podejścia. Celem produkcji nie jest przecież produkcja sama w sobie. Aby kiedyś osiągnąć wysokie zyski, planowanie procesów produkcji musi opierać się na wymaganiach użytkowników, bez zatracania się w szczegółach produktu. To jest właśnie myśl przewodnia metody mapowania historyjek użytkownika tworzonych na potrzeby procesów agile.

Ta odkrywcza książka, kierowana przede wszystkim do product managerów, analityków biznesowych i osób zajmujących się wrażeniami użytkownika, ma na celu pokazanie, w jaki sposób można w pełni wykorzystać zalety procesów agile i lean poprzez mapowanie historyjek. Technika ta umożliwia nakreślenie obrazu całości, który niekiedy trudno zrekonstruować na podstawie wielkiego zbioru osobnych historii. Modyfikowalne mapy historyjek umożliwiają zespołowi prowadzenie bardziej wnikliwych dyskusji o projekcie w ramach procesu produkcyjnego. W efekcie zespół sprawnie buduje wspólną wizję tego, co chce stworzyć, co przybliża produkt do osiągnięcia sukcesu.

W tej książce znajdziesz:

Mapowanie to prawdziwe źródło inspiracji!

Znajdź podobne książki

Darmowy fragment publikacji:

Tytuł oryginału: User Story Mapping Tłumaczenie: Maksymilian Gutowski ISBN: 978-83-283-2059-8 © 2016 Helion SA. Authorized Polish translation of the English edition of User Story Mapping, ISBN 9781491904909 © 2014 Jeff Patton. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/maphis Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Słowo wstępne od Martina Fowlera ........................................................................... 11 Słowo wstępne od Alana Coopera .............................................................................. 13 Słowo wstępne od Marty’ego Cagana ........................................................................ 15 Wprowadzenie .......................................................................................................... 19 20 Dlaczego akurat ja? Jeśli masz problemy z historyjkami, ta książka jest dla Ciebie 20 21 Kto powinien przeczytać tę książkę? 22 Konwencje formatowania przyjęte w książce Struktura książki 23 Przeczytaj to najpierw ............................................................................................... 25 25 Głuchy telefon 28 Wspólne porozumienie można osiągnąć bezproblemowo Nie staraj się pisać idealnych dokumentów 29 30 Dobre dokumenty są jak zdjęcia z wakacji 31 Dokumenty są jak ściągi Mów o tym, co ważne 32 32 Dziś i jutro 33 Oprogramowanie nie jest najważniejsze 34 No dobra, nie chodzi o samych ludzi Wytwarzaj mniej 35 36 Brzydkie słowo na „w” To właściwie tyle 37 1. Obraz całości ............................................................................................................. 39 39 40 41 Słowo na „a” Historie są do opowiadania, nie do czytania Opowiadanie historii w całości 5 Poleć książkęKup książkę Gary i tragedia płaskiego rejestru Mów i zapisuj Naszkicuj zarysy pomysłu Opisz klientów i użytkowników Opowiedz historie użytkowników Zapoznaj się ze szczegółami i możliwościami 42 43 44 45 46 49 2. Produkuj mniej ......................................................................................................... 55 56 59 59 60 61 62 62 65 66 Mapowanie pomaga dużym grupom uzyskać wzajemne zrozumienie Mapowanie ułatwia znajdowanie luk w opowieści Do zrobienia zawsze jest za dużo Wydziel minimalne, działające wydanie produktu Wydziel harmonogram produkcji Nie priorytetyzuj funkcji, tylko rezultaty To czysta magia — naprawdę Dlaczego MVP jest takie ważne Nowe MVP wcale nie jest produktem! 3. Ucz się szybciej .......................................................................................................... 69 70 70 71 72 72 75 75 76 77 78 Zacznij od omówienia korzyści Zweryfikuj problem Ucz się z prototypów Ludzie mogą chcieć nie tego, czego potrzebują Twórz, aby się uczyć Powtarzaj aż do uzyskania funkcjonalności Jak tego nie robić Zdobywanie weryfikowanej wiedzy Minimalizuj swoje eksperymenty Podsumowanie 4. Kończ na czas ............................................................................................................ 79 80 81 82 83 83 84 88 88 89 90 90 Opowiedz zespołowi o wszystkim Jak skutecznie szacować czas Budowanie kawałek po kawałku Nie wypuszczaj pojedynczych plastrów Jak skutecznie szacować czas — sekret drugi Zarządzaj swoim budżetem Iteratywnie i przyrostowo Otwarcie, gra środkowa i gra końcowa Podziel strategię produkcyjną na mapie Wszystko sprowadza się do ryzyka Co teraz? 6 (cid:95) Spis treści Poleć książkęKup książkę 5. Już wiesz, jak to robić ................................................................................................ 91 91 94 95 97 98 99 100 101 102 103 104 1. Wypisz swoją opowieść krok po kroku 2. Ułóż swoją opowieść 3. Zastanów się nad innymi wariantami historii 4. Opracuj rdzeń mapy 5. Wydziel działania umożliwiające osiągnięcie konkretnego rezultatu I już! Wiesz już wszystko, co trzeba Wypróbuj to w domu i w pracy Mapa opowiada o tym, co jest dziś, nie o jutrze Wypróbuj to w praktyce Programistom trudniej Mapa to dopiero początek 6. Cała prawda o historyjkach .......................................................................................109 109 110 111 113 114 Absurdalnie prosty pomysł Kenta Proste nie znaczy łatwe Ron Jeffries i trzy C Hasła i obrazy To tyle 7. Opowiadanie lepszych historii ..................................................................................115 115 118 120 123 124 Szablon Connextra Szablonowi zombie i jazda pługiem Lista dobrych tematów do omówienia Rób zdjęcia z wakacji To rzeczywiście dużo zachodu 8. Karteczka to nie wszystko .........................................................................................125 125 126 128 130 Różni ludzie, różne dyskusje Potrzebujemy większej kartki Grzejniki i lodówki Piła to nie młotek 9. Karteczka to dopiero początek ..................................................................................135 136 136 137 138 139 140 140 Miej w głowie jasną wizję Stwórz tradycję przekazu opowieści Sprawdzaj wyniki swojej pracy To nie jest Twoja zabawka Twórz, aby się uczyć Nie chodzi tylko o oprogramowanie Planuj naukę, ucz się planować Spis treści (cid:95) 7 Poleć książkęKup książkę 10. Opowieści są jak tort ............................................................................................... 141 141 143 Stwórz przepis Pieczenie tortu w kawałkach 11. Łupanie kamieni ..................................................................................................... 147 147 148 150 151 151 152 153 154 155 156 158 159 159 Rozmiar zawsze ma znaczenie Opowieści są jak kamienie Eposy to wielkie kamienie, którymi się rzuca w ludzi Organizuj grupy historyjek tematycznie Nie przejmuj się terminologią, tylko snuj opowieści Zacznij od okazji Odkryj MVS Przyjrzyj się szczegółom historyjki w trakcie produkcji Dyskutuj podczas produkcji Przeprowadź ewaluację każdego elementu Przeprowadź ewaluację z użytkownikami i klientami Przeprowadź ewaluację z interesariuszami Wydaj produkt i ucz się 12. Praca w kamieniołomie ........................................................................................... 161 162 163 164 167 168 Wartościowe — Użyteczne — Wykonalne Zespół badawczy potrzebuje cudzej pomocy Trzej amigos Właściciel produktu jako producent To nie takie proste 13. Zacznij od okazji ...................................................................................................... 169 169 170 174 174 179 Prowadź dyskusje o okazjach Zbadaj, zrezygnuj lub zastanów się O okazjach trzeba mówić Okazje a mapowanie historyjek Bądź wybredny 14. Tworzenie wzajemnego zrozumienia poprzez odkrywanie ....................................... 181 181 182 194 195 W odkrywaniu nie chodzi o oprogramowanie Cztery kroki do odkrycia Czynności, dyskusje, efekty Odkrywanie jest tworzeniem wzajemnego zrozumienia 8 (cid:95) Spis treści Poleć książkęKup książkę 15. Odkrywaj, aby weryfikować wiedzę ..........................................................................197 197 198 199 202 203 204 208 Przeważnie się mylimy Stare, niezbyt dobre czasy Design thinking Jak zepsuć coś dobrego Krótkie pętle weryfikujące Jak koncepcja Lean Startup zmienia metodę projektowania produktu A historyjki i mapy? 16. Udoskonalaj, definiuj i buduj ....................................................................................211 211 211 212 214 217 218 222 223 223 Kartki, konwersacje, więcej kartek, więcej konwersacji… Przycinanie i szlifowanie Warsztaty historyjek Planowanie sprintu lub iteracji Tłumy nie współpracują Dziel i redukuj Wykorzystuj mapę historyjek podczas produkcji Używaj mapy do odnotowywania postępów Używaj prostych map podczas warsztatów historyjek 17. Historyjki są jak asteroidy .........................................................................................227 228 230 230 Składanie rozbitych kamieni Nie przesadzaj z mapowaniem Nie przejmuj się pominiętymi szczegółami 18. Ucz się z wszystkiego, co tworzysz ............................................................................233 233 236 237 238 239 239 240 Przeglądy zespołowe Prowadź przeglądy z innymi członkami organizacji Wystarczy Ucz się od użytkowników Ucz się z wydań Terminowe uzyskiwanie wyników Wykorzystaj mapę do ocenienia gotowości wydania Czy to koniec? ..........................................................................................................243 Podziękowania ........................................................................................................245 Bibliografia ..............................................................................................................249 Skorowidz ................................................................................................................251 Spis treści (cid:95) 9 Poleć książkęKup książkę 10 (cid:95) Spis treści Poleć książkęKup książkę ROZDZIAŁ 1. Obraz całości „Produkcja z agile jest genialna! Co parę tygodni wypuszczamy masę nowego i sprawnego oprogra- mowania. Czasami tylko mam wrażenie, że gdzieś nam się gubi pełny obraz tego, czym się zajmujemy”. Gdybym tylko dostawał po cencie za każdym razem, gdy słyszę coś takiego od członka zespołu pracującego w metodyce zwinnej, to… No, generalnie zebrałbym już sporo centów. Być może nawet sam kiedyś powiedziałeś coś w tym stylu. Mam dla Ciebie dobrą wiadomość: praca w procesie agile’owym, wzbogacona o podejście oparte na wykorzystaniu historyjek, umożliwia zachowanie obrazu całości. Dzięki temu możesz prowadzić konstruktywne dyskusje o całym produkcie i wciąż raz na parę tygodni cieszyć się na widok postępów prac zespołu. Jako że cierpliwie przeczytałeś rozdział „Przeczytaj to najpierw”, postaram się już nie ględzić o hi- storyjkach, tylko przejdę od razu do omówienia tego, jak mapy historyjek rozwiązują jeden z naj- większych problemów z produkcją agile’ową. Jeśli umiesz już pisać historyjki na potrzeby zwin- nych projektów, po przeczytaniu tego rozdziału powinieneś być gotowy do pracy. Słowo na „a” Skoro czytasz tę książkę, to prawdopodobnie wiesz, że mapowanie historyjek jest metodą polegającą na używaniu historyjek użytkownika, tworzonych na potrzeby procesów agile. W każdej innej książce związanej w jakiś sposób ze zwinnym procesem znalazłbyś na tym etapie przedruk Manifestu programowania zwinnego, napisanego w roku 2001 przez siedemnastu panów, którzy mieli dość kontrproduktywnych trendów panujących wówczas w procesach produkcyjnych. Cieszę się, że napi- sali ten manifest. Cieszę się też, że ich dzieło znalazło tak silny oddźwięk. Muszę Cię jednak zawieść. Nie przedrukuję manifestu i nie będę rozpisywał się o tym, jaki jest nie- samowicie ważny. Myślę, że sam doskonale wiesz, o czym jest, a jeśli go nie czytałeś, to powinieneś nadrobić zaległości. W miejscu, w którym znalazłby się manifest, umieszczam śmieszne zdjęcie z kotkiem1. Dlaczego? Ponieważ od dawien dawna wiadomo, że śmieszne zdjęcia z kotkami są ciekawsze od jakiegokolwiek manifestu. 1 Autorem zdjęcia, dostępnego na serwisie Flickr (http://flic.kr/) na licencji Creative Common Attribution, jest Piutus. 39 Poleć książkęKup książkę Co ma ten kotek wspólnego z agile? Właściwie to nic. Za to agile ma wiele wspólnego z tą książką, a także opowieściami i ewolucją techniki mapowania historyjek użytkownika. Teraz wyobraź sobie, że akcja poniższego akapitu toczy się w czarno-białym filmie… W roku 2000 pracowałem w San Francisco w startupie, który w celu rozkręcenia swojego procesu produkcji oprogramowania zatrudnił jako konsultanta Kenta Becka (autora koncepcji programo- wania ekstremalnego oraz pierwszego opisu idei historyjek). Było to dość dawno temu, ale chciał- bym tym samym podkreślić, że historyjki są naprawdę starym narzędziem. Jeśli dopiero zaczynasz z nich korzystać, to musisz wiedzieć, że stosowanie ich było przejawem pionierskiego ducha może z dziesięć lat temu. Kent i inni pionierzy ekstremalnego programowania doszli do wniosku, że uży- wane wówczas metody opracowywania wymagań nie sprawdzały się za dobrze. Kent był zdania, że zamiast korzystać z wymagań, wystarczałoby zwyczajnie się spotykać i opowiadać sobie nawza- jem historie, by wypracowywać wzajemne zrozumienie i wspólnie wymyślać lepsze rozwiązania. Historie są do opowiadania, nie do czytania Kiedy po raz pierwszy usłyszałem o historyjkach, coś mi w tej całej koncepcji nie pasowało. Muszę to otwarcie przyznać. To, że mieliśmy trywializować istotne zapotrzebowania poprzez nazywanie ich „historyjkami”, nie brzmiało dobrze. Wychodzi jednak na to, że to ja byłem w błędzie, o czym już wspomniałem przy okazji omówienia pojęcia wzajemnego zrozumienia. Trochę mi zajęło przy- swojenie tego, że: Historyjki służą do opowiadania, a nie do zapisywania w określony sposób. 40 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Zanim jeszcze pojąłem, dlaczego historyjki nazywają się, jak się nazywają, to zrozumiałem, że mogę sobie zapisać wiele historii — składających się z pełnych zdań czy prostych tytułów — na kar- teczkach lub fiszkach. Mogłem je przedstawiać innym osobom i układać w różnej kolejności, aby określić priorytety. Po wskazaniu, które historyjki są ważniejsze, mogliśmy rozpocząć na ich temat dyskusję. Było to całkiem przyjemne. Dlaczego nigdy nie wpadłem na to, by zapisywać myśli na kartkach i organizować je w ten sposób? Problem w tym, że kartka mogła przedstawiać element oprogramowania o bliżej nieokreślonym czasie opracowania przez deweloperów: od paru godzin, przez kilka dni lub tygodni, po miesiąc. Nie byłem tego świadom, dopóki nie zaczęliśmy o tym dyskutować. Podczas pracy nad swoim pierwszym agile’owym projektem miałem okazję wziąć udział w dość trudnej kłótni. Wynikło to z tego, że podczas konwersacji o historyjce dowiedziałem się, że jest ona za długa i wdrożenie jej w kolejnej iteracji, tak jak bym chciał, nie było możliwe. Miałem wraże- nie, że zrobiłem coś źle. Deweloperzy wskazali, że moglibyśmy omówić mały fragment historyjki, który dałoby się opracować w kolejnej iteracji. Sam byłem jednak zirytowany tym, że nie daliśmy sobie okazji do omówienia obrazu całości. Bardzo chciałem się dowiedzieć, ile zajmie opracowanie tej dłuższej opowieści. Miałem nadzieję, że uzgodnimy to podczas dyskusji, ale tak się nie stało. Opowiadanie historii w całości W roku 2001 dołączyłem do nowego zespołu, z którym postanowiłem współpracować inaczej. Przy- jęliśmy, że będziemy tworzyć historyjki odnoszące się do ogólnej postaci rzeczy. Staraliśmy się wspólnie zrozumieć, jaki konkretnie produkt tworzymy, i wspólnie decydowaliśmy się na kom- promisy. Używaliśmy sterty fiszek z tytułami, aby rozłożyć obraz całości na szczegółowe elementy, które mogliśmy od razu opracować. W roku 2004 napisałem swój pierwszy artykuł na ten temat. Pojęcie mapowania historyjek wymyśliłem jednak dopiero w roku 2007. Okazuje się, że nazwy są ważne. Moja technika zyskała popularność dopiero wtedy, kiedy dałem jej dobrą nazwę. Myślałem wówczas, że stworzyłem coś naprawdę świetnego, dopóki nie trafiłem na in- nych ludzi, którzy robili coś podobnego, czy wręcz to samo. Odkryłem tym samym pewien schemat. Po raz pierwszy definicję schematu usłyszałem od Lindy Rising, a brzmiała ona następująco: kiedy opowiadasz komuś o swoim genialnym pomyśle, a w odpowiedzi słyszysz „Tak, też coś takiego robimy”, oznacza to, że nie stworzyłeś wynalazku, tylko opracowałeś schemat. Mapowanie historyjek to schemat. To jest coś, co wystarczająco rozgarnięci ludzie robią, żeby obja- śnić charakter całego produktu lub funkcji. Posługują się tą techniką, aby rozbijać większe opowieści na mniejsze. Nie powinieneś się czuć źle z tym, że sam tej metody nie wymyśliłeś, bo w końcu byś to zrobił. Ta książka pozwoli Ci jednak oszczędzić sobie tygodni czy wręcz miesięcy frustracji. Mapy historyjek służą do rozbijania dłuższych opowieści na mniejsze. Obecnie coraz więcej firm zaczyna korzystać z techniki mapowania historyjek użytkownika. Martina, moja znajoma z SAP, we wrześniu 2013 roku napisała mi, że: Opowiadanie historii w całości (cid:95) 41 Poleć książkęKup książkę „(…) do tej pory oficjalnie przeprowadziliśmy ponad 120 warsztatów z mapowania histo- ryjek użytkownika. Organizatorzy procesów uwielbiają je! Ta technika jest już silnie zako- rzeniona w SAP”. Co tydzień odzywają się do mnie przeróżni ludzie z najróżniejszych miejsc, żeby powiedzieć mi, jak mapowanie historyjek pomogło im w rozwiązaniu ich problemów. Z rozmów z innymi ludźmi wynoszę wiedzę, której o własnych siłach nigdy bym nie zdobył. Historyjkom z założenia przyświeca prosta idea. Mają one zmniejszać nacisk na tworzenie wspólnych dokumentów, a prowadzić do zwiększenia wzajemnego zrozumienia. Standardowym sposobem używania historyjek jest sporządzenie ich listy, wskazanie priorytetów, omówienie ich i przekształca- nie ich po kolei w elementy oprogramowania. Na pierwszy rzut oka wygląda to dość sensownie, ale już w praktyce można natknąć się na niemałe problemy. Gary i tragedia płaskiego rejestru Kilka lat temu poznałem Gary’ego Levitta, przedsiębiorcę tworzącego nowy serwis internetowy. Serwis powstał i nosi nazwę Mad Mimi, co jest skrótem od music industry marketing interface (interfejs marketingowy dla branży muzycznej)2. Gary pisze własne utwory, ma własny zespół, pomaga w zarządzaniu innymi zespołami, a także pracuje jako muzyk sesyjny i nagrywa na zlecenie. Kiedy poznałem Gary’ego, był on zajęty przygotowaniem kilkudziesięciu wstawek muzycznych dla Oprah Winfrey Show, które miały być puszczane jako przejścia przed blokami reklamowymi. Takie wstawki są dla producentów programów telewizyjnych tym samym, czym kliparty dla autorów newsletterów — niejako klipartami dźwiękowymi. Gary chciał stworzyć dość rozbudowaną aplikację, która miałaby pomagać muzykom takim jak on we wspólnej pracy nad tego typu zleceniami, a także oferować różne funkcje ułatwiające zarządzanie zespołem i promowanie go. Gary zdecydował się nawiązać współpracę z kimś, kto używał metodyki zwinnej. Otrzymał polecenie, by spisać listę wszystkich funkcji, jakie go interesowały, i uporządkować ją pod kątem priorytetów, aby później przedyskutować najważniejsze elementy i zabrać się po kolei za ich opracowanie. Taką listę nazywamy w zwinnym procesie rejestrem, więc sporządzenie jej i wyznaczenie najważniejszych funkcji wydało się sensownym rozwiązaniem. 2 Więcej o Garym dowiesz się z opublikowanego w „Business Insider” artykułu How This Guy Launched A Multi- Million Dollar Startup Without Any VC Money (http://www.businessinsider.com/goldstar-ceo-jim-mccarthy-groupon-2011-11). 42 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Gary stworzył swój rejestr, a deweloperzy zaczęli opracowywać program kawałek po kawałku. Gary zaczął pompować w to przedsięwzięcie olbrzymie fundusze, płacąc za każdy kolejny przygotowany element. Oprogramowanie zaczęło pomału nabierać kształtu, ale było już widać, że stworzenie programu spełniającego pierwotną wizję potrwa dużo dłużej, niż przewidziano, a przez ten czas budżet zdąży się wyczerpać. Znałem osobę, której Gary zlecił wykonanie tego projektu. Ów znajomy widział, że Gary poważnie się niepokoi, i chciał mu jakoś pomóc. Poprosił mnie, bym porozmawiał z Garym i pomógł mu w uporządkowaniu jego pomysłów. Odezwałem się do Gary’ego i umówiliśmy się na rozmowę w jego biurze na Manhattanie. Mów i zapisuj Spotkaliśmy się. Gary mówił, a ja zapisywałem na karteczkach najważniejsze punkty. Przy two- rzeniu map historyjek lubię sobie powtarzać w myślach mantrę „mów i zapisuj”, co sprowadza się zwyczajnie do tego, by nie pozwolić słowom ulecieć w niebyt. Zapisuj słowa na kartkach, żeby móc do nich później wrócić. Szybko zauważysz, że wskazanie paru słów na kartce pomaga wszystkim uczestnikom dyskusji przypomnieć sobie, o czym była wcześniej mowa. Kartki można do woli przekładać po biurku w ramach porządkowania myśli. Ludzie zaczynają używać takich prostych, a niezwykle użytecznych słów jak to czy tamto, gdy wskazują na poszczególne fiszki. Można w ten sposób zaoszczędzić masę czasu. Zachęcenie Gary’ego do wyrażenia swoich myśli było istotne dla wy- pracowania wzajemnego zrozumienia. Gary nie był przyzwyczajony do pracy w takim trybie, więc kiedy już go skłoniłem do opowiedzenia historii, mogłem z łatwością zapisać różne wątki na kartkach. Mów i zapisuj: zapisuj kartki samoprzylepne lub fiszki, aby zeksternalizować myśli wyrażane podczas opowiadania historii. Zaczęliśmy układać kartki na stole, ale szybko zabrakło nam miejsca. W tym akurat dniu firma Gary’ego przeprowadzała się do innego biura, więc usunięto już większość mebli z lokalu. Dzięki temu mogliśmy ułożyć naszą rozrastającą się mapę kartek na podłodze. Pod koniec dnia podłoga wyglądała tak: Mów i zapisuj (cid:95) 43 Poleć książkęKup książkę My(cid:316)l — pisz — obja(cid:316)niaj — organizuj Gdy pracujesz z zespołem nad mapą historyjek, czy w ogóle o czymkolwiek z nim dyskutujesz, twórz na bieżąco prostą wizualizację, która ułatwi prowadzenie rozmowy. Częstym problemem jest to, że myśli zwyczajnie wyparowują — wypowiadamy je, a inni kiwają głową, mimo że wcale nie zwracają na nie uwagi. Nie zapisuje się ich i nie wraca się do nich. Później wracamy do tych samych myśli, które trzeba jednak na nowo wytłumaczyć, ponieważ albo nikt nie zwrócił na nie uwagi, albo zwrócił uwagę, ale zapomniał, o co chodziło. Wyrób sobie odruch notowania swoich pomysłów przed wyjaśnianiem ich. 1. Jeśli używasz fiszek lub kartek samoprzylepnych, zapisz kilka słów o swoim pomyśle od razu po tym, jak przyjdzie Ci do głowy. 2. Objaśnij swój pomysł innym, wskazując kartkę lub fiszkę. Gestykuluj. Rysuj obrazki. Opowiadaj historie. 3. Umieść kartkę lub fiszkę we wspólnej przestrzeni roboczej, gdzie każdy będzie mógł ją zobaczyć, wskazać, coś na niej dopisać bądź ją przesunąć. Zauważyłem, że kiedy staram się kogoś słuchać, to automatycznie zaczynam wpadać na własne pomysły. Kiedyś starałem się zachowywać je w myślach, żeby się w odpowiednim momencie wypowiedzieć, choć często po prostu wtrącałem się w środku zdania, bo nie mogłem już dłużej wytrzymać. Potem jednak uświadomiłem sobie, że przestaję słuchać swojego rozmówcy na bieżąco, ponieważ swoje ograni- czone zasoby umysłowe poświęcam na rozmyślanie nad swoim genialnym pomysłem. Teraz po prostu zapisuję takie pomysły na karteczkach i czekam na odpowiedni moment dyskusji, żeby o nich wspomnieć. Zapisanie myśli sprawia, że wyrzucam ją z głowy i mogę skoncentrować się na słuchaniu. Z kolei od- czytywanie zapisków z fiszek ułatwia mi dokładne przypominanie sobie pomysłów i objaśnianie ich. Nie spotkaliśmy się po to, żeby spisać wymagania Gary’ego. Nasza rozmowa nie zaczęła się od poruszenia kwestii rejestru. Musieliśmy się trochę cofnąć myślami i zacząć od początku. Naszkicuj zarysy pomysłu W swojej pierwszej rozmowie skoncentrowaliśmy się na naszkicowaniu zarysów jego pomysłu na produkt. Porozmawialiśmy o jego firmie i celach biznesowych. Dlaczego chcesz to stworzyć? Powiedz mi więcej o korzyściach dla ciebie i ludzi, którzy będą z tego serwisu korzystać. Jakie problemy ma rozwiązywać? Być może zauważyłeś już, że te pytania oparte są na omówionym wcześniej modelu dziś-jutro. Starałem się zrozumieć, jakich Gary oczekiwał rezultatów, a nie co konkretnie chce wy- produkować. Kiedy umieszcza się jedną kartkę nad drugą, to ludzie zakładają, że ta znajdująca się wyżej jest waż- niejsza. Nie muszę niczego mówić — wystarczy, że przesunę jedną kartkę nad drugą, żeby wskazać, że coś jest ważne. Wypróbuj to z listą celów. Umyślnie wyłóż je w błędnej kolejności i popatrz, jak osoba, z którą współpracujesz, sama zacznie je porządkować. Zrobiłem tak z Garym, dzięki czemu mógł wyrazić, co jest dla niego ważniejsze. 44 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Opisz klientów i użytkowników Zabraliśmy się z Garym za rozmawianie i spisywanie pomysłów. Kolejna nasza dyskusja dotyczyła klientów i użytkowników, którzy — odpowiednio — mieli jego oprogramowanie zakupić i korzystać z niego. Wymieniliśmy różne kategorie użytkowników. Omówiliśmy, jakie odnieśliby korzyści, a także zastanowiliśmy się, dlaczego korzystaliby z produktu i co mogliby za jego pomocą zrobić. Co mieliby z tego? Sporządziliśmy wielki stos karteczek z takimi zagadnieniami. Karty rozkładały się tak, że najważniejsi użytkownicy trafiali na górę. Zabawne, że to zawsze tak działa, nawet jeśli nie podejmie się żadnych ustaleń co do zasad rozkładania fiszek. Zanim przeszliśmy do jakichkolwiek szczegółów, mogłem już zrozumieć, że wizja Gary’ego była całkiem imponująca. Jednym z poważnych problemów związanych z wytwarzaniem oprogramo- wania jest to, że do zrobienia zawsze jest więcej, niż wystarczy na to czasu i środków. Celem po- winno być to, żeby wcale tego nie robić. Celem jest minimalizacja liczby opracowywanych funkcji. Czym prędzej zadałem Gary’emu następujące pytanie: „Gdybyśmy mieli skupić się na zadowoleniu jednej kategorii użytkowników i skoncentrować się na jednej funkcji, to kogo i co byś wybrał?”. Gary dokonał wyboru i to właśnie wtedy na poważnie zabraliśmy się za opowiadanie historyjek. Opisz klientów i użytkowników (cid:95) 45 Poleć książkęKup książkę Kategorie u(cid:348)ytkowników Mad Mimi Oto kategorie użytkowników Mad Mimi, które Gary wyszczególnił. Samo nazwanie ich i stworzenie krótkich opisów tego, czego oczekują, pomogło nam zrozumieć, że grono odbiorców jest całkiem duże. Zanim jeszcze przeszliśmy do rozmowy o funkcjonalności oprogramowania, postanowiliśmy odłożyć na później opracowanie funkcji dla niektórych rodzajów użytkowników. Opowiedz historie użytkowników Następnie powiedziałem: „Wyobraźmy sobie przyszłość. Załóżmy, że produkt już jest gotowy. Omówmy dzień z życia kogoś, kto z niego korzysta, i zacznijmy opowiadać jego historię. Ta osoba najpierw robi to, potem to i tak dalej”. Tę historię opowiedzieliśmy, idąc po fiszkach od lewej do prawej. Czasami cofaliśmy się z narracją i wstawialiśmy nowe myśli między poprzednie, co było proste, bo wszystko zapisywaliśmy na kartkach. Innym ciekawym zjawiskiem, które zachodzi automatycznie podczas pracy z kartkami, jest to, że gdy dwie kartki znajdują się obok siebie w poziomie, ich sekwencja jest oczywista już na pierwszy rzut oka. To działa jak magia, ale przyznaję, że nietrudno mnie ucieszyć. Jestem zachwycony tym, z jaką łatwością potrafimy się porozumiewać bez słów. Przekładając wspólnie kartki, możemy przekazać sobie bardzo dużo bez wypowiedzenia ani jednego słowa. Mówiąc i zapisując, tworzymy coś bardzo ważnego, przy czym nie mam na myśli stosu kart na podłodze. Tym czymś istotnym jest wzajemne zrozumienie. Zaczynamy nadawać na tych samych 46 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę falach. Gary nigdy wcześniej nie rozmawiał w taki sposób o swojej wizji produktu, a przynajmniej nie aż tak szczegółowo. Sam też zresztą nie rozmyślał nad swoją wizją. Pamiętał tylko o najważ- niejszych punktach, trochę tak jak w zwiastunach filmowych pokazuje się najciekawsze sceny akcji. Do tej pory Gary wykonywał moje polecenia. Zapisał stos kartek z nazwami historyjek, ułożył z nich listę i wszystkie po kolei omówił. Konwersacja dotyczyła raczej szczegółów, a nie całościowego obra- zu przedsięwzięcia. W tej ogólnej wizji było zresztą wiele luk. Okazuje się, że niezależnie od tego, jak bardzo Twoja historia wydaje się spójna, wystarczy ją opowiedzieć i sporządzić jej mapę, aby odkryć luki we własnym myśleniu. Mapowanie opowieści ułatwia odkrywanie luk we własnym myśleniu. Z czasem uświadomiliśmy sobie, że historia nie opowiadała tylko o jednym użytkowniku. Gary zaczął od menedżera zespołu, któremu zależy na wypromowaniu swoich podopiecznych. Opowiedział o jego pracy nad materiałami promocyjnymi i rozsyłaniu ich fanom. Gary musiał od razu przejść do omówienia persony fana zespołu i opowiedzieć historię o tym, jak ten z kolei otrzymuje materiały promocyjne, a następnie planuje wyjście na koncert. Skoro już mówiliśmy o promocji jakiegoś konkretnego wydarzenia, to musieliśmy też opowiedzieć historię kierownika lokalu i wspomnieć co nieco o informacjach, którymi on z kolei byłby zainte- resowany. Na tym etapie mapa była już na tyle szeroka, że ciągnęła się od ściany do ściany. Musieli- śmy kontynuować narrację na nowej warstwie, umieszczonej pod pierwszą. Dlatego właśnie na zdję- ciu kartki są porozkładane w pewnym oddaleniu od siebie. Gary miewał momenty, w których zaczynał się bardzo ekscytować i opisywać szczegół po szczególe. Umieszczanie kartek w kolumnach może służyć do określania priorytetów, ale niekiedy wskazuje dekompozycję, czyli po prostu przegląd drobniejszych elementów większej całości. Przedstawione szczegóły zapisywałem na karteczkach i umieszczałem pod kartką opisującą większy krok podej- mowany przez użytkownika. Gary był szczególnie podekscytowany i przychodziło mu do głowy wiele szczegółów, gdy opisywał, jak menedżer zespołu tworzy plakaty. Gary mieszka w Nowym Jorku, więc podczas swojej opowieści nawiązywał do plakatów wywie- szanych na nowojorskich murach i latarniach. Takie plakaty wprawdzie czasami wyglądają, jakby najpierw ktoś posklejał wycinki z gazet taśmą klejącą, a potem je skserował, ale niektóre prezentują się całkiem elegancko. Po zapisaniu kilku szczegółów stwierdziłem: „Może wróćmy do szczegółów Opowiedz historie użytkowników (cid:95) 47 Poleć książkęKup książkę później, a na razie skoncentrujmy się na pociągnięciu historii dalej”. Łatwo zgubić się w detalach, zwłaszcza tych, na których komuś szczególnie zależy. Kiedy jednak staramy się nakreślić obraz całości, należy najpierw dotrzeć do końca opowieści, a dopiero potem zająć się detalami. Na tym etapie mapowania powtarzam sobie w głowie kolejną myśl: „sięgaj myślą po horyzont, ale zagłębiaj się tylko na cal”. Dojdź do końca opowieści, zanim zgubisz się w szczegółach. Skoncentruj się na określeniu rozległości opowieści, nim zaczniesz się w nią zagłębiać. Ostatecznie udało nam się dotrzeć do końca historii Gary’ego. Menedżerowi zespołu udało się wypromować koncert wśród tysięcy fanów, którzy przekazali informację dalej, a sam koncert udał się jak nigdy. Kiedy wizja produktu stała się dla nas obydwu jasna, oznajmiłem: „Cofnijmy się teraz, uzupełnijmy szczegóły i rozważmy inne możliwości”. W górnym rzędzie mapy Gary’ego znaleźć można bardziej rozbudowane zadania, takie jak: G(cid:293)ówna narracja Mimi (cid:120) rejestracja, (cid:120) zmiana usługi, (cid:120) przeglądanie statystyk zespołu, (cid:120) praca z kalendarzem koncertów, (cid:120) praca z odbiorcami, (cid:120) promocja koncertu, (cid:120) zapisywanie się na listę mailingową zespołu, (cid:120) przeglądanie promocji online. Znalazło się tam jeszcze wiele innych większych spraw, ale powyższy zbiór w miarę dobrze odwzorowuje, co pisze się na fiszkach. Zauważ, że możemy domyślić się, kto co robi. Gdy Gary wspomniał o „promocji koncertu”, to obaj wiedzieliśmy, że jest to zadanie menedżera zespołu. Kiedy ja powiedziałem o „zapi- sywaniu się na listę mailingową zespołu”, to Gary wiedział, że mówię o fanach. Te karteczki trzymali- śmy pod ręką i mogliśmy je z łatwością wskazywać podczas dyskusji. „Promocja koncertu” okazała się bardzo ważna. Rozłożyliśmy ją na kilka etapów, rozmieszczonych od lewej do prawej pod kartką z nazwą zadania. (cid:120) Rozpoczęcie promocji koncertu. (cid:120) Przejrzenie ulotki promocyjnej, którą Mimi stworzyło za mnie. (cid:120) Dostosowanie ulotki do własnych potrzeb. (cid:120) Obejrzenie podglądu utworzonej ulotki. Zauważ, że na każdej karteczce znalazł się krótki opis, określający, co konkretna kategoria użytkownika chce zrobić. Dzięki temu mogliśmy opowiedzieć historię następująco: „menedżer zespołu następnie promuje koncert. W tym celu rozpoczyna promocję, przegląda stworzoną przez Mimi ulotkę, dosto- sowuje ją, a w końcu…”. Zauważ, że wystarczy wstawić zwroty typu „następnie” czy „w końcu” między czynności określone na kartkach, by uzyskać spójną opowieść. 48 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Zapoznaj się ze szczegółami i możliwościami Po wyłożeniu opowieści w całej jej rozpiętości tematycznej zabieramy się za jej pogłębianie. Karty, które znajdują się u szczytu każdej z kolumn, są ogólnymi zagadnieniami, a pod nimi znajduje się wykaz szczegółów. Na każdym etapie historyjki użytkownika zatrzymujemy się i rozważamy na- stępujące kwestie: (cid:120) Co konkretnie użytkownik ma teraz zrobić? (cid:120) Co mógłby zrobić zamiast tego? (cid:120) Co zrobić, żeby było to naprawdę atrakcyjne? (cid:120) Co w sytuacji, kiedy coś pójdzie nie tak? Skończyło się tak, że prześledziliśmy historię od początku i uzupełniliśmy ją o wiele szczegółów. Wynikiem tego było opowiedzenie historii o dniu z życia menedżera zespołu, a także innych osób, których działania są kluczowe dla sukcesu menedżera: fanów i kierowników lokali. Krok „dostosowanie ulotki do własnych potrzeb” po rozłożeniu na szczegóły wyglądałby następująco: Szczegó(cid:293)y (cid:120) wczytaj obraz, (cid:120) dodaj plik audio, (cid:120) osadź film, (cid:120) dodaj tekst, (cid:120) zmień layout, (cid:120) wykorzystaj wcześniejsze materiały promocyjne. Od razu widać, że nawet te pomniejsze kroki wymagają omówienia, aby uzyskać wszystkie istotne szczegóły. Na dobry początek wystarczy je po prostu wymienić. Zauważ, że na kartkach zapisujemy krótkie zwroty, które ułatwiają opowiadanie historyjek. Można je ze sobą połączyć zwrotami typu „lub” czy „bądź”: „menedżer może dostosować ulotkę, wczytując obraz lub dodając do niej plik audio bądź osadzając w niej film, albo…”. To całkiem proste i skuteczne. Zapoznaj się ze szczegółami i możliwościami (cid:95) 49 Poleć książkęKup książkę W końcu zapytałem Gary’ego: „I co teraz? Mamy jeszcze pozostałe kategorie użytkowników i ich własne cele. Chcesz o nich porozmawiać? Sam widzisz, że wkrótce będziemy musieli się przenieść do innego pokoju, żeby kontynuować tę dyskusję. Poza tym jeśli będziesz chciał wprowadzić wszystkie te funkcje do oprogramowania, będzie się to wiązało ze sporymi wydatkami. Możemy porozmawiać o pozostałych wątkach, ale gdybyś wypuścił produkt z wszystkimi tymi funkcjami, które już omówiliśmy, to wydaje mi się, że i tak byłby całkiem wartościowy”. Gary przyznał mi rację i zdecydował, że poprzestaniemy na tym, co już zrobiliśmy. Ta historia ma jednak gorzką puentę. Pod koniec zadałem Gary’emu pytanie: „Zleciłeś już opra- cowanie sporej ilości oprogramowania, ale ile z tego, co już masz, pokrywa się z tym, co znajduje się na naszej mapie?”. „Prawie nic (cid:127) odpowiedział. (cid:127) Kiedy spisałem listę i wyznaczyłem priorytety, jakoś wyszedłem z założenia, że musimy zacząć od czegoś innego. Myślałem o ogólnej wizji całego projektu, której realizacja trwałaby latami. Po tej rozmowie widzę, że zacząłem w zupełnie niewłaściwym miejscu”. Mapowanie historyjek sprowadza się do przeprowadzenia najzwyklejszej na świecie dyskusji i wy- rażenia jej wniosków w formie mapy. Większość ludzi najpierw patrzy na przebieg historii od le- wej do prawej, który określa całokształt opowieści. W kolumnach zapisane są szczegóły. Jednak kluczowe elementy, które definiują kształt produktu i nakreślają właściwy kontekst, często znajdują się ponad mapą lub obok niej. Są to cele, jakie produkt ma osiągnąć, a także informacje o użyt- kownikach i nabywcach. Jeśli chcesz umieścić mapę na ścianie, to weź pod uwagę, że warto wokół niej rozkleić szkice interfejsu użytkownika (UI, z ang. user interface) oraz inne notatki. W ciągu zaledwie jednego dnia współpracy zaczęliśmy razem z Garym rozumieć charakter pro- duktu, jaki chciał stworzyć. Dostrzegliśmy zarazem, że szykuje się rewolucja. Na każdej z kartek za- uważyliśmy wiele dodatkowych szczegółów i punktów wyjścia do kolejnych dyskusji. Dla Gary’ego wszystkie te szczegóły i konwersacje przekładały się na fundusze, które powinien przeznaczyć na opracowanie produktu, a których nie miał. Tym samym poznał jedną z fundamentalnych reguł rządzących produkcją oprogramowania: zawsze jest więcej do zrobienia, niż starczy na to czasu. 50 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Gary przyjął jeszcze wiele innych ogólnych założeń co do tego, jacy ludzie mieliby korzystać z jego produktu, oraz tego, czy rzeczywiście byliby zainteresowani i czy robiliby to tak, jak on sam to sobie wymyślił. W tym momencie nie był to jednak jego największy problem. Musieliśmy dołożyć starań, żeby skonkretyzować jego wizję produktu tak, aby jego opracowanie stało się realnie możliwe. Opowieść o Garym ostatecznie skończyła się szczęśliwie. W następnym rozdziale opowiem jednak o organizacji, której pracownicy uświadomili sobie, że mają za dużo do zrobienia, a następnie wyko- rzystali mapę do znalezienia praktycznego rozwiązania. Na styku sztuki i IT Ceedee (Clare) Doyle, menedżer projektu i szkoleniowiec agile, Assurity Ltd, Wellington, Nowa Zelandia Tło opowieści The Learning Connexion (TLC) jest szkołą artystyczną w nowozelandzkim Wellington, w której pro- wadzi się naukę sztuk pięknych i rozwój kreatywnego myślenia. Program nauczania w TLC jest nietu- zinkowy, ponieważ opiera się zasadzie „nauki poprzez działanie”. Innymi słowy, praktyka jest teorią. Uczniowie we współpracy z opiekunami opracowują briefy opisujące te dziedziny, z którymi chcą się zapoznać. TLC było typową, średniej wielkości organizacją, która tworzyła systemy informatyczne pozwalające na zaspokojenie jej bieżących potrzeb. Informacje o uczniach gromadzono w pięciu różnych miej- scach, a w dodatku były one inne w zależności od systemu. TLC musiało znaleźć jakiś sposób na za- rządzanie uczniami, który przystawałby do obowiązującego w organizacji trybu nauczania — dość odmiennego od tego, z jakim można się spotkać w większości placówek edukacyjnych. TLC nie miało żadnego doświadczenia z projektami IT. Każda mała aplikacja, którą stworzono na potrzeby szkoły, była dziełem różnych krewnych i znajomych; przeważnie oparte były na prostych technologiach, takich jak Microsoft Excel i Access. Jedyna aplikacja komercyjna (służąca do prowadzenia rachunkowości) musiała przetwarzać dane z czterech innych źródeł. Jako była uczennica TLC utrzymuję kontakt z pracownikami, więc zwrócili się do mnie, gdy potrze- bowali mojej pomocy. W roku 2009 miałam już za sobą dziewięć lat doświadczenia w pracy w branży IT, a o wykonaniu zwinnego projektu marzyłam od trzech lat, czyli od kiedy tylko usłyszałam o tej metodyce. Tym samym trafił mi się idealny projekt, w idealnym miejscu i czasie. Project Phoenix Pierwsze warsztaty miały być dwiema trwającymi po pół dnia sesjami z najważniejszymi pracowni- kami. Pracowałam z dużą, zróżnicowaną grupą, a moim celem było wypracowanie wzajemnego zro- zumienia. Zaczęłam od omówienia tego, jak działa mapowanie historyjek, oraz opisania przeglądu najważniejszych kroków procesu zarządzania danymi uczniów. Zapoznaj się ze szczegółami i możliwościami (cid:95) 51 Poleć książkęKup książkę Dopóki nie pokazałam tego rysunku (rdzenia mapy opowieści), każdy pracownik dobrze wiedział, co sam robi, ale po raz pierwszy — jak zauważyła Alice, sponsorka projektu — wszyscy mieli okazję zoba- czyć, gdzie ich działania mieszczą się w ogólnym procesie i jak poszczególne zadania się ze sobą łączą. W tym miejscu przeprowadziliśmy burzę mózgów na temat oczekiwanej funkcjonalności systemu. Zakres funkcji był olbrzymi, a opowieści było co niemiara. Poszło nam całkiem nieźle, bo miałam do czynienia z kreatywnymi ludźmi, przyzwyczajonymi do stoso- wania „podejścia doceniającego”, więc nie mieli żadnego problemu z wyrzucaniem z siebie pomysłów na to, co system musi być w stanie zrobić. Diagram procesu składał się z następujących kroków: Zapytania → Przyjęcia → Zapisy → Zajęcia → Ukończone prace → Zakończenie nauki → Wydanie dyplomu. 52 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Bazując na zasadach mapowania historyjek, prześledziliśmy kolejno każdą sekcję, aby upewnić się, czy wszystko się zgadza i czy udało nam się oddać drogę ucznia przez wszystkie etapy procesu kształcenia. Kilka osób nagle zrozumiało swoją rolę w ogólnym procesie i pojęło, dlaczego muszą wykonywać nie- które ze swoich zadań, podczas gdy inni uświadomili sobie, że są wykluczeni z etapów, na które mogliby mieć istotny wpływ. Przejście po mapie historii i wyłożenie obok siebie w pionie tych historyjek, które odbywały się jednocześnie, pomogło wskazać miejsca, w których można by usprawnić współpracę bądź w których działania się powielały. Do tej pory poszczególni członkowie zespołu nie wiedzieli za dobrze, czym zajmują się pozostali. Nagle udało nam się wypracować wspólne zrozumienie tego, jak działa proces, oraz opracować wspólną terminologię. Na przykład zmieniliśmy nazwę etapu Zajęcia na Nauczanie, ponieważ niektórzy uczniowie kształcili się zdalnie. Zapoznaj się ze szczegółami i możliwościami (cid:95) 53 Poleć książkęKup książkę Przy określaniu priorytetów nie mogliśmy zdać się na podział typu „trzeba zrobić”, „warto zrobić”, „można zrobić”. Trzeba było zdecydować, które elementy zostawiamy, a które odrzucamy. To proste. Kartki, o których mogliśmy uczciwie powiedzieć „bez tego sobie nie poradzimy”, umieszczaliśmy nad „grubą kreską”, a całą resztę pod nią. Po przejściu etapu Zapytań zespół wiedział już, co robić, a resztę dnia spędził na porządkowaniu reszty. Nie musiałam im nawet pomagać! Pracownicy sami zaczęli do- dawać karteczki z opisami typu: „to wszystko musi się dziać naraz, a potem trzeba zrobić to”. W ostatecz- nym rozrachunku udało im się grupowo stworzyć całościowy ogląd etapów, które uczeń musi przejść od pierwszego zgłoszenia do otrzymania dyplomu. Dwie trwające po pół dnia sesje przekształciły się w trzydniowe warsztaty, na których stawiali się różni uczestnicy, kiedy tylko mogli (ponieważ mieli też inne obowiązki, takie jak prowadzenie zajęć). Dzięki panującej w organizacji swobodnej atmosferze pracy niemal wszyscy pracownicy przewinęli się przez naszą salę i dorzucili swoje trzy grosze. Stwierdzili, że proces ten znacząco ułatwia zrozumienie ogólnego zarysu przedsięwzięcia i pozwala na uwzględnienie potrzeb wszystkich zainteresowanych. Ponadto można było dzięki niemu wyłapać luki i wskazać, jakie elementy są rzeczywiście istotne. Pod koniec naszej wspólnej pracy mieliśmy już jasny obraz tego, co przede wszystkim trzeba zawrzeć w pierwszej wersji oprogramowania. 54 (cid:95) Rozdział 1. Obraz całości Poleć książkęKup książkę Skorowidz A E akwarium kuliste, 217 analityk biznesowy, 21, 125, 156, 167, 212, 213 empatyzacja, 199 epos, 150, 151, 169 B Barrett Luke, 28 Beck Kent, 12, 20, 40, 109, 115, 140 Blank Steve, 65, 203 budżet, 84, 129 C Cagan Marty, 77, 162, 171 Cardboard, 131 ciąg narracyjny, 58, 95, 96, 97, 99 Cockburn Alistair, 82, 93, 139 Confluence, 132 Connextra, 116 cykl produkcyjny, Patrz: produkcja cykl czas, 84 D da Vinci Leonardo, 86, 88 Davies Rachel, 115 design thinking, 77, 199, 202, 205 budowanie prototypów, 201 definiowanie problemu, 200 empatyzacja, Patrz: empatyzacja generowanie pomysłów, 201 testowanie, 201, 206, 207, 208 dokument idealny, 30 działanie, 97, 99, 106 G grzejnik informacyjny, 128 H Halley Lane, 184 harmonogram produkcji, 61 wydania, 62 HiPPO, 65 historyjka użytkownika, 11, 30, 37, 40, 110, 136, 168, 208 budżet, 129 daty, 130 dyskusja, 120, 121, 122, 123, 136, 149, 155, 164, 166, 174, 194, 217 grupowanie, 151 karta, 129, 212 kryteria akceptacji, 21 mapowanie, 11, 14, 19, 41, 59, 104, 105, 106, 109, 154, 174, 230, Patrz też: mapa numer, 129 opis, 129 priorytet, 129 priorytetyzacja, 193, 194 pułapki, 20 status, 130 szablon, Patrz: szablon tworzenie, 152, 161 tytuł, 116, 125, 129 warsztat, Patrz: warsztat 251 Poleć książkęKup książkę HiPPO wielkość, 147, 148, 149, 150, 154, 219, 227 wskaźniki, 130, 160 zależności, 130 Hussman David, 96, 167 I ideacja, 188 interfejs użytkownika, Patrz: użytkownik interfejs klient, 70, 153, 195 Kniberg Henrik, 75 K L Lean Startup, 76, 77, 203, 204, 208 Lean User Experience, 77 Levitt Gary, 42 lodówka informacyjna, 128 M manifest programowania zwinnego, 39, 135, 140 mapa, 55, 73, 80, 95, 96, 102, 104, 174, 191, 208, produktu, Patrz: produkt menedżer projektu, Patrz: projekt menedżer metoda Design Studio, 187, 188 Design Thinking, 77, 199 HiPPO, 65 Lean Startup, 76, 77 Lean User Experience, 77 minimum viable product, Patrz: MVP minimum viable product experiment, Patrz: MVPe minimum viable solution, Patrz: MVS MVP, 65, 66, 207 MVPe, 76, 78 MVS, 66, 153, 159, 193, 197 252 (cid:95) Skorowidz 222, 223 plaster, 82, 83, 99, 192 podróży, 102, 174, 178 narracyjna, 185 produktu, 174, 175, 178 rdzeń, Patrz: rdzeń rozwiązania, 185 skalowanie, 107 menedżer nabywca wczesny, 73 nagroda, 102 narzędzie testowe, 82 N O okazja, 152, 169, 174, 228 cechy, 169 dyskusja, 170 ewaluacja, 171 rejestr, Patrz: rejestr okazji zarządzanie, 174 oprogramowanie, 13 orgzon, 184 P persona, 183 Pigneur Yves, 171 pomiar, 83 pomysł, 102, 191, 201 poziom, 94, 99 problem, 102, 181, 192, 200 proces projektowy, 198, 202, 204, 205, 206 produkcja, 33 cykl, 221, 223, 227 planowanie, 228 harmonogram, Patrz: harmonogram produkcji iteracja, Patrz: iteracja minimalizowanie, 35, 55, 192 szybkość, 33 produkt, 33, 66, 70 do rozważenia, 191 eksperymentalny o minimalnej koniecznej funkcjonalności, Patrz: MVPe mapa, Patrz: mapa produktu menedżer, 21, 125, 162, 163 o minimalnej koniecznej funkcjonalności, Patrz: MVP odkrywanie, 77 projektowanie, 198, 202, 204, 205, 206 przegląd z interesariuszami, 236 rejestr, Patrz: rejestr produktu właściciel, 21, 69, 71, 125, 156, 161, 162, 163, 167 złożony, 105 profil organizacyjny, Patrz: orgzon Poleć książkęKup książkę programowanie ekstremalne, 154, 221 zwinne, 11, 20 manifest, Patrz: manifest programowania zwinnego projekt menedżer, 125, 126 projektant interakcji, 71 UX, 125, 126, 156, 184, 186, 212 prototyp, 71, 72, 201 pytanie, 102 R rdzeń, 57, 58, 73, 97 rejestr, 56, 71, 106, 192, 229 okazji, 152, 170 pielęgnacja, 155 produktu, 112, 181 wydania, 154 Repucci Demian, 186 rezultat, 33, 62, 66 biznesowy, 193 maksymalizowanie, 35 Ries Eric, 65, 66, 76, 203 Robinson Frank, 65 rozwiązanie, 185 mapa, Patrz: mapa rozwiązania o minimalnej koniecznej funkcjonalności, Patrz: MVS użyteczne, 181 Rumsfeld Donald, 82 ryzyko, 90 S spike, 154 sprint, 74, 214 przegląd, 157, 233, 234 storyboard, 186 strategia produkcyjna, 89, 228 zdobywania weryfikowanej wiedzy, 76 szablon, 118 Connextra, 116 Opportunity Assessment, 171, 172, 173 szablonowy zombie, 118 temat, 151 tester, 125, 212, 213 testowanie, 201, 235, 238 triada, 163, 164 T U Unger Jim, 187 user experience, Patrz: UX user stories, Patrz: historyjka użytkownika UX, 21, 174, 176, 187, 234 użytkownik, 65, 70, 106, 153, 195, 238 historyjka, Patrz: historyjka użytkownika interfejs, 120 scenariusz, 71 wrażenia, Patrz: UX zadanie, Patrz: zadanie W warsztat, 155, 164, 212, 219, 223 program, 213 White Jeff, 187 wpływ, 34, 35 wskaźnik pomiarowy, 160 wspólne rozumienie, 28, 70, 81, 103, 131, 181, 182, 195, 205, 214, 222 wymagania, 33, 36, 37, 174, 214 niefunkcjonalne, 27 Z zadanie, 92, 99 poziomu funkcyjnego, 94 stos, 95 sumaryczne, 94 zdjęcie z wakacji, 123, 132, 136 zombie szablonowy, 118 Skorowidz (cid:95) 253 Poleć książkęKup książkę 254 (cid:95) Skorowidz Poleć książkęKup książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Mapowanie historyjek użytkownika. Przepis na produkt idealny
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: