Как оценивать каждого ученика, когда один робонабор на четверых
Групповые робототехнические проекты сплошь и рядом скрывают тех, кто едет за чужой счёт. Оценить личную компетентность точно можно, отделив общую сборку от трёх индивидуальных контрольных точек: артефактов по ролям, трассировки кода на бумаге и 60-секундного устного опроса.
Когда четверо учеников делят один робонабор, обычное групповое оценивание гарантированно даёт неверную отметку. Почти в любой четвёрке один доминирующий ученик пишет блочный код, второй собирает шасси, а двое пассивно смотрят в экран или слоняются по компьютерному классу. Выставить всем четверым одинаковые 85% за задачу с движением по линии — значит поощрить безделье и скрыть серьёзные пробелы в знаниях до начала четвертей с высокими ставками.
Решение не в том, чтобы купить вчетверо больше железа. Решение в том, чтобы отвязать физический групповой результат от индивидуального оценивания. Команда делит шасси и шину датчиков, но каждый ученик оценивается по трём отдельным индивидуальным точкам касания: документации по закреплённой роли, индивидуальной трассировке кода и 60-секундному устному опросу по живому коду.
Схема ротации четырёх ролей
Совместное использование железа проваливается там, где роли неформальны. Если сказать ученикам «поработайте вместе над программой объезда препятствий по ультразвуковому датчику», клавиатуру заберёт тот, кто быстрее печатает. Нужно ввести явные, не подлежащие обсуждению роли, которые меняются каждый проектный цикл или каждую неделю.
Для команды из четырёх человек задайте четыре функциональные роли, каждая из которых привязана к индивидуальному оцениваемому артефакту, который учитель проверяет отдельно от работающего робота:
| Роль | Зона ответственности во время сборки | Индивидуальный оцениваемый результат |
|---|---|---|
| Ведущий программист | Вводит код, задаёт логику переменных, отвечает за синтаксис. | Выгрузка кода с комментариями и письменным объяснением логических ветвлений. |
| Инженер по железу | Подключает датчики, ставит моторы, следит за расходом батареи. | Схема разводки с назначением контактов и портов и пороговыми значениями датчиков. |
| Инженер QA & тестирования | Проектирует протоколы тестов, измеряет расстояния и допуски. | Журнал тестов с входными значениями, наблюдаемым и ожидаемым поведением робота и отчётами об ошибках. |
| Руководитель проекта по системам | Управляет временем, координирует интеграцию, отслеживает ограничения. | Диаграмма состояний или блок-схема, показывающая полную последовательность работы системы. |
Если робот работает, команда получает базовый групповой балл (например, от 20% до 30% общей оценки за задание). Остальные 70–80% складываются целиком из индивидуального результата и прямой проверки личной компетентности.
60-секундный устный опрос по коду
Самый надёжный инструмент, чтобы выяснить, понимает ли ученик программу, работающую на роботе, — живой устный разбор. За 45-минутный урок с 10 группами (40 учеников) развёрнутые собеседования провести невозможно. Зато можно провести 60-секундные опросы, пока команды тестируют роботов на полу.
Подзовите одного ученика к ноутбуку. Укажите на случайную строку или блок кода и задайте один из трёх диагностических вопросов:
- «Что физически сделает робот, если я поменяю этот оператор сравнения с > на <?»
- «Почему чтение этого датчика стоит внутри цикла, а не в блоке начальной настройки?»
- «Покажи точный блок кода, который выполняется, когда левое колесо крутится назад».
Ученик, который сам строил логику, отвечает сразу. Пассажир, отдавший работу товарищу по команде, замирает или отвечает расплывчато — «это заставляет мотор ехать». Поставьте отметку по простой трёхбалльной шкале (0 — нет понимания, 1 — частичное понимание, 2 — уверенное владение). Меньше чем за десять минут вы индивидуально оцените десять учеников, не останавливая ход урока.
Трассировка кода на бумаге
Когда в компьютерных классах ненадёжное электричество или веерное отключение прерывает занятие, бумажные тесты на трассировку — самый устойчивый уравнитель. Это к тому же соответствует тому, как формальные проверки по учебной программе CAPS «Кодирование и робототехника» оценивают алгоритмическую логику.
Дайте ученикам фрагмент проектного кода, распечатанный на бумаге (или выведенный на экран), но внесите в него намеренную ошибку: неуместную задержку, перевёрнутую проверку условия или неверную область видимости переменной. Дайте пять минут на самостоятельную работу и попросите записать:
- В какой строке содержится логическая ошибка.
- Что физически сделает робот из-за этой ошибки.
- Исправленный псевдокод или параметр блока.
Это снимает преимущество быстрого соседа по парте. Если ученик не может проследить ход выполнения на бумаге, он не понял код, работавший на роботе его команды.
Как выстроить структуру оценки
Чтобы оценивание оставалось посильным на больших потоках и при этом сохранялась личная ответственность, стройте проектные рубрики по такому весу:
Групповая часть (30%): отвечает ли собранная конструкция проектным требованиям и выполняет ли требуемую автономную задачу?
Индивидуальный результат по роли (35%): создал ли этот конкретный ученик полный и точный артефакт своей роли (схему разводки, блок-схему состояний или журнал тестирования)?
Индивидуальная проверка компетентности (35%): продемонстрировал ли ученик понимание во время устного опроса или бумажной трассировки кода?
При таком распределении в команде, собравшей выдающегося ровера для прохождения лабиринта, активный программист получит 92%, а отстранённый пассажир — 48%. Такой итог справедлив, прозрачен и сразу пригоден для обратной связи родителям и четвертного отчёта.
Школам, которые ведут внедрение сразу в нескольких классах и стандартизированный учёт по параллелям, наша команда Sheen School Services предоставляет адаптированные рубрики оценивания, шаблоны ролей и семинары для педагогов, спроектированные специально под южноафриканские ограничения расписания и класса.
