Lesmateriaal: verschil tussen versies
(15 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 3: | Regel 3: | ||
* uitgangspunten | * uitgangspunten | ||
* manier van werken | * manier van werken | ||
* "deployment"/gebruik | |||
** nascholing | |||
** ondersteuning voor docenten (netwerk; forum) | |||
** ondersteuning voor leerlingen (e.d., forum) | |||
== Uitgangspunten == | == Uitgangspunten == | ||
* concept-context aanpak (waar zinvol) | * concept-context aanpak (waar zinvol) | ||
** contexten: actueel, relevant en herkenbaar voor leerlingen | |||
* modulaire aanpak; modules niet te groot | * modulaire aanpak; modules niet te groot | ||
** badge voor afronden van een module? | |||
* onderscheid HAVO/VWO(?) | * onderscheid HAVO/VWO(?) | ||
** doenende denkers, denkende doeners | ** doenende denkers, denkende doeners | ||
Regel 13: | Regel 19: | ||
** | ** | ||
* waar mogelijk geschikt voor zelfstudie | * waar mogelijk geschikt voor zelfstudie | ||
** ook te volgen voor leerlingen als eigen docent geen expertise in dit domein heeft | |||
* "kleine stappen" - met resultaat en evaluatie voor elke stap | * "kleine stappen" - met resultaat en evaluatie voor elke stap | ||
* gericht op "mastery based learning" - je gaat pas verder als je de voorafgaande stappen beheerst. | * gericht op "mastery based learning" - je gaat pas verder als je de voorafgaande stappen beheerst. | ||
Regel 18: | Regel 25: | ||
=== Hoe ziet het resultaat eruit? === | === Hoe ziet het resultaat eruit? === | ||
* | * leesstof (eventueel aangevuld met video's) | ||
* naslag/referentie-materiaal | * naslag/referentie-materiaal | ||
* self-assessments (formatieve toetsing) | * self-assessments (formatieve toetsing) | ||
* praktische opdrachten | * praktische opdrachten | ||
** | ** 1. tutorial (nadoen; met uitleg en assessment-vragen) | ||
** experimenten (zelf uitzoeken; o.a. aan de hand van leesmateriaal) | ** 2. experimenten (zelf uitzoeken; o.a. aan de hand van leesmateriaal) | ||
** eigen uitbreidingen | ** 3. eigen uitbreidingen | ||
* Open Source/Creative Commons (CC-BY-SA) | * Open Source/Creative Commons (CC-BY-SA) | ||
** (dit betekent dat materiaal van elders ook aan deze eis moet voldoen) | ** (dit betekent dat materiaal van elders ook aan deze eis moet voldoen) | ||
* docentenhandleiding | |||
** met richtlijnen voor beoordeling | |||
** met suggesties voor nascholing | |||
* beschrijving van badges, criteria en richtlijnen voor beoordeling | |||
* op meerdere niveaus af te ronden | |||
** module met badges | |||
Vgl.: aanpak bij Coderclass/ICT in de Wolken? | Vgl.: aanpak bij Coderclass/ICT in de Wolken? | ||
* uitdaging op elk niveau | |||
* geen bovengrens? | |||
== Manier van werken == | == Manier van werken == | ||
Regel 44: | Regel 59: | ||
** Schrijver(s) | ** Schrijver(s) | ||
** (inhoudelijke expertise?) | ** (inhoudelijke expertise?) | ||
=== Agile aanpak === | |||
Het ontwikkelen van lesmateriaal is lastig te plannen: je weet van te voren niet welke problemen je tegenkomt. Dit is enigszins te vergelijken met het ontwikkelen van software. Voor dat laatste wordt tegenwoordig vaak een "Agile" aanpak gebruikt, bijvoorbeeld in de vorm van Scrum. Enkele aspecten van die aanpak zijn: | |||
* Sprints: een sprint is een vaste, relatief korte periode (een week, enkele weken) waarin een deel van de gewenste functionaliteit opgeleverd wordt. Van te voren ligt niet precies vast welke functionaliteit opgeleverd wordt. Het team pakt zo mogelijk de functionaliteit met de grootste prioriteit aan, en maakt deze af. Pas daarna wordt er aan de volgende functionaliteit gewerkt. | |||
* Sprint-resultaat is "af": het resultaat van een sprint is "af": het kan in principe zo gebruikt worden. | |||
** Bij software speelt de "definition of *done*" een grote rol: opdrachtgever en ontwikkelteam spreken af aan welke kwaliteitseisen een "af" resultaat voldoet. | |||
Het resultaat van een sprint is "af": dit is inhoudelijk compleet, en direct bruikbaar voor docenten en leerlingen. (Mogelijk is de vormgeving nog niet definitief.) | |||
=== Brainstorm/kick-off === | === Brainstorm/kick-off === | ||
Regel 63: | Regel 87: | ||
Bij deze brainstorm wordt ook de "definitie van AF" eventueel verder gepreciseerd. | Bij deze brainstorm wordt ook de "definitie van AF" eventueel verder gepreciseerd. | ||
=== Sprint 0 === | |||
Mogelijk hebben we een "sprint 0" nodig waarin het team probeert het materiaal te ordenen, en een eerste opzet te maken. Dit kan nodig zijn als het team niet erg bekend is met het materiaal, en/of als er geen goede voorbeelden van een dergelijke ordening zijn. | |||
=== Sprint 1 === | === Sprint 1 === | ||
Regel 73: | Regel 101: | ||
De uitwerking van sommige onderdelen, zoals praktische opdrachten, kan mogelijk aan studenten (docenten in opleiding; studenten met educatieve minor) uitbesteed worden. | De uitwerking van sommige onderdelen, zoals praktische opdrachten, kan mogelijk aan studenten (docenten in opleiding; studenten met educatieve minor) uitbesteed worden. | ||
NB: bij een Agile aanpak hoort ook regelmatig overleg tussen de opdrachtgever/product owner en het implementatie-team. Dit is vooral belangrijk bij het maken van keuzes, bijvoorbeeld welke onderdelen/onderwerpen eerst aangepakt worden. | |||
NB: een sprint hoeft niet helemaal overeen te komen met een module; de sprint wordt bepaald door een vaste planning, niet door een vaste inhoud. | |||
=== Oplevering sprint 1 === | === Oplevering sprint 1 === | ||
Regel 80: | Regel 112: | ||
Het materiaal moet op dit moment "af" zijn: het moet direct bruikbaar zijn voor docenten en leerlingen. | Het materiaal moet op dit moment "af" zijn: het moet direct bruikbaar zijn voor docenten en leerlingen. | ||
=== | Deze bijeenkomst is ook de voorbereiding op de volgende sprint. Het ontwikkelteam kan bepaalde vragen hebben die voor de volgende fase van belang zijn, om te bespreken met het hele team. | ||
=== Testen van het resultaat === | |||
Zodra het resultaat van de sprint beschikbaar is, kunnen docenten en leerlingen hiermee aan de slag. | |||
(Voor docenten en leerlingen kan het rooster een beperkende factor zijn. Mogelijk kunnen geselecteerde leerlingen, deels vrijgesteld van het normale rooster, er eerder mee aan de slag. Maar we willen ook zo snel mogelijk het materiaal proberen met een "gemiddelde groep" van leerlingen.) | |||
De resultaten van deze test worden zo snel mogelijk gedeeld met het ontwikkelteam: dit kan deze feedback gebruiken voor het bijstellen van het materiaal, waar nodig. | |||
* (Uiteindelijk zou ik graag een "permanente feedback" willen voor het ontwikkelteam, en voor de docenten: daarmee kan het materiaal voortdurend verbeterd worden. Het moet mogelijk zijn om daarvoor een geschikte infrastructuur te maken/vinden.) | |||
=== Sprint N === |
Huidige versie van 15 mei 2017 om 07:54
Ontwikkelen van lesmateriaal
- uitgangspunten
- manier van werken
- "deployment"/gebruik
- nascholing
- ondersteuning voor docenten (netwerk; forum)
- ondersteuning voor leerlingen (e.d., forum)
Uitgangspunten
- concept-context aanpak (waar zinvol)
- contexten: actueel, relevant en herkenbaar voor leerlingen
- modulaire aanpak; modules niet te groot
- badge voor afronden van een module?
- onderscheid HAVO/VWO(?)
- doenende denkers, denkende doeners
- praktisch werk; programmeren/programmeervaardigheid als uitgangspunt (en als doel)
- waar mogelijk geschikt voor zelfstudie
- ook te volgen voor leerlingen als eigen docent geen expertise in dit domein heeft
- "kleine stappen" - met resultaat en evaluatie voor elke stap
- gericht op "mastery based learning" - je gaat pas verder als je de voorafgaande stappen beheerst.
Hoe ziet het resultaat eruit?
- leesstof (eventueel aangevuld met video's)
- naslag/referentie-materiaal
- self-assessments (formatieve toetsing)
- praktische opdrachten
- 1. tutorial (nadoen; met uitleg en assessment-vragen)
- 2. experimenten (zelf uitzoeken; o.a. aan de hand van leesmateriaal)
- 3. eigen uitbreidingen
- Open Source/Creative Commons (CC-BY-SA)
- (dit betekent dat materiaal van elders ook aan deze eis moet voldoen)
- docentenhandleiding
- met richtlijnen voor beoordeling
- met suggesties voor nascholing
- beschrijving van badges, criteria en richtlijnen voor beoordeling
- op meerdere niveaus af te ronden
- module met badges
Vgl.: aanpak bij Coderclass/ICT in de Wolken?
- uitdaging op elk niveau
- geen bovengrens?
Manier van werken
- Agile aanpak
- sprints, met tussentijdse evaluatie en feedback
- themateam als "product owner"
- Themateam
- docenten
- externe experts (HO, bedrijfsleven)
- vakdidacticus (anders dan in ontwikkelteam)
- Ontwikkelteam
- Coordinator
- Vakdidacticus
- Schrijver(s)
- (inhoudelijke expertise?)
Agile aanpak
Het ontwikkelen van lesmateriaal is lastig te plannen: je weet van te voren niet welke problemen je tegenkomt. Dit is enigszins te vergelijken met het ontwikkelen van software. Voor dat laatste wordt tegenwoordig vaak een "Agile" aanpak gebruikt, bijvoorbeeld in de vorm van Scrum. Enkele aspecten van die aanpak zijn:
- Sprints: een sprint is een vaste, relatief korte periode (een week, enkele weken) waarin een deel van de gewenste functionaliteit opgeleverd wordt. Van te voren ligt niet precies vast welke functionaliteit opgeleverd wordt. Het team pakt zo mogelijk de functionaliteit met de grootste prioriteit aan, en maakt deze af. Pas daarna wordt er aan de volgende functionaliteit gewerkt.
- Sprint-resultaat is "af": het resultaat van een sprint is "af": het kan in principe zo gebruikt worden.
- Bij software speelt de "definition of *done*" een grote rol: opdrachtgever en ontwikkelteam spreken af aan welke kwaliteitseisen een "af" resultaat voldoet.
Het resultaat van een sprint is "af": dit is inhoudelijk compleet, en direct bruikbaar voor docenten en leerlingen. (Mogelijk is de vormgeving nog niet definitief.)
Brainstorm/kick-off
De eerste bijeenkomst (een dagdeel) is een brainstorm met het complete thema-team. Het doel hiervan is om in grote lijnen vast te stellen wat de inhoud van het materiaal kan zijn: welke concepten en onderwerpen moeten aan de orde komen; welke contexten zijn hiervoor relevant en geschikt voor de leerlingen; wat is hierbij essentieel en wat is "nice to have".
Daarnaast kan het thema-team bronnen aandragen voor het ontwikkelteam:
- voorbeelden van lesmateriaal (bijvoorbeeld uit het buitenland); eventueel voorzien van kritische opmerkingen;
- lesmateriaal uit het Hoger Onderwijs;
- referentiemateriaal voor het ontwikkelteam;
Het resultaat hiervan is een spreadsheet met deze concepten en contexten; deze wordt als "backlog" gebruikt bij de ontwikkeling van het lesmateriaal.
Zo mogelijk geeft een inhoudelijk expert een overzicht van enkele actuele ontwikkelingen en trends.
De volgende aspecten hoeven bij de brainstorm niet aan de orde te komen:
- didactiek
- volgorde van onderwerpen, logische opbouw
Bij deze brainstorm wordt ook de "definitie van AF" eventueel verder gepreciseerd.
Sprint 0
Mogelijk hebben we een "sprint 0" nodig waarin het team probeert het materiaal te ordenen, en een eerste opzet te maken. Dit kan nodig zijn als het team niet erg bekend is met het materiaal, en/of als er geen goede voorbeelden van een dergelijke ordening zijn.
Sprint 1
Op basis van de resultaten van deze brainstorm gaat het ontwikkelteam aan de slag. Voor de eerste sprint wordt een selectie gemaakt uit de onderwerpen in de backlog, met inachtneming van de aangegeven prioritieiten.
Er kan een spanning bestaan tussen deze prioriteiten en een logische opbouw van het materiaal. Het ontwikkelteam is verantwoordelijk voor de logische opbouw van het materiaal - ook als dit enigszins bots met de aangegeven prioriteiten.
Als het team onvoldoende inhoudelijke kennis heeft, kan het nodig zijn om de externe experts met enige regelmaat te raadplegen.
De uitwerking van sommige onderdelen, zoals praktische opdrachten, kan mogelijk aan studenten (docenten in opleiding; studenten met educatieve minor) uitbesteed worden.
NB: bij een Agile aanpak hoort ook regelmatig overleg tussen de opdrachtgever/product owner en het implementatie-team. Dit is vooral belangrijk bij het maken van keuzes, bijvoorbeeld welke onderdelen/onderwerpen eerst aangepakt worden.
NB: een sprint hoeft niet helemaal overeen te komen met een module; de sprint wordt bepaald door een vaste planning, niet door een vaste inhoud.
Oplevering sprint 1
De oplevering van het resultaat van de eerste sprint gebeurt in een bijeenkomst voor het hele team. Het ontwikkelteam legt uit welke keuzes gemaakt zijn, en waarom.
Het materiaal moet op dit moment "af" zijn: het moet direct bruikbaar zijn voor docenten en leerlingen.
Deze bijeenkomst is ook de voorbereiding op de volgende sprint. Het ontwikkelteam kan bepaalde vragen hebben die voor de volgende fase van belang zijn, om te bespreken met het hele team.
Testen van het resultaat
Zodra het resultaat van de sprint beschikbaar is, kunnen docenten en leerlingen hiermee aan de slag.
(Voor docenten en leerlingen kan het rooster een beperkende factor zijn. Mogelijk kunnen geselecteerde leerlingen, deels vrijgesteld van het normale rooster, er eerder mee aan de slag. Maar we willen ook zo snel mogelijk het materiaal proberen met een "gemiddelde groep" van leerlingen.)
De resultaten van deze test worden zo snel mogelijk gedeeld met het ontwikkelteam: dit kan deze feedback gebruiken voor het bijstellen van het materiaal, waar nodig.
- (Uiteindelijk zou ik graag een "permanente feedback" willen voor het ontwikkelteam, en voor de docenten: daarmee kan het materiaal voortdurend verbeterd worden. Het moet mogelijk zijn om daarvoor een geschikte infrastructuur te maken/vinden.)