Jak demonstrujesz oprogramowanie bez interfejsu użytkownika w przeglądzie sprintu?

Robimy sprawne tworzenie oprogramowania, w zasadzie zgodnie ze Scrumem. Staramy się robić recenzje sprintu, ale jest to trudne. Nasze oprogramowanie przetwarza wiele danych, a historie często dotyczą zmiany różnych zasad wokół tego.

Jakie są opcje demonstrowania zmian, które wystąpiły w sprincie, gdy nie ma interfejsu użytkownika ani widocznej zmiany przepływu pracy, ale zamiast tego zmiana jest subtelną regułą biznesową dla zadania przetwarzania, które może potrwać 10 minut, a nawet kilka godzin ?

Podczas sprintu tworzysz wartość. Zawsze jest jakaś różnica między tym, co miałeś na początku i na końcu sprintu. Zwykle nawet w sposób zauważalny przez klienta. Po prostu pokaż różnicę.

w niektórych przypadkach sprint zajmuje się odkryciami lub wewnętrznymi zmianami, które mogą zabrzmieć subtelnie, ale musisz być w stanie pokazać różnicę i wyjaśnić opinii publicznej, dlaczego uważasz, że to dobrze i jaka jest korzyść z włożonego wysiłku. (? narożną sprawę możesz odnieść do Edisona, który jako pierwszy odkrył ponad tysiąc sposobów, w jaki sposób NIE można zrobić działającej żarówki.)

Jeśli rzeczywiste przetwarzanie trwa długo, dobrze jest wyświetlić film z zapakowanym czasem lub po prostu tabelę liczb. Lub wstępnie zebrane wyniki.

Osobiście wolę rzeczy, które wykonują pracę zaplecza, aby znaleźć zmianę użytkownika końcowego. Jeśli przetwarzane dane ostatecznie kończą się w raporcie, pokaż różnice w raporcie przed / po.

Zakładam, że chęć zmiany wynikała z potrzeby. Jaki był problem, który wywołał potrzebę napisania tej historii? Twoja „forma głosowa” historii użytkownika powinna wskazywać, w jaki sposób będziesz w stanie zademonstrować problem, działając jako użytkownik w Twojej historii (tzn. Jako Joanne muszę przejrzeć raport bez użytkowników z Europy).

Ponadto możesz poprosić zespół testowy o pomoc w tym przypadku. Musiał istnieć jakiś sposób, aby zespół testowy mógł zweryfikować, czy historia została ukończona. Jak oni to zrobili? Czy jesteś w stanie pokazać ten proces w demie?

Skąd wiesz, że funkcja działa samodzielnie? Kiedy go wdrażasz, w jaki sposób upewniasz się, że rzeczywiście działa?

Jeśli nie potrafisz odpowiedzieć na te pytania, masz większe problemy niż przegląd sprintu. Powinieneś być w stanie to pokazać na swoim demie.

W Scrumie podczas demonstracji właściciel produktu sprawdza każdą z opracowywanych historii i akceptuje je lub przywraca do rozwoju. Musisz być w stanie udowodnić, że funkcja działa; zwykle najlepiej jest to zrobić za pomocą testu automatycznego. Czy potrafisz wybrać zautomatyzowane testy odpowiadające testom akceptacyjnym i wyróżnić kluczowe zmiany?

Twój właściciel produktu powinien również być w stanie pomóc; powinni dokładnie rozumieć opracowywany produkt. Nie muszą rozumieć pełnych szczegółów implementacji, ale muszą je zrozumieć wystarczająco dobrze, aby móc wyjaśnić cel (lub wartość biznesową) każdej funkcji. W końcu Właściciel produktu to osoba, która poprosiła Cię o wdrożenie tej historii!

Jedną z opcji, które potencjalnie spełniam dla biznesu (BSA, licencjackie, menedżerskie i tym podobne), jest prezentacja od pięciu do dziesięciu slajdów na temat tego, czego się spodziewano i co zostało osiągnięte. A jeśli istnieje sensowna metoda wyświetlania wyników wykonanej pracy, taka jak zrzut danych lub wyniki zapytania SQL, i czas na ich wyjaśnienie, to często interesuję się interesariuszami.

Często trudno jest przedstawić sensowną wersję demonstracyjną dla programistów / personelu nietechnicznego w systemach typu back-end. Próbowałem powyższego kilka razy i czuję, że interesariusze byli bardziej zadowoleni z ich odpowiedzi, niż kiedy po prostu uruchomiłem oprogramowanie i pokazałem im wyniki.

To prawda, że ​​może to być dla ciebie więcej pracy niż jest warte. Będziesz musiał zważyć świadczenie i pracę wymaganą do jego realizacji.

Możesz użyć programu PowerPoint lub czegoś graficznego, aby przekazać zmianę. Na przykład, jeśli dodano regułę biznesową, która zależy od wartości komórki w arkuszu kalkulacyjnym, możesz pokazać, która to komórka i wyjaśnić, jak została zmieniona.

Jeśli jest kilka zmian zaplecza, żadnych zmian interfejsu użytkownika, możesz po prostu przejrzeć listę wyjaśniającą to i pokazać ogólną zmianę. Jeśli możesz utworzyć wykres lub grafikę, która podkreśla różnice, może to wystarczyć. Flash niektóre zmiany kodu lub listę zmian / zatwierdzeń, które zostały opracowane w sprincie.

Jeśli twoją zmianą jest „back-end”, prawdopodobnie istnieje interfejs użytkownika, w którym zmiany się manifestują. Możesz to pokazać. Mój zespół nie lubi tego robić, ponieważ nie jest właścicielem tego systemu, ale na koniec, jeśli w taki sposób klienci reagują na zmiany, musisz mieć świadomość tego interfejsu użytkownika i dobrze go znać wystarczy, aby pokazać gotowy produkt.