Tarkvaraarendus algajatele: Kriitiline pilk ja lahendused järgmiseks aastaks

Kui alustasin “Sissejuhatus tarkvaraarendusse” kursuse ettevalmistamist, ei teadnud ma väga täpselt, mida pidin tegema või kuidas programmi üles ehitada. Seega lootsin uurida õppijate vajadusi ja täiendada kursust vastavalt sellele, mida näen – mida näen, et on vaja või kuidas on vaja.

Tagantjärele vaadates tundub, et sellest lähenemisest tulid õppetöö alguses ka teatud struktureerimatus, ning puudus seega ka kindel raamistik, mis oleks aidanud seda kursust struktureerida.

Kursus oli suunatud Rakendusinformaatika eriala esmakursuslastele. Enamik neist pole tugeva IT-taustaga, vaid alles teevad esimesi samme selles vallas. kuid on ka neid, kel tarkvaraarendusest teadmised süvitsi või lausa töötavad sel alal. Tegelikult ei teadnud ma, mida pidin tegema või kuidas üldse midagi teha. Pigem plaanisin alustada uurivalt ja täiendada õppekava vastavalt sellele, mida näen.

Käesolev artikkel vaatleb kriitiliselt kursuse jooksul tehtut, toob esile selle kitsaskohad ja pakub välja võimalikud lahendused tuleviku jaoks.

Mida me ei teinud?

Me ei korraldanud tuima teoreetilist loengusarja teemal, mis on tarkvara arendus.
Vähemalt ei plaaninud sellist, vaid tegime suuremas osas praktilise, grupi- ja individuaalsete tööde ja aruteludega seminaride sarja, mille vahel olid kodutööd. Võibolla välja kukkus teisiti, eks tulevikus kuule seda üliõpilastelt. Eesmärk oli näidata, et tarkvara arendus ei võrdu koodimine, vaid on laiem tervik, hõlmates toote loomist, disaini, projekti juhtimist jne.

Kursuse alustalad ja õpikeskkond

Üks minu peamisi eesmärke oli pakkuda praktilist õpikogemust. Kursuse keskmes oli git’i ja Githubi kasutamine ja ülevaate andmine tarkvaraarendusest üldse. Õpilased alustasid versioonihalduse põhitõdedega: kuidas luua repositoorium, teha commite ja hallata muudatusi. Lisaks uurisime, kuidas tõhusalt kasutada pull request’e ja code review protsesse.

Kodutööde ja muude ülesannete esitamine käis Githubis pull requestide kaudu. Enne kodutöö õppejõule, ehk mulle saatmist, tuli sellele kaasüliõõpilase poolne code review teha.

Seminarides keskendusime agiilsetele meetoditele, tarkvaraarenduse elutsüklile ja rollidele meeskonnas. Kuigivõrd oli kuivemat sorti teooria lugemist, kuid üldjuhul püüdsin teadmiste omandamise viia läbi grupi- ja inidviduaaltööde tasandil. Minu jaoks oluline oli selgitada, miks head commit-sõnumid ja regulaarne commitimine on mitte ainult hea tava, vaid ka osa tõhusast tarkvaraarendusest. Iseküsimus, kuidas see sihtgrupini jõudis.

Õpilaste refleksioonid

Õpilaste refleksioonid andsid head tagasisidet. Näiteks kiideti praktilisi seminare, kuid toodi välja, et tempo oli algajatele kohati liiga kiire. Algajad tundsid, et oleks vajanud rohkem tööriistade tutvustamist ja lihtsamaid harjutusi, et mitte tunda end ülekoormatuna. See puudutas peamiselt terminali ja Visual Studio Code’i kasutamist. Tegelikkuses ei olnud töö terminalis esimesel poolaastal vajalik, Github Desktop’i kasutamine oli piisav, kuid ilmselt jäi see kas ebaselgeks või oleks ka Github Desktopi kasutamise suurem juhendamine vajalik olnud. Seda peab järgmisel aastal arvesse võtma.

Kogenumad õppurid andsid mõista, et osa teemadest oli nende jaoks juba tuttav ning nad oleksid soovinud rohkem väljakutseid. See viitab vajadusele diferentseerida õpetamist rohkem vastavalt õppurite tasemele.

Üks tõsisem murekoht oli osade õppijate passiivsus grupitöödes. Sageli jäi aktiivsus jaotamata, kusjuures osa ülioõpilasi võttis kogu koormuse enda kanda, samas kui teised taandusid vaatajapositsioonile. Reflektsioonides pakuti välja, et konkreetsemate rollide määramine ja regulaarne grupitöö hindamine võiksid aidata seda probleemi lahendada.

Seminarides sõna võtmist nähti samuti väljakutsena. Vaiksemad õppurid tundsid, et vajaksid rohkem julgustamist või struktureeritumat viisi oma ideede esitamiseks. Võib-olla aitaksid siin rohkem anonüümsete ideede esitamise meetodid või ettevalmistatud aruteluküsimused.

Kuigi code review protsess näitas edusamme, ilmnes ka siin kitsaskohti. Reflektsioonidest selgus, et paljud õppijad ei osanud anda sisulist tagasisidet, sest neil puudus selge arusaam, mida hinnata ja kuidas seda konstruktiivselt esitada. Osad tundsid, et nad ei olnud piisavalt kindlad, et kaasõpilaste töid kritiseerida, kartes negatiivset reaktsiooni. Reflektsioonides pakuti välja vajadus töötoa järele, kus tutvustatakse heade kommentaaride põhimõtteid ja näidatakse, kuidas anda tõhusat tagasisidet. Samuti mainiti, et võib olla kasulik jagada anonüümseks tehtud näiteid nii headest kui ka parandamist vajavatest code review’dest, et selgitada standardeid ja ootusi.

Võtmekohad hindamises

Kogu protsessi analüüs näitas, et need, kes esitasid töid regulaarselt ja hajutasid oma pingutused kogu semestri peale, saavutasid paremaid tulemusi. Need, kes jätsid kõik viimasele minutile, nende tulemused olid halvemad, arusaam arendusest ebaselgem.

Hindamise osas ilmnes mitmeid probleeme. Commitite regulaarsuse ja kvaliteedi rõhutamine jäi ebapiisavaks, samuti polnud hinnangutes alati selge, kuidas õppija arengut mõõdetakse. Tulevikus peaks hindamisskeem olema läbipaistvam ja keskenduma rohkem õppimisele kui pelgalt tulemusele – protsessi olulisus peaks õppijatele selgemaks saama.

Lisaks on oluline rõhutada õigeaegset tööde esitamise tähtsust. Kui õpilane võtab kogu kursuse jooksul vaid paar suurt sammu, kaotab ta võimaluse õppida pideva tegemise ja tagasiside kaudu.

Tuleviku plaanid

1. Kogenud õppurite kaasamine mentoritena

Kogenumad õppurid saavad väärtuslikuks ressursiks, kui neid suunata algajaid juhendama. Kahjuks sel korral ei toimunud piisavalt aktiivset mentorlust – ei osanud veel seda ressurssi kasutada, mistõttu on see kindlasti üks arengukohti tulevikus. See mitte ainult ei toeta algajate õppimist, vaid hoiab ka kogenumad õppurid motiveerituna. Selle jaoks leiab kindlasti materjali ja kolleegide soovitusi, kuidas seda paremini teha.
Ilmselt peaks see olema selline lahendus, kus tarkvara arendusega juba sina peal olev üliõpilane ei ole mitte õpetaja rollis, vaid grupitöös sobivas rollis, kus saab oma nõuga kasulikult protsessi suunata, mille läbi teised õpivad.

2. Grupitöö initsiatiivi tõstmine

Seminarides võiks kasutada rohkem struktureeritud grupitöid, kus igaühel on kindel roll (nt analüütik, disainer, testija). See aitaks julgustada aktiivset osalemist ja anda selgemaid vastutusvaldkondi. Seda on ilmselt esimesel poolaastal palju nõuda, kuid hea oleks, kui see mingil moel ise organiseeruks. Võib nuputada mingeid “nügimismeetodeid”.

3. Aktiivne osalemine seminarides

Seminarides võiks rakendada rohkem interaktiivseid mänge ja arutelusid, mis kaasaksid ka vaiksemad õppurid. Millised konkreetsed mängud ja harjutused sobiksid? Kuidas motiveerida vaiksemaid õppureid aktiivselt osalema? Lisaks saaks kasutada tehnoloogilisi lahendusi, nagu anonüümne välja pakutud ideede hindamine, kuid kas see oleks piisav, et kõiki kaasata? Võiks kaaluda ka tagasiside ankeete, et saada paremat pilti nende osalusvalmidusest.

4. Commitite kvaliteedi hindamine

Regulaarne ja sisukas commitimine võiks olla hindamiskriteerium, kuid selle mõju õppijate motivatsioonile ja arengule tuleb hoida “radaril”. Selle asemel, et rõhuda ainult formaalsele mõõdikule, võiksin uurida, kuidas commitimine aitab kaasa õppija tegelikule oskuste kasvule. Kas tunnustus, nagu “parima commiti” auhind, võiks luua positiivse õhkkonna või pigem soodustab liigset konkurentsi? Peaks proovima ka leida rohkem toetava ja arutleva õpikeskkonna loomisele, kus commitid peegeldavad õppija arengut, mitte vaid nõuetele vastamist.

5. Projekti pidev iteratsioon

Tulevikus tahan enam rakendada iteratiivset lähenemist, kus õppijad saavad täiendada oma töid ja tagasiside põhjal neid parandada. See annaks neile võimaluse näha oma arengut ja muuta õppetöö dünaamilisemaks. Tagasisidest ilmnes, et neile meeldiks kui oleks suurem selgus lõppeesmärgist. Võib mõelda mingit laadi projekti koostamsie peale kohe algusest, nii nagu meil on järgmistes ainetes.

Kokkuvõte

Kokkuvõttes oli “Sissejuhatus tarkvaraarendusse” praktilise suunitlusega, kuid kannatas vähemalt alguses selgelt läbimõeldud struktuuri puudumise all. Õppurite vajaduste ja tasemete mitmekesisus tõi esile vajaduse kohandada lähenemisviise ning arendada paremaid toetusmehhanisme. Tulevikuplaanid peavad keskenduma süsteemsemale kavandamisele, õppurite aktiivse kaasamise suurendamisele ja nende iseseisvuse soodustamisele. Paras väljakutse on luua kursus, mis on samaaegselt paindlik, struktureeritud ja vastab erinevate õppijate ootustele.

Illustratsioon: Midjourney
Viip:
Illustration for Teaching Software Development (Sketchbook Style)
Main Subject:

• A teacher (let’s call them Alex) standing confidently with a laptop under one arm and gesturing toward a chalkboard or digital screen filled with code snippets and diagrams. The teacher should have a casual, approachable look—perhaps glasses, a hoodie, or a T-shirt with a programming pun.

Sketch Elements:

• Use loose, gestural pencil lines for the main drawing, keeping some areas detailed (like the teacher’s face) and others rough (like their shoes or background items).
• Add cross-hatching and shading to the laptop, chalkboard, and teacher’s stance for depth.

Scatter margin notes around the main drawing, such as:

• “Debugging guru.”
• “Explains recursion with cookies.”
• “Git master.”
• Include mistakes like light eraser marks, faint smudges, and overlapping lines for authenticity.

Small Doodles:

• Tiny sketches of a bug (representing debugging), a computer with "" on the screen, and a coffee mug with “Ctrl+Alt+Del” on it.
• A flowchart with arrows labeled “Input → Process → Output.”
• Sticky notes with words like “Sprint planning” and “Code review.”

Color Splashes:

• Minimal watercolor-like splashes of color: green on the chalkboard, yellow on sticky notes, and blue highlighting Alex’s laptop.
  Background:
• An off-white or textured paper background with visible pencil strokes. A faint grid pattern might suggest a coding notebook.

Extra Scene:

• In one corner, sketch a small scene of students collaborating on a project, represented as stick figures around a large screen displaying code.

—ar 3:2