728 x 90

Przyjdzie klient i będzie machał rękami.

Przyjdzie klient i będzie machał rękami.

Już Grębosz w Symfonii C++ pisał, że najpierw przyjdzie klient i będzie machał rękami. Potem klienta posadzić trzeba przed sobą w wygodnym krześle. Następnie zadawać jak najprostsze pytania, a kiedy on będzie na nie odpowiadał, notować i wymyślać kolejne coraz bardziej szczegółowe. Tak długo aż zrozumie się, co klient chce zamówić. Zostanie wtedy stworzony opis produktu, który otrzymują programiści… wtedy zaczyna się zabawa.

źródło obrazu: www.bowdoin.edu

Historyjka użytkownika (ang. user story) jest sposobem na opis cech funkcjonalności produktu często stosowanym w zwinnych metodykach wytwarzania oprogramowania. Każda historyjka użytkownika reprezentuje rzeczywistą wartość biznesową. Cechują się prostą strukturą i są dobrym sposobem na definiowanie wymagań, ponieważ mogą być zrozumiane przez programistów, jak i osoby nietechniczne.

Wymagania biznesowe można zapisywać w historyjce na różnym poziomie detali, które w czasie są uszczegóławiane. Aby przedstawić wymaganie jako historyjkę, należy nadać jej tytuł, zdefiniować klasę użytkownika (jego rolę), zamiar, jaki ta klasa użytkowników chce osiągnąć oraz opcjonalnie zysk z osiągnięcia celu. Pomimo tego, że zysk z osiągnięcia celu jest pozycją opcjonalną, to warto go zapisywać, gdy nie jest on oczywisty. Przykładem historyjki użytkownika może być historyjka o tytule „Przesyłanie zdjęcia do systemu”. Jako zalogowany użytkownik chcę przesłać zdjęcie do serwera, dzięki czemu będę mógł je wykorzystać w profilu użytkownika. W tym przypadku klasą użytkownika jest zalogowany użytkownik, zamiarem jest przesłanie zdjęcia na serwer a zyskiem z tego celu możliwość wykorzystania zdjęcia w profilu użytkownika.

Każda historyjka użytkownika powinna zawierać również kryteria ukończenia (ang. Definition of Done, w skrócie DoD). Pomagają one deweloperom w zrozumieniu jak ma działać implementowana przez nich funkcjonalność. Kryteria akceptacji pozwalają jednoznacznie stwierdzić, czy prace nad historyjką użytkownika zostały zakończone. Bez zdefiniowanych kryteriów, wśród deweloperów mogą występować różne definicje zakończenia prac nad funkcjonalnością. Brak kryteriów akceptacji prowadzi do nieporozumień i utrudnia komunikację między członkami zespołów. Kryteria akceptacji często dają się przełożyć na zautomatyzowane testy należące do grupy tzw. testów akceptacyjnych. Wtedy prace nad historyjką kończą się, gdy związane z nią testy akceptacyjne zostaną zaliczone. Z wykorzystaniem testów akceptacyjnych wiąże się metodologia Acceptance Test-Driven Development (w skrócie ATDD), która jest podobna do metodologii TDD.

Każdy element rejestru produktu, w tym historyjka użytkownika, powinien mieć ocenę, która określa ilość pracy wymaganej do jego zrealizowania. Do oceny wielkości historyjek używa się szacowania względnego. Jest to lepsze podejście, gdyż bardzo trudno jest bezwzględnie oszacować ile czasu zajmą pracę związane z implementacją. Złożoność historyjki szacuje się względem złożoności innych historyjek. W metodologii Scrum jednostką używaną do oceny wielkości historyjki są punkty historyjkowe (ang. story points). Historyjka oceniona na trzy punkty historyjkowe oznacza, że jest ona trzy razy bardziej skomplikowana od historyjki ocenionej na jeden punkt. Nadawanie takich ocen jest łatwiejsze ze względu na to, że prościej jest porównywać elementy pomiędzy sobą.

Kryteria historyjek

Można wyróżnić sześć kryteriów, które powinna spełniać każda dobrze zdefiniowana historyjka użytkownika. Angielskie nazwy tych kryteriów składają się na skrót INVEST. Historyjka użytkownika powinna być:

  • niezależna,
  • negocjowalna,
  • wartościowa,
  • ocenialna,
  • o dobrym rozmiarze oraz
  • testowalna.

Pierwsze z kryteriów oznacza, że historyjki użytkownika powinny być od siebie niezależne lub jak najmniej powiązane. Omawiane kryterium nie ma na celu wyeliminowanie wszystkich zależności między wymaganiami, lecz minimalizowanie ich ilości. Historyjki, które zależą od innych, trudno się ocenia i planuje. Drugie kryterium, mówiące o tym, że historyjka użytkownika powinna być negocjowalna, oznacza, że wymagania nie powinny być obligatoryjnym kontraktem z listą wymagań, lecz punktem wyjścia do dyskusji, podczas której zostaną sprecyzowane wszystkie szczegóły. Ma to na celu doprowadzenie do udziału wszystkich członków zespołu scrumowego w specyfikacji wymagań. Prowadzi to do zwiększenia innowacyjności zespołu, wczesnego wykrycia nieporozumień oraz do wyeliminowania sytuacji, w których występuje zrzucanie odpowiedzialności na grupę osób, która samodzielnie, bez dialogu z innymi, wyspecyfikowała wymagania. Kolejne kryterium mówi o tym, że historyjka użytkownika powinna być wartościowa. Oznacza to, że każda z nich powinna reprezentować wartość biznesową dla użytkownika lub klienta. Jeśli nie ma ona takiej wartości, to nie powinno się jej realizować. Wyjątkiem są historyjki inżynieryjne na przykład mówiące o migracji na nowszą wersję biblioteki. Gdy zysk z takiej migracji, np. wyeliminowanie luk bezpieczeństwa, zostanie wyjaśniony właścicielowi produktu, to może on dostrzec w takim zadaniu wartość. Historyjka powinna być ocenialna. Jeśli zespół nie jest w stanie jej ocenić oznacza to, że jest ona zbyt duża, niejasna lub wymaga działań eksploracyjnych. Kryterium dobrego rozmiaru mówi o tym, że historyjka użytkownika powinna mieć rozmiar adekwatny do jej aktualnego miejsca w projekcie. W większości przypadków historyjka po utworzeniu powinna być duża i mieć niewielki poziom szczegółowości, a w momencie gdy będzie zaplanowana w sprincie, powinna być niewielka i uszczegółowiona. Ostatnie kryterium oznacza, że historyjka użytkownika powinna być testowalna. Wiąże się to w dużym stopniu z kryteriami ukończenia. Zespół powinien mieć możliwość jednoznacznego stwierdzenia, czy historyjka jest już zaimplementowana, czy jeszcze nie.

Podsumowanie

Historyjki są więc niezwykle ważne, nie tylko jeśli korzystamy ze zwinnych metodyk programowania. Bez nich produkt może okazać się nie tym, co klient miał na myśli.

Źródło obrazu tytułowego: opracowanie własne na podstawie www.bowdoin.edu

Leave a Comment

Your email address will not be published. Required fields are marked with *

Cancel reply

Inne artykuły