Selleks, et mõista, mis asi on sprint, peame enne tegema selgeks, mis asi on scrum. Neid mõisteid kasutatakse peamiselt organisatsioonides, mis on seotud tarkvaraliste teenuste/toodete arendamisega.
Scrum on raamistik, mis aitab inimestel ja organisatsioonidel luua väärtust ja lahendada kompleksseid probleeme kasutades selleks adaptiivset lähenemist.
Lihtsamalt öeldes on scrum põhimõtete kogumik, mille abil saavad arendusmeeskonnad oma tööd efektiivsemalt korraldada ja eesmärke saavutada.
Scrum ja selle rakendamine
Kuigi scrum raamistikku kasutatakse laialdaselt, olen näinud ja kogenud, et osades organisatsioonides ei rakendata seda raamistikku alati nii nagu peaks. Kuna arendusmeeskonnad ja organisatsioonikultuurid võivad juba oma olemuselt olla väga erinevad, siis hakatakse seda raamistikku kohandama endale sobivamaks. See ei pruugi olla iseenesest halb, kuid alati peaks sel juhul veenduma, et sellest oleks ka päriselt kasu.
Scrum töötab järgmiselt: Kõigi tootega seotud arenendusülesannete hulgast (product backlog) valitakse sprindikoosolekul (sprint planning) ülesanded, mis peavad järgmise sprindi jooksul saama tehtud (sprint backlog). Seejärel alustab arendusmeeskond tööd (scrum team) ning sprindi ajal teevad iga päeva stand-up ehk ülevaatekoosolekuid (daily scrum). Kui sprint saab läbi, siis peavad sprinti valitud ülesanded olema valmis ja sellega koos ka tükk tarkvara (increment). Sprindi lõpus vaadatakse üle, mis sai valmis (sprint review) ning õpitakse tehtust (sprint retrospective). Kui juhtus nii, et midagi ei saadud valmis või sprindi käigus selgus uusi asjaolusid, mis vajavad eraldi tähelepanu, siis need ülesanded lähevad tagasi kõigi tootega seotud arendusülesannete hulka (product backlog), kus järgmise sprindi koosolekul (sprint planning) saab jälle valida uusi ülesandeid sprinti.
Kui näiteks arendusmeeskond ei vii läbi korralikke sprindi planeerimise koosolekuid, ei tee igapäevaseid ülevaatekoosolekuid, ei analüüsi eelnevaid arendusi või sprinti valitud ülesanded on hoomamatud, siis tekib suur oht, et scrum muutub kasutuks ning tekitab pigem probleeme juurde, kui neid lahendab. Seega peavad arendusmeeskonnad ja organisatsioonid mõtlema, mida ja keda neil on vaja, et scrum enda jaoks edukalt tööle panna.
Scrum-i põhiline idee seisneb iteratiivses ja pidevat õppimist julgustavas tootearenduses.
See tähendab, et arendusmeeskond planeerib oma tööd väikeste tükkidena, siis hakatakse seda tööd reaalselt tegema ning lõpuks vaadatakse töö üle ning sellest õpitakse. Seejärel protsess kordub ja nii sadu või tuhandeid kordi.
SPRINT ja sprintimine
Sprint on üks põhilistest sündmustest, mille abil scrum üldse töötab. Edukas sprint võib olla seega üks mõõdikuid, mille alusel saab öelda, kas arendusmeeskond rakendab scrum-i õigesti või mitte. Kui sprindid ei toimi – see tähendab, et väärtust ei looda, uusi funktsionaalsusi ei saada valmis ja probleeme ei lahendata, siis üsna suure tõenäosusega on probleem scrum-i õiges rakendamises. Seega scrum-i põhimõtete õige rakendamine on esimesi asju, millest arendusmeeskond peaks alustama, et sprintimine muutuks edukaks.
Sprint on regulaarselt toimuv fikseeritud ajaperioodiga sündmus, kus tehakse kokkulepitud osa töödest, mis on vajalikud toote eesmärkide saavutamiseks.
Sprindi pikkus võib olla üks kuu või vähem ja sprindi lõpus peab valmima konkreetne ja töötav tükk tarkvara. Sprint loob selleks suurepärased eeldused, sest võimaldab kogu arendusmeeskonnal keskenduda kindla perioodi jooksul konkreetse eesmärgi täitmisele. Seega arendusmeeskondadele, kelle eesmärk on regulaarselt ja pidevalt välja lasta uusi funktsionaalsusi, on sprintimine suureks abimeheks selle eesmärgi saavutamisel.
Eeldused edukaks sprindiks
Kõik arendusmeeskonnad, kes tahavad sprindist võimalikult palju kasu lõigata, võiksid arvestada allpool toodud soovitustega. Need põhinevad isiklikul kogemusel ning scrum-i olemusel. Need loovad eelduse edukaks sprindiks ning kindlasti aitavad arendusmeeskondi, kes ei taha või ei saagi kõiki scrum-i põhimõtteid rakendada, kuid siiski sprindivad.
Järgi scrum-i põhimõtteid
Alustame kõige olulisemast! Need põhimõtted ja juhised on paika pandud põhjusega. Nende eesmärk ongi ju aidata arendusmeeskonnal scrum-i rakendada. Kui seda teha, siis kõik muu polegi enam nii oluline.
Toote prioriteedid peavad olema selged
Toote omaniku ülesanne on selgelt kommunikeerida lühemas ja pikemas plaanis, mida ja miks tuleb arendada. Seda tehes on horisont alati selge ning sprindi eesmärke lihtsam seada. Lisaks aitab see hoida järjepidevust ning kindlasti vähendab arendusmeeskonna stressi.
Sprindid peaksid olema ette planeeritud
Arendusmeeskond peaks mõtlema vähemalt 1-2 sprinti ette, võimalusel isegi pikemalt. See läheb kokku eelmise punktiga ning tagab suurema selguse pikemas perspektiivis ja hoiab ära kiirustamise või kaose sprindikoosolekutel. See tähendab ka seda, et ülesanded on läbi arutatud ning ette valmistatud nii palju kui sel hetkel võimalik.
Sprindikoosolek
Kui eeldused olemas, siis võib juba hakata vaatama detailsemalt tööülesandeid. Sprint on meeskonnasport ja kõige olulisemad otsused tehakse sprindi planeerimise koosolekutel. Nendel otsustel võib olla oluline mõju sprindi edukusele ning kokkuvõttes ka toote eesmärkide saavutamisele. Põhilised otsused sprindi edukaks läbiviimiseks on järgmised:
Mis on eesmärk?
Mida tahetakse sprindiga saavutada? Arendusmeeskond peab selles kokku leppima nii, et kõik saavad aru, mis peab sprindi lõpuks olema juhtunud. Pole mõtet alustada sprindiga, kui pole selge, mida sellega tahetakse saavutada.
Kui keerukas see on?
Keerukuse ja võimaliku ajakulu hindamine on omaette kunst ning scrum-i juhendis sellest eriti ei räägita. See on iga arendusmeeskonna enda otsustada, kuidas ülesannete keerukust koos ajakuluga hinnata. Hindamine aitab pikemas plaanis muuta sprintide planeerimise veelgi tõhusamaks, sest võimaldab arendusmeeskonnal aru saada, kui palju ülesandeid on võimalik sprindi jooksul ära teha.
Kes seda teeb?
See tähendab ressursside planeerimist. Arendusmeeskonnas on mitmeid arendajaid ning kõigil peavad olema ülesanded sprindiks planeeritud. Enne sprindi algust peab olema selge, kui palju tööd arendajatel on, kas keegi on ülekoormatud või alakoormatud ning täpsemalt, kes millega tegeleb.
Kui need põhiasjad on korras, siis on suures pildis juba väga hästi. Nüüd saab sprinti planeerida nii, et kõigile on selge, mida on vaja teha, kas see on ajaliselt reaalne ning kes täpselt mida teeb. Ülejäänud seisneb juba detailides ja mehaanikas, kuidas arendusmeeskond päriselt töötab (protsessid) ja otsuseid teeb.
Olen näinud, et scrum-i rakendamine on lihtsam, kui kokku tuleb uus arendusmeeskond ja nad hakkavad õigeid põhimõtteid kohe algusest kasutama. Palju keerulisem võib see olla olukordades, kus arendusmeeskond on osaliselt scrum-i põhimõtteid juba kasutanud pikka aega, kuid pole paljusid olulisi protsesse oma töövoogu integreerinud.
Sellised arendusmeeskonnad ei ole tõenäoliselt väga tõhusad oma toimetustes ning kindlasti suurendab see kaose ja probleemide riski. Muutumist võib segada ka inerts, mis on meeskonnal juba nii tugev, et selle seisma panek tundub ilmvõimatu. Pakun, et selliseid arendusmeeskondi saab suunata õigele teele ainult kahte moodi: 1) kiire ja täielik restart või 2) aeglased ja järjepidevad muutused protsessis, mis lõpuks viivad õigete scrum põhimõtete rakendamiseni.
Mida jätta meelde?
Tee selgeks scrum-i põhimõtted
Loo eeldused edukaks sprintimiseks
Sprindikoosolekutel tehke otsuseid
