Skip to content

Właściciel Produktu to także członek zespołu

Od zawsze traktowaliśmy klienta jako tę drugą stronę. Zawsze byliśmy „my” i zawsze byli „oni”. Nawet pracując w Scrumie z wewnętrznym klientem, kiedy rolę Właściciela Produktu (Product Owner) pełni osoba z naszej organizacji, nader często jesteśmy świadkami postawy „my kontra oni”. Postawę tę można zaobserwować najczęściej podczas Planowania czy Przeglądu Sprintu, ale także w pracy codziennej w trakcie Sprintu czy przy innych okazjach. Deweloperzy najczęściej winą za coś obarczają Właściciela Produktu i vice versa.

Postawa jest wynikiem przyzwyczajeń, które Scrum próbuje naprostować w postaci Zespołu Scrumowego, w którego skład wchodzą: Właściciel Produktu, Zespół Deweloperski i Scrum Master. Kiedy jednak mówimy o zespole w kontekście Scruma, najczęściej mamy na myśli jedynie Zespół Deweloperski. Zapominamy, że Zespół Scrumowy to także zespół, a Właściciel Produktu jest jego członkiem. 

Jako członkowie Zespołów Scrumowych powinniśmy współpracować na zasadach pracy zespołowej i znosić bariery komunikacyjne między poszczególnymi członkami zespołu.

Jeśli więc jesteś deweloperem, a szczególnie jeśli jesteś Scrum Masterem, następnym razem, kiedy zobaczysz, że Właściciel Produktu ma problem np. ze sformułowaniem historyjki użytkownika, zamiast narzekać na brak kompetencji u niego, spróbuj mu pomóc, tak jakbyś pomógł koledze z zespołu. Jeśli jesteś Właścicielem Produktu i np. zbyt często nie akceptujesz wykonanej przez deweloperów pracy, bądź dla nich dostępny w trakcie Sprintu i staraj się im pomóc, a nie tylko wymagaj. Niezależnie od roli pamiętaj, że razem tworzycie zespół i także od Ciebie zależy, czy będzie to prawdziwy zgrany zespół, czy będzie nim tylko z nazwy.

Categories: Product Owner, Team.

Czy User Experience można zaprojektować?

Hasło user experience (UX) od jakiegoś już czasu jest silnie obecne w branży interaktywnej i ogólnie w wytwarzaniu oprogramowania. Mówimy o projektowaniu UX, powstały stanowiska User Experience Designer czy User Experience Director. 

Cieszy rosnąca świadomość wagi user experience w kontekście sukcesu produktu, jakim jest serwis internetowy czy w ogóle oprogramowanie użytkowe, ale niesłusznie jest to często sprowadzane do badania użyteczności i projektowania interfejsu użytkownika (UI).

Wikipedia:

User experience (UX) is the way a person feels about using a product, system or service. […] ISO 9241-210 defines user experience as „a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. So, user experience is subjective and focuses on the use.

User experience to wszystko to, czego osoba doświadcza podczas korzystania z produktu, systemu lub usługi. Całość odczuć, wrażeń, które są wynikiem wpływu kilku czynników: samego użytkownika, właściwości produktu oraz kontekstu, w jakim produkt jest używany.

Odczuć i wrażeń zaprojektować się nie da. Zaprojektować można produkt z myślą o użytkowniku i czynnikach wpływających na jego odczucia.

Sama lista właściwości produktu, jakim jest oprogramowanie, które wpływają na odczucia użytkownika jest bardzo długa. Nie chodzi tylko i wyłącznie o użyteczność i ergonomię interfejsu, ale też o stabilność działania, poczucie bezpieczeństwa, wydajność, szybkość odpowiedzi na interakcję ze strony użytkownika, dostępność (accessibility), dostępność (availability) i wiele innych kwestii.

Mnogość czynników oraz szeroki zakres wiedzy i niezbędnych umiejętności powodują, że zapewnianie dobrego user experience to działalność złożona i wymaga współpracy specjalistów z wielu dziedzin: projektantów, programistów, administratorów, grafików, analityków, konsultantów biura obsługi klienta, marketerów itd.

Tak więc zapewnianie dobrego user experience, to rzeczywiście coś dużo więcej niż projektowanie interfejsu i testowanie użyteczności. Czy to jednak oznacza, że potrzebujemy stanowisk typu UX Specialist, UX Designer, UX Director?

Jesteśmy chyba jedyną branżą, w której mamy stanowiska dedykowane UX. Inne branże, w których nie chodzi o nic innego, jak o user experience, nie potrzebują dedykowanych temu stanowisk. W branży filmowej mamy reżyserów, scenarzystów, aktorów, kompozytorów, scenografów, inżynierów dźwięku, kamerzystów, specjalistów wielu innych dziedzin. Każdy z nich robi swoje i współpracuje z resztą zespołu ze świadomością, że ostatecznie liczy się „user experience” widza. Bez pomocy User Experience Directora.

Dlaczego nam już nie wystarcza specjalista ds. użyteczności (Usability Specialist) czy projektant interfejsu (UI Designer)?

Categories: UX.

Prędkość a pojemność

Załóżmy, że dwa zespoły rozpoczynają pracę nad jednym i tym samym Backlogiem Produktu i niezależnie od siebie pracują nad tymi samymi historyjkami użytkownika (user stories). Dla uproszczenia przyjmijmy, że wszystkie historyjki zostały oszacowane na 5 punktów (story points) każda.

Elementy Backlogu Produktu Estymata
Historyjka A 5 pkt.
Historyjka B 5 pkt.
Historyjka C 5 pkt.
Historyjka D 5 pkt.
Historyjka E 5 pkt.
Historyjka F 5 pkt.
Historyjka G 5 pkt.
Historyjka H 5 pkt.
Historyjka I 5 pkt.
Historyjka J 5 pkt.

Sprint pierwszy

Na pierwszy Sprint każdy zespół wybrał po 3 historyjki: A, B i C. Oba zespoły ukończyły wszystkie zaplanowane historyjki, a więc prędkość (velocity) obu zespołów jest taka sama i wynosi 15.

Sprint drugi

Na drugi Sprint oba zespoły wybierają znowu po 3 historyjki: D, E, F i znowu wszystkie udaje im się ukończyć. Prędkość znowu 15.

Sprint trzeci

Na trzeci Sprint zespół nr 1 wybiera historyjki G, H i I. Zespół nr 2 natomiast wykrył błąd w aplikacji, który powstał podczas realizacji Historyjki B. Zespół dodaje więc do Backlogu Produktu element „Błąd B#1”, usunięcie którego zespół szacuje też na 5 pkt. Do trzeciego Sprintu wybiera więc usunięcie błędu B#1 oraz historyjki G i H, bo więcej nie zdąży zrobić.

Obu zespołom udaje się ukończyć wszystko, co sobie zaplanowały na Sprint. Prędkość obu zespołów znowu jest taka sama i wynosi 15. Czyżby?

Nie bilansuje się

Spójrzmy na Backlog Produktu i stan samego produktu. Produkt jest bogatszy w przypadku zespołu nr 1 o historyjkę I. Zespół 2 dopuścił się gdzieś wcześniej (przy historyjce B) zaniedbania i za ukończone zostało uznane coś, co zawierało defekt. Więc tak naprawdę należałoby cofnąć się do pierwszego Sprintu, cofnąć akceptację historyjki B i obliczyć prędkość zespołu na 10. Oczywiście nikt tego nie robi.

W takich przypadkach należy przyznać zespołowi nr 2 na start trzeciego Sprintu −5 do prędkości i wtedy wszystko się bilansuje. Prościej: nie wliczać do prędkości zespołu prac mających na celu usunięcie usterki. Dla pełnej przejrzystości rozgraniczyć prędkość (velocity) i pojemność (capacity) zespołu. W tym przypadku za trzeci Sprint prędkość zespołu nr 2 wynosiła 10, a pojemność — 15.

Uogólniając:

  • Prędkość zespołu to wszystkie ukończone w trakcie Sprintu elementy Backlogu Produktu, które tworzą wartość dodaną do produktu.
  • Pojemność zespołu to wykonana w trakcie Sprintu praca. Pojemność wyznacza możliwą do osiągnięcia prędkość, gdyby były przetwarzane tylko te elementy, które tworzą wartość dodaną, a praca była ukończona.

Co tworzy wartość dodaną?

Czy tylko usuwanie usterek i nieukończona praca nie powinny być wliczane do prędkości? Co tworzy wartość dodaną, a co nie? Posłużmy się autem, jako analogią.

Załóżmy, że jesteśmy właścicielem auta o nominalnej wartości 20 tys. złotych. Jak wiadomo, auto się czasem psuje i usterki trzeba usuwać, należy też dokonywać okresowych przeglądów i ponosić koszty na profilaktyczne naprawy. Wszystkie te prace, choć potrzebne, i związane z nimi koszty nie zwiększają nominalnej wartości naszego auta. Co innego, jeśli zainwestujemy na przykład w sprzęt audio, zamontujemy czujnik cofania (którego domyślnie nie było), wymienimy felgi na alu itp.

Tak samo należy patrzeć produkt, jakim jest oprogramowanie. Usuwanie usterek, refaktoryzacja, uzupełnianie kodu testami jednostkowymi, analizy, raporty, dopisywanie dokumentacji „po fakcie” — to wszystko, choć wartościowe, nie dodaje wartości produktowi, a jest jedynie kosztem ponoszonym na jego utrzymanie, a czasem wręcz spłacaniem długu technologicznego, czyli wyrównywaniem poziomu jakości do pewnego stanu zero, a nie na plus.

Warto rozgraniczać te dwie metryki; zwiększa to przejrzystość, a Zespół Scrumowy i interesariusze mają jaśniejszy obraz całej sytuacji, a ich analiza (np. w trakcie Retrospektywy) może pomóc w poszukiwaniu metody na zwiększenie prędkości.

Categories: Metryki.

Przegląd Sprintu to nie (tylko) demo

Na koniec każdego Sprintu odbywa się Przegląd Sprintu (Sprint Review). Często spotkanie to określa się potocznie jako Demo, bo Zespół Deweloperski demonstruje wtedy to, co udało się stworzyć w trakcie Sprintu. W praktyce więc spotkanie to często sprowadza się do demonstracji wprowadzonych nowych lub zmienionych funkcjonalności dla Właściciela Produktu.

Prezentacja produktu, choć kluczowa, nie jest jednak jedynym elementem tego spotkania, ani tym bardziej jego celem samym w sobie. Prezentacja Przyrostu produktu jest niezbędna, aby można było dokonać jego inspekcji, co ma prowadzić do adaptacji pod postacią zmian w Backlogu Produktu.

Jest to także spotkanie, w którym oprócz Zespołu Scrumowego uczestniczą pozostali interesariusze. Aby mogli oni udzielić wartościowej informacji zwrotnej, potrzebują kontekstu, jaki stanowi aktualny Backlog Produktu prezentowany i omawiany przez Właściciela Produktu.

Zamiast więc myśleć o Przeglądzie Sprintu jako demonstracji zmian w produkcie przez Zespół Deweloperski dla Właściciela Produktu, należy spojrzeć na to jak na:

  • prezentację wyników Sprintu w kontekście planów rozwoju produktu
  • przez cały Zespół Scrumowy dla interesariuszy obecnych na spotkaniu
  • w celu uzyskania informacji zwrotnej i ustalenia najbliższych kroków.

Aby to osiągnąć należy dobrze zaplanować i przeprowadzić samo spotkanie, które może przyjąć następujący przebieg:

  1. Właściciel Produktu przypomina Cel Sprintu i określa, czy udało się go osiągnąć.
  2. Właściciel Produktu wymienia elementy Backlogu Produktu (np. historyjki użytkownika) wybrane przez Zespół Deweloperski do Sprintu i określa, które z nich zostały ukończone.
  3. Zespół Deweloperski demonstruje to, co udało się ukończyć, odpowiada na pytania dotyczące produktu oraz omawia problemy, jakie napotkał w trakcie pracy i jak je rozwiązał.
  4. Właściciel Produktu prezentuje aktualny Backlog Produktu omawiając zmiany, jakie zaszły w nim od ostatniego Przeglądu.
  5. Biorąc pod uwagę postępy i tempo prac Właściciel Produktu przewiduje termin zakończenia prac i najbliższego wydania oraz przedstawia alternatywne drogi do osiągnięcia celu. Pomocne może być wyliczenie aktualnej prędkości (velocity) oraz symulacja terminu zakończenia różnego zakresu prac przy różnych założeniach co do prędkości.
  6. Zespół Scrumowy wraz z obecnymi na spotkaniu interesariuszami omawia najbliższe kroki, czyli to, co najprawdopodobniej będzie robione w nadchodzącym Sprincie.

Na wejściu mamy więc Przyrost produktu, na wyjściu zaś powinniśmy otrzymać uaktualniony Backlog Produktu, który posłuży Zespołowi Scrumowemu w jak najlepszym zaplanowaniu kolejnego Sprintu.

Podsumowując: Przegląd Sprintu to nie (tylko) demo, ani tym bardziej spotkanie statusowe, na którym Zespół Deweloperski raportuje Właścicielowi Produktu i zbiera oklaski bądź wysłuchuje słów krytyki. Przegląd Sprintu to spotkanie robocze całego Zespołu Scrumowego oraz interesariuszy nad produktem i planami jego rozwoju.

Categories: Sprint Review.

Optymalna długość Sprintu

Długość iteracji w Scrumie (Sprint) jest ograniczona do jednego miesiąca kalendarzowego. Chociaż w najnowszej wersji Scrum Guide’a nie ma określonego minimalnego czasu trwania Sprintu, to przyjmuje się, że krótsze niż jeden tydzień mogą być nieefektywne. Jak określić optymalną długość Sprintu?

Długość Sprintu powinna być określana na podstawie akceptowalnego poziomu ryzyka z jednej strony i czasu potrzebnego zespołowi na wytworzenie czegoś ukończonego z drugiej. Poziom ryzyka zależy od złożoności środowiska, w jakim pracujemy i horyzontu planowania.

Czynniki składające się na złożoność środowiska to: wymagania (ich znajomość i zmienność, co ma odzwierciedlenie w Backlogu Produktu i jego dynamice); technologia (nowa czy dobrze znana itd.); i ludzie (wielkość zespołu, zgranie, doświadczenie i poziom umiejętności, różnorodność specjalizacji itd.).

Jeśli więc mamy np. początek projektu, kiedy w wymaganiach jest dużo niewiadomych, często się zmieniają, Zespół Deweloperski jest liczny (np. 6-9 osób), świeżo skompletowany i do tego pracuje w nowej technologii, której nie zna, to mamy do czynienia z bardzo złożonym środowiskiem. Obranie więc 30-dniowego horyzontu planowania w takiej sytuacji spowoduje prawdopodobnie to, że poziom ryzyka będzie nie do przyjęcia. Chcąc go ograniczyć można redukować złożoność albo skracać horyzont planowania.

Oczywiście redukując i skracając do minimum możemy dojść do sytuacji, kiedy taki „zespół” nie będzie w stanie niczego wytworzyć. To ta druga strona, determinująca minimalną długość iteracji.

Tak więc to wszystko zależy od bardzo wielu czynników i nie ma prostej odpowiedzi na pytanie o optymalną długość Sprintu, chociaż ogólne wzorce można spróbować określić:

  • Dla krótkiego projektu (np. 2-miesięcznego) lepsze będą krótkie iteracje (np. 1-2 tygodniowe), bo długich (miesięcznych) będzie po prostu za mało i będziemy mieli zbyt mało okazji do inspekcji i adaptacji. W długich projektach można zaryzykować dłuższe iteracje, bo krótkie mogą okazać się zbędnym narzutem organizacyjnym.
  • Jeżeli mamy do czynienia z mało zaangażowanym klientem, lepsze mogą być znowu krótsze iteracje, bo zmusi go to do częstszych kontaktów z zespołem. Z zaangażowanym, ulokowanym w pobliżu zespołu Właścicielem Produktu umiejącym wykorzystywać Scrum w swojej pracy, można spróbować dłuższych.
  • Dla świeżych i niedoświadczonych zespołów znowu lepsze mogą być krótsze iteracje, żeby zespół nauczył się wytwarzać coś małego ale ukończonego. Długie iteracje to zbyt duże ryzyko, że więcej czasu i pracy się zmarnuje. O miesięczne Sprinty może się pokusić zgrany zespół wyjadaczy.
  • Jeżeli wymagania są słabo znane albo uczymy się nowej technologii, może być potrzeba wprowadzania częstszych zmian i szybszego uzyskiwania informacji zwrotnej, a więc krótsze iteracje. Stabilny, dobrze przygotowany Backlog Produktu, oraz technologia, z którą czujemy się komfortowo — można dłuższe.

Ważne jest, żeby zdawać sobie sprawę z tych wszystkich czynników i przy określaniu długości Sprintu brać je wszystkie pod uwagę, a najlepiej długość określać empirycznie, tj. wypróbowując różne „ustawienia”, pamiętając jednocześnie, że zbyt częste zmiany „ustawień” to znowu zwiększanie złożoności.

Categories: Sprint.