Студенческие проекты и тайм-менеджмент
From The Joel on Software Translation Project
Автор: Джоэл Спольски
Переводчик: Олег Чирухин
В оригинале статья называлась Capstone projects and time management и была написана 26 октября 2009 г.
В переводе статья называется Студенческие проекты и тайм-менеджмент и была переведена 29 октября 2009 г.
Изумительно, как легко доплыть до получения степени в Computer Science в топовом университете, даже без намеков на изучение основных инструментов разработчиков ПО, никогда не работая в команде, и никогда не проходя курсы, за которые не получить автомат с помощью списывания у товарищей. Множество факультетов ИВТ (информатики и вычислительной техники) застряли в 1980х, изучая всё ту же старую учебную программу, которая сейчас абсолютно разошлась с реальностью современной разработки ПО.
Где студентам предполагается обучаться контролю версий, отслеживанию багов, работе в командах, составлению расписаний, оценок, отладке, проверке юзабилити и документированию? Где они научатся писать программы, длиннее чем в 20 строчек?
Многие университеты умудрились убедить себя в том, что чем более далекой от реального мира является их учебная программа, тем более элитными они являются. Это — путь гуманитарных наук. Предоставьте профессионально-техническим институтам, краснокирпичным университетам и младшим школам, напичканным названиями сторон света ("Университет Северной Юго-Западной Флориды") — право в действительности выпускать программистов. Все элитные университеты в мире хотели бы учить и линейной алгебре, и теориям вычислений, и программированию на Хаскелле, — и все прихлебательские факультеты ИВТ пытаются повысить свои стандарты, и делают это благодаря уничтожению всего практического, что есть у них в учебной программе, в пользу большего количества теории.
Теперь, не поймите меня неправильно, это не обязательно плохо. По крайней мере они заменяют Java на Scheme, но только по той причине, что "это именно то, что делают в MIT".(Слишком поздно!). И они обучают студентов думать определенным способом. И если посмотреть, сколько знает о настоящей разработке ПО средний профессор Computer Science, думаю, я скорее отдал бы детей учиться всему этому на стажировке в моей Fog Creek.
Грег Вилсон, старший преподаватель в University of Toronto, говорил об этом на конференции, очень интересно, информативно, и вообще. Мы пообщались с ним, и он рассказал о своей последней идее, UCOSP (расшифровывается как "All The Good Names Are Taken").
Это консорциум 15 университетов, в основном канадских, которые организуют объединенные проекты для старшекурсников. Они создают группы из шестерых новичков из разных университетов, чтобы сотрудничать для создания OpenSource-проектов, в обмен на хорошую репутацию и положительные оценки. Как только я услышал об этой программе, я стал спонсировать команду, которая работает над улучшением Mercurial. Спонсорство заключалось в деньгах на проезд до Торонто для всех студентов, и предоставлении команде учителя.
Просматривая блог UCOSP, вспомнил, почему студенческие проекты, даже похвальные, обычно не приносят ничего полезного. "Одна из вещей, которые дает вам этот курс — это шанс понять, как это: поставить собственные цели и достингуть их." — пишет Грег. "Общий результат с этой точки зрения довольно ясен: во многих случаях студенты делают в неделю на этом курсе намного меньше, чем на более структурированном курсе с тем же содержанием".
Студенты в колледжах на последнем курсе обучения обладают 16 годами опыта создания коротких проектов и оттягивания времени до последней минуты. Пока вы остаетесь старшекурсником, вы скорее всего никогда не встретитесь с проектом, который нельзя было было бы сделать за ночь.
Обычное для Computer Science задание предполагает, что студены пишут "интересную" часть кода (в академическом понимании этого слова). Остальные 90% работы, которые нужно, чтобы довести код до уровня "полезного, настоящего кода" — никогда не ожидаются от студентов, потому что "не интересно" фиксать баги и работать с настоящими условиями, и потому что в большинстве факультетов Computer Science никогда не работали по-настоящему и понятия не имеют, что нужно сделать чтобы создать ПО, которое выживет в поединке с пользователями.
Обычно виноват тайм-менеджмент. В группе из четырех студентов, если даже один или два из них достаточно инициативны, чтобы начать точно в срок, остальные будут тянуть до последнего, потому что у них есть более срочные проекты по другим предметам, которые нужно сдать завтра. Инициативные студенты должны будут выбрать между тем, чтобы начинать первыми и делать большую часть работы чем положено, или ждать вместе со всеми остальными последнего срока, и угадайте? что они выбирают.
У студентов есть в точности Нуль опыта в отношении длительных командных графиков работы. Так что, почти всегда они работают очень паршиво, когда им дают долгоиграющий проект и предлагают самостоятельно распределить время.
Даже если из такого рода проектов и получается что-то продуктивное, у вас будут еженедельные дедлайны, и вы поймете, что ВСЯ работа над проектом делается за ночь до еженедельного дедлайна. Похоже, это является постоянной частью человеческого фактора, определяющего то, что долговременные дедлайны без кратковременных вех практически не встречаются.
Это замечательная возможность попробовать Scrum. Один раз в неделю команда собирается, вживую или виртуально, и просматривает результаты работы на предыдущей неделе. Потом они решают, какие фичи и задачи нужно сделать в течение следующей недели. Кстати, для отслеживания этого отлично подходит FogBugz, пожалуйста, дайте знать — и мы дадим вам его бесплатно. Мы можем также дать бета-доступ до Kiln'а, нашего собственного хостинга Mercurial, в котором есть функция code review.
Я ругал здесь студентов за недостаток дисциплины для создания долгосрочных проектов в нужные сроки, за то, что они тянут резину. Но, конечно, эта проблема свойственна и для не-студентов. Это заняло определенное время, но в конце концов я понял, что долговременные дедлайны (или вообще отсутствие дедлайнов) просто не работает с профессиональными программистами. Или у вас должно быть расписание регулярных, частых работ для поддержания продуктивности в течение длительного времени, или одно из двух. Единственная причина того, что там где проваливаются студенческие команды, в настоящих проектах всё хорошо — это то, что в настоящих проектах есть менеджеры, которые могут устаналивать такие дедлайны, которые не под силу команде студентов.
