Учебный проект — дубль 3

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

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

Некоторые детали проекта. 18-недельный семестр. 6 академических часов в неделю + не менее 6 часов в неделю на самостоятельную проработку, т.е. планирование шло исходя из 12 академических часов в неделю. Количество студентов 14. Временной ресурс, таким образом, составил 168 человеко-часов в неделю или 3024 человеко-часов на весь проект. Число выглядит внушительным. Правда, повторюсь, половина — это аудиторные занятия, т.е. законное время, когда все мы, и студенты, и преподаватели, могли встречаться, обсуждать, анализировать, планировать и выполнять свои обязанности вместе. Вторая половина (по моим ожиданиям) — это работа вне аудитории, самостоятельная, но не обязательно изолированная.

Первое занятие — первая встреча в рамках нашего проекта. Первая встреча была посвящена организационным вопросам, знакомству с концепцией проекта, общими правилами игры, первичное разделение обязанностей. Студенты были разделены (добровольно) на две большие группы: группа аналитиков и группа разработчиков. В группе аналитиков был назначен руководитель группы, задачей которого было взаимодействие со мной, другими руководителями, планирование и распределение работ внутри своей команды. В группе разработчиков также был назначен руководитель, который также должен был взаимодействовать с общим руководством проекта (моим коллегой), другими руковдителями. Также был назначен (добровольно) архитектор. Позже появились еще два студента (приехали из Америки), которых мы сделали тестировщиками.

На следующем занятии был проведен тренинг-лекция, посвященный вопросам работы с требованиями и, в первую очередь, с вариантами использования. Было проведено общее собрание, на котором вся команда участвовала в разработке образа решения и планировании первой итерации нашего проекта. После чего группа аналитиков принялась за анализ требований под моим руководством, а группа разработки занималась тренингом по овладению языка php. Также ребятам было предложено несколько вариантов систем управления проектом с целью выбрать одну из них и начать работать с помощью нее. Выбрали projectscloud.ru.

Одной из первичных целей, которые я ставил перед собой, было максимальное использование UML на всех фазах проекта. Хотелось бы, чтобы студенты не только поняли синтаксис и семантику UML элементов, но проникли в прагматику их использования и научились активно применять UML. Мною была предложена такая структура UML проекта: Моделирование использования, Моделирование структуры и Моделирование поведения. В начале шло все очень даже не плохо. Я давал четкие рекомендации, ребята их выполняли. Правда не всегда точно и безукоризнено, но … Начали с вариантов использоваия и диаграмм использования. Поскольку задача концептуально была достаточно хорошо продумана, материал по заданию был достаточно обширен и взят традиционно из книги Вигерса, первая часть моделирования прошла вполне быстро. В пакете Моделирование использования были созданы пакеты: Действующие лица и Варианты использования, где просто были перечислены все актеры и ВИ. Предполагалось, что по мере уточнения и развития модели сюда будут добавляться пропущенные действующие лица, новые ВИ. Далее была сделана первая декомпозиция будущей системы: построили несколько диаграмм использования по действующим лицам: по Клиенту, по Менеджеру меню, по Персоналу кафетерия, по Персоналу службы доставки. Вслед за этим, студентам было предложено произвести первичную декомпозицию системы по частям (подсистемам), то как они это понимают и показать как взаимодействуют эти подсистемы, как зависят друг от друга. Для это я предложил создать диаграмму Composite Structure. Тут возникли определенные трудности. Образовалось несколько вариантов. Устроили собрание выделили один из наиболее приемлемый на первый взгляд вариант. Далее я уже попросил разнести варианты использования (какие уже были) по этим подсистемам и нарисовать диаграммы использования уже с точек зрения отнесениях их по подсистемам. При этом исходная подсистема превращалась в границу (Boundary) с названием этой подсистемы, а другие подсистемы, которые так или иначе оказались непосредственно связанными с подсистемой рассматриваемой, превращались в действующие лица-системы. Это позволило выделить еще ряд дополнительных ВИ. Далее моделирование начало набирать обороты и описать строгую последовательность просто невозможно. Появилась первичная диаграмма классов предметной области и начали формировать словарь предметной области. Выделили наиболее значимые варианты использования, т.е. те которые представляют наибольший интерес и начался их последовательный анализ вглубь и вширь. На первых парах пришлось привлечь часть команды разработчиков. Следует отметить, что я старался как можно реже вмешиваться в вопросы организации работы, распределения обязанностей. Старался, главным образом, взаимодействовать с руководителями групп. Пытался донести до ребят мысль, что они сами должны распределять задачи и работы, адаптироваться под ситуацию, поскольку их главная задача сделать то, что намечено в срок и достаточно качественно. Раз или два в неделю проводили планерки, на которых студенты рассказывали что они сделаи, что ожидают сделать, какие сложности возникли.

В целом первая половина проекта (первые два месяца) прошли вполне успешно. За это время у нас было несколько лекций (замаскированные под тренинги, мастер-классы 🙂 Но в месте с тем появилась опасность, что народ увязает в моделировании, рисовании диаграмм и тихо стервенеет, не понимая, зачем он это делает. Ситуация стала усугубляться тем, что архитектор по сути принял решение о дата-центрированной архитектуре, но каким-то образом не довел этого до сведения всех заинтересованных лиц. Я видел, как инициатива и управляемость стала ускользать из моих рук. Пришлось срочно устроить занятие-собрание, чтобы понять в чем проблемы и как их решать. Чувствовал, что мои слова и убеждения до команды не доходят, потому принял решение — пускай сами шишки понабивают. В чем возникло разногласией:
1. я предлагал не спешить с созданием структуры базы данных, а сначала проработать декомпозицию системы и ясно выделить интерефейсы подсистемы, с тем чтобы можно было делать проект параллельно
2. сосредоточить внимание на разработке некоторого базового функционала: способа соединения с базой данных, некоторые общесистемные функции и утилиты
3. изучить некий фреймвёрк и использовать его в ходе разработки, а не начинать все с нуля
4. последовательно следовать объектно-ориентированному подходу
5. не забывать о бизнес-целях проекта и основном назначении системы

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

Вторая неделя декабря. Проект вышел на завершающую стадию. Началась интеграция частей, которые делали различные программисты. Ну конечно возникли непредвиденные сложности:
1. разные группы писал код в разных форматах (имеется в виду русского текста) 
2. некоторые «отщепенцы» при разработке своих частей создали заглушки не согласующиеся с другими частями
3. они же придумали свою версию базы данных, так что по сути их части пришлось переделывать на 50-60%
4. возникла непреодолимая сложность «напялить» на имеющийся код, созданный плодами титанических усилий общий дизайн сайта, к тому же одобренный заказчиком

Одновременно с завершением проекта я попросил каждого участника подготовить небольшой отчет на тему «Мои впечатления от проекта». Аналитики готовили презентацию проекта, собирая все воедино. Презентация шла два дня 23 декабря, Четверг, и 27 декабря, Понедельник. Что же было представлено? Ну девочки-аналитики свою работу выполнили на мой взгляд неплохо. Руководитель аналитической группы был отмечен многими, хотя аналитиков «ругали» за то, что они не могли порой ответить на вопрос «что нужно» и «как это должно быть». Архитектуры можно сказать не было, если не считать классическое разделение: клиент-сервер, при это клиенту отводилась весьма пассивная роль отображаться в браузере, вся нагрузка на серверный код. База данных получилась очень неплохая, продуманная, чувствуется, что занятия по дисциплине управление данными не прошли даром 🙂 Далее был представлен первый компонент реализации: регистрация и авторизация. В ходе презентации я попросил тестировщика проверить корректность программы. За некоторым исключением поведение программы было ожидаемым. Далее выступала группа работы с меню. Функционал работы с меню был вполне широк и продуманный. Презентатор сделал комплимент тестировщику за его детальные тестовые сценарии … Тут возник первый ляп, в пылу ажиотажа забыли смонтировать самый важным компонент, работу с заказом. Правда совместными усилиями ляп был исправлен, хотя впечатление все-таки стерлось.

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

Ниже представляю пример отзыва студентов о проекте:

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

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

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

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

Другой кандидатуры на должность архитектора в нашей группе не было. Хотя он не совсем хороший руководитель в том отношении, что он действует по принципу «мне проще сделать самому, чем объяснить». Когда программисты подходили к нему с определенным вопросом, касающимся дальнейшего объединения подсистем, он отвечал, что это делать не нужно – он сделает это сам. В итоге он набрал для себя такое количество работы, с которым не в состоянии был вовремя справиться.

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

Распределение ролей. Мне кажется, было бы полезнее распределить роли по-другому. Возможно, стоило разделить разработчиков на проектировщиков и программистов. На мой взгляд, это разные задачи, требующие совершенно разного склада ума.  По моему мнению, разделение на проектировщиков и программистов способствовало бы достижению Вашей цели в плане внушения нам преимуществ использования UML. При таком разделении проектирование стало бы, как и положено, промежуточным этапом между анализом и кодированием, а не осталось где-то сбоку, как это вышло у нас. Проектировщик, занятый  только проектированием, был бы больше заинтересован в его результате и сделал бы свою работу более качественно. Программисты же, обращаясь не к аналитикам, а к проектировщикам, учились бы читать UML-диаграммы, и, возможно, оценили бы их удобство. Возможно, мне стоило распределить работы так, чтобы диаграмму и код одного варианта использования писали разные люди.  А поскольку это чаще делал один и тот же человек, диаграммы рисовались «для галочки».

Образование. Этот проект очень хорошо показал, чему мы научились за предыдущие 4 года. Как выяснилось, этот список весьма невелик. Я считаю, что одна из причин кроется в том, что большая часть наших преподавателей учат нас  тому, с чем никогда не сталкивались на практике.  Первую половину одного курса нам цитировали ГОСТ и внушали, что следование ему решит все наши проблемы при разработке ПО. Вторую половину курса нам рассказывали, что есть такие UML-диаграммы, но, как признался по секрету сам преподаватель, единственная их польза – это возможность генерации программного кода.»