Rääkige kornišoniga ja õppige, kuidas koguda oma projektile nõudeid

Projektile nõuete kogumine on keeruline protsess. Kui te ei tee seda õigesti, võite raisata nii raha kui ka aega. Tarkvaraarendusettevõttega koostööd alustavatel klientidel on sageli probleeme oma vajaduste täpsustamisega. Et vältida kommunikatsioonitõrgete tekkimist projektile asumisel - ükskõik, kas olete klient või töövõtja - õppige, kuidas nõudeid koguda!

Nõuded insenerianalüüs

Äriprobleemi määratlemine - see on nõuete tehnilise analüüsi esimene samm. Selle ülesande täitmisel ei peaks me keskenduma üksikasjadele, vaid mõtlema probleemile globaalselt. Siin on näide hästi kujutatud probleemist:

"IKT-sektori jaoks on üha keerulisem leida kvalifitseeritud spetsialiste"

Teine samm on sellele probleemile lahenduse loomine. See võib olla teenus, toode või isegi protsess. Järgmisena võiks näide varem esitatud probleemile olla järgmine:

„Rakenduse SkillHunt.io loomine - värbamisplatvorm, mis võimaldab kasutajatel saada suurt tasu selle eest, kui ta mõnele sõbrale oma töökoha suunab“

Selles etapis on üksikasjad tarbetud. Kui hindame ideed, viime läbi turu-uuringuid ja selgub, et meie lahendusel on äriline põhjendus, võime hakata nõudeid koguma. Veendumaks, et nad täidavad oma funktsiooni, peaksime kontrollima, kas nad vastavad kolmele peamisele kriteeriumile. Need peavad olema:

  • Selgesõnaline ja ühemõtteline
  • Arusaadav kõigile sidusrühmadele,
  • Ajakohane ja dokumenteeritud.

Nõuete kogumise protsessi lihtsustamiseks ja kõigile esitatud kriteeriumidele vastamiseks võime kasutada gherkini keelt. See on loomulik keel, mis võib olla kasulik nii nõudeid koguvatele ärianalüütikutele kui ka funktsionaalsete testide stsenaariume loovatele arendajatele.

Räägi Gherkinist sujuvalt

Gherkini nõuete kirjeldus on üheselt mõistetav, selgesõnaline ja - mis on kõige tähtsam - kõigile osapooltele arusaadav. Seetõttu on arutelu nõuete üle tegelikult võimalik.

Nagu igal teisel keelel, on ka Gherkinil oma süntaks. Sellel on konkreetne struktuur, mõned märksõnad peavad ilmuma. Kuidas see välja näeb:

Funktsioon: rakendusest väljalogimine
Stsenaarium:
   Arvestades, et olen sisse logitud
   Kui klõpsan nupul „Logi välja”
   Siis olen kursis eduka väljalogimisega
   Ja mind suunatakse sisselogimislehele

Gherkinis kogutud nõuded salvestatakse .feature-faili. Tänu sellele saavad arendajad neid faile hõlpsalt kasutada kurkide abil automaatsete testide kirjutamiseks BDD-s (käitumispõhine arendus).

Uue nõuete kirjelduse loomiseks peame määratlema funktsiooni, mis annab meile uue funktsiooni nime. Seejärel jätkame stsenaariumi kirjutamist. Tasub mainida, et üks fail võib sisaldada rohkem kui ühte stsenaariumi. Iga stsenaarium koosneb kolmest peamisest etapist: antud, millal ja siis. Sõnale järgnev kirjeldus seab eeltingimused. Millal määratletakse konkreetses funktsioonis toimuvad toimingud ja kirjeldatakse seejärel toimingu eeldatavat tulemust. Ülaltoodud näites on veel üks märksõna: ja mis jätkab järgitavat meetodit. Seetõttu jätkatakse selle jaotise lisamisega pärast millal seda jaotist ja määratletakse veel üks toiming. Tšerkin teab veel ühte märksõna: aga - kui aus olla, siis kogu oma projektijuhi karjääri jooksul pole ma kunagi leidnud olukorda, kus seda saaks rakendada.

Sujuvaks muutumine

Vaadake näidet, milles kasutaja on sisse logitud iga stsenaariumi korral:

Funktsioon: Valige profiil
Taust:
   Arvestades, et olen sisse logitud
Stsenaarium: esimese profiili valimine
   Arvestades, et lähen pärast logimist rakendusse
   Kui minult küsitakse, millist profiili tahaksin oma loendist valida
   Ja valin nimekirjast profiili
   Siis näen selle profiili juhtpaneeli
Stsenaarium: järgmise profiili valimine
   Arvestades, et olen armatuurlaual
   Ja ma olen profiili valinud
   Kui valin rippmenüüst loendiga
   Siis näen selle jaoks armatuurlauda

Veelgi enam, kui soovime nõudeid arutada ja tulevikus katsetada mitut stsenaariumi, siis tasub kasutada mõnda näidet - kasutades näidet Funktsioon. Sellisel kujul andmete kogumine on sageli kõige ühemõttelisem. Näite kasutamiseks peame panema muutuja sisemised nurksulud <> ja panema tabelid stsenaariumi alla. Peame meeles pidama, et kui kasutame näiteid, peaks meie stsenaariumid saama nimeks Stsenaariumi ülevaade. Järgmine näide peaks selle selgeks tegema:

Funktsioon: logige sisse rakendusse
Taust:
   Arvestades, et olen registreeritud kasutaja
   Ja minu konto on aktiveeritud
Stsenaariumi ülevaade: edukas sisselogimine
   Arvestades, et olen sisselogimislehel
   Kui ma täidan "login" nupuga 
   Ja ma täidan sõna "parool" nupuga <õige parool>
   Ja ma vajutan nuppu "Logi sisse"
   Seejärel suunatakse mind profiili valimise lehele
Näited:
   | sisselogimine | õige parool |
   | Lukasz | Gh3rk1n |
   | Arek | Cucumb3r |
Stsenaariumi ülevaade: ebaõnnestunud sisselogimine
   Arvestades, et olen sisselogimislehel
   Kui ma täidan "login" nupuga 
   Ja ma täidan sõna "parool" sõnaga 
   Ja klõpsake nuppu "Logi sisse"
   Siis teavitatakse mind ebaõnnestunud sisselogimisest
Näited:
   | sisselogimine | vale parool |
   | Lukasz | Piparkoogid |
   | Arek | Kurk |
Stsenaarium: volitamata sisenemine
   Arvestades, et ma pole sisse logitud
   Kui ma üritan minna juhtpaneeli lehele
   Siis suunatakse mind sisselogimislehele

Muidugi muutuvad agiilses projektis nõuded. On vaja rakendada muudatused .failifailides ja seetõttu - käimasolevad muudatused rakendusetestides. Nii saame hoida oma dokumentatsiooni ajakohasena. Ülesannete stsenaariumidele vastava lõpuleviimise tulemusel pakutakse välja ja käitatakse elemente, mis sobivad ideaalselt Agiilse juhtimise põhimõtetega.

___

Algselt avaldas Łukasz Nowacki saidil neoteric.eu/blog 20. oktoobril 2016.