Z pamiętnika nauczyciela akademickiego: Challenge-Based Learning

This article is originally published at http://smarterpoland.pl

Challenge-Based Learning to technika uczenia przez zderzanie uczestników (studenci, uczniowie) ze współczesnym, ciekawym, rzeczywistym problemem do rozwiązania.
Aby taki problem rozwiązać, uczestnicy muszą zrobić badania literaturowe, zrozumieć problem, zaprojektować rozwiązanie i to najlepiej działające. Ta technika jest coraz częściej stosowana w szkołach średnich i podstawowych otwartych na nowe formy nauczania. Rozmawiałem ostatnio z twórcą koderka (aktywności dla dzieci związane z informatyką i nowymi technologiami) o edukacji STEM dla dzieci i młodzieży. Wątek Challenge-Based Learning pojawiał się nieustannie.

A jak to może wyglądać na uczelni?
Od jakiegoś czasu (ojej, to już 10 lat?) testuję różne techniki edukacyjne na zajęciach. Tym razem sprawdzałem pewien pomysł wzorowany na Challenge-Based Learning. Poniżej opiszę sam pomysł wraz z moimi obserwacjami po przeprowadzeniu zajęć.

Zaprojektowany by upaść

Jak pokazać na zajęciach wyzwania, jakie niesie komunikacja przy budowaniu wspólnego rozwiązania przez wiele osób?
W letnim semestrze prowadziłem Zaawansowane programowanie i analizę danych w R na MiNI PW. Jako drugi projekt studenci wykonali inteligentnego asystenta, pakiet R, który pomaga w pracy analityka danych wykonując co trudniejsze/żmudniejsze czynności (jak już raz się nauczy wczytywać dane to nie będzie w kółko pytać o te same parametry analityka).

Każdy z 14 studentów (luksus pracy z małymi grupami) dostał do wykonania jedną funkcjonalność. W sumie te funkcjonalności powinny złożyć się w jeden pakiet – jednego asystenta wspierającego pracę analityka.
Wciąż, jeden student opiekuje się jedną przypisaną mu funkcjonalnością – wczytaj dane, wykonaj preprocessing danych, przeprowadź budowę modelu predykcyjnego, wygeneruj raport, zapisz wykres, odtwórz sesji itp.
Zaliczenie projektu dotyczy częściowo tej jednej funkcjonalności a częściowo spójności rozwiązania z całą resztą pakietu.
Pomimo iż każdy opiekuje się swoją częścią to też opłaca się wszystkim by całość działała.
A jak wiadomo, całość to więcej niż suma składowych.
Wspomniany asystent nazywa się Hugo. Jeżeli chcecie go poznać bliżej, to zerknijcie na https://github.com/hugo4r/hugo.

Doświadczenia

* Każda z pojedynczych funkcjonalności jest prosta, ale gdy trzeba zintegrować 14 prostych funkcjonalności to pojawia się nie lada wyzwanie. Ktoś użyje pakietu rJava i okazuje się, że u innej osoby pracującej na OSX pakiet przestaje się budować, bo jest jakiś problem z java. Ktoś źle zbuduje NAMESPACE i cały pakiet przestaje przechodzić check.
Projekt ma być oddany o 10 rano. O 8 jeszcze wszystko było ok, ale drobna zmiana jednej osoby o godzinie 9 powoduje, że pakiet przestaje się budować, Travis świeci na czerwono.
Niby wiadomo jaka jest teoria (zakończyć funkcjonalności i integracje wcześniej i ostatnie dni poświęcić na dokumentacje), ale też wiadomo jak często pewne rzeczy odkłada się na ostatnią chwilę. Zaleta: ewidentnie widać jakie konsekwencje może mieć odkładania istotnych zmian na ostatnią chwilę.

* Gdy projekt prowadzi mała grupa 2-4 osób, to nawet jeżeli połowa osób odpuści projekt, reszta to szybko zauważy i jest w stanie nadrobić brakującą część. W grupie 14 osób to nie jest możliwe bez aktywnego monitorowania czy wszystkie funkcjonalności są realizowane zgodnie z planem. Duża grupa – nowe doświadczenia, niedostępne dla małych grup.

* W takich projektach zawsze pojawia się pytanie o rolę nauczyciela. Czy to on powinien monitorować na bieżąco postępy prac? W tym przypadku ograniczyłem się wyłącznie do określenia warunków początkowych i końcowych. Cały proces był bez żadnego aktywnego nadzoru i koordynacji. Studenci sami musieli sobie wypracować wewnętrzny mechanizm koordynacji postępów prac. Zaleta: jeżeli wszyscy będą bierni to skończą marnie.

* Gdy projekt prowadzi mała grupa osób, to zmiany w ostatniej chwili nie są bardzo kłopotliwe. Nawet jeżeli poprawka zepsuje funkcjonalność osoby z zespołu, to możemy się z nim szybko skontaktować i naprawić problem. Ale w zespole 14 osób, jeżeli poprawka zepsuła nagle funkcjonalności dwóch innych osób i te zaczną niezależnie coś zmieniać w ostatniej chwili, to ryzyko wystąpienia kuli śnieżnej jest bardzo wysokie.

* Jeżeli komunikacja w zespole oparta jest na wzorcu każdy z każdym, to w grupie 3 osobowej mamy 3 pary osób, w grupie 14 osób mamy 91 par. Więcej kanałów – większa szansa że któryś okaże się wąskim gardłem.

* Jeżeli pakiet ma składać się z funkcji o podobnym nazewnictwie funkcji i zmiennych, podobnej dokumentacji, to autorzy poszczególnych funkcji muszą uzgodnić pewne standardy wcześniej lub aktywnie monitorować kod innych osób by utrzymać spójność swojego rozwiązania z rozwiązaniami innych osób. Czytanie kodów innych osób to oczywiście bardzo porządane zachowanie (Read The Source Luke!).

* Czasem w projektach zespołowych studenci są sami sobie klientem i dostarczycielem rozwiązania. Tutaj specyfikacja przychodzi z zewnątrz i w półgotowej postaci. Trzeba ją aktywnie rozwinąć. To też ćwiczy przydatną umiejętność odgadywania o co klientowi mogło chodzić.

* Większość studentów robi sensowny reaserch do swoich zadań, przez co można poznać nowe rozwiązania pewnych problemów. Przykładowo, jeden student miał za zadanie zrobienie funkcji, która wysyła innej osobie zaszyfrowany obiekt R za pośrednictwem publicznego konta na GitHub. Dowiedziałem się z takiego rozwiązania dowiedzieć i jak szyfrować obiekty i jak je automatycznie przerzucać przez GitHuba.

* Cześć studentów na zajęciach była z 5-go roku, część z 4-tego, część z informatyki część z matematyki. Część pracuje już w firmach a część nie. Gdy wykonują wspólny projekt to można zobaczyć jak wykorzystują swoje różnorodne doświadczenia.

* Weryfikacja rozwiązania polegała na tym, że dwuosobowe grupy studentów używały całego pakietu do wykonania pewnej prostej analizy. Musiały więc użyć zarówno swoich funkcji jak i funkcji innych osób. To idealnie ilustrowało na ile opracowane rozwiązanie jest zgodne ze specyfikacją, a na ile użyteczne do wykorzystywania do rozwiązywania realnych problemów.

* Ponieważ wszystkim opłaca się wykonanie dobrego całego pakietu, ustawia się reguły gry premiujące pomoc (jeżeli ktoś nie wie jak coś zrobić to opłaca mi się mu pomóc), ale nie zastępowanie (skoro każdy ma do zrobienia jedną funkcję, przypisaną do konkretnego imienia i nazwiska, to przecież nie będę za kogoś robił całej jego funkcji). To jest duża zaleta, korzysta z systemu uczenia się wielu do wielu, peer to peer.

* Niestety trzeba przygotować 14 zadań o podobnej trudności, które muszą jakoś od siebie zależeć. To jednak jest sporo pracy.

Ogólnie takie ustawienie problemu na projekt z programowania uważam za całkiem udane. Pomysł na projekt stawiam na równi z moim dotychczasowym faworytem: SuperFarmerem.

Thanks for visiting r-craft.org
This article is originally published at http://smarterpoland.pl
Please visit source website for post related comments.