Da li tradicionalni SRS dokument treba pretvarati u format korisničkih priča?
- Detalji
- Klikova: 18678
 |
Mnogi tradicionalni projekti počinju sa Software Requirements Specification (SRS) dokumentom. Onda se u nekom momentu implementacije projekta donese odluka o primjeni agilnog pristupa. Postavlja se prirodno pitanje: Da li SRS dokument može služiti kao product backlog agilnog projekta? Razmišljanja nekih timova idu tako daleko da bi kompletan SRS dokument pretvorili u product backlog sa korisničkim pričama (user stories). Hajde da razmotrimo da li je to potrebno.
|
Prije nego se posvetim odgovoru na ovo pitanje, želim pojasniti šta ja podrazumjevam pod specifikacijom zahtjeva software-a odnosno SRS-om. Uvidio sam da ovaj tip dokumenta izrazito varira u sadržaju i formatu od kompanije do kompanije. Ipak, generalno pod ovim podrazumjevam dokument pun izjava tipa "Sistem treba...".
Ovdje možete zamisliti bilo koju vrstu tradicionalnog dokumenta sa zahtjevima i moji savjeti bi trebali biti primjenjivi. Ovo se posebno odnosi na bilo koji dokument sa pobrojanim, ugniježdenim zahtjevima, bez obzira da li je svaki zahtjev zaista počinje sa "Sistem treba ...".
Neki od nedostataka korištenja SRS dokumenta kao Product Backlog-a
U agilnom razvoju proizvoda, product backlog služi dvjema svrhama:
• Predstavlja repozitorij posla koji treba da se uradi
• Pomaže prioretizaciju posla
Dakle, product backlog govori timu šta treba da se uradi i može biti korišten kao alat za planiranje sekvenci posla. Nasuprot tome, tradicionalni SRS dokument se fokusira samo na to šta treba uraditi na projektu.
U SRS dokumentu se ne pokušava pisati zahtjevi tako da oni mogu biti implementirani u jednom sprintu ili tako da postoji prioretizacija. Također se ne pridaje puno pažnje pisanju međusobno nezavisnih zahtjeva, na što ukazuje hijerarhijska organizacija većine SRS dokumenata, sa numerisanim zahtjevima tipa 1, 1.1, 1.1.1, itd.
Ovo nisu problemi ako se SRS posmatra isključivo kao dokument sa zahtjevima. Ali kada se zahtjevi navedeni u SRS-u žele koristiti i kao stavke product backlog-a, tu nastaje problem.
Sa SRS dokumentom je često nemoguće timu da razvije zahtjev 1.1.1 ako istovremeno se ne razvija 1.1.2 i 1.1.5. Ove međuzavisnosti čine posao težim u odnosu na biranje korisničkih priča iz dobro uređenog product backlog-a.
Prioretizacija podstavki u SRS-u je također teško kao i utvrđivanje podskupa funkcionalnosti koje čine MVP (minimum viable product).
Specifikacija zahtjeva sistema/software-a je dobar format za specifikaciju zahtjeva. Dobar je u objašnjavanju šta sistem odnosno proizvod treba da radi. (Naravno, SRS ima problem sa mnogim agilnim aspektima poput progresivnog rafiniranja zahtjeva, kolaboracije, otkrića i sl. Pretpostavljam da će se to u agilnom projektu ipak desiti.)
Ali SRS nije dobar za planiranje, prioretizaciju i utvrđivanje vremenskih okvira za posao. Product backlog se u agilnim projektima koristi za obje ove svrhe.
Moj savjet
Generalno ne preporučujem da se troši vrijeme na prepisivanje dobro urađenog SRS dokumenta. Reformulacija zahtjeva iz SRS dokumenta u korisničke priče te razvoj dobro uređenog product backlog-a će riješiti probleme koje sam naveo, ali obično to nije vrijedno vremena potrebnog za formiranje takvog product backlog-a.
Neko bi na ovo trebao potrošiti vrijeme i obično ta osoba može to vrijeme provesti na profitabilniji način. Posebno bih bio suzdržan od ovoga, ako bi drugi članovi tima morali čekati da se zahtjevi urede u product backlog formatu.
Scrum Master ili neko iz razvojnog tima će morati pronaći način praćenja progresa urađenog posla u odnosu na SRS i pobrinuti se da se ne zaboravi na neki od zahtjeva. Obično bi angažman QA bio dobar pristup validiranju da je sve iz SRS dokumenta urađeno odnosno prikazano u product backlog-u.
Jedna dodatno važna strategija bi bila educiranje ljudi uključenih u kreiranje SRS dokumenta kako bi razmotrili pristupe da to na budućim projektima rade na agilniji način. Ako na to možete uticati, pomoći ćete da naredni projekat izbjegne izazove agilnog razvoja koji počinje tradicionalnim SRS dokumentom.
