Przewodnik dla nietechnicznych budowniczych
Zdecyduj, co ma udowodnić Twoja pierwsza aplikacja.
Zanim poprosisz o ekrany i funkcje, zamień ogólny pomysł w krótki, możliwy do przetestowania opis.
01 — opisz jedną osobę i jedno zadanie
Załóżmy, że pomagasz grupie społecznej organizować zmiany wolontariuszy. Przydatnym pierwszym pytaniem może być to, czy wolontariusz może znaleźć odpowiednią zmianę i wiedzieć, jak wyrazić zainteresowanie. Jest mniejszy i łatwiejszy w przeglądaniu niż pełny system planowania z przypomnieniami, uprawnieniami i listą płac.
- Opisz, co dana osoba robi dzisiaj i co jest trudne.
- Wybierz akcję, którą chcesz uczynić jaśniejszą lub łatwiejszą.
- Zapisz, co byś zauważył, gdyby pierwsza wersja działała.
02 — Przejdź przez podróż na papierze
Na przykład ochotnika naszkicuj listę zmian, szczegóły zmiany i formularz zainteresowania. Daj każdemu ekranowi jedno zadanie. Użyj kilku realistycznych przykładowych zmian, w tym pełnej zmiany lub pustej listy, aby recenzja obejmowała coś więcej niż tylko dopracowaną szczęśliwą ścieżkę.
- Nazwij ekran startowy i następną akcję.
- Lista pól niezbędnych do wykonania tego testu.
- Uwzględnij stan pusty i stan niepowodzenia działania.
- Trzymaj prawdziwe dane osobowe z dala od podpowiedzi i przykładów.
03 — Oddziel wersję demonstracyjną od usługi operacyjnej
Zdecyduj, czy ta wersja przedstawia tylko podróż, czy musi zapisać rzeczywiste żądanie. Demo może zawierać wyraźnie oznaczone przykładowe potwierdzenie. Usługa działająca potrzebuje miejsca docelowego, odpowiedniego dostępu i sposobu na odzyskanie żądania. Potwierdź te wymagania przed zaproszeniem prawdziwych uczestników.
- Zaznacz w briefie każde przykładowe działanie.
- Oddzielnie wypisz połączenia, uprawnienia i potrzeby publikowania.
- Zostaw konta, płatności i przypomnienia na później, chyba że od nich zależy pierwszy test.
- Poproś o wykwalifikowaną pomoc, gdy zadanie dotyczy wrażliwych informacji lub skomplikowanego dostępu.
04 — przejrzyj wynik pod kątem briefu
Skorzystaj z poniższego arkusza, a następnie postępuj zgodnie z instrukcjami dotyczącymi produktu, aby przekształcić go w żądanie kompilacji. Po pokoleniu udajcie się w tę samą podróż i zanotujcie, co się wydarzyło. W przypadku ochotnika udana demonstracja może oznaczać, że nowy gość będzie mógł znaleźć właściwą zmianę i zrozumieć następny krok bez wyjaśnień z Twojej strony.
- Poproś kogoś niezaznajomionego z pomysłem, aby spróbował wykonać zadanie.
- Zapisz mylące kroki, zanim poprosisz o więcej funkcji.
- Wprowadź jedną konkretną zmianę i powtórz tę samą kontrolę.
- Rozszerz zakres tylko wtedy, gdy pierwsza podróż odpowie na Twoje pierwotne pytanie.
Punkt wyjścia
Sformułuj krótki opis.
Dostosuj ten przykład do swojej firmy. Trzymaj przykładowe dane oddzielnie od prawdziwych informacji o kliencie.
Arkusz zakresu pierwszej wersji Osoba korzystająca z niego: ___ Problem, z którym się dzisiaj boryka: ___ Jedno zadanie, które powinien wykonać: ___ Strony potrzebne do tego zadania: ___ Wyświetlane lub wprowadzone informacje: ___ Co dzieje się po głównej akcji: ___ To, co pozostaje tylko próbką: ___ Funkcje pozostawione na później: ___ Pierwsza wersja przechodzi, kiedy mogę zaobserwować: ___
Kiedy potrzebujesz następnego kroku
Postępuj zgodnie z dokumentacją produktu.
Zanim zaczniesz.
Czy muszę najpierw wybrać język programowania?
Zacznij od użytkownika, zadania, informacji i obserwowalnego wyniku. Jeśli istniejący system lub ograniczenia techniczne determinują język lub platformę, uwzględnij to w briefie i potwierdź z osobą odpowiedzialną za ten system.
Ile funkcji powinna zawierać pierwsza wersja?
Użyj najmniejszego zestawu, który pozwala sprawdzić jedną pełną podróż. Nie ma uniwersalnej liczby funkcji. Funkcja należy do pierwszej wersji, gdy bez niej nie można w znaczący sposób przetestować zadania.
Znajdź następny krok.
Zacznij od jednego przydatnego zadania