Da li tradicionalni SRS dokument treba pretvarati u format korisničkih priča?

 

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.

About the author
Mike Cohn
Author: Mike CohnWebsite: http://www.mountaingoatsoftware.com/
Agile Software Practitioner, Coach, Author and Owner at Mountain Goat Software
About:
Mike Cohn is one of the contributors to the invention of the Scrum framework. He is one of the founders of the Scrum Alliance and owner of Mountain Goat Software, a company that provides training on Scrum and Agile software development techniques.He began his career in the early 1980s as a Programmer in APL and BASIC before moving on to C++ and Java and running development groups. Cohn ran his first Scrum project in 1995 and has been a vocal proponent of Scrum ever since. Cohn is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development and Succeeding with Agile: Software Development using Scrum, as well as books on Java and C++ programming[4] and articles for Better Software, IEEE Computer, Software Test and Quality Engineering, Agile Times, Cutter IT Journal, and the C++ Users' Journal. He is also the editor of the Addison-Wesley Mike Cohn Signature Series of books. In 2012, Cohn was named #1 in The Top 20 Most Influential Agile People.

Past Events

Our Services

Contact Us

Bosnia Agile
Milana Preloga 12, Sarajevo 71000
Bosna i Hercegovina

This email address is being protected from spambots. You need JavaScript enabled to view it.
www.agile.ba