Seriously guys, I think we have to remember this is the man. He answers to no one except ownership and God. And he doesn't have to answer to us. We make suggestions, he makes decisions.

Powyższy cytat pochodzi ze sceny filmu Moneyball, w której grany przez Brada Pitta menedżer klubu Oakland A’s Billy Beane, przedstawia swoją strategię dotyczącą kompletowania drużyny na nadchodzący sezon.

Podczas spotkania ze skautami — osobami zajmującymi się wyszukiwaniem talentów w celach transferowych — kontrowersyjna strategia spotyka się z brakiem zrozumienia i akceptacji, a skauci podważają każdy z wyborów Beane’a. Dopiero zacytowana powyżej wypowiedź jednego ze skautów kończy dyskusję.

W Scrumie to Właściciel Produktu podejmuje ostateczne decyzje dotyczące produktu, bo to on — nie kto inny — odpowiada za produkt. Można na niego wpływać, powinien słuchać sugestii, ale decyzje należą do niego.

Polecam cały film. Postać grana przez Brada Pitta to kwintesencja tego, co kryje się pod pojęciem product ownership.

Lata temu, kiedy firma dopiero rozpoczynała próby ze Scrumem, zespoły nie były ulokowane razem oraz nie używały żadnego webowego narzędzia do Scruma, Rejestry Sprintów były prowadzone w Excelu. Taki arkusz był aktualizowany raz dziennie podczas Codziennego Scruma. Zespół spotykał się w sali konferencyjnej, Scrum Master przynosił wydrukowany arkusz z Rejestrem Sprintu, uzupełniał go, po spotkaniu wracał do swojego pokoju, przepisywał dane na komputerze i wysyłał aktualny Rejestr Sprintu do całego Zespołu Scrumowego. Razem z aktualnym Rejestrem Sprintu w mailu były zawarte prognozy dotyczące Sprintu, wykres spalania oraz zidentyfikowane podczas spotkania przeszkody.

Czasy się zmieniły...

Obecnie większość zespołów siedzi ulokowanych razem, Właściciele Produktów pracują w pobliżu, zespoły mają do dyspozycji analogowe tablice oraz narzędzie webowe do prowadzenia Rejestrów Sprintów. 

...nawyki pozostały

Mimo że zespoły mają obecnie możliwość aktualizacji Rejestru Sprintu na bieżąco, mało który to robi. Deweloperzy nadal wstrzymują się z aktualizacją rejestru do Codziennego Scruma, a spotkanie wygląda w ten sposób, że Scrum Master ma otwartą na laptopie aplikację z rejestrem, za jego plecami stoi reszta zespołu i każdy deweloper po kolei odpowiada na pytanie: „Ile godzin jeszcze zostało przy tym zadaniu?”. Zespół poświęca na to sporą część czasu spotkania, a samo spotkanie ma charakter statusowy, gdzie poszczególni członkowie zespołu raportują Scrum Masterowi. To nie powinno tak wyglądać.

Sumowanie godzin to nie jest podsumowanie

Wspólne podsumowanie pozostałej do wykonania pracy z Rejestru Sprintu jest ważne i powinno się odbywać co najmniej raz dziennie — podczas Codziennego Scruma. Pytania: „Co robiłem wczoraj?”, „Co będę robił dzisiaj?”, „Jakie mam przeszkody?” mają prowadzić do odpowiedzi na pytanie: „Co jako zespół zrobiliśmy od ostatniego spotkania i jaki mamy plan do następnego?”. 

Żeby odpowiedzieć na te pytania, Zespół Deweloperski potrzebuje aktualnego Rejestru Sprintu i wykresu spalania. Dlatego powinny one być aktualizowane na bieżąco, tak by podczas spotkania można było poddać zespołowej inspekcji postępy pracy i dostosować plan.

Jednak żeby móc się skupić na podsumowaniu, należy przestać skupiać się na sumowaniu godzin. Warto więc wprowadzić w zespole zasady, że:

• każdy deweloper jest odpowiedzialny za aktualizację zadań, nad którymi pracuje;
• rejestr musi być zaktualizowany przed Codziennym Scrumem.

Rejestr Sprintu warto aktualizować na bieżąco też po to, by zabezpieczyć się przed sytuacją, kiedy dwie osoby niezależnie rozpoczną pracę nad tym samym zadaniem.

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.

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