Skoncentruj się na tym, co jest i dlaczego, i unikaj tego, jak piszesz historie użytkowników.
To, z czym masz do czynienia, jest w rzeczywistości bardzo dobrym ćwiczeniem dla wszystkich programistów. Ważną umiejętnością jest umiejętność wyrażenia wymagań w prosty, biznesowy sposób.
Powinieneś skupić się na ogólnym wymogu, takim jak „potrzeba dokonania pojedynczego wyboru z listy rozwijanej obiektów, aby użytkownik mógł włączyć akcję Foo”, zamiast wybierać kombinację lub pole listy lub cokolwiek, co uruchamia określoną procedurę .
Innym sposobem podejścia do tego jest udawanie, że podstawowa baza kodu / framework to prawie kompletna czarna skrzynka. Za każdym razem, gdy mówisz „użyj obiektu XYZ”, możesz sam sprawdzić, pytając, czy wiesz o tym w systemie czarnej skrzynki.
Aktualizacja:
IMO, w porządku jest umieszczanie szczegółów w przypadku użycia, który wskazuje poziom szczegółowości wymagany dla informacji. Na przykład w przypadku systemu rejestracji można określić uczciwą grę
- nazwisko; pole wymagane
- imię; pole wymagane
- identyfikator konta; system nie wygenerował żadnych danych wejściowych
- znak zodiaku; pole opcjonalne - (sugestia) podać wyszukiwanie od daty urodzin?
- etc ....
Kluczem jest to, że nie określasz technicznego sposobu dla tych informacji. Jeśli zauważysz, że mówisz „użyj klasy String / tablicy znaków / lub pola varchar” dla nazwiska, oznacza to, że przesadzasz.
Jeśli jesteś wielojęzyczny, użyj dwóch różnych języków jako testu lakmusowego. Na przykład ciągi w C są na ogół tablicami char (aktor), podczas gdy C ++, Java i C # (dobrze, i prawie wszyscy inni ...) mają rzeczywisty obiekt typu String. Jeśli stwierdzisz, że twoja specyfikacja została unieważniona przy użyciu jednego z tych języków, będziesz wiedzieć, że została przekroczona.
Warto zauważyć, że konkretnie używam terminu Przypadek użycia w przeciwieństwie do User Story , chociaż wariant, którego używam, jest hybrydą obu. Moim celem przypadku użycia jest przedstawienie przeglądu tego, co się dzieje (User Story w najściślejszym znaczeniu), ale następnie praca z aktorami, systemami i ogólną wymaganą funkcjonalnością. Moje podejście jest bliższe temu, co sugeruje Fowler w tym artykule na Wikipedii, w przeciwieństwie do podejścia Cockburn.
Więc będę miał jeden przypadek użycia (lub mniej więcej) dla scenariusza rejestracji lub elementu pracy. Jeśli to naprawdę skomplikowane, podzieliłbym to na wielokrotności, ale to nie jest wielka sprawa. W razie potrzeby przypadek użycia można następnie podzielić na poszczególne zadania. To, co jest wrzucane do konkretnego scrumu, zależy od wielu zmiennych, ale w tym podejściu nie ma nic, co uniemożliwiałoby posiadanie możliwego do udowodnienia komponentu na końcu scrumu.
