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), cenę 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 (usability testing). 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)?

Załóżmy, że dwa zespoły rozpoczynają pracę nad jednym i tym samym Rejestrem 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.

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 Rejestru 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 Rejestr 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 Rejestru 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.

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 Rejestrze 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 Rejestr 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 Rejestru 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 Rejestr 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 Rejestr 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.

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 Rejestrze 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 Rejestr 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.

20 lipca 2011r. na Scrum.org została opublikowana nowa wersja Scrum Guide. Na razie tylko w języku angielskim, ale społeczność Scrum zapewne już pracuje nad tłumaczeniami na inne języki, w tym polski.

O ile nic się nie zmieniło, jeśli chodzi o podstawy Scruma, to doprecyzowano kilka kwestii i udoskonalono sam dokument, o czym można przeczytać w komunikacie Kena Schwabera i Jeffa Sutherlanda.

Główne zmiany:

1. Scrum Guide zawiera teraz jedynie reguły gry, a więc usunięto wszelkie wskazówki.
2. Zespół, który wcześniej nazywano The Team, od teraz nazywa się The Development Team (Zespół Deweloperski), zaś członków zespołu nazywa się deweloperami. Zapewne dla jaśniejszego rozróżnienia pojęć Zespołu Scrumowego i Zespołu „właściwego”.
3. Zespół Deweloperski nie zobowiązuje się do ukończenia całej pracy zaplanowanej podczas spotkania planistycznego Sprintu. Zespół tworzy prognozę pracy, którą wierzy, że wykona podczas Sprintu, ale prognoza ta zmienia się w trakcie Sprintu w miarę, jak zespół dowiaduje się więcej.
4. Nie jest już wymagany wykres spalania (burndown chart) do śledzenia postępów pracy. Natomiast pozostała do wykonania praca jest sumowana codziennie i znana oraz postępy nadal powinny być śledzone.
5. Planowanie wydania, choć wartościowe, nie jest wymagane. Nigdy nie było, ale we wcześniejszej wersji Scrum Guide’a było opisane.
6. Rejestr Sprintu (Sprint Backlog) składa się z elementów Rejestru Produktu (Product Backlog) wybranych do Sprintu i planu ich dostarczenia. Twór znany jako „element Rejestru Sprintu” (Sprint Backlog item) nie jest więc konieczny.
7. Rejestr Produktu (Product Backlog) nie jest już „spriorytetyzowany”, tylko „uporządkowany”.

Autorzy zapowiadają na przyszłość szersze wyjaśnienie wprowadzonych zmian.