Meistringslæring blei lansert på 1960-talet, av Benjamin Bloom («Learning for mastery») og Fred Keller («Personalized System of Instruction» – PSI). Keller prøvde dette ut da han underviste i psykologi ved universitetet i Brasilia på 1960-talet. Sentrale idéar:

• Meistring av kursmaterialet. Pensum blir delt opp i læringsmodular, og studentar skal meistre første modul før dei går vidare til andre, osb., typisk gjennom ein test med høg grad av perfeksjon (t.d. score over 90%).
   
• Velje eige tempo («self-pacing»). Somme studentar lærer raskare, andre langsamare, og kvar kan velje sitt eige passande tempo frå modul til modul. Hovudidéen blir dermed at heller enn at alle studentar skal tvingast inn i same tempo, der somme oppnår meistring og andre ikkje, skal alle kunne oppnå meistring gjennom eit tempo som passar – men må kanskje da bruke meir tid.
   
• Ikkje introdusere nytt stoff gjennom plenums førelesing! Sidan studentane er på ulike nivå, har plenums førelesing lite for seg. Om ein i det heile bruker førelesing, bør det vere for motivasjon og demonstrasjon, men ikkje for innlæring av nytt stoff.

Det var aukande interesse rundt meistringslæring i Amerika på 1970-talet, med gode resultat i empiriske studiar (Kulik et al., 1979; Kulik et al., 1990), men interessa avtok etter kvart, mellom anna fordi det var ressurskrevjande med alle testane. Moderne IT-verktøy kan gjere det mogeleg å automatisere ein del av arbeidet når det gjeld gjennomføring og retting av testane, som kan gi von om ein ny vår for meistringslæring (Eyre, 2007). 

Bloom, B. S. (1968). Learning for Mastery. Instruction and Curriculum. Regional Education Laboratory for the Carolinas and Virginia, Topical Papers and Reprints, Number 1. Evaluation comment, 1(2), n2.

Keller, F. S. (1968). Good-bye, teacher... Journal of applied behavior analysis, 1(1), 79.

Keller, F. S. (1967). Engineering personalized instruction in the classroom. Revista Interamericana de Psicologia/Interamerican Journal of Psychology, 1(3).

Kulik, J. A., Kulik, C. L. C., & Cohen, P. A. (1979). A meta-analysis of outcome studies of Keller's personalized system of instruction. American psychologist, 34(4), 307.

Kulik, C. L. C., Kulik, J. A., & Bangert-Drowns, R. L. (1990). Effectiveness of mastery learning programs: A meta-analysis. Review of educational research, 60(2), 265-299.

Eyre, H. L. (2007). Keller's Personalized System of Instruction: Was it a Fleeting Fancy or is there a Revival on the Horizon?. The Behavior Analyst Today, 8(3), 317.

Meistringslæring oppsto i heilt andre fag, som psykologi, men programmering er eit fag der meistringslæring kan ha mykje for seg. Det finst somme grunnleggjande konsept og så gradvis meir avanserte konsept som byggjer på dei grunnleggjande konsepta. Det blir vanskeleg å skjøne dei meir avanserte konsepta dersom ein ikkje har meistra dei grunnleggjande. Døme på svært grunnleggjande konsept er variable og operatorar. Dersom ein ikkje har forstått desse, blir det vanskeleg å kome vidare til dømes til kontrollstrukturar som if-setningar og løkker, sidan variable og operatorar typisk også inngår her. Robins (2010) kallar dette fenomenet «learning edge momentum» - ein student som har god meistring av dei grunnleggjande konsepta, vil ha ein fordel vidare, medan dei som først har kome litt bakpå, vil hamne meir og meir bakpå. 

Meistringslæring har dermed vore ein del brukt i intro programmeringsundervisning dei siste åra, både i Noreg (Purao et al., 2016) og utlandet, t.d. (Garner et al., 2019). Vårt opplegg hentar inspirasjon frå desse andre, men er samstundes også annleis på visse måtar.

Purao, S., Sein, M., Nilsen, H., & Larsen, E. Å. (2016). Setting the pace: Experiments with Keller's PSI. IEEE Transactions on Education, 60(2), 97-104.

Garner, J., Denny, P., & Luxton-Reilly, A. (2019, January). Mastery learning in computer science education. In Proceedings of the Twenty-First Australasian Computing Education Conference (pp. 37-46).

Emnet er delt opp i 9 modular, som har fått namn I, H, G, F, E, D, C, B, A – fordi karakter direkte blir bestemt av kor mange modular kandidaten har greidd, som vist i figuren.


For å stå i emnet må altså studenten ta dei 5 første av 9 modular, medan ein må ta alle 9 modulane for å få toppkarakter. Å ta ein modul, inneber:

• Å klare ein auto-retta test for modulen (typisk med stågrense 90%) 
   
• Å levere eit prosjekt. Prosjektet er eit individuelt programmeringsprosjekt, som kan vere det same programmet gjennom heile semesteret, berre at studenten byggjer på programmet litt og litt for kvart bokstavnivå.

Læringsutbyta for emnet kan sjåast her

Her er det slik at kunnskapsmåla K1, K2, K3 og dels også F1 er mest dekt av dei automatiserte testane, medan måla F2, F3 og G1 er mest dekte av prosjektet. 

Summative testar for kvar modul vart haldne kvar fredag gjennom semesteret. Sentralt i undervisningsopplegget sto dessutan obligatoriske seminar. Hausten 2023 var desse ein dobbelttime kvar torsdag.

Testane blir gjort i eksamensverktyet Inspera og er 100% autoretta. Dessverre har ikkje Inspera nokon oppgåvesjanger der skriving av kode kan autorettast. Såleis handlar oppgåvene dels om å forstå programkode (skjøne kva den vil kome til å gjere, om den er korrekt eller ikkje), dels om å komplettere kode der noko manglar (fylle inn eller velje kva som skal setjast inn i tomrom i delvis ferdig kode), eller plassere i rett rekkefølgje kodeliner som er stokka om, noko som innan programmeringsundervisning internasjonalt gjerne blir kalla Parsons problems (Du et al., 2020). Oppgåver med komplettering og omstokking av kode har generelt vist seg å korrelere bra med oppgåver om skriving av kode (Cheng & Harrington, 2017).

Spesielt for vårt opplegg var at vi hadde svært høg transparens når det galdt testane. Studentane hadde tilgjengeleg formative treningstestar med dei same oppgåvene som dei summative testane inneheldt. Dermed kunne studentane bruke dette som eit aktivt verktøy for sjølv-tilbakemelding. Ta ein treningstest. Du ser at du scorer berre 60% og veit at du treng 90% på den summative testen. På kva deloppgåver er det du mistar poeng, og kva programmeringskonsept er det dermed du treng å skjøne betre? Sjå læringsvideoar om akkurat dette, prøv ein ny treningstest, osb. Men – for å unngå at eit så transparent opplegg skulle føre til rein pugg av svar, måtte vi lage mange ulike variantar av kvar deloppgåve. 

Under viser vi to konkrete døme på oppgåver frå G-testen, som altså var den tredje testen i rekkja, og der hovudtemaet var logiske vilkår og if-setningar. Begge oppgåvene fanst i om lag 20 variantar som Inspera ville trekkje tilfeldig mellom på kvar einskild student sin treningstest eller summative test. Den første figuren viser ein variant av oppgåve G-7. Dette er ei oppgåve som testar forståinga av kode, her spesifikt å forstå kva som blir resultatet av eit logisk uttrykk som inkluderer operatorar and, or, not. 

Den neste figuren viser ein variant av oppgåve G-8, som er ei oppgåve som krev mykje meir algoritmisk tenking, ved at ein må klare å pusle saman eit fungerande program ved å setje tilgjengelege bitar i rett rekkjefølgje, og med riktige innrykk, sidan innrykka er semantisk signifikante i Python. Læringsutbytet denne oppgåva skal teste, er om studentane har forstått if-setningar, skilnaden på når ein må bruke nøsta if-setningar eller to uavhengige if-setningar, og at ein greier å knytte else-delen til riktig if. 

Du, Y., Luxton-Reilly, A., & Denny, P. (2020, February). A review of research on parsons problems. In Proceedings of the Twenty-Second Australasian Computing Education Conference (pp. 195-202).

Cheng, N., & Harrington, B. (2017, March). The Code Mangler: Evaluating coding ability without writing any code. In Proceedings of the 2017 ACM SIGCSE Technical Symposium on Computer Science Education (pp. 123-128).

Prosjektet var individuelt, dvs. kvar student skulle skrive sitt eige program. Vi vurderte også å ha prosjektet som gruppearbeid, men tenkte at det ville kunne ha fleire ulemper enn fordelar når kvar student kan ha ulikt tempo og ambisjonsnivå. Kvar student sto fritt til å bestemme kva sitt program skulle handle om, med ei viktig føring: programmet måtte vere noko som kunne ha vore tenkt brukt i undervisning av denne studenten sitt disiplinfag på LUR-studiet, for 8.-13. trinn i skulen.

Studentane på LUR vel ulike spesialiseringar allereie frå første semester. Det er fem mogelege retningar: Matematikk + Fysikk, Matematikk + Informatikk, Matematikk + Kjemi, Matematikk + Biologi og Kjemi + Biologi. La oss t.d. ta ein student som går Kjemi + Biologi, denne kan da velje mellom sju ulike fag som Python-programmet kan vere tenkt brukt i: Naturfag 10. trinn, Naturfag vg1, Naturfag vg3, Kjemi 1 vgs, Kjemi 2 vgs, Biologi 1 vgs, Biologi 2, vgs. Innanfor desse faga står studenten heilt fritt, både til kva fagleg tema programmet skal omhandle og kva slags type læringsprogram det skal være (t.d. quizprogram, spel, tutorial, simulering av naturfenomen, …)

Lat oss seie at studenten vår tenkjer å gjere noko for faget Biologi 2 i vgs. Ein kan da anten sjå i ei lærebok for dette for å hente inspirasjon, sjå på Udir sin læreplan, snakke med tidlegare lærarar frå faget, snakke med klassekameratar, eller anna. Om vi tar utgangspunkt i Udir sin læreplan for Biologi 2, https://www.udir.no/lk20/bio01-02/kompetansemaal-og-vurdering/kv539 , har denne 11 kulepunkt med kompetansemål, og kvart av desse kan vere mogeleg tema for eit program. For somme vil simulator kunne passe godt, t.d. punkt 3 om populasjonsøkologi, for andre vil et program som samlar inn og presenterer informasjon kunne passe godt (t.d. data frå feltarbeid), og for atter andre vil kanskje quiz-program passe best.

I motsetning til testane som trener studentene i å løyse ein masse små og generiske oppgåver, gir prosjektet sjansen til å gjere noko meir kreativt som også er kontekstuelt relevant i  forhold til studenten sin framtidige profesjon som lektor.

For å ikkje drukne i vurderingsarbeid, hadde vi ikkje nokon strenge kvalitative krav til prosjektet. Krava for kvar innlevering var berre at:

• programmet må køyre feilfritt
   
• gi forståeleg informasjon ut på skjermen
   
• ha gjort føremålstenleg bruk av dei sentrale konsepta som har vore gjennomgått i tilsvarande testar opp til og med den aktuelle modulen. 

For G-prosjektet var det dermed eit krav at koden måtte ha gjort bruk av logiske vilkår og if-setningar, som var sentrale tema for den bolken. Krava for kvar modul var sette opp i sjekklister som studenten først vurderte og kryssa av sjølv, og som fagstaben deretter såg over.

Seminara vart haldne i eit interaktivt læringsareal med gruppebord, og der kvart gruppebord hadde ein halvstor veggskjerm. Sidan studentar var på ulikt nivå, var det ikkje noko poeng i plenums presentasjon av fagstoff. Det einaste seminaret som litt hadde preg av førelesing, var det aller første, men da for at faglærar skulle forklare og motivere for emnedesignet og undervisningsopplegget, ikkje for å undervise i programmering. Resten av semesteret hadde seminara typisk ein 5 minutts motivasjonsprat frå faglærar heilt i starten, deretter sat studentane og jobba gruppevis. 

Somme studentar brukte seminaret til å bu seg til neste test. Da kunne 5-6 studentar som var på same nivå, og t.d. neste dag skulle ta G-testen, ta opp ein G-treningstest på skjermen og diskutere seg gjennom den oppgåve for oppgåve. Somme oppgåver gjekk kanskje raskt, medan andre oppgåver (t.d. G-8) kunne trengje ein god del diskusjon før dei vart samde om kva som burde vere rett svar og korfor. Straks dei leverte, fekk dei automatisk tilbakemelding og kunne sjå om dei hadde alt rett eller ikkje – og om det var tid igjen, kunne dei prøve enda ein G-treningstest. Andre var kanskje på eit anna nivå og øva til F-testen, og atter andre kunne ønskje å jobbe med programmeringsprosjektet i seminartida – desse blei sette på bord saman etter kor langt dei hadde kome med prosjektet.

Sidan seminara hadde obligatorisk oppmøte (80%) kom alle bortsett frå ved sjukdom, og dette var eit viktig bidrag til at studentane blei kjende med andre i klassen.