fbpx
goodfirms LOGO Created with Sketch.







    Najczęściej popełniane błędy podczas pisania user stories

    16
    styczeń
    2020
    5 minut czytania
    Udostępnij

     

    Agile

     

    Dzisiaj każdy zespół chce przejść na zwinne metodyki programowania typu Agile, czyli umieścić użytkownika w centrum planowania procesu podczas budowania produktu. W końcu budujemy produkt dla użytkowników końcowych, prawda? User stories (historie użytkowników) są jednym z podstawowych narzędzi, które pomagają zespołom pamiętać o użytkowniku podczas definiowania produktu oraz jego funkcjonalności. Dużo mówi się o tym, jak je poprawnie pisać.

    Pisząc user stories, wydaje nam się niejednokrotnie, że piszemy je z perspektywy użytkownika. Jednak ostatecznie zawsze są one wypaczone przez naszą stronniczość oraz specjalistyczną wiedzę. Często błędy te są ze sobą połączone i nigdy nie kończą się wyłącznie na jednym nietrafnym osądzie. Dlatego chcę omówić niektóre z typowych i najczęściej popełnianych błędów przez zespoły podczas pisania user stories.


    1. User stories, które są zbyt szerokie, ogólne

    Gdy historie użytkowników są zbyt ogólne, łatwo pominąć kluczowe informacje dotyczące oczekiwanego działania i potrzeby. Jeśli w user stories istnieje wiele „i” bądź „lub” jest to wskazówka, że są one zbyt szerokie i należy rozważyć rozpisanie ich ponownie. Istnieje również bardzo dużo szansa, że szeroko napisana user story jest naprawdę epicka, ale... No właśnie.

    2. User stories, które są zbyt dobre

    Gdy user stories są zbyt dobrze napisane, zaczynamy mówić o tym, jak zamierzamy je wdrożyć. Usuwa to skupienie użytkownika oraz prowadzi do słabej komunikacji w zespole.

    3. Brak możliwości negocjacji

    User stories nie powinny być konkretnym i dokładnym opisem funkcji. Czasami historia użytkownika została napisana w tak charakterystyczny sposób, że zespół ma trudności, aby poprawnie ją wdrożyć, ponieważ istnieje łatwiejsza alternatywa. W takich przypadkach zespół powinien być skłonny do kompromisu w kwestii samego podejścia, pod warunkiem, że nie zaszkodzi to wartości, jaką ma z niej czerpać użytkownik.

    4. Powtórzenie user story w kryteriach akceptacji

    Kryteria akceptacji pozwalają na opisanie warunków, które należy spełnić, aby story zostało oznaczone jako ukończone. Zapewnia to zbieranie opinii, pomoc w planowaniu pracy zespołu oraz śledzenie ich pracy. Dzięki temu user story jest bardziej bogate, precyzyjne oraz testowalne.

    5. Posiadanie niezdefiniowanego użytkownika

    Wspominanie o osobowości użytkownika w każdej user story może wydawać się niepoważne. Jednak z drugiej strony może przynieść ogromną wartość pod względem wyniku. Jest to szczególnie ważne, jeżeli Twój produkt ma więcej niż jednego użytkownika. Oczywiście będą dostępne funkcje dopasowane do różnych postaci. Jeśli chcesz, aby Twój zespół był bardziej dopasowany do wyników, których od niego oczekujesz, musi wiedzieć, kim są użytkownicy końcowi oraz jakie korzyści uzyskają dzięki wprowadzeniu danej funkcjonalności.

    6. Zły kontekst

    Po pewnym czasie prawie każda user story zaczyna wyglądać tak samo np. jako menedżer treści chcę edytor tekstu, aby móc edytować treść. Wszystko to mówi zespołowi, że chcesz, aby zbudowali edytor tekstu i nic więcej. Jeżeli od dłuższego czasu zapisujesz kilka user stories, zrób sobie przerwę i wróć do nich z nową perspektywą. Czasami nawet po przerwie, możesz nie być w stanie wymyślić czegoś bardziej znaczącego. To dobry wskaźnik mówiący, że powinieneś więcej rozmawiać z użytkownikami i lepiej rozumieć ich potrzeby. Naprawdę nie ma potrzeby wymyślać koła od nowa.

     

    user stories brainstorming

     

    Wniosek

    Chociaż użycie szablonu user stories może być przydatne, nigdy nie jest tak proste, jak się wydaje. Jeden błąd podczas pisania często prowadzi do szeregu innych jako produktów ubocznych. A wtedy znajdziemy się w jeszcze większym bałaganie niż gdybyśmy w ogóle go nie pisali. Dlatego jeśli decydujemy się na jego przygotowanie, poświęćmy temu naprawdę dużo czasu i uwagi.

    Wiktor Sobczyk

    Bezpłatna konsultacja

    Powiedz nam czego potrzebujesz, a nasi eksperci Powiedzą Ci jak to zrobić, ile to kosztuje i na kiedy będzie gotowe.

    Inne wpisy na blogu

    29
    lipiec
    2020
    Jedne z najczęściej zadawanych pytań przez naszych Klientów na początku współpracy to: „Co to Warsztaty Discovery w tworzeniu MVP?”; „Dlaczego tego potrzebuję?”; „Jaką korzyść daje PD w wytwarzaniu aplikacji?”.  W niniejszym artykule odpowiemy na nie wszystkie. Skupimy się również na kwestii warsztatów discovery w tworzeniu MVP.          Zacznijmy od tego, że wierzymy…
    tagi: #Technologia
    czytaj artykuł
    29
    październik
    2019
    Dlaczego potrzebujesz prototypowania aplikacji? Czy zdarza Wam się, że klient ma wiele swoich pomysłów i wymagań, jeśli chodzi o projekt? Jeśli tak, ten wpis jest właśnie dla Was! Opowiemy bowiem nieco o tym, czym jest prototypowanie aplikacji. Prototyp to słowo, które większości ludzi kojarzy z materialnymi produktami, niekoniecznie zaś z aplikacjami mobilnymi czy webowymi. Jednak…
    tagi: #Design
    czytaj artykuł
    Jak możemy Ci pomóc?
    Porozmawiaj z nami!







      Kamil
      Head of Business Development
      Kliknij, aby podejrzeć