Обо мне, о школе 1С и об июньском модуле курса «Управление разработкой программных продуктов»

    В июне я преподавал в 1С: Клубе программистов курс по управлению разработкой ПО. Две недели мы обсуждали со школьниками реалии ИТ-жизни, и школьники в командах кодили проекты. В этом посте я рассказываю, чем конкретно мы занимались.

    Кто я такой?


    Меня зовут Виталий Павленко, я окончил бакалавриат МФТИ по специальности «прикладная математика и информатика». Стажировался год софтверным инженером в компании Интел. За последние четыре года я вёл кружок по олимпиадному программированию в московской гимназии 1534, уроки информатики в школе «Интеллектуал», преподавал в Летней компьютерной школе и многих других выездных школах. Я привык рассказывать школьникам Дейкстру и декартово дерево, в последний год также пытаюсь говорить про веб-фреймворки и криптографические протоколы.

    Этой весной меня позвали в 1С: Клуб программистов (http://club.1c.ru) прочитать курс под названием «Управление разработкой программных продуктов». Программа курса показалась мне крайне необычной. Некоторые части из неё нам преподавали в вузе на факультете ФИВТ на курсах «Инновационный практикум» и «Управление проектами». Другие части — это общие знания о реалиях работы в софтверных компаниях.

    Что за школа и что за курс?


    Как я позже узнал, «1С: Клуб программистов» — это сеть из сотни филиалов в разных регионах России, которая создана на базе центров по обучению взрослых работе с продуктами 1С. Школьников в них обучают не 1С: Предприятию, а более интересным вещам: основам программирования на Java, базовым алгоритмам, элементам системного администрирования. При этом разработка программы курсов, пособий для учеников и методичек для преподавателей ведется централизованно, чтобы стандартизировать преподавание в разных центрах.

    В этом году руководство школы решило запустить новый курс — «Управление разработкой программных продуктов», который предназначается для выпускников курса «Основы программирования на языке Java». Ребята уже неплохо умеют программировать, в том числе работали с оконными приложениями и с рисованием на форме. Основная идея нового курса: рассказать о том, что происходит в ИТ-отрасли, а также дать школьникам возможность в небольших командах закодить проект за время курса.

    Учебник с теоретическим изложением тем написал Николай Завриев (Лицей информационных технологий №1533, г.Москва).
    В учебнике рассказывается о таких вещах:
    — Какие различные сотрудники работают в ИТ-компаниях, чем они занимаются
    — Путь программного продукта: проектирование, реализация, тестирование, внедрение
    — Процесс сбора требований, техническое задание
    — Модели разработки ПО, водопадная модель, итеративная разработка, Agile и Scrum
    — Проектирование пользовательских интерфейсов

    Что было в этом июне?


    Основа течения времени в Школе — это модуль. В течение года модуль — это 12 занятий по два академических часа по выходным (получается модуль = учебное полугодие). В этом году, 1С: Клуб программистов проводил особый двухнедельный июньский модуль для московских школьников.

    На модуле в июне были только те, кто уже ходил в клуб ранее. Каждый школьник изучал в июне один из трёх курсов: системное администрирование, олимпиадное программирование и управление. Пилотный модуль курса «Управление разработкой программных продуктов» было поручено читать мне.
    Постановка задачи была, что называется, challenging: есть только что написанный учебник и 14 школьников. Требуется придумать, как же данный курс читать: как рассказывать теорию и какие практические задания давать по ней. А ещё требовалось, чтобы школьники параллельно с освоением теории разбились на команды по 2-4 человека, выбрали тему проекта, который можно сообща закодить за две недели. Темы для проектов выбирались с таким расчётом, чтобы ребята могли в течение следующего года расширять функционал и весной представить проект на одной из проектных олимпиад.

    Модуль в июне проводился как типичная летняя школа: до обеда у нас было две пары — теория и практика, а после обеда у школьников была культурная программа, состоявшая в основном из экскурсий. Руководители школы смогли организовать массу экскурсий: как в ведущие ИТ-вузы вроде МФТИ, МГУ и ВШЭ, так и в подземный бункер, в главный офис Яндекса и на завод мороженого «Баскин Роббинс».

    В самом конце школы, на закрытии, каждая команда представляла свой проект перед всеми учениками школы и их родителями.
    Вот пример одного такого выступления: http://www.youtube.com/watch?v=VA-30ANDArA

    О самом курсе


    Как все устроено

    Всё, что мы делали в рамках курса, можно разделить на три части.
    Первое — это собственно обсуждение теории. Каждый день мы обсуждали по одной теме из учебника, на это уходило полчаса-час.
    Второе — это практические задания по теории, если теория это позволяет. Скажем, после теории про ТЗ каждой команде нужно было за час совместно написать техническое задание к своему проекту.
    И третье — это программирование в командах. Примерно два часа в день команды программировали на самой школе, многие кодили что-то и дома вечером.

    Я называю курс про управление разработкой гуманитарным. В противовес техническим, содержание которых составляют строгие логичные построения, этот курс состоит из вольного описания реальности с точки зрения автора. Преподавание такого курса было для меня новым опытом.

    Когда преподаёшь алгоритмы, то ситуация складывается так: в начале занятия ты единственный в аудитории знаешь обход в ширину (ну или почти единственный), а в конце — многим школьникам кажется, что они тоже что-то поняли. То есть, в начале между вами есть явная разница в знаниях и в течение занятия происходит осязаемый процесс их передачи. При преподавании курса о реалиях в ИТ-отрасли всё не так. Я читаю Хабр и работаю в ИТ-компании. Но школьники тоже читают Хабр, и у многих родители тоже работают в ИТ-компаниях. Многие уже знают те или иные аспекты и реалии, и рассказать что-нибудь действительно новое для всех очень трудно. Впрочем, в преподавании такого курса есть и своя лёгкость. На курсе по алгоритмам учитель может плохо объяснить обход в ширину, а ученик может его не понять. С курсом про управление разработкой таких проблем почти не возникало.

    Думая о том, как преподавать курс, я решил, что важно делать две вещи. Во-первых, важно как можно больше подтем предварять вопросами к аудитории: что вы знаете об этом? Например, при обсуждении стадии реализации проекта стоит сначала спросить школьников: где стоит хранить код проекта, где его хранят в реальной практике? Или: что такое правильный стиль программирования? стоит ли его придерживаться? зачем программисты это делают? Школьники знают большую часть того, что ты сам знаешь по теме, и рассказывают тебе своё видение. И тут важно делать вторую вещь: рассказывать что-то новое, то, чего почти никто из слушателей раньше не знал. Например, после обсуждения темы про хранение кода, рассказать про системы контроля версий и про их устройство. Или после обсуждения стиля программирования привести пример реального правила из стайл-гайдов и объяснить, почему его несоблюдение порой стоит людям нескольких часов счастливой отладки. Очень хорошо приводить примеры из своей собственной практики на работе или примеры из рассказов друзей.

    Конкретнее про теорию

    Чтобы дать конкретное представление о том, как проводились занятия, опишу, как мы проходили тему «Что, собственно, разрабатываем?». Она устроена так:
    — Этап сбора требований: общение с заказчиком, почему с ним бывает сложно найти общий язык?
    — Работа аналитика с заказчиком: демонстрация существующих решений, наблюдение за бытом будущих пользователей.
    — Мозговой штурм по определению требований. Три этапа: собираем круг потенциальных пользователей, генерируем идеи для реализации в продукте, анализируем и отбираем наиболее подходящие идеи.
    — Техническое задание: его содержание, проблема «всего не опишешь в ТЗ».

    Сначала мы обсудили теорию. Начали с коллективного обсуждения такой ситуации. К вам приходит заказчик и говорит: «Я хочу сайт для продажи смартфонов с недельной выручкой в 100 000 рублей». Как стоит начать с ним диалог, чтобы постепенно разобраться, что же действительно требуется делать нам как программистам?

    После того, как мы обсудили теорию на занятии и посмотрели пример реального ТЗ на создание сайта для дома отдыха, я предложил каждой команде:
    — провести мозговой штурм для выработки требований к своему проекту для реализации за две недели;
    — составить по итогам мозгового штурма ТЗ.

    За основу я советовал брать то ТЗ, которое мы разбирали на теории. Через час работы каждая команда представляла своё ТЗ и мы обсуждали сильные/слабые места проделанной работы.

    Занятие по техническому заданию проходило в третий день курса, когда все команды уже закодили каркас проекта. Конечно, логичнее было бы начать писать код после выработки требований и проектирования. Но при последовательном и логичном изложении курса, первые два занятия уходят на обсуждение профессий в ИТ-отрасли и жизненного цикла ПО. Ученики параллельно с этим уже начинают писать код: не ждать же им занятия по сбору требований. Это общая проблема подобных курсов: теоретические знания приходят с опозданием.

    Практика по теории

    За один модуль курса мы прошли половину программы. У нас было три практических задания: анализ предшествующих решений, мозговой штурм с последующим составлением ТЗ и проектирование интерфейса. Первые два задания каждая команда выполняет применительно к своему проекту.
    В ходе анализа предшествующих решений команда ищет в интернете данные о проектах с функционалом и тематикой, схожей с их собственным проектом, анализирует сильные и слабые стороны аналогов, определяется с уникальной фишкой своего проекта.
    Мозговой штурм — это задание на четкое отделение этапа генерации идей от этапа анализа и отбора идей. В ходе составления ТЗ команда пытается детально описать и формализовать каждую фичу, которая была отобрана в ходе мозгового штурма.
    Перед заданием по проектированию интерфейсов мы обсуждали некоторые общие законы хорошего дизайна: ориентируемся на пользователя, отталкиваемся от задачи пользователя, скрываем редко используемые функции, группируем объекты с общим назначением, даем пользователю обратную связь о происходящем в системе. Само задание было таким: используя сервис прототипирования интерфейсов, спроектировать и запрототипировать веб-сайт для записи больного на прием ко врачу. Идея не оригинальна: я позаимствовал её из вступительной в «Школу стажёров Артёма Горбунова». В качестве сервиса прототипирования интерфейсов я предлагал использовать gomockingbird.com: он очень простой и позволяет приступить к работе за несколько секунд. Как и в случае с первыми двумя заданиями, после прототипирования каждая команда презентовала своё решение, и мы обсуждали его.

    Проекты

    На первом занятии я представил много тем проектов, которые можно делать в течение модуля. Школьники разбились на пять команд, каждая команда выбрала уникальную тему.
    Первая команда взяла на себя большой проект по моделированию дорожного трафика и управлению светофорами. За июньский модуль они пытались написать визуализатор трафика на дорогах с перекрёстками и редактор дорог.

    image

    Вторая — решила написать обучающую игру по мотивам Lightbot.

    image

    Третья — построитель графиков функций вместе с модулем разбора выражений.

    image

    Четвёртая — аркадный лабиринт и редактор карт к нему.

    image

    Пятая — попыталась перенести игру «Сокобан» на кубик Рубика. Действие происходит на поверхности куба N*N*N. В каждый момент пользователю видна вся развёртка, на одной из граней стоит человечек, на поверхности кубика нарисованы ящики, стены и целевые клетки. Кубик Рубика можно вращать, из-за чего поле может очень причудливо меняться.

    image

    Каждый день занятия длились две пары — от линейки и до обеда. Конец первой пары и всю вторую пару мы отводили на программирование в классе. Главным принципом программирования была итеративность: от каждой команды перед стартом я требовал сообщить, что было сделано по проекту за предыдущие дни и что они собираются закодить в течение ближайших пары часов. По окончании второй пары каждая команда демонстрировала всем остальным, насколько она успела реализовать запланированное на сегодня. День за днём команды учились правильно оценивать свои силы, ставить всё более реалистичные цели, двигаться более мелкими шагами. «Через каждые два часа всё должно работать и что-то новое должно быть реализовано». Лично мне кажется очень важным прививать этот принцип школьникам. В начале программистской жизни в каждом из нас живёт «демон водопадной разработки», который проектирует космический корабль под видом безобидной игрушки. Этого демона надо вытравливать процессом маленьких итераций с детства.

    Дисбаланс

    Во время командного программирования очень хорошо чувствуется, что силы команд не равны и силы внутри команды тоже не равны. Команда, моделировавшая светофоры, в первые дни попыталась поднять гит-репозиторий на собственном домашнем сервере. По закону Мёрфи, команда поплатилась за своё желание администрировать всё самостоятельно: в один из дней их удаленный гит-сервер таки лежал из-за выключенного света в доме.

    Другие команды не имели представления о системах контроля версий. Я не пытался их научить этому: считаю, что на первых порах лучше хранить код в облачном файловом хранилище и переходить к системам контроля версий только тогда, когда команда устанет от ада конфликтных копий файлов. Впрочем, многие команды неохотно работали даже с облачными хранилищами. Для программирования в классе у нас была поднята локальная сеть и команды обменивались данными через общие папки в ней.

    В команде, разрабатывавшей аналог Lightbot'а, было три человека, и уровень одного из них был слишком высок для остальных. Этот человек в одиночку за день написал весь каркас проекта на Джаве. На следующий день ему показалось, что в Джаве будет не слишком удобно использовать drag-n-drop, и он переписал весь проект на Джаваскрипте, выложив его на Гитхаб. Работа с этой командой была моим полным педагогическим провалом: я так и не смог убедить божественного программиста объяснить остальным двум членам команды, что такое Джаваскрипт, что такое гит и как они могут что-нибудь запрограммировать сами. Большую часть времени остальные два члена команды искали подходящие иллюстрации и продумывали уровни.

    Что дальше?


    Считаю, что у меня получилось придумать, как преподавать этот курс. Сейчас у нас есть пособие для учеников, методичка для преподавателей моего авторства, и мы подбираем достойных преподавателей в регионах. С октября курс будет преподаваться во многих учебных центрах 1С в России.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 5

      +1
      Опубликуйте пост ещё в каких-нибудь хабах, тогда его увидит бОльшее количество хабровчан.
      0
      Спасибо, попробую

      Only users with full accounts can post comments. Log in, please.