Definiowanie historii użytkownika i zwinny rozwój
Podstawową zasadą nowoczesnych procesów programistycznych jest zwinny rozwój . Ta metodologia rozwoju kładzie nacisk na używanie małych, niewielkich historyjek użytkownika w celu zdefiniowania, co system robi z perspektywy użytkownika, a nie technicznej. Użytkownikowi zależy na tym, czy produkt jest szybki, łatwy w użyciu i rozwiązuje jego problem. Nie obchodzi ich, czy jest zgodny z architekturą trójwarstwową, ma Mongo DB, czy używa Railsów lub Asp.net.
Historie użytkownika:
- Są łatwe do zrozumienia i każdy może wziąć udział
- Pracuj iteracyjnie; mogą i powinny być często zmieniane lub poprawiane
- Dopasuj programistów, użytkowników i specjalistów biznesowych do wspólnych celów i oczekiwań
- są o wiele łatwiejsze do odczytania niż 400-stronicowe dokumenty z wymaganiami
Storyboard That stanowi idealną platformę do tworzenia zwinnych historii użytkowników i inicjowania rozmów w formacie, który jest znacznie mniej obciążający niż ściana tekstu.
Epicki
W kontekście historyjek użytkownika „epos” to po prostu bardzo obszerna historia, która zostanie później podzielona na wiele konkretnych historyjek użytkownika. Rozpoczęcie od epopei łączy wszystkich z jedną wizją na wysokim poziomie. Epicka historia zakotwicza projekt od góry do dołu, a jeśli konstruowanie epickiego nie ma sensu, wspieranie pracy również będzie stratą wysiłku.
W tej historii jest bardzo jasne, jaka jest długoterminowa wizja i jak powinien wyglądać sukces. Dobra epicka historia powinna zawierać:
- Ustawienie lub kontekst
- Aktorzy lub użytkownicy
- Cele i zadania
- Aktywności i wydarzenia
Definiowanie użytkowników
Szczególnie przy projektowaniu oprogramowania ważne jest, aby mieć dobrą wizję tego, jacy będą użytkownicy. Nie każdy użytkownik dokładnie dopasuje się do tej wizji i może istnieć wiele kategorii użytkowników, ale te dyskretne wizje wymagają artykulacji. Myślenie o użytkownikach przede wszystkim chroni przed nadmierną inżynierią i komplikacjami, uniemożliwiając nowemu produktowi coś dla wszystkich i nieprzydatność nikomu.
Tworzenie historii
Po utworzeniu epopei i zdefiniowaniu użytkowników można tworzyć mniejsze, bardziej szczegółowe historie dotyczące konkretnych doświadczeń użytkowników. Poniższe historie dzielą opisane powyżej na dwie narracje: wyszukiwanie zamówienia i ponowne zamawianie produktu.
Te narracje nie zawierają informacji technicznych; użytkownicy nie dbają o to, jak osiągane są wyniki, o ile wykonuje pożądane zadania. Podobnie UX jest przedstawiany ogólnie, aby uniknąć tłumienia innowacji lub forsowania ścieżki. Ogólnie rzecz biorąc, historie powinny być:
- Mały – poniżej 10 dni pracy
- Cenne – Po ukończeniu powinny dostarczyć coś użytecznego
- Szacunkowy – Potrafi oszacować, ile wysiłku jest w to zaangażowane
Wyszukiwanie zamówienia
Wykonywanie ponownego zamówienia
Rozmowa i planowanie testów
Te historie powinny zachęcać do rozmowy i pytań, takich jak:
- Czy to są odpowiednie historie pasujące do naszej epopei?
- Jakie inne historie należałoby stworzyć?
- Czy te historie są zgodne z tym, co wiemy o naszych użytkownikach?
Całkowicie rozsądne jest tworzenie wielu historii; w rzeczywistości należy do tego zachęcać. Niektóre z tych historii nigdy nie zostaną wykorzystane, ale ważne jest, aby zobaczyć ścieżkę, którą wyznaczyły. Ten zbiór historii wyeliminuje dodatkowe wymagania i wpłynie na testowanie.
Historie powinny prowokować i skłaniać do dyskusji o tym, jak oprogramowanie będzie testowane i jakie reguły biznesowe należy wyraźnie zdefiniować. Na przykład:
- Jak szybkie musi być wyszukiwanie?
- Czy istnieje limit czasu na ponowne zamówienia?
- Co powinien zrobić system, jeśli jest to drugie ponowne zamówienie? Piąty?
- Jakie testy i pytania uzupełniające miałbyś?
© 2024 - Clever Prototypes, LLC - Wszelkie prawa zastrzeżone.
StoryboardThat jest znakiem towarowym firmy Clever Prototypes , LLC , zarejestrowanym w Urzędzie Patentów i Znaków Towarowych USA