Не мог определиться с названием темы, если кто-то предложит более точную - буду благодарен и исправлю в последствии.

Итак, в рамках академического курса в ходе практических занятий я бы хотел дать возможность студентам получить какие-то (желательно правильные ) навыки и знания, работая над неким учебным проектом.

В качестве темы я избрал пример Вигерса про систему заказов в кафетерии.

Примерные задачи в ходе такого проекта:
1. Выявление и анализ требований
2. Формирование видения
3. Специфицирование вариантов использования
4. Реализция вариантов использования
5. Разработка скажем прототипа системы
6. Тестирование системы
7. Подведение итогов - оценка результатов

Сегодня провел первый семинар, материалы в виде презентации прикладываются
Прошу высказать замечания по нему, возможно предложить, как лучше подать материал и организовать текущую и последующую работу.

В идеале хотелось бы организовать все так, чтобы группа студентов (21) работала с одним проектом как единым целым. В прошлом году пытался, не получилось.

Удалось разбиться по подгруппам, каждая их которых выполняла проект в целом, но с упором на свою зону ответственности. В итоге было сделано 5 проектов (разный дизайн, разная реализация). Вместе смотрели оценивали - было прикольно.

Организовать работу 21 человека трудно. Тем более, что вряд ли среди студентов есть опытные руководители проектов.

Кроме того, по своему опыту студенчества, замечу, что в группах появляются халявщики, которые числятся, но ничего не делают. И "уволить" их в силу приятельских отношений трудно.

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

В идеале хотелось бы организовать все так, чтобы группа студентов (21) работала с одним проектом как единым целым. В прошлом году пытался, не получилось.

А зачем? Если говорить о реальном проекте, в котором участвуют порядка 20 человек, то это уже достаточно масштабная система, а то, что есть в презентации, на мой взгляд, лучше подходит для групп по несколько (5-6) человек. Более того, каким образом понять критерии "правильности" или "успешности" выполнения того или иного задания? Почему лучше именно таким образом выделять проблемы, а не другим?

Если разные группы будут работать над одним материалом, то в итоге получится (или должно получится) несколько различных точек зрения на одну и ту же проблему/вопрос. В дальнейшем можно будет сравнивать, агрументировать решения и т.п. Здесь и будет идти основная наработка навыков, понимания причин тех или иных решений.

С ув., Саша

А зачем? Если говорить о реальном проекте, в котором участвуют порядка 20 человек, то это уже достаточно масштабная система, а то, что есть в презентации, на мой взгляд, лучше подходит для групп по несколько (5-6) человек.

Да конечно лучше. Ясно, что для 20 человек тут мало работы. И будут халявщики. Да и пусть. Просто идет некая деловая игра. Да сделать не 1, а 4 проекта было бы хорошо. Но как говорится требует и от меня в 4 раза больше усилий.

Все-таки цели сделать конечный продукт как бы не ставится. Скорее получить некое представление от совместной работы.

Более того, каким образом понять критерии "правильности" или "успешности" выполнения того или иного задания? Почему лучше именно таким образом выделять проблемы, а не другим?

Никто не говорит о лучше или хуже. Это просто предложение. Есть некое описание, можем мы из него понять проблемы? Достаточно ли мы ясно выделили эти проблемы, в чем их причины, нельзя ли обнаружить еще какие-то проблемы?
Т.е. то что я предложил - затравка для дискуссий. Далее мы в общем обсуждали проблемы, пытались выяснить правильно ли мы понимаем цели и какие задачи нам придется решать.
Вчера например прошлись по каждому ВИ с целью получить общее понимание и выделить правила, ограничения и т.п. Несколько человек вели записи. Выделена роль помощник ПМ, который организует эти  записи в более корректном и точном виде.

Но если Вы можете что-то предложить по ходу и по тексту - велком. Буду благодарен

Если разные группы будут работать над одним материалом, то в итоге получится (или должно получится) несколько различных точек зрения на одну и ту же проблему/вопрос. В дальнейшем можно будет сравнивать, агрументировать решения и т.п. Здесь и будет идти основная наработка навыков, понимания причин тех или иных решений.

В принципе так и получилось в прошлом. Мы сравнивали насколько близко получилась реализация с теми требованиями, которые были определены в начале.

Не знаю как получится в этот раз. Посмотрим

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

Именно так и будет. Естественно халявщики получат минимум или вообще ничего не получат. А там зачет, потом экзамен. А нервы у меня железные

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

Итак, как все было в двух словах.

Дисциплина имела 200 аудиторных часов: лекции, лабораторные и практические.

Я все объединил в одном перманентном процессе, т.е. лекции были только в особых случаях, в основном были практические занятия.

Дабы теория училась, студентам было предложено пройти два курса на Intuit.ru, где сдать тестирование и экзамен. Что ими и было сделано. Также народу было предложено 3 контрольные работы (чтобы проверить усвоение некоторого материала и как дань традициям учебного процесса).

Ну и отдельным блоком был общий проект описанный ниже (или выше - это у какого как настроено отображение тем).

Из группы были выделены: аналитики, архитекторы-проектировщики, программисты, тестеры, руководитель проекта, ответственные по направлениям.

Я играл роль заказчика и куратора проекта. Наверное еще погонялы.

В прошлую пятницу (25 декабря) состоялась презентация проекта.

Начал руководитель проекта. Хорошо и обстоятельно рассказал, что за проект, какие проблемы и цели, что нужно делать, как распределили обязанности. Затем выступили аналитики с аналитической моделью. Проектировщики промолчали - более того были удивлены, что им что-то нужно представлять. Мол мы представим продукт.

Затем выступили дизайнеры , предоставив дизайн и почему именно такой дизайн ими придуман.

Программисты рассказывали и показывали то, что они сотворили с этим дизайном и во что воплотилась аналитическая модель.

В результате было продемонстрировано менее 15% функциональности.

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

Я как заказчик остался недовольным и сказал: граждане разработчики, но мне это не нужно, мне нужен продукт, а его я не вижу. Я не могу его начать эксплуатировать, т.к. не реализовано главное - прием заказа в соответствии с требованиями. Не говоря уж об управлении заказа, планировании заказов и т.п.

Спросил почему?

Программисты стали оправдываться, что они не успели. Нас должно быть 5, работали 2. Я спросил, но ведь 2 - это 40%, но никак не 15%.

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

Я спросил - а освобождение от экзамена всей группы о итогам проекта - это нормальный стимул и мотивация? (об этом я сказал еще в самом начале проекта) Все сказали - да!

Окей, сказал я - если так, то все идут на экзамен, поскольку проект полностью провален. Кто в этом виноват? Аналитик работали, программисты работали, тестеры работали, дизайнеры работали - в чем же дело? Можно ли сказать, что команда не была заинтересована в конечном результате, был только интерес сделать часть своей работы?

Ну что ж - нет проекта - нет освобождения! Все идут сдавать экзамен. ...Правда решили так, если к 30 декабря проект все-таки будет доделан, до приемлемого уровня, то зачтем автоматом. Жду...

Профессионалы посоветовали сделать в будущем немного не так:
1. разбить проект на 3-4 контрольные точки
2. Последнюю точку отвести под анализ либо провала, либо проблем с которыми во время исполнения проекта столкнулись
3. экзамен оставить как потенциальную морковку

Есть предложения и замечания?

Была ли студентам предложена методика (XP,SCRUM...).
Или они должны были сами выбрать модель разработки ПО?

Не выпала ли большая часть работы на программистов ?
В свое время у нас была похожая задача. И все свелось к тому, что все сделали те люди, которые умели программировать. Остальные роли просто были не нужны.

Думаю что в роли менеджера проекта нужно выступать преподавателю. Потому что у студентов очень мало опыта в разработке ПО. За ними нужно следить и пинать.

Я бы охарактеризовал ситуацию, как у Райкина: "к пуговицам претензии есть - нет, не оторвать" :о))

Думаю, что основной проблемой была ориентация не на тот результат, который "ждал заказчик" (преподаватель). Обычно в таких случаях (сам был грешен в студенчестве) исполнители ориентируются на выполнение своей работы: ПМ- составление плана (в лучшем случае - его отслеживание), аналитики - создание модели, программисты - разработка кода и т.д. Поэтому закономерный вопрос "кто шил костюм?" так и остался без ответа :о((

От себя предложил бы четче сформулировать цель и повторять ее как мантру на каждом занятии: Мы создаем продукт, который заказчик может непосредственно использовать (или что-нить в этом духе). Нужно чтобы каждый исполнитель назубок знал это, плюс что для конечного результата делает он (мы все вместе создаем продукт, а для этого я делаю то-то и то-то). Однако не могу с полной уверенностью сказать, что это изъян конкретной программы.

Конечно, студенты к таким ситуациям не готовы, поэтому им надо помогать, например на стадии планирования. Могу сосласться на Лармана, в его книге, насколько помню, дан полный цикл работ и прослеживается их состояние по отношению к конечному результату. Например, на начальных (лекционных) занятиях дать набор последовательных квадратиков (этапы работ), объяснить какой у каждого результат и как он влияет на конечный. Потом можно было бы разбить остальное время на эти самые этапы с контрольными точками и, соответственно, мероприятиями. Например, можно было бы поэтапно сдавать концепцию системы, дизайн, модель данных и т.п. - причем не окончательно, а в предварительном варианте. Тогда же можно было бы озвучить некие риски, уже возникшие (те же два программиста вместо пяти) и потенциально возможные, да и много еще чего - навыки презентации, схемы взаимодействия ролей и проч.

В данном случае проект, как мне кажется, изначально обречен на неуспех, так как функцию постановки задачи отдельным исполнтелям, которую на реальных проектах должен выполнять руководитель проекта, здесь не выполняет никто. Цель проекта кто-то должен декомпозировать на мини-цели, расставить им приоритеты, поручить исполнителям, проконтролировать выполнение и т.д.

Кто-то должен в процессе разработки оперативно принимать решения в зависимости от сложившихся обстоятельств и при этом обладать достаточными полномочиями, чтобы обеспечить претворение этих решений в жизнь. Иначе будет коллективная безответственность. Коллега Водолей, полагаю, очень уместно упомянул блистательную миниатюру Аркадия Райкина применительно к данной ситуации.

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

И еще, как мне кажется, каждому студенту целесообразно предложить экспертно оценить плановые трудозатраты на выполнение поставленного задания и где-то зафиксировать эти оценки.
В процессе работы, естественно, с большой долей вероятности многие в оценку не уложатся. И тут важно дать студентам понять, что если ты чувствуешь, что не успеваешь, то проблему надо эскалировать руководителю как можно быстрее, пока еще не поздно принять какие-либо меры (например, договориться об уменьшении объема работ или подключить дополнительные ресурсы). А если факт того, что студент не успел сделать свою работу, будет выявлен только в процессе сдачи - приемки, то это, наверное, повод для того, чтобы "морковку" такому студенту не давать. Студентам, полагаю, неообходимы наглядные примеры ответственного и безответственного отношения к своим словам и к работе в команде с другими людьми.

От души желаю вам удачи.

Ну хотел сказать только, чтобы на контрольных точках они показывали результаты во всех дисциплинах. Т.е. по РУП как раз получается 4 этапа.

Студентам, полагаю, неообходимы наглядные примеры ответственного и безответственного отношения к своим словам и к работе в команде с другими людьми.

поддерживаю.
вопрос в том, ставилась ли задача научить студентов определенным индивидуальным навыкам (в т.ч. РП - навыкам управления проектом) или все-таки коллективно решать задачу.
посколько задача все-таки была учебная, то преподаватель должен, видимо, в какой-то мере играть роль наставника - играющего тренера и уже потом заказчика.
и самое главное объяснить почему в какой-то конкретной ситуации нужно делать так-то или так-то. может быть тогда в голове у студентов что-то останется и от это им в будущем будет польза. а равно и всем тем, кто имеет отношение к ИТ: и будущим потенциальным коллегам, и будущим потенциальным заказчикам

Кстати, возможно можно предложить МП то, что он может на тебя эскалировать проблемы по графику и другие, кот. он не может решить. М.б. даже и не только МП.

Коллеги, спасибо за интерес к теме и интересные предложения.

Для начала ответы на вопросы.
Явно не было предложено никакой методологии разработки. Вернее была избрана Usecase-ориентированная разработка.

Это 5 курс, при том бакалавры. Объем знаний, опыт бакалаврской работы вполне достаточен. Тем не менее в  начале мы поговорили о нашем процессе разработки. Сейчас вижу, что следовало это сделать более детально.

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

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

Насчет цели - говорил постоянно, именно как мантру.

Тут еще вот какое дело. Это второй мой эксперимент. В прошлом году я уже делал нечто подобное. Правда тогда вся группа разбилась на 4 или 5 подгрупп, и каждая в конце концов делала самостоятельно проект. И сделали практически все. Потому я вероятно заблуждался, когда первый этап группе этого года прошел достаточно результативно и дружно.

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

Как показывает опыт многое зависит от группы в целом. Прошлый год группа была вероятно более заинтересована в результате, в этом году (как и сказал Водолей) в выполнении своей частной задачи.

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

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

На самом деле факт, что не удалось пока отмазаться от экзамена, вовсе не наказание или стресс. 5 курс люди закаленные. Тем более примерно треть все равно бы пошла на экзамен. Эта та треть, которая проигнорировала проект.

Меня огорчило в это ситуации то, что студенты (особенно программисты) имели большое самомнение и совершенно не хотели прислушиваться к моим советам. А через силу мне не хотелось навязывать свое решение, поскольку в реальной обстановки я бы просто уволил, а тут что сделаешь?

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

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

на самом деле с точки зрения преподавателя всё более-менее успешно, и вопрос даже в том, сколько человек пошло на экзамен, а сколько получили экзамен автоматом :о))

и я согласен с тем, что большинство сказанного в начале работы было просто пропущено мимо ушей. тут даже умные книжки (типа "Дэдлайна") не помогут, хотя в них много ответов на бытовые вопросы.

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

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

на самом деле с точки зрения преподавателя всё более-менее успешно, и вопрос даже в том, сколько человек пошло на экзамен, а сколько получили экзамен автоматом :о))

Исходно было 21 человек. Постоянно не ходили 4 человека, еще 3 ходили эпизодически. Итого 7 человек планировалось на экзамен в любом случае, т.е. треть. (если вообще дойдут до экзамена)

Оставшиеся 14 человек помимо работы с проектом, делали тесты, сдавали он-лайн экзамен и выполняли 3 контрольные на знание рнр

и я согласен с тем, что большинство сказанного в начале работы было просто пропущено мимо ушей. тут даже умные книжки (типа "Дэдлайна") не помогут, хотя в них много ответов на бытовые вопросы.

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

может быть стоило почётче разработать оргмодель проекта (не только кто в каких ролях будет работать, но и как следует взаимодействовать с коллегами) и контролировать наличие и качество определенных артефактов (т.е. включить в итоговую оценку определенные моменты этих взаимодействий),

Да, наверное, ты прав. Вообще идея более детально описать взаимодействие возникла у меня после СЕЕ-SECR, когда я поучаствовал в игре выработки требований по Agile. Думаю нужно постараться четко спланировать каждую итерацию или спринт.

также уделив определенное время работе с рисками и проблемами? причем можно было бы устраивать что-то типа мозговых штурмов, предлагая в качестве конкурентных предложений свои, по рискам и способам работы с ними. аналогично и с изменениями - обладая опытом (или показывая такое обладание)

Боюсь, у меня пока нет столь значительного опыта и виртуозного владения различными фреймоворками. Однако студентам доступен мой проект, достаточно сложный и проработанный, для изучения. Там есть разные модули авторизации, шаблонизации, фидбэка, доступа к данным, работа с файлами, управление контентом и т.п.

можно было бы с позиции преподавателя указать определенные результаты, которые будут достигнуты при том или ином развитии событий. конечно, для студентов это будет что-то типа вынимания из шляпы кролика или игры краплеными картами, но тем не менее.

Возможно - это моя ошибка, но как я и говорил, просто я ожидал, что проблем серьезных не возникнет.

Надо добавить, что вот прямо сейчас подошли ребята и заверили меня о том, что завтра покажут мне проект. В разговоре они сказали. что потратили примерно 2 дня (в часах около 4), причем большая часть - это интеграция их заготовок в текущий код. При этом по заверением ребят - особых проблем с программированием они не испытали. Значит получить освобождение от экзамена все-таки является определенным стимулом для них.

могу рассказать, что в компании ПМ-эксперт проводятся деловые игры по управлению проектами (можно посмотреть на их сайте, хотя у них природа проектов не чисто софтверная), так там в учебных целях специально заложены определенные вводные, чтобы можно было отработать работу с рисками и прочим. возможно стоит пообщаться с устроителями, в принципе можно и на меня сослаться, глядишь - еще помнят такого.

А может без них обойдемся?

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

Научить всему вообще сложно