Planujemy przyjąć historie użytkowników, aby uchwycić „intencje” interesariuszy w sposób lekki, a nie ciężki SRS (specyfikacje wymagań oprogramowania). Wydaje się jednak, że choć rozumieją wartość opowieści, nadal istnieje potrzeba „konwersji” opowieści na język podobny do SRS ze wszystkimi atrybutami, priorytetami, danymi wejściowymi, wynikami, źródłem, miejscem docelowym itp.
Historie użytkowników „eliminują” potrzebę formalnego artefaktu typu SRS na początek, więc jaki jest sens posiadania SRS? Jak mam przekonać mój zespół (przy okazji, którzy są bardzo wykwalifikowanymi pracownikami CS - zarówno z wykształcenia, jak i praktyki), że SRS zostałby „wyeliminowany”, gdybyśmy przyjęli historie użytkowników do przechwytywania wymagań funkcjonalnych systemu? (Można również uchwycić NFR itp., Ale nie o to chodzi w pytaniu).
Oto mój argument „przepływu pracy”: przechwytuj początkowe wymagania jako historie użytkowników, a następnie opracowuj je do przypadków użycia (które muszą być udokumentowane na niskim poziomie, tj. Opisujące interakcje z prototypami / makietami interfejsu użytkownika i są postem dostarczalnym rozlokowanie). W ten sposób przechodzę od historyjek użytkownika do przypadków użycia zamiast opowiadań użytkownika do SRS do przypadków użycia.
Jak obecnie wszyscy przechwytujecie historie użytkowników w swoim miejscu pracy (jeśli w ogóle) i jak sugerujecie, żebym „uzasadniał” brak SRS w obecności historii użytkowników?
Odpowiedzi:
Małymi kroczkami. Kontynuuj pisanie SRS przez chwilę. Następnie zwołaj spotkanie i przedyskutuj, czy nadal służą celowi. Czy ktoś nadal je czyta? Czy czas spędzony na nich jest uzasadniony? Czy istnieje inny pośredni krok, który byłby lżejszy?
Nigdy nie wiadomo, może się okazać, że się mylisz. Pamiętajcie o manifestie Agile, większą wartość znajdujemy w „Działającym oprogramowaniu w porównaniu z obszerną dokumentacją”, ale nadal ma ona wartość.
Sądzę jednak, że szybko odkryjesz, że chęć kontynuowania pisania ciężkich dokumentów zanika, gdy zobaczą, jak ściśle powiązane są przypadki i historie użytkowników.
źródło
Epiki są symbolami zastępczymi
W prawie każdej metodologii Agile koncepcja Epics byłaby tyle, ile potrzebujesz do specyfikacji wymagań, a miejsce na tym poziomie jest potrzebne. Wpisy będą traktowane priorytetowo w sposób ciągły, wszelkie dalsze szczegóły są marnowane, jeśli wymaganie ma niski priorytet przez długi czas lub nigdy nawet nie zostanie wdrożone. Dokumentowanie go i zarządzanie dokumentacją wokół niego byłoby kompletną stratą czasu. YAGNI obejmuje działania związane z wymaganiami, a także działania związane z kodowaniem.
Narzędzia są twoim przyjacielem!
Jeśli użyjesz odpowiedniego narzędzia do zbierania historii użytkowników i zarządzania nimi, możesz wygenerować na ich podstawie Specyfikację wymagań. Specyfikacja wymagań jest w każdym razie dokumentem artefaktu czasowego , nie jest żywym dokumentem, jest migawką wymagań w czasie. I nigdy nie jest zsynchronizowany z rzeczywistością.
Automatycznie generuj artefakty
Historie użytkowników, które można wyeksportować z odpowiedniego narzędzia, są o wiele bardziej wartościowe niż jakikolwiek dokument ze statycznym artefaktem w dowolnym momencie. Osobiście wolę Pivotal Tracker do śledzenia historii użytkowników, napisałem nawet pakiet wtyczek MoinMoin w Pythonie, aby opublikować wszystkie różne historie i ich stany na Wiki (które zawierały szczegółowe notatki dla programistów i podobne historie), dane na żywo są zawsze lepsze niż dane statyczne.
Wiki stała się żywym dokumentem wszystkich sklepów / wymagań oraz ich stanu ukończenia i priorytetu ze szczegółami, komentarzami i innymi metadanymi.
O wiele lepszy niż ogromny dokument Worda w Sharepoint, który jest ciągle wysyłany pocztą elektroniczną i nigdy nie jest aktualizowany, gwarantując, że każdy ma inną wersję i nie jest zsynchronizowany ze wszystkimi innymi!
Historie użytkowników są bogatsze niż przypadki użycia
Historia użycia jest o wiele cenniejsza niż przypadek użycia, ponieważ mówią DLACZEGO .
Format User Story:
As a [ROLE] I [ACTIVITY] so that [WHY]
jest o wiele bardziej wyrazisty niż podobne przypadki użyciaThe System [shall/shall not/may/must] perform [action]
(gdzie akcja jest schematem blokowym).Dzięki Historii użytkowników masz KTO chce coś zrobić, masz CO CHCESZ zrobić (co może wskazywać na bardziej szczegółowy schemat / dokument dla złożonych zadań) i masz najważniejszą część DLACZEGO chcą robić to działanie.
Jeśli masz pierwszy, drugi jest całkowicie zbędny, aw najlepszym razie po prostu hałas. Tradycyjna specyfikacja wymagań formalnych z metodologii Waterfall nie ma miejsca w środowisku Agile.
Na końcu
Jeśli twoje kierownictwo nie jest zobowiązane do zmiany, nie odniesiesz sukcesu dzięki nowej metodologii. Ja pracowałem na 100+ mld dolarów firma lat, nie brały kroki dziecka w przeprowadzce do Agile / SCRUM, po prostu powiedział, cała firma zmierza do tego, tutaj jest nowy sposób robienia rzeczy, tu jest kiedy zacznie się twoje szkolenie na nowej drodze, oto nowe narzędzia, których będziemy używać, oto data, od której zaczniemy działać w ten sposób. Pracowało dla nich w niecały rok. Z takim samym sukcesem pracowałem nad wdrożeniem tego w mniejszych firmach.
Zaangażowanie
Wdrożenia Baby Step , niezależnie od zmiany, to przepis na niepowodzenie. Jest to słowo kodowe dla kierownictwa, które po cichu się nie zgadzają i pasywnie agresywnie przygotowują cię na porażkę. Mówią, że nie wierzę w to na tyle, aby się do tego zobowiązać, więc pozwolę ci zrobić tyle, by zawieść / nie odnieść sukcesu , w ten sposób mogą powiedzieć, że próbowali i to nie działało, a sposób, w jaki zarządzali, działał po prostu w porządku. Częściowe zaangażowanie ostatecznie prowadzi do niepowodzenia.
W twoim przypadku prawdopodobnie po cichu nie wierzą w Historie użytkowników, a po chwili zrobienia obu zaczną twierdzić, że to Historie użytkowników są bezużyteczne, a nie SRS, i będą naciskać, aby przestać pisać Historie użytkowników , który poprowadzi Cię do tyłu, a nie do przodu.
źródło
Chciałbym użyć humoru.
Zacznij od http://www.halfarsedagilemanifesto.org/
Porozmawiaj o tym przez chwilę ( dywersja )
i porozmawiaj o tym, co tak naprawdę oznaczają konflikty ( otwarta dyskusja ),
a następnie po chwili zwróć się do swojej organizacji ( pivot )
i sprawdź SRS i czy ma to sens w nowej konfiguracji projektu .
Następnie zakończyłbym (a może na innym spotkaniu) dyskusją na temat zmiany podejścia do SRS i sprawdziłbym, czy masz więcej konsensusu.
Na koniec dnia jesteś również ograniczony przez budżet i obsługę ludzi biznesu, więc może być punkt, w którym jesteś trochę bardziej zdecydowany w tym, co się przyzwyczai, ale tak naprawdę zależy to od branży, wielkości firmy, czynników organizacyjnych i wielu inne takie czynniki.
źródło
Przekonanie mgmt do ucieczki od SRS i rozpoczęcia korzystania z historii użytkowników jest zasadniczo tym samym, co przekonanie mgmt do przyjęcia Agile. Istnieją przekonujące statystyki dotyczące korzyści płynących z Agile. Jednym z przykładów jest prezentacja przedstawiona przez VersionOne na konferencji w 2013 r. Pokaż mgmt te dane branżowe, a jeśli są to typy nasłuchiwania, masz szansę.
źródło