Budowanie wspólnego zrozumienia #storymapping

Przykład Story Mappingu

Przykład Story Mappingu

Kilka godzin temu zakończyłem warsztaty produktowe. Ich głównym celem było przygotowanie użytecznego oraz wykonalnego rozwiązania, realizującego konkretną potrzebę klienta.

To już któryś raz z rzędu, gdy wychodzę z tego rodzaju warsztatów zafascynowany, jak niesamowicie prostym, a zarazem nadzwyczaj skutecznym narzędziem jest Story Mapping.

Posłużę się prawdziwym przykładem, oczywiście na potrzeby tego wpisu w uproszczonej wersji, aby móc podzielić się z Wami wysokopoziomową ideą oraz przebiegiem samego ćwiczenia. Czytaj dalej

Co to jest MVP (Minimum Viable Product) i jak zrobić to dobrze?

MVP - czy nasz produkt przeżyje crash-test z rynkiem?

MVP – czy nasz produkt przeżyje crash-test z rynkiem?

Powiedzmy to sobie wprost – nie mówmy o projekcie trwającym kilka miesięcy, z którego usunęliśmy kilka nikomu nie potrzebnych funkcji, że zbudowaliśmy MVP (ang. Minimum Viable Product). Sam popełniłem ten błąd kilka lat temu, zbyt długo rozwijając produkt w ukryciu, zanim zdecydowaliśmy się wypuścić go publicznie. Bardzo chcieliśmy uniknąć zażenowania po wypuszczeniu pierwszej wersji, co zdaniem założyciela LinkedIn oznacza, że najprawdopodobniej prezentujesz swój produkt zbyt późno.

MVP to nic innego jak wykonanie jak najmniejszego możliwego kroku, który pozwoli nam przetestować nasz pomysł na biznes i zdobyć wiedzę. Krok ten im mniej kosztowny tym lepszy, bo przecież nie mamy pewności, że ktokolwiek jest gotowy płacić za to, co planujemy stworzyć.

Nie ma to nic wspólnego z odchudzaniem gotowych produktów z mniej istotnych funkcji – taką strategię nazywamy raczej zdrowym rozsądkiem ;)

Poniżej kilka przykładów obrazujących, co to znaczy stworzyć MVP:

  • IBM* rozważał wprowadzenie na rynek systemów sterowanych głosem. Zamiast spędzić miesiące/lata nad budową skomplikowanych algorytmów, przeprowadził prosty i genialny zarazem eksperyment: zaprosił ludzi do testowania nowego systemu, który reagował na polecenia głosowe. Biorący udział w eksperymencie nie wiedzieli, że to nie maszyna wykonuje ich polecenia, a żywy człowiek, siedzący w pokoju obok. Pomimo 100% skuteczności w rozpoznawaniu komend przez „komputer”, ludzie biorący udział w eksperymencie wypowiadali się negatywnie o całym pomyśle – woleli bowiem sterować komputerem ręcznie, przy pomocy klawiatury oraz myszy.
  • Buffer – zanim aplikacja powstała, autor przygotował stronę, na której w paru słowach opisał działanie aplikacji oraz umieścił przycisk „Plans and Pricing”. Dowiedział się w ten sposób, czy ktokolwiek jest zainteresowany jego aplikacją. Kolejnym krokiem nie było napisanie aplikacji, tylko dodanie kolejnej podstrony z dostępnymi abonamentami. Zainteresowani eksplorowali stronę, odpowiadając w ten sposób na pytanie, czy ktokolwiek jest gotowy zapłacić za jego software.
  • startup ze Stanford – grupa osób chciała użyć dronów do wykonywania super-szczegółowych zdjęć plantacji rolniczych, aby później sprzedawać te zdjęcia rolnikom, którzy na ich podstawie mogliby ocenić ogólny stan ich pól (choroby, brak wody, inne szkody). Zamiast budować drona od podstaw, zachęcono ich, aby na początek wypożyczyli działający egzemplarz, zrobili zdjęcia i gdy okaże się, że rolnicy są gotowi im za nie zapłacić, to wtedy dopiero zastanawiać się nad budowaniem własnego drona.
  • Dropbox – zanim autor na poważnie zaczął rozwijać aplikację, przygotował nagranie video, w którym zaprezentował ideę działania aplikacji. Aplikacja bowiem wbrew pozorom nie jest banalna z technicznego punktu widzenia – wiele różnych platform sprzętowych, bezpieczeństwo danych, proces synchornizacji danych itd. Feedback jaki otrzymał od potencjalnych użytkowników zafascynowanych jego nagraniem upewnił go w przekonaniu, że aplikacja może być strzałem w dziesiątkę i warto ją dalej rozwijać.

Znasz jakiś inny, warty wspomnienia przykład MVP? Napisz o tym w komentarzu.

* – nie dam głowy, że chodziło o IBM, ale nie znalazłem w sensownym czasie źródła

Fotografia użyta na licencji Creative Commons od użytkownika lincolnblues.

Najstarsze i najlepsze narzędzie wspierające pracę zespołów

Narzędzia pracy zespołu

Narzędzia pracy zespołu

Pracowałem ostatnio z dwoma zespołami, w których zmienił się skład osobowy. Pierwszy zespół został pomniejszony o kilka osób, przy czym trzon zespołu pozostał bez zmian. Drugi zespół został tak naprawdę stworzony „od zera”, a ludzie tworzący ten zespół nie pracowali ze sobą wcześniej.

Dla jednego oraz drugiego zespołu zmiany te były punktem zwrotnym, który wymusił na nich chwilę refleksji, pozwolił spojrzeć w przeszłość, jak i zastanowić się nad przyszłą formą współpracy.

Pomyślałem, że to dobry moment, aby przeprowadzić proste ćwiczenie i porozmawiać o oczekiwaniach wobec konkretnych postaci w zespole. Pomogły nam w tym trzy pytania:

  • Jakie są wasze oczekiwania wobec Product Ownera?
  • Jakie są wasze oczekiwania wobec Scrum Mastera?
  • Jakie są wasze oczekiwania wobec Zespołu Deweloperskiego? (czyli w większości wobec siebie samych)

W obu przypadkach dosyć sprawnie zebraliśmy oczekiwania, omówiliśmy je oraz zapisaliśmy w postaci listy. Obydwa zespoły miały nieco inne pomysły, które wynikały między innymi z doświadczeń z przeszłości – jeśli coś nie działało wcześniej, to teraz chcieliby, aby działało to poprawnie.

Przykładowo, oczekiwanie wobec Product Ownera „musi być decyzyjny”, może świadczyć o tym, że poprzednio zespół doświadczył pracy z osobą, która nie miała ostatniego słowa w kwestii rozwoju produktu.

Tak stworzone listy mogą być świetnym materiałem wspomagającym rozwój zespołu. Z jednej strony, dla osób pełniących konkretną rolę (Product Owner, Scrum Master) jest to drogowskaz, który mówi im o potrzebach reszty teamu. Pozwala rozwijać brakujące umiejętności lub upewnić się, że pewne postawy są doceniane przez zespół.

Z drugiej strony jest to lista, do której można się odwołać w kryzysowych sytuacjach i zastanowić się, czy spełniamy zebrane wcześniej oczekiwania, a także sprawdzić, czy któreś z oczekiwań uległo zmianie.

Dostrzegam w tym ćwiczeniu niewielkie ryzyko – pewne oczekiwania wobec ról mogą być bądź nie do spełnienia w krótkim czasie, bądź nieadekwatne wobec konkretnej roli. Sądzę jednak, że nie ma to ostatecznie dużego znaczenia. Zespół po pewnym czasie sam do tego dojdzie i w razie potrzeby dokona adaptacji.

OK, wystarczy już pisania o samym ćwiczeniu. Największa jego wartość to – wbrew pozorom – nie lista ze spisanymi oczekiwaniami, a podsunięcie zespołowi sprawdzonego narzędzia, które w przyszłości pozwoli na rozwiązywanie problemów dowolnego kalibru.

To narzędzie to szczera i otwarta komunikacja.

Fotografia użyta na licencji Creative Commons od użytkownika juanpol.

Swarming – technika dla zespołu pomagająca kończyć zadania

Swarming w praktyce

Swarming w praktyce

Pomagałem ostatnio nowo powstałemu zespołowi podczas ich drugiego Sprintu. Kiedy się u nich pojawiłem – dzień przed Sprint Review – na tablicy korkowej wisiało 10 zadań, z czego tylko 1 było zakończone. Co więcej, było to zadanie znajdujące się na ostatniej pozycji ich Sprint Backlogu.

Podczas rozmowy ze Scrum Masterem tego zespołu dowiedziałem się, że mają problem z finalizowaniem zadań oraz, że to kolejny sprint, kiedy dużo pracy jest w trakcie realizacji, a pomimo tego niewiele jest faktycznie skończone.

Co to jest swarming?

Zaproponowałem użycie techniki zwanej swarming (ang. rój). Polega ona na tym, że w danym momencie cały zespół pracuje nad jedną, wybraną historyjką i nie przechodzi do kolejnej, zanim poprzednia nie zostanie zakończona.

Jak podzielić się pracą?

Oczywiście od razu pojawiło się pytanie – „no dobrze, ale jak zorganizować pracę, żeby wszyscy mieli co robić?”. Poniżej kilka przykładów pracy, która może zostać wykonana równocześnie w ramach pracy nad jednym zadaniem:

  • przygotowanie scenariuszy testowych
  • zdobycie brakującej wiedzy biznesowej potrzebnej do realizacji zadania
  • napisanie unit testów
  • konfiguracja środowiska testowego (zapewnienie danych, połączeń do zewnętrznych systemów, konfiguracja)
  • nagranie testów automatycznych (początkową będą świecić na czerwono)
  • opracowanie planu prezentacji przyrostu na Sprint Review
  • przyglądnięcie się zadaniu z perspektywy Definition of Done
  • programowanie w parach
  • konsultacja rozwiązania z innymi deweloperami (spoza zespołu)

Na co zwrócić uwagę?

  • rozmiar zadania – zbyt małe zadanie może powodować, że trudno będzie sensownie podzielić się pracą; z drugiej strony zbyt duże może spowodować, że w rzeczywistości każdy zajmie się swoim, niezależnym fragmentem większej historyjki
  • liczba jednocześnie realizowanych zadań – spotkałem się z wariantem „dwie historyjki na raz” oraz „tyle historyjek na raz, ilu testerów w zespole”

Fotografia użyta na licencji Creative Commons od użytkownika SidPix.

Sposoby dzielenia User Stories na małe części

Małe, zbywalne kawałki - tak myśl o user stories

Małe, zbywalne kawałki – tak myśl o user stories

Efektem każdego sprintu w Scrumie powinien być działający fragment oprogramowania. Problematyczne dla wielu zespołów – szczególnie jeśli wcześniej pracowali w modelu kaskadowym – jest dzielenie wymagań produktowych na małe, zbywalne przyrosty. Często słyszy się głosy z zespołu mówiące, że krótkie sprinty uniemożliwiają oddanie sensownego przyrostu, a jako rozwiązanie proponują wydłużyć sprint.

Idąc tym tokiem myślenia możemy założyć, że skoro w ciągu jednotygodniowego sprintu oddajemy zero działającego oprogramowania, to w ciągu dwutygodniowego sprintu oddamy… 2 razy zero.

Jak zatem uporać się ze wspomnianym zerem? Przy dzieleniu wymagań na mniejsze części, pomocne może być spojrzenie z kilku perspektyw i próba odpowiedzi na proste pytania:

  • użytkownik – Która rola jest najważniejsza? Czy możemy obsłużyć na początku tylko zwykłego użytkownika? Który typ użytkownika jest najczęściej wykorzystywany?
  • dane – Czy możemy pewne dane odczytać z pliku zamiast z bazy? Czy możemy użyć wygenerowanych danych? Które dane są najistotniejsze, a które opcjonalne?
  • algorytmy – Jak możemy maksymalnie uprościć algorytm? Czy zamiast pisać kompletny algorytm, możemy go zasymulować? Czy możemy użyć Mechanicznego Turka?
  • wydajność – Czy zanim wydajność będzie satysfakcjonująca, funkcjonalność może po prostu zacząć działać? Czy musimy od razu umożliwiać obsługę 100 tys żądań na sekundę? Czy możemy póki co poczekać 5 sekund na wynik zapytania i upewnić się, że wynik (dane) jest dla nas satysfakcjonujący?
  • bezpieczeństwo – Czy moglibyśmy najpierw udowodnić, że nasz pomysł działa, zanim zabezpieczymy się przed każdym możliwym sposobem ataku?
  • interfejs – Czy możemy wyświetlić wynik w konsoli zamiast na stronie internetowej? Czy możemy odczytać wynik z logów? Czy możemy przygotować formularz w czystym HTML’u, zanim zaczniemy zaokrągląć rogi w CSS?
  • ścieżki procesu – Czy możemy obsłużyć najbardziej prawdopodobną scieżkę procesu bez ścieżek warunkowych? Która ścieżka jest najbardziej prawdopodobna? Którą scieżką użytkownicy porusząją się najczęściej?
  • walidacja danych – Czy możemy zrezygnować z walidacji danych w formularzu? Czy możemy zrezygnować z walidacji w Javascripcie? Czy możemy tymczasowo przyjąć, że klient wie co wpisuje?
  • zarządzanie danych – Czy potrzebujemy panel administratora, czy możemy aktualizować dane bezpośrednio w bazie danych? Czy możemy aktualizować pliki z danymi ręcznie? Czy możemy przyjąć domyślne dane i póki co ich nie aktualizować?
  • częstotliwość użycia – Które funkcje są najważniejsze/najczęściej używane przez użytkowników? Które składają się na MVP (ang. Minimum Viable Product)?

Gdy następnym usłyszysz, że „tej historyjki się nie da pociąć na mniejsze części”, zaproponuj spojrzenie na problem z perspektywy powyższej listy.

Fotografia użyta na licencji Creative Commons od użytkownika Ben Sutherland.