Я б вагався так швидко відкинути Водоспад через борт.
Хоча це і є хибною моделлю для фактично побудови програмних систем, але це не погана модель навчання для того, щоб викладати належні практики для кожного етапу життєвого циклу. Незалежно від моделі процесу, яку ви застосовуєте до проекту, ви все ще виконуєте вимоги проектування, архітектури системи та проектування, впровадження, тестування, випуск та обслуговування (включаючи рефакторинг та вдосконалення). Різниця полягає в тому, як ці фази організовані та проведені, але всі заходи все ще відбуваються.
Я б заперечував, що ваш перехід від Водоспаду до Scrum посеред проекту - не найкраща ідея. Запорукою успіху Scrum є тривалий проект. Перші три-п’ять спринтів - це команда, яка швидко влаштовується, вивчає процес і проходить розвиток команди. Хоча ви робите за допомогою рухів, це насправді не Scrum на той момент. Крім того, намагатися створити виключно на основі Scrum навчальну програму, мабуть, погана ідея, оскільки Scrum як не срібна куля - краще навчити кращих практик, а не єдиної методики. У робочій силі не всі проекти збираються використовувати Scrum. Насправді, в деяких середовищах Scrum завдасть шкоди успіху проекту.
Ви вже знайшли проблеми з Scrum в академічній ситуації, і деякі з них важко адекватно вирішити.
Невипуск у вашому списку невідповідностей полягає в тому, що оцінити складно. Так. Але єдиний спосіб покращити оцінку - це оцінити та порівняти фактичні дані з оцінкою. Студенти повинні оцінювати розмір, час та зусилля, використовуючи різні засоби (пункти розповідей, вихідні рядки коду, години, сторінки, людино-години), щоб вони були готові до цього після закінчення навчання та вступу до робочої сили.
Потреба в документації - це те, що можна вирішити як з точки зору професора, так і з точки зору студентів. Лежачі підходи говорять нам про те, що документація, яка не додає цінності ні для команди, ні для замовника, є марною (з точки зору часу та витрат). Однак необхідна деяка документація для досягнення певних цілей як студентів, так і професора (замовника / клієнта) для різних цілей. Загалом це звучить як можливість навчити пошиванню процесів та кількісному управлінню проектами (що має роль навіть у спритних методах).
Щодо зустрічей і розкладу Scrum, мені спадають на думку дві ідеї. Перший полягає в тому, що це вказує на те, що Scrum, можливо, не є найкращим процесом для використання в академічних умовах. Не існує єдиної "найкращої моделі процесів" для програмних проектів з такими факторами, як графік, штатний розпис, видимість та досвід роботи групи розробників (серед інших).
В цілому, я пропоную наголосити на передовій практиці, пошитті процесів та вдосконаленні процесів за допомогою однієї методології. Це дозволить вам бути найбільш ефективним для всіх, хто проходить курси, і піддасть їх різноманітним методологіям процесів і зрозуміє, які найкращі практики для даного набору умов.
Оскільки ви працюєте над тим, щоб створити навчальну програму університету, я дам високий рівень огляду того, як навчальна програма з інженерії програмного забезпечення в університеті, який я відвідував, підходила разом.
Вступна інженерія програмного забезпечення пройшла через проект у моделі водоспаду, лекції на кожному етапі відповідали різним способам ведення діяльності на цій фазі. Команди прогресували через етапи з однаковою швидкістю. Маючи чітко окреслені межі, вони добре вписуються в модель навчання для групи людей, що не мають мінімального досвіду роботи над командами зі створення програмного забезпечення. Протягом курсу посилалися на інші методики - різні гнучкі методи (Scrum, XP), Rational Unified Process, Spiral Model - щодо їх переваг та недоліків.
Що стосується заходів, то були спеціальні курси для обговорення вимог інженерії, архітектури та дизайну (два курси - один із фокусу на детальному дизайні з використанням об'єктно-орієнтованих методів та один із системної архітектури), ряд курсів, присвячених проектуванню та впровадженню різних класи систем (в режимі реального часу та вбудованих систем, корпоративних систем, одночасних систем, розподілених систем тощо) та тестування програмного забезпечення.
Також три курси, присвячені процесу програмного забезпечення. Управління процесами програмного забезпечення та управління проектами, що зосереджується на кращих практиках управління програмним проектом стосовно кількох методологій. Другий курс процесу викладає вимірювання, показники та вдосконалення процесів (підкреслюючи CMMI, Six Sigma та Lean). Нарешті, існує технологічний курс, який навчає гнучкої розробки програмного забезпечення (Scrum, Extreme Programming, Crystal, DSDM), використовуючи проект, здійснений за методологією Scrum.
Проект Capstone був проектом на два квартали, який виконувався для компанії-спонсора і повністю керується командою студентського проекту, з керівництвом як від спонсорів, так і з боку професорсько-викладацького складу. Кожен аспект того, як проводити проект, залежить від студентів у межах обмежень, встановлених спонсорами. Єдиними термінами, призначеними університетом, були проміжна презентація на півдорозі (10 тижнів) до проекту, остаточна презентація наприкінці та презентація чотирьох плакатів незадовго до кінця. Все інше було вирішено погодитись із спонсором та командою.