Jak przekonać mój zespół, że specyfikacja wymagań nie jest konieczna, jeśli przyjmiemy historie użytkowników?

9

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?

— Doktorat
źródło

to się nie stanie za dnia,

— podejdź

Jeśli pracujesz dla dostawcy usług programowych, SRS może nie być potrzebny do wdrożenia, ale do wykonania „obwiniania”, gdy klient chce obniżyć koszty lub argumenty dostawcy usług, że potrzeba więcej pieniędzy lub obie są w sądzie.

— k3b

14

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.

— pdr
źródło

2

@PhD: Masz rację. Jest prawie pierwotny. I dlatego nie wygrasz tej bitwy z logiką, tylko z dowodami. Małymi kroczkami.

— pdr

2

Pracowałem dla menedżerów, którzy stawiali czoła zmianom krok po kroku, to było ich kryptonimem „zrobić tylko tyle, by upaść, więc mogę powiedzieć, że miałem rację”, to nie jest droga do sukcesu, ponieważ pokazuje podstawowy brak zrozumienia nowej metodologii oraz brak pełnego zakupu przez kierownictwo, który ma kluczowe znaczenie dla pomyślnej zmiany. Brzmi to dobrze w teorii, ale w praktyce jest to wymówka, aby nie zmieniać i ogłaszać zwycięstwa, że nowy sposób nie działa, a stary działa. W ten sposób SRS został wzmocniony, a historie zostaną oznaczone jako dodatkowa praca, a ty wrócisz tam, gdzie byłeś.

2

Moje doświadczenie nie jest wyjątkowe, mam ponad 22 lata w branży, z czego większość to konsulting. Pracowałem więc z większą liczbą menedżerów i decydentów niż większość ludzi w tym samym czasie. Chodzi mi o to, że podejście oparte na krokach dziecka jest podejściem polegającym na niepowodzeniu, jedynie zaangażowanie wyższego kierownictwa w zmianę, a filozofia zmiany doprowadzi do pomyślnego wdrożenia. Jeśli jego koledzy nie są przekonani, pozwolenie im na robienie tego, co chcą, nie przekonuje ich, to po prostu karmi to, że wciąż potrzebujemy starej drogi, a nowa droga jest stratą czasu.

1

@JarrodRoberson Chcę tylko dodać, że moje doświadczenia bardziej odzwierciedlają twoje. Istnieją dwa rodzaje ludzi, a zatem dwa rodzaje menedżerów, konserwatyści i osoby podejmujące ryzyko. Konserwatyści są naturalnie niechętni zmianom i ryzykują. Kiedy znajdują model, który działa, nawet słabo, trzymają się go. Kiedy zmiana jest wymuszona lub naciskana na nich, podświadomie sabotują ją, próbując zrobić kroki dziecka . To dlatego jedyny raz, kiedy widziałem prawdziwą pracę Agile, kiedy kierują nią osoby podejmujące ryzyko.

— maple_shaft

2

@maple_shaft: Sztuką jest iść do przodu. Jeśli zmiana przyrostowa nie działa, niekoniecznie wykonaj ponownie ten sam krok wstecz, zastanów się, dlaczego to nie zadziałało ... może spędzasz zbyt dużo czasu, pisząc bezsensowny dokument. Teraz przyznaję, że dobry menedżer musi myśleć w ten sposób i że większość ucieknie z powrotem do swojej strefy komfortu. Ale z dokładnie tego samego uzasadnienia nie oznacza to, że jedyną inną opcją jest drastyczna zmiana. Zły menadżer zepsuje to w inny sposób.

— pdr

6

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życia The 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.

— kmote
źródło

będziesz dość zaskoczony, historie użytkowników SĄ zarządzane przez narzędzie, które może (i robi) eksportować je jako wymagania. Wydaje się jednak, że chodzi o „przetłumaczenie” historii użytkowników na język SRS „system powinien ...” itd. I NIE pozostawiać ich jako historii użytkowników.

— dr

1

Cóż, jeśli rozłączenie jest terminem „powinien / musi / może” , prawdopodobnie plujesz na wiatr z tymi ludźmi. Historie użytkowników mówią WHO / WHAT i, co najważniejsze, DLACZEGO coś trzeba zrobić, o wiele bardziej przydatne niż te statyczne przypadki użycia, które w większości przypadków są bardziej błędne.

2

-1: wcale nie zgadzam się z większością odpowiedzi, jednak stwierdzenie, że i SRS to „Specyfikacja wymagań jest dokumentem artefaktu czasowego, to nie jest żywy dokument”, jest tak błędne, że niepokojąco nie rozumie, co SRS służy do tego, w jaki sposób jest właściwie stosowany - zwykle tylko w dzisiejszych domach oprogramowania w modelu wodospadu.

— mattnz

5

SRS to martwy dokument, gdy tylko zostanie opublikowany. Pisałem je od 1990 roku. Są jak plan wojenny, nigdy nie przeżyją pierwszego kontaktu. I nigdy nie nadążają za faktyczną implementacją, chyba że masz dedykowany zespół pisarzy, którzy stale edytują to, a nawet wtedy jest źle, z powodu odłączenia się od ciągłych zmian i programistów, którzy zawsze wyprzedzają dokument i nie zawsze powiedz właścicielowi dokumentu, co się dzieje. Firmy spędzają tysiące godzin na pisaniu takich rzeczy, a dokumenty kładą się na półce i gniją na początku tworzenia.

3

@JarrodRoberson +1 dla Ciebie. Rzeczywiście Mattnz ma również rację, że SRS ma być żywym dokumentem, ale bierzesz kilka krytycznych problemów produkcyjnych, które wymagają zmiany przez klienta, pracując nad jednym lub kilkoma rozgałęzionymi wydaniami podstawy kodu, źle interpretowanymi wymaganiami przez analitycy biznesowi, programiści i QA ... pozostaje ci dokument, który nie jest teraz prawdziwym odzwierciedleniem systemu, ale także nie odzwierciedla potrzeb użytkownika. Historie użytkowników są naprawdę adoptowane przez firmy bardziej zainteresowane klientem niż systemem.

— maple_shaft

0

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.

— Michael Durrant
źródło

5

Bądź bardzo ostrożny. Działa tylko wtedy, gdy twoi współpracownicy są bardzo bezpieczni i masz z nimi dobre relacje. Wiele osób denerwuje się, jeśli używasz humoru, aby powiedzieć im, że się mylą i są ukryte.

— MarkJ

-1

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ę.

— Joe
źródło

1

Przepraszam, to nie jest duża odpowiedź. Mówisz „pokaż statystyki” i nawet nie podajesz linków.

— Jan Doggen,

i pisz kompletne słowa i zdania ...

— jwenting