В настоящее время я работаю с профессором в моем университете, чтобы разработать новые учебные планы для курсов разработки программного обеспечения и дизайна Capstone, предлагаемых в моем колледже.
До недавнего времени на обоих курсах использовалась исключительно модель водопада, и поэтому студенты тратили большую часть своего времени на написание длинных отчетов. После большого давления со стороны меня мой профессор решил включить Scrum в программу разработки программного обеспечения в прошлом семестре.
Первая половина семестра была по-прежнему похожа на водопад: студенты писали 40-страничные отчеты о дизайне и документы по спецификации программного обеспечения. В середине семестра все команды должны были выпустить демонстрацию своих приложений. В этот момент курс переключился на Scrum с двумя 3-недельными спринтами. Сейчас мы пытаемся выяснить, как полностью ликвидировать водопад и создать исключительно учебную программу на основе Scrum.
К сожалению, мы столкнулись с несколькими несовместимостями между Scrum и студентами:
- Ежедневные встречи Scrum почти невозможны для студентов. Даже во время самого занятия студентам неудобно проводить собрания Scrum, поскольку профессор обычно читает лекции.
- Оценить баллы / часы сложно, так как студенты неопытны и поэтому не могут точно предсказать, сколько времени что-то займет.
- Scrum лучше всего работает с совместными разработчиками, работающими полный рабочий день, но студенты - нет. В лучшем случае студенты посвящают этому курсу 15-20 часов в неделю, и организация рабочих встреч может быть чрезвычайно сложной. Команды могут иметь до 10 студентов (и всегда есть один или два бездельника).
- Профессора жаждут документации! Я не слышал ни о каких отчетах Scrum - только журналы отставания и вычеркивания (которых я не уверен, что будет достаточно, чтобы успокоить ученых).
- Студенты часто предполагают, что agile означает «прыгнуть прямо и начать кодирование, не оглядываясь назад». Это приводит к созданию самого ужасного кода, который только можно представить. Поэтому я ищу способ обеспечить надлежащий дизайн, не требуя 50-страничный документ или кучу диаграмм UML.
Учитывая эти проблемы, как вы думаете, как я и мой профессор можем адаптировать Scrum для работы в академической среде (и стоит ли вообще вообще беспокоиться о Scrum)? Кроме того, все еще имеет значение обучение модели водопада?
Заранее спасибо за любые отзывы!
Ответы:
Я не хотел бы так быстро сбрасывать Водопад через доску.
Хотя это некорректная модель для фактического построения программных систем, это неплохая модель преподавания для инструктажа о передовых методах для каждого этапа жизненного цикла. Независимо от модели процесса, которую вы применяете к проекту, вы по-прежнему выполняете разработку требований, архитектуру и проектирование системы, реализацию, тестирование, выпуск и обслуживание (включая рефакторинг и усовершенствование). Разница в том, как эти фазы организованы и проведены, но все действия все еще происходят.
Я бы сказал, что ваш переход от 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 недель) в проект, заключительная презентация в конце и презентация четырехстороннего плаката незадолго до конца. Со всем остальным согласился спонсор и команда.
источник
Когда я получил степень магистра в области разработки программного обеспечения, был курс под названием «Процесс разработки программного обеспечения», посвященный XP, Scrum и другим гибким подходам. По сути, весь класс сформировал гипотетическую компанию по разработке программного обеспечения и получил указание разработать довольно сложное программное обеспечение в течение курса. Лекции были посвящены таким вещам, как практика XP, проведение фуршетов и т. Д.
Большинство студентов слышали об этих методах и обычно заинтересованы в их применении. Конечно, нет способа заставить команду работать итеративно и т. Д. Но на самом деле в этом и была суть курса: сама стать мотивом для проведения множества коротких встреч, итеративной работы, непрерывных сборок и т. Д., Потому что вы быстро обнаруживаете это просто самый простой и надежный способ произвести что-либо ценное с группой людей и с небольшим количеством времени.
Помните одно: убедитесь, что вы хорошо играете с клиентом и измените некоторые ключевые требования на полпути. Или «забудь» упомянуть их изначально.
источник
Является ли целью облегчить разработку, или изучить Scrum, или - мое предположение - и то и другое? Я хотел бы рассмотреть более короткие спринты, чтобы ускорить процесс обучения.
Возможно, вы можете заменить ежедневные занятия менее строгой формой, когда это лучше всего подходит для студентов. Кроме того, не все должны участвовать в каждой встрече.
Оценить календарное время еще сложнее, по тем же причинам :-) С историческими моментами вы не оцените, сколько времени займет что-то: вы оцените его относительный размер. Продолжительность определяется.
Может быть, попробовать с меньшими командами? 10 на верхней шкале для команды Scrum. Я думаю, что вы можете добиться успеха и с распределенными командами, не занятыми полный рабочий день, но, конечно, это сложнее! Пусть это будет урок сам по себе.
Scrum не определяет, какая документация требуется. На самом деле, даже графики выгрузки не являются обязательными. Это не означает, что документация запрещена: команда должна представить необходимую документацию, включая отчеты, которые профессора считают необходимыми.
Не только студенты :-) Большинство команд Scrum используют практики XP, такие как TDD (разработка через тестирование) и рефакторинг: я предлагаю вам включить это в учебные планы.
Да, по крайней мере, по двум причинам: во-первых, вы не уверены, что ваши ученики будут использовать Scrum в своей работе, и, во-вторых, я думаю, что легче понять суть гибкой разработки, если вам есть с чем сравнить.
источник
Это звучит немного похоже на тему, которую я однажды взял.
Некоторые мысли:
источник
Мой совет - отделить и изолировать то, чему вы пытаетесь научить. Если это курс по разработке программного обеспечения или какой-либо другой предмет разработки программного обеспечения (алгоритмы или еще много чего), сфокусируйтесь на этом. Если использование SCRUM становится помехой (как вы намекаете), не беспокойтесь об этом.
Как мы это делали, когда я учился в колледже, должен был пройти специальный курс по гибким методологиям. Курс включал в себя проект разработки, который должен был выполняться в соответствии с SCRUM или XP. Фактическое программное обеспечение, которое должно было быть поставлено, было тривиальным, поскольку в центре внимания курса было не программирование или дизайн, а процесс. Рассуждения здесь такие же, как и то, почему вы не должны смешивать «твердые основные» предметы разработки программного обеспечения с предметами методологии, поскольку один, как правило, затмевает другой, а учащиеся в большинстве своем не готовы или не обладают достаточными навыками для того, чтобы справиться с обоими на этом этапе.
Результатами курса были такие вещи, как отчеты о спринт-планировании, еженедельные отчеты о ходе работ, ретроспективы, отчеты об исчерпании, плюс каждую неделю у нас было как минимум две сессии, которые включали групповую встречу / совещание, на котором ТП распространяли и слушали.
Этот курс также включал TDD (Test Driven Development), и он работал очень хорошо.
Это наверняка так. Многие компании используют версии этой модели для своих проектов (PPS, RUP, PROPS и т. Д.). Многие считают (правильно, на мой взгляд), что «чистый» SCRUM лучше подходит для текущего обслуживания, чем для проектов. SCRUM (и Agile в целом) требует определенной гибкости в объеме и возможности согласования требований и доставки по пути. Не все проекты работают так, они бинарные: доставить X в момент времени Y, все остальное - неудача.
источник
Цель академического курса Software Engineering - научить основным этапам жизненного цикла программного обеспечения - анализу, проектированию, внедрению, тестированию вместе с использованием реальных стандартов качества программного обеспечения вместо обычного кода качества домашней работы.
Ценность демонстрации практики с использованием процесса , не связанного с водопадом , имеет смысл , однако, по причинам, которые вы наметили, SCRUM не является подходящим процессом - студенты проходят много курсов в семестр, многие также имеют реальную работу во время учебы, поэтому у вас не может быть 100 % преданных членов команды или проводить ежедневные встречи.
Попробуйте использовать менее гибкий итеративный процесс, такой как UP (RUP).
Чтобы показать значение по сравнению с процессом водопада, измените требования между итерациями. Это покажет разницу между UP и водопадом и подсказку о ценности использования гибких процессов.
Демонстрация водопада после этого будет излишней, так как UP покрывает все стадии водопада.
Поскольку семестры относительно короткие, 2 небольших итерации были бы реалистичными.
Обеспечьте широкую основу для использования студентами, поскольку акцент этого курса не должен быть углублен в реализацию, для этого существуют другие курсы, вместо этого следует подчеркнуть стандарты кодирования и модульное тестирование.
Во время лекций курса преподают теорию нескольких процессов, таких как водопад, UP, XP, SCRUM и Kanban (наряду с другими темами, например, требованиями к написанию, UML, тестированием и т. Д.).
Для студентов, которые закончили вышеупомянутый курс, рассмотрите отдельный семинар SCRUM как факультативный курс, который занимает двухнедельный рабочий день в течение летнего семестра.
источник
Scrum работает, если у вас есть проект, рассчитанный на семестр или семестр, и класс разделен на группы от 6 до 10 человек. Тогда вы могли бы посвятить последние 10 минут учебного времени встрече.
источник