Я не хотел бы так быстро сбрасывать Водопад через доску.
Хотя это некорректная модель для фактического построения программных систем, это неплохая модель преподавания для инструктажа о передовых методах для каждого этапа жизненного цикла. Независимо от модели процесса, которую вы применяете к проекту, вы по-прежнему выполняете разработку требований, архитектуру и проектирование системы, реализацию, тестирование, выпуск и обслуживание (включая рефакторинг и усовершенствование). Разница в том, как эти фазы организованы и проведены, но все действия все еще происходят.
Я бы сказал, что ваш переход от Waterfall к Scrum в середине проекта - не лучшая идея. Ключом к успеху Scrum является длительный проект. Первые три-пять спринтов - это команда, набирающая скорость, изучающая процесс и проходящая через развитие команды. Хотя вы делаете через движения, это не совсем Scrum на тот момент. Кроме того, пытаться создать исключительно Scrum-ориентированную учебную программу, вероятно, плохая идея, так как Scrum, а не серебряная пуля - лучше учить передовым методам, а не одной методологии. В рабочей силе не все проекты собираются использовать Scrum. На самом деле, в некоторых средах Scrum может нанести ущерб успеху проекта.
Вы уже нашли проблемы со Scrum в академической среде, и некоторые из них трудно адекватно решить.
Проблема в вашем списке несовместимостей заключается в том, что оценка затруднена. Да, это так. Но единственный способ улучшить оценку - это оценить и сравнить фактические данные с оценками. Студенты должны оценивать размер, время и усилия, используя различные средства (сюжетные линии, исходные строки кода, часы, страницы, человеко-часы) на ранней стадии, чтобы они были более подготовлены к этому после выпуска и поступления на работу.
Потребность в документации - это то, что может быть рассмотрено как с точки зрения профессора, так и с точки зрения студентов. Подходы Lean говорят нам, что документация, которая не добавляет ценности ни команде, ни клиенту, является расточительной (с точки зрения времени и затрат). Тем не менее, некоторая документация необходима для достижения некоторых целей как студентов, так и профессора (клиента / клиента) для различных целей. В целом, это звучит как возможность научить адаптации процессов и количественному управлению проектами (что играет роль даже в гибких методах).
Что касается встреч и планирования Scrum, то мне на ум приходят две идеи. Во-первых, это указывает на то, что Scrum, возможно, не лучший процесс для использования в академической среде. Не существует единой «наилучшей модели процесса» для программных проектов с такими факторами, как график, штатное расписание, видимость и опыт команды разработчиков (среди прочих).
В целом, я бы рекомендовал сделать акцент на передовой практике, адаптации процессов и улучшении процессов по сравнению с отдельными методологиями. Это позволит вам быть наиболее эффективными для всех, кто посещает курсы, и познакомит их с различными методологиями процессов и поймет, каковы лучшие практики для данного набора условий.
Поскольку вы работаете над созданием учебной программы для университета, я дам общий обзор того, как учебная программа по разработке программного обеспечения в университете, в котором я учился, подходит друг другу.
Это была вводная разработка программного обеспечения, которая проходила через проект в виде модели водопада, причем лекции на каждом этапе соответствовали различным способам проведения мероприятий на этом этапе. Команды прошли через этапы с одинаковой скоростью. Наличие четко определенных границ хорошо вписывается в модель обучения для группы людей с минимальным опытом работы в командах по созданию программного обеспечения. На протяжении всего курса были сделаны ссылки на другие методологии - различные гибкие методы (Scrum, XP), Rational Unified Process, Spiral Model - в отношении их преимуществ и недостатков.
Что касается мероприятий, то были организованы специальные курсы для обсуждения разработки требований, архитектуры и дизайна (два курса - один, посвященный детальному проектированию с использованием объектно-ориентированных методов, а другой - архитектуре системы), ряд курсов, направленных на разработку и реализацию различных классы систем (системы реального времени и встроенные системы, корпоративные системы, параллельные системы, распределенные системы и т. д.) и тестирование программного обеспечения.
Есть также три курса, посвященных программному процессу. Процесс разработки программного обеспечения и управления проектами, в котором основное внимание уделяется передовым методам управления программным проектом в отношении нескольких методологий. Второй процесс обучения учит измерения, метрики и улучшения процесса (с упором на CMMI, Six Sigma и Lean). Наконец, есть процесс обучения, который учит гибкой разработке программного обеспечения (Scrum, Extreme Programming, Crystal, DSDM) с использованием проекта, выполненного с использованием методологии Scrum.
Проект Capstone представлял собой проект, рассчитанный на две четверти, который был выполнен для компании-спонсора и полностью осуществлялся студенческой проектной командой под руководством как спонсоров, так и консультанта факультета. Каждый аспект того, как вести проект, зависит от учеников в рамках любых ограничений, установленных спонсорами. Единственными установленными университетом крайними сроками были промежуточная презентация на полпути (10 недель) в проект, заключительная презентация в конце и презентация четырехстороннего плаката незадолго до конца. Со всем остальным согласился спонсор и команда.