Nasz proces
User Story
User Story (opowieść użytkownika albo historie lub historyjki użytkownika) jest pochodną przypadków użycia.
Zarówno przypadki użycia, jak i user stories odnoszą się do wymagań użytkowników, które opisują, co użytkownicy będą mogli zrobić za pomocą systemu.
Przykład User Story
Przypadek użycia mógłby brzmieć następująco: „Księgarnia – zaktualizuj profil klienta”.
Tymczasem User Story wyglądałoby tak: „Jako klient chcę zaktualizować mój profil, dzięki czemu przyszłe zakupy będą przychodzić pod mój nowy adres zamieszkania”. Ważne jest tutaj wzięcie pod uwagę, że użytkownicy mają różne potrzeby.
Widzimy, że User Story wykracza poza wskazanie celu, do którego zmierza użytkownik, gdyż opisuje także motywacje, które stoją za celem.
Software: User Story a testy akceptacyjne
Historyjki użytkownika, czyli User Stories, pozwalają na przeprowadzenie testów akceptacyjnych (związanych z acceptance criteria).
Celem testu akceptacyjnego nie jest wykrycie błędów, lecz uzyskanie potwierdzenia wykonania oprogramowania odpowiedniej jakości.
W ten sposób dowiadujemy się, czy udało nam się sprostać wymaganiom, które postawił przed nami klient / interesariusz.
Testy odbywają się już na wczesnym etapie prac, co przekłada się na zadowalające efekty, niezależnie od przyjętej metodyki.
W celu wyłonienia szczegółów, które są zawarte w user stories, bazuje się przede wszystkim na acceptance criteria, nie zaś na wymaganiach podanych pisemnie.
Choć testerzy ocenią, czy dane wymaganie zostało prawidłowo zaimplementowane, nie mogą dokładnie stwierdzić, co powie klient / interesariusz na temat oprogramowania.
Kiedy zrozumiemy, że należy zmienić wymaganie, niezbędne jest poinformowanie o tym analityka biznesowego.
Kierujmy się zdefiniowanym dla projektu procesem kontrolowania zmian, co da nam gwarancję, że zmiany nie zostaną pominięte, a wpływ każdej z nich zostanie przeanalizowany.
Lecz co w sytuacji, gdy kolejne User Story są zbyt duże, aby zostały zaimplementowane w trakcie jednej iteracji? Dzielmy je na mniejsze historie – każdą z tych historii wdrażajmy podczas pojedynczej iteracji.
Użytkownik i jego wymagania. Problem z początkowymi założeniami projektu
Wymagania to specyfikacja tego, co powinno zostać zaimplementowane.
Opisują one, jak powinien zachowywać się system, określają jego właściwości lub atrybuty, a ponadto mogą nakładać ograniczenia na proces tworzenia systemu.
Definicji tego, czym są wymagania użytkownika, jest więcej, ale powyższa to jedna z bardziej trafnych.
Do sposobów przedstawiania wymagań użytkowników można zaliczyć przypadki użycia, User Story (historyjki użytkownika) i tabele zdarzenie-reakcja.
Wymagania użytkowników (User Requirements) dotyczą celów lub zadań, które użytkownicy będą musieli realizować za pomocą produktu.
Co więcej, wymagania odnoszą się także do opisu atrybutów produktu lub cech związanych ze zaspokajaniem potrzeb użytkowników.
Aby przedstawić user requirements, możemy posłużyć się między innymi User Story.
User Story pomaga ustalić ostateczne priorytety projektu, ale muszą być one realne – wówczas zapewnią wysoką efektywność prac.
Pamiętajmy przy tym, jak ważne jest zdanie zespołu programistycznego.
Chodzi o ustanawianie realnych celów, dlatego zwróćmy uwagę, gdy team stwierdzi, że na przykład nie da się przygotować danej funkcjonalności w żądanym czasie.
Bywa też, że projekt znacznie wykracza poza początkowe założenia.
Wtedy musimy ograniczyć jego zakres, wydłużyć harmonogram prac, wygospodarować dodatkowe fundusze czy znaleźć więcej rąk do pracy.
User Story: jak odbywa się identyfikowanie wymagań użytkownika?
W celu zidentyfikowania wymagań użytkownika powinniśmy określić wspólnie zadania, które ma on do wykonania za pomocą oprogramowania.
Ważne jest także wybranie celów, jakie próbuje osiągnąć. Wymagania można opisać nie tylko za pomocą User Story, ale także przypadków użycia i scenariuszy.
User Story, zbieranie wymagań i iteracje
Przy tworzeniu produktów cyfrowych praca w zakresie zbierania, analizowania, uszczegółowienia i aktualizacji wymagań będzie przebiegać przez cały czas fazy projektowania rozwiązania.
Nie zmienia to jednak możliwości, że właściciel produktu może w każdym momencie, nawet na etapie developmentu, dojść do wniosku, że trzeba coś zaprojektować inaczej.
W takiej sytuacji analityk biznesowy podejmuje się aktualizacji wymagań, gdzie kluczową jego umiejętnością będzie sprawdzenie, jak zmiana jednego wymagania może wpłynąć na inne wymagania systemu.
Zbieranie wymagań może odbywać się na bardzo wiele sposobów.
Wśród najpopularniejszych mamy metody warsztatowe, wywiady pogłębione, analizę przepisów prawa, norm regulujących rynek, analizę ograniczeń (np. technicznych), obserwację zachowania użytkowników (np. wobec dotychczasowego systemu, który chcemy zastąpić), obserwację i mapowanie procesów itp.
Pozyskane wymagania analityk biznesowy klasyfikuje do odpowiednich kategorii wymagań (wymagania funkcjonalne, atrybuty jakościowe, reguły biznesowe) oraz decyduje, czy wymagania mieszczą się w wizji produktu cyfrowego, a następnie są dzielone na tzw. iteracje produkcyjne.
Podziału na iteracje warto dokonywać w sposób intuicyjny z właścicielem produktu, który określi, na ile dana funkcjonalność jest kluczowa z punktu widzenia użyteczności i atrakcyjności rozwiązania.
Iteracje możemy nazwać inaczej zakresami wdrożenia. Im dalsze zakresy, tym ich wizja jest bardziej rozmyta.
Zebrane wymagania to baza dla analityka wymagań systemów IT, który dokonuje podziału wymagań ze względu na ich priorytety wdrożenia. Dokonuje się tego z udziałem właściciela biznesu.
Metod priorytetyzacji jest bardzo wiele, przy czym najczęściej spotykana jest metoda „MoSCoW”, w której wszystkie wymagania dzielimy w czterostopniowej skali: „must, „should”, „could”, „won't”.
Na rynku obserwuje się różne wariacje tej metody, jak np. użycie trójstopniowej skali: „must be”, „should be ”, „nice to have”.
Do oceny priorytetyzacji przydatna będzie wiedza na temat kluczowych przewag konkurencyjnych projektowanego produktu cyfrowego i kluczowych funkcjonalności oraz oszacowany koszt wdrożenia.
Jedną z bardziej zaawansowanych i bardzo dokładnych metod priorytetyzacji jest metoda „Domu jakości”, o której niebawem w kontekście produkcji aplikacji webowej napiszemy oddzielny artykuł.
Kiedy określono już priorytety wymagań, dzielimy je na sprinty produkcyjne, które mogą mieć z góry określony budżet i czas trwania.
Problem z folgowaniem wymagań
Co sprawia, że użytkownicy docelowi aplikacji mogą być niezadowoleni z systemu informatycznego? Wcale nie musi chodzić o to, że trafił się nam wieczny malkontent.
Problem zasadza się na luce oczekiwań, czyli różnicach między tym, czego w rzeczywistości potrzebują użytkownicy, a tym, co zostało wdrożone.
Taka sytuacja może mieć miejsce np. w sytuacji, kiedy na etapie zbierania wymagań położymy większą wagę na wysłuchanie potrzeb grupy interesariuszy, którzy nie będą docelowo korzystać z oprogramowania.
Zdarza się często, że przy okazji produktu cyfrowego niektórzy interesariusze chcą zrealizować swoje potrzeby, które niekoniecznie są zgodne z wizją produktu, albo w trakcie prowadzenia wywiadów osoby z bardziej doniosłym głosem domagają się wprowadzenia swoich konkretnych wytycznych.
Są to tzw. zjawiska pełzania lub złocenia wymagań funkcjonalnych. Dlatego tak ważne jest, aby osoba która zbiera wymagania, miała wysokie umiejętności interpersonalne i potrafiła przeprowadzić facylitację w profesjonalny sposób.
Ratunkiem agile i scrum
Warto o tym pamiętać, bo żyjemy w dynamicznie zmieniającym się świecie biznesu i technologii, gdzie ciągła współpraca z klientem jest wręcz nieodzowna.
Stąd chociażby coraz większa popularność MVP, design sprintu czy scruma. Innymi słowy, metodyka agile z roku na rok zyskuje na znaczeniu.
Metodyka agile
Metodyka agile narodziła się w latach 90. w Dolinie Krzemowej, choć sama nazwa pojawiła się oficjalnie dopiero w 2001 roku. To właśnie wtedy opublikowano „Manifest Agile”, czyli zbiór zasad usprawniających prace nad projektami programistycznymi.
Manifest zakłada, że od procesów i narzędzi bardziej ceni się ludzi i interakcje, a od szczegółowej dokumentacji ważniejsze jest działające oprogramowanie.
Od negocjacji umów ważniejsza jest z kolei współpraca z klientem, a od realizacji założonego planu reagowanie na zmiany.
Agile jest przeciwieństwem modelu kaskadowego, którego cechują sztywne schematy i brak elastyczności w stosunku do zmieniających się potrzeb klienta.
Scrum vs. jak na projekt patrzy użytkownik?
Scrum, element agile, gdzie występują user stories, jest podzielony na sprinty, tj. trwające maksymalnie cztery tygodnie etapy prac nad projektem.
Dzięki temu zmiany są dokonywane na bieżąco, a klient jest cały czas zaangażowany w proces tworzenia produktu.
Gdy pod koniec sprintu otrzymamy informację, że wybrane funkcjonalności nie spełniają oczekiwań, możemy dokonać poprawek w kolejnym sprincie: można zawsze szybko zmienić daną funkcjonalność na inną lub zaoszczędzić pieniądze poprzez porzucenie pomysłu, który się nie sprawdził.
W scrumie ważną rolę pełni product owner, który tworzy listę potrzeb na dany sprint, a pod koniec prezentuje efekty prac klientom i użytkownikom w celu otrzymania informacji zwrotnej.
Jednakże zanim product owner przystąpi do działania, jego prace poprzedza planowanie sprintu. Proces planowania ograniczamy tylko do maksymalnie ośmiu godzin, jeśli sprint trwa miesiąc.
Zainteresowanych tematem odsyłamy do książki „Agile. Metodyki zwinne w planowaniu projektów”, której autorem jest Mike Cohn, jeden z twórców scruma.
To publikacja, która dobrze wprowadza w specyfikę metodyki agile i będzie na pewno przydatna, gdy chcemy pracować wykorzystując między innymi User Story.
Software: przykład, jak ogromną rolę w jego tworzeniu odgrywa klient
Reguła jest prosta: im częstsze będą kontakty z właścicielem biznesu i/lub użytkownikami docelowymi oprogramowania, tym łatwiej będzie pozostać na właściwej ścieżce rozwoju produktu.
Eksperci twierdzą, że cykl spotkań doprowadzi pod koniec projektu do znacznie mniejszej luki oczekiwań, a poza tym pozwoli uzyskać rozwiązania, które będą o wiele bliższe rzeczywistym potrzebom klienta docelowego.
Projekty zwinne charakteryzują się tym, że zarządzanie wymaganiami przyjmuje zwykle formę opowieści użytkowników w rejestrze wymagań.
Właściciel produktu i team osiągają podczas sesji planistycznych porozumienie co do opowieści, które zostaną zaimplementowane w kolejnej iteracji.
Taki zestaw opowieści dobierany jest zaś na podstawie ich priorytetów, jak i tego, na ile sprawny okazuje się zespół programistyczny.
Co dzieje się dalej? Otóż po wybraniu i zatwierdzeniu zestawu opowieści zostają one „zamrożone” – zgłoszone zmiany w wymaganiach zostaną rozpatrzone w przyszłych iteracjach.
W projektach zwinnych nie próbuje się z góry uzyskać zatwierdzenia pełnego zakresu wymagań przez interesariusza, gdyż w ich wypadku pełen zbiór funkcjonalności wyłania się wraz z upływem czasu.
Pamiętajmy jednak, że wizja i pozostałe wymagania biznesowe powinny zostać zdefiniowane już na początku.
Product backlog: jak ustalać priorytety i jaką rolę odgrywa tutaj team programistyczny
W jaki sposób ustalać priorytety w product backlog, czyli liście potrzeb, na którą składają się wymagania i funkcjonalności?
Dobrze, jeśli team programistyczny udostępnia informacje o kosztach i ryzyku związanym z każdym wymaganiem. Do ustalenia ostatecznych priorytetów może posłużyć także user story.
Mając ustalone realne priorytety, będziemy w stanie pomóc programistom w wytworzeniu maksymalnej wartości przy najniższym koszcie i we właściwym czasie.
To właśnie wspólne ustalenie priorytetów stanowi podstawę sukcesu w projektach zwinnych. Sprawia to, że programiści mogą oddawać użyteczne oprogramowanie tak szybko, jak to tylko możliwe.
User stories pozwolą nam na lepsze zrozumienie użytkownika, a co za tym idzie – sprawią, że dostarczymy mu oprogramowanie, które spełni jego potrzeby.
Inaczej wdrażanie oprogramowania nie ma najmniejszego sensu. Nihil novi: każdy biznes, także cyfrowy, powinien na pierwszy miejscu stawiać klienta / użytkownika.