Czy można przekształcić tradycyjne SRS w User Stories?

Wiele tradycyjnie zarządzanych projektów rozpoczyna się od Software Requirements Specification (SRS). W pewnym momencie podczas projektu zapada decyzja o przejściu na podejście zwinne. Pojawia się wtedy oczywiście pytanie, czy SRS może służyć jako nowy zwinny Product Backlog. Niektóre zespoły rozważają nawet przepisanie SRS do Product Backlogu z User Stories. Ale czy to naprawdę konieczne?

Zanim zajmiemy się tym pytaniem, chciałbym pokrótce wyjaśnić, co dokładnie mam na myśli przez Requirements Specification lub SRS. Zauważyłem, że dokumenty te mogą znacznie się różnić w różnych firmach. Zasadniczo jednak odnoszę się do typowego dokumentu zawierającego stwierdzenia takie jak „System powinien...".

Moja rada pasuje jednak w zasadzie do prawie wszystkich tradycyjnych dokumentów specyfikacji. Dotyczy to oczywiście każdego dokumentu z wbudowanymi i ponumerowanymi wymaganiami, niezależnie od tego, czy wszystkie stwierdzenia są faktycznie sformułowane jako „System powinien...".

Kilka wad używania SRS jako Product Backlogu

W zwinnym produkcie Product Backlog pełni dwie ważne funkcje:
- Służy jako archiwum wszystkich prac, które należy wykonać
- Ułatwia priorytetyzację pracy

Product Backlog mówi więc zespołowi, jakie prace należy wykonać, i może być również używany jako narzędzie planowania do sekwencjonowania pracy. W przeciwieństwie do tego, tradycyjna SRS wskazuje jedynie, jakie prace należy wykonać w projekcie.

SRS nie ma na celu pisania wymagań, które można włączyć do Sprinta, ani ich priorytetyzowania. Pisanie niezależnych wymagań jest co najwyżej drugorzędnym celem, co dobrze widać po hierarchicznej organizacji większości dokumentów SRS z ich ponumerowanymi wymaganiami (1.0, 1.1, 1.1.1 itd.).

Dopóki SRS jest traktowane jako czyste wymaganie dokumentacyjne, nie stanowi to żadnych problemów. Jeśli jednak elementy SRS mają służyć jako Product Backlog Items i być priorytetyzowane, prowadzi to do problemów.

Przy SRS często zespołowi nie jest możliwe rozwinięcie wymagania 1.1.1 bez jednoczesnego rozwijania wymagania 1.1.2 i 1.1.5. Te zależności znacznie utrudniają pracę w porównaniu do prostego wybierania i realizowania jednej Story po drugiej z dobrze opracowanego Product Backlogu.

Priorytetyzacja podrzędnych elementów w SRS jest równie trudna jak identyfikacja podrzędnych funkcji do stworzenia Minimum Viable Product.

Software Requirements Specification dobrze nadaje się jako specyfikacja wymagań. Dobrze opisuje, co system lub produkt powinien robić. (Oczywiście nie odnosi się do wszystkich zwinnych aspektów pojawiających się wymagań, współpracy, spostrzeżeń itp. Zakładam jednak, że te rzeczy się zdarzają.)

Moja rekomendacja dotycząca SRS w Sprincie

Zasadniczo nie polecałbym poświęcania czasu na przepisanie prawidłowo działającego SRS. Oczywiście, biorąc pod uwagę wspomniane problemy, przepisanie SRS na User Stories i ładny Product Backlog mogłoby być pomocne, jednak wysiłek zazwyczaj po prostu nie jest wart zachodu.

Ktoś musiałby znaleźć na to czas, ale ta osoba może w normalnych warunkach znacznie lepiej spożytkować swój czas. Szczególnie odradzałbym przepisanie SRS, gdyby inni członkowie zespołu musieli czekać na nowo napisany Product Backlog, zanim będą mogli rozpocząć pracę.

Scrum Master lub inny członek zespołu musi znaleźć sposób na mierzenie postępów nawet przy SRS i zapewnić, że żadne wymagania nie przepadną. Zazwyczaj dobrym pomysłem jest włączenie zapewnienia jakości, aby zagwarantować, że wszystko w SRS zostało ukończone lub wymienione w Backlogu.

Ponadto ważne jest, aby przekazać tym, którzy są zaangażowani w tworzenie dokumentów SRS, że w przyszłych projektach należy robić to w sposób lepiej kompatybilny z Agile. Jeśli to się uda, można w następnym projekcie uniknąć problemów wynikających z rozbieżności między Agile a tradycyjnym dokumentem SRS.

Tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony.

Wymagania niefunkcjonalne

=> Dowiedz się tutaj, jak przenosić wymagania niefunkcjonalne do User Stories.

Sprint Planning zorientowane na zaangażowanie

=> Dowiedz się tutaj, dlaczego preferuję Sprint Planning zorientowane na zaangażowanie zamiast Sprint Planning opartego na velocity.