Historie użytkowników dla wymagań funkcjonalnych

Question

Ponieważ jesteśmy małą firmą, pracuję zarówno jako kierownik projektu, jak i programista. Specyfikacje, które tworzę dla klientów, zawierają pewną liczbę elementów używanych do opisania i zdefiniowania projektu, w tym historie użytkowników wraz z innymi elementami, które moim zdaniem należy uwzględnić w celu zdefiniowania projektu (np. Makiet, przepływów użytkowników, map witryn itp.) Dla klienta.

Jeśli specyfikacja funkcjonalna "opisuje, jak produkt będzie działać całkowicie z punktu widzenia użytkownika. Nie obchodzi go, jak to się dzieje. Mówi o funkcjach. ". Czy ktoś widzi jakiś problem z korzystaniem z Historie użytkowników, aby zdefiniować funkcjonalną specyfikację strony internetowej? Czy ktoś tak naprawdę wykonuje specyfikacje funkcjonalne w ten sposób?

Naprawdę staram się trochę uprościć swoją grę i zastanawiam się, czy to podejście byłoby skuteczne dla większych klientów, którzy być może mają bardziej rygorystyczne pomysły na temat specyfikacji funkcjonalnej, i które mogą wymagać formalnego podejścia. Zdecydowanie w tej chwili nasi klienci dobrze reagują na naszą metodę produkcji dokumentacji.

Interesuje mnie to, co ludzie profesjonalnie zajmujący się zarządzaniem projektami myślą o tym.

Answer 1

Nie zgadzam się z opinią kilku innych osób.

Najpierw do góry Zgadzam się - historie to świetny sposób na określenie wymagań funkcjonalnych. Dla moich pieniędzy są one jednym z najlepszych sposobów komunikowania wymagań w sposób, w jaki użytkownicy końcowi naprawdę będą się znosić. Widziałem zbyt wiele specyfikacji, które zostały podpisane bez przeczytania.

Jedna rzecz, którą chciałbym dodać, to niefunkcjonalne wymagania - obejmujące wydajność, bezpieczeństwo, ilość danych, audyt, archiwum i tak dalej. O ile można je opisać w opowiadaniach, czasami są one lepiej omówione w sposób, który przecina wszystkie historie.

Pod względem tego, czy jest odpowiedni dla dużych firm, to tam się nie zgadzam. Z mojego doświadczenia (i robiłem projekty dla Shell, American Express, kilku międzynarodowych banków i innych) często nie są bardziej formalne niż mniejsze firmy, więc będą dobrze z historiami. W rzeczywistości użytkownik w dużej firmie nie jest lepiej wyposażony (lub zainteresowany) w czytaniu diagramów klas i sekwencji niż gdzie indziej.

Rozmiar i złożoność projektu może wymagać bardziej szczegółowych wymagań, ale to rozmiar projektu, a nie wielkość firmy ma znaczenie przy określaniu sposobu dokumentowania wymagań.

Dla mnie najlepszą dokumentacją wymagań jest dokumentacja dostosowana do jej odbiorców, a dla mnie historie użytkowników trafiają w sedno najczęściej - są na tyle krótkie i na tyle jasne, że kiedy je podpisują, mają na myśli coś, ponieważ je przeczytali i zrozumieli (w przeciwieństwie do podpisu z 100-stronicowej specyfikacji, która niezmiennie oznacza, że ​​tak naprawdę go nie czytali), ale wystarczająco dobry, aby programiści mogli także pracować.

Answer 2

Tak, możesz użyć historii użytkownika dla swoich potrzeb funkcjonalnych. Robię to cały czas i jestem od lat. Moim zdaniem działa to naprawdę dobrze i lepiej niż inne systemy, z których korzystałem.

Czy to podejście będzie działać dla większych klientów? Aby zrobić ogólne uogólnienie, nie. Będą mieć system, który użyje do zdefiniowania wymagań i prawdopodobnie nie będzie historiami użytkowników. Jeśli zapoznasz się z historyjkami użytkowników, nastąpi rozłączenie z bieżącymi praktykami, które będziesz musiał wykonać.

Udało mi się wykorzystać historie użytkowników w większych organizacjach, ale wymaga to wspólnego wysiłku, któremu obie strony muszą się zaangażować.

Answer 3

To, co opisujesz, to scenariusze użycia, które definiują funkcje, to jest to, co jest wymagane z perspektywy użyteczności i jest dokładnie tym, co klient zrozumie i zaakceptuje. Makiety ekranów i diagramy przepływu z pewnością pomogą zarówno klientowi, jak i programistom.

Wymagana może być wówczas specyfikacja implementacyjna, aby poinformować programistów o tym, co należy uwzględnić w rzeczywistej konstrukcji. Ich głębokość zostanie określona przez możliwości programistów, które obejmują ich znajomość architektury/struktury domu i metodologii/konwencji i może zawierać informacje o wpływie różnych części aplikacji.

Pracujemy również w małych zespołach (czasami jeden lub dwóch programistów) i uważamy, że powyższe jest wszystkim, co jest wymagane w tym przypadku.

Większe firmy o znacznie większych zespołach mogą korzystać z oprogramowania do modelowania, diagramów UML i innych bardziej szczegółowych specyfikacji. W przypadku, gdy jesteś głównym programistą, powinieneś poświęcić czas na projektowanie aplikacji, ale jeśli nikt nie będzie chciał przejrzeć projektów i wymagać wszystkich formalności, lepiej poświęć czas na wdrożenie oprogramowania.