Lahendused suurtele väljakutsetele sünnivad harva vaakumis. Esimese etapina paneme kokku tiimi, et saaksime rollidele ja nende vahelistele suhetele protsessiliselt otsa vaadata.
Kujutame ette siseveebi projekti, mille eesmärgiks on koguda kasutajatelt tellimusi, hallata tellimusi ja kasutajaid ning koguda ja genereerida statistikat kasutajate ja tellimuste kohta. Rakendus suhtleb majandushaldustarkvaraga (MHT) ning võimaldab genereerida tellimustele automatiseeritud arveid.
Instinktiivselt kaevume sügavamale: kes on kasutajad ja millised on nende harjumused? Kuidas kasutaja registreerub ja sisse logib? Milliseid tooteid müüakse? Kust tuleb tooteinfo? Kas erinevatel kasutajatel võivad olla erinevad ostutingimused ja hinnakirjad? Milliseid tegevusi hõlmab haldusprotsess? Mille põhjal ja millistel tingimustel genereeritakse statistikat? Millise MHTga on tegemist ja kas sellel eksisteerib toimiv liides? Kas arveid loob ja genereerib MHT või siseveeb?
Küsimusi tekitavaid kohti on nii palju, et neid on isegi parima tahtmise korral väga keeruline tervikuna ette valmistada. Parim praktika selliste komplekssete probleemide lahendamiseks on eesmärgistatud ja rollipõhine tegevuste jaotus.
Olukorra lahendamiseks komplekteerime spetsialistide tiimi:
- Analüütik
- Eesmärk: komplekteerida ja detailselt dokumenteerida kõik projektiga seonduvad funktsionaalsed ja mittefunktsionaalsed vajadused ning kasutusjuhtumid.
- Tulemid: analüüsidokumentatsioon (eel/detailanalüüs), arenduspiletid.
- Kasutajakogemuse disainer (UX - user experience)
- Eesmärk: uurida, mida lõppkasutaja tegelikult vajab ja defineerida persoonad. Luua prototüüp ja testida seda lõppkasutajate peal.
- Tulemid: kasutajate persoonad, wireframe´d, kasutuslood.
- Kasutajaliidese disainer (UI - user interface)
- Eesmärk: luua visuaalselt ühtne ning atraktiivne kasutajaliides vastavalt testitud prototüübile ja ettevõtte visuaalsele identiteedile.
- Tulemid: kasutajaliides ja sellega seonduvad moodulelemendid.
- Back-end arendaja (BE)
- Eesmärk: tuginedes analüüsile, defineerida arhitektuur ning luua toimiv andmestruktuur kasutajate ja toodete info hoiustamiseks ja muutmiseks. Arendada vajalikud liidesed nii sise- kui väliskommunikatsiooni jaoks.
- Tulemid: arenduskood, seostatud andmebaasid, SQL päringud, defineeritud süsteemsed piirangud ja õigused.
- Front-end arendaja (FE)
- Eesmärk: tuginedes analüüsile, disainitud kasutajaliidesele ning back-end arendaja poolt sätestatud õigustele ja piirangutele, luua funktsionaalselt toimiv ja kasutatav visuaal.
- Tulemid: HTML, CSS, JavaScript visuaalne arenduskood, taustsüsteemidega (back-end) liidestus, WCAG standarditele ja kasutajaliidesele vastavus.
- Tarkvaratestija
- Eesmärk: läbi metoodilise lähenemise avastada arendajate poolt loodud lahenduse puudujääke, võrreldes neid nii analüüsi, UI disaini ning mittefunktsionaalsete nõuete vastu.
- Tulemid: testitud rakendus, arenduspiletid.
Siinkohal tasub mainida, et komplekteeritud tiimis ei ole täidetav roll alati üks-ühele seoses inimeste arvuga projektis. Vastavalt projekti keerukusele, mahule ja ajaraamile võivad ühte rolli täita mitu erinevat tiimiliiget või üks tiimiliige võib korraga täita mitut rolli.
Näiteks võib tiimis olla disainer, kes on suuteline täitma korraga nii kasutajakogemuse (UX) kui kasutajaliidese (UI) disaineri rolli. Samuti võib tiimis olla täispinu (full-stack) arendaja, kes täidab korraga nii front-end (FE) kui back-end (BE) arendaja rolli.
Erandlikult on teenusedisaini ja tarkvaraarenduse rollid lahus. Seda põhjusel, et disainerite ja arendajate oskuspagasid on piisavalt erinevad, et mitte omada suurt ühisosa. Erand kinnitab reeglit ja sellest tulenevalt eksisteerib ka näiteid, kus disainer on varasemalt programmeerinud.
Samuti võib tuua mitmeid näiteid, kus arendaja on varasemalt testinud ja analüütik on varasemalt disaininud või programmeerinud. Moodne tarkvaraarendus on üles ehitatud tihedale suhtlusele ning erinevate rollide ja tegevuste sügavam mõistmine annab tiimile tugeva eelise.