?

Log in

No account? Create an account
Andrei Ivanov
Чему нужно учить на курсе "Software Engineering" 
4th-Nov-2006 03:19 am
JetBrains
На второй семестр для группы 2-го года обучения Академии Современного Программирования запланирован курс Software Engineering. Когда мы разрабатывали программу, имелось в виду познакомить студентов с управлением требованиями, управлением конфигурациями, процессами разработки (от агильных до CMMI-совместимых) и управлению проектами (роли тим-лидера и менеджера проэкта, планирование, трекинг, и.т.д. с одной стороны, построение команд, мотивация, и.т.д. с другой).

Есть, однако, сомнения. Во-первых, на примере формата, которым пользовался Борланд, обучать проэктной работе в команде и связанными с этим навыкам лучше во время интерншипа. Как и во многих других местах в Software Engineering лекции на эту тему воспринимаются гораздо лучше как обобщение уже имеющихся практических знаний или решение для испытанных проблем, чем как абстрактные знания. Во-вторых, 20 часов, которые у нас есть, не позволят охватить все, что упомянуто выше, в сколько нибудь полезном объеме.

Отсюда вопрос - на что лучше всего использовать 20 часов занятий, если общая цель - подготовить студента к работе в команде в рамках реального проэкта?

Заранее спасибо за ваши мнения.
Comments 
4th-Nov-2006 12:47 am (UTC)
Может просто дать почусвствовать на своей шкуре. менеджмент проектами отрастает кода появляется ощущение что это нужно. Прокрутить перед студентами процесс фикса баги на разных стадиях.
с расчетом стоимости фикса баги на каждом этапе. Привязать к этому потребности в трекалке и т.д.

попробовать отрастить коммуникейшн скилл.

Дать задачу в виде вороха требований и пусть планируют как они ее будут решать и сколько на это потребуется ресурсов. А на фоне такого домашнего задания расказать детали процесса планирования и делать вводные которые должны сильно изменять архитектуру (как обычно и бывает).
4th-Nov-2006 01:22 pm (UTC)
...познакомить, то есть, со всем на свете планировалось.

Все-таки 20 часов - лекций или практики? Я так понял, что лекций.

Есть два универсальных правила: нельзя учить тому, чего студент не пробовал, и необходимо немедленно упражняться в том, чему научили.

Ясное дело, у т.н. "глупых америкосов" должны быть сборники теоретических упражнений на это дело. Или уже используете? Дать каждому студенту параллельно с лекциями побыть менеджером невозможно: на это не хватит ни времени (его пару месяцев, как я понимаю), ни кадров (ни студента). Поэтому нужны альтернативные (пусть более слабые) способы закрепления знаний.
7th-Nov-2006 05:26 pm (UTC)
Думаю, в рамках курса Software Engineering стоит сконцентрироваться именно на технической организации процесса командной разработки, а управление требованиями, тим-менеджмент и т.д. оставить на отдельный курс.

Показать, насколько быстро количественные изменения размера программы переходят в качественные и перестаёт работать подход "на коленке". Обрисовать и обосновать обязательные компоненты и этапы — репозиторий, трекалка, сборка, юнит-тестирование, локализация-интернационализация, написание хелпов и документации, сборка релиза. Рассказать про те же Agile и CMMI.

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

Это всё вроде как банально и очевидно, но почему-то масса людей, с которыми приходится сталкиваться по работе, этого не понимают. И вот талдычишь занудно человеку с многолетним типа опытом работы, что copy-paste — плохо, что к коду и коммитам в репозиторий нужно писать внятные комментарии, и что жи-ши пиши с буквой и. А на тебя смотрят недоумённо с одним-единственным вопросом: "И на хрена мне это надо?". И бессмысленно объяснять ему, что надо это для того, чтобы когда он или кто другой в этот же кусок кода через год полезет фичу добавлять или багу исправлять, то сначала не терял бы время на мучительные попытки понять, что тут наделано и как оно работает, а потом не нарисовал бы новую багу, поправив только три из пяти дублирующихся кусков, и что если в тексте написано "жывотное", то смысл, конечно, не изменится, но вот поиск по такому тексту будет несколько затруднён. У него одна задача — закрыть висящую на нём сейчас багу побыстрее и с минимальными усилиями, и вообще, в слове "превед" нету ни жи, ни ши. А ты тут фантазируешь что да где там где через год будет. Теоретик хренов.
10th-Jan-2007 11:11 am (UTC)
Рабочей дисциплине
5th-Mar-2007 12:05 am (UTC)
Приходить в 9:00 ? ;-)))
5th-Mar-2007 09:29 am (UTC)
нет, я имел в виду - делать то что просят в установленные сроки
This page was loaded Nov 20th 2017, 11:50 am GMT.