Як Scrum може бути адаптований до академічного середовища?

Зараз я працюю з професором у моєму університеті для розробки нових навчальних програм для курсів з програмної інженерії та дизайну Capstone, які пропонуються в моєму коледжі.

До недавнього часу обидва курси використовували виключно модель водоспаду, і таким чином більшість свого часу студенти витрачали на написання довгих звітів. Після великого тиску від мене, мій професор вирішив включити Scrum в навчальну програму інженерії програмного забезпечення цього останнього семестру.

Перша половина семестру була все ще водоспадом, де студенти писали 40-сторінкові звіти про дизайн та документи з специфікації програмного забезпечення. У середині семестру всі команди були зобов'язані випустити демо-програми. У цей момент курс перейшов до Scrum, з двома 3-тижневими спринтами. Зараз ми намагаємося з'ясувати, як взагалі ліквідувати водоспад і створити виключно програму Scrum.

На жаль, ми зіткнулися з кількома несумісностями між Scrum і студентами:

  • Щоденні зустрічі Scrum практично неможливі для студентів. Навіть під час самого класу студентам незручно проводити зустрічі Scrum, оскільки професор, як правило, читає лекції.
  • Розрахунок точок/годин є складним, оскільки учні не мають досвіду і тому не можуть точно передбачити, як довго щось займе.
  • Scrum найкраще працює з розробниками, які співпрацюють повний робочий день, але студенти не є ні. Найбільше студенти присвячують 15-20 годин на тиждень курсу, а організація робочих зустрічей може бути надзвичайно важкою. Команди можуть мати до 10 студентів (і завжди є один або два слайси).
  • Професори жадають документації! Я не чув жодних звітів Scrum - лише відставання та викривлення (які, я не впевнений, буде достатньо, щоб заспокоїти вчених).
  • Студенти часто вважають, що agile означає "Перейти прямо і почати кодування, не озираючись назад". Це призводить до деяких найстрашніших кодів, які можна собі уявити. Таким чином, я шукаю спосіб забезпечити належний дизайн, не вимагаючи документу на 50 сторінок або купу діаграм UML.

З огляду на ці проблеми, як, на вашу думку, ми з професором можемо адаптувати Scrum до функціонування в академічному середовищі (і чи варто навіть перейматися Scrum насамперед)? Крім того, чи є значення для навчання моделі водоспаду?

Заздалегідь дякуємо за будь-які відгуки!

 15
додано Змінено
Перегляди: 1
джерело
ro nl ja ru fr es pt de zh hi bn kk uz be tr
Звучить так, ніби ви намагаєтеся практикувати SCRUM, а не викладати основи того, як він повинен працювати
додано Автор CodeART, джерело

7 Відповіді

Я б не наважувався так швидко відкинути Водоспад через дошку.

Хоча це і є недосконалою моделлю для побудови програмних систем, це не погана модель навчання, яка б давала вказівки щодо передового досвіду для кожного етапу життєвого циклу. Незалежно від моделі процесу, яку ви застосовуєте до проекту, ви все ще виконуєте інженерні вимоги, архітектуру системи та проектування, впровадження, тестування, випуск та обслуговування (включаючи рефакторинг та вдосконалення). Відмінність полягає в тому, як ці фази організовуються і проводяться, але все це все ще відбувається.

Я стверджую, що перехід від Водоспаду до 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.

Цей проект був два квартали, який був виконаний для компанії-спонсора і виконувався повністю командою студентських проектів, з керівництвом як спонсорів, так і консультанта факультету. Кожен аспект того, як проводити проект, залежить від студентів, в межах будь-яких обмежень, викладених спонсорами. Єдиними термінами, що мандатувалися університетом, були проміжні презентації на півдорозі (10 тижнів) у проекті, заключна презентація наприкінці, а також презентація чотирьох плакатів незадовго до кінця. Все інше було до спонсора і команди, щоб погодитися.

3
додано
джерело

Коли я займався магістерським ступенем з програмної інженерії, існував курс, який називався Software Process, який стосувався XP, Scrum та інших гнучких підходів. По суті, весь клас сформував гіпотетичну компанію програмного забезпечення і йому було доручено розробити частину досить складного програмного забезпечення під час виконання курсу. На лекціях йшлося про такі речі, як практика XP, проведення зустрічей та ін.

Більшість студентів чули про ці прийоми і, як правило, зацікавлені в їх застосуванні. Зрозуміло, що команда не може змусити працювати ітераційно, і т.д. Але це було насправді сутністю курсу: щоб стати мотивацією для проведення коротких зустрічей, працюючи ітеративно, роблячи безперервні збірки і т.д., тому що ви швидко виявите, що це найпростіший і найнадійніший спосіб виробити що-небудь цінне з групою людей і невеликою кількістю часу.

Потрібно пам'ятати: переконайтеся, що ви добре відіграєте клієнта і змінюєте деякі ключові вимоги до середини. Або «забудьте» згадати їх спочатку.

3
додано
джерело

Scrum працює, якщо у вас є довгостроковий проект/семестр, а клас розділений на 6-10 груп. Тоді ви можете присвятити останнім 10 хвилинам класу час для зустрічі з scrum.

1
додано
джерело

У цей момент курс перейшов до Scrum, з двома тритижневими спринтами. Зараз ми намагаємося з'ясувати, як взагалі ліквідувати водоспад і створити виключно навчальну програму на основі Scrum

Це мета полегшити розвиток, або навчитися Scrum, або - моє припущення - обидва? Я б вважав більш короткими спринтами, щоб прискорити процес навчання.

• Щоденні зустрічі Scrum практично неможливі для студентів. Навіть під час самого класу студентам незручно проводити зустрічі з Scrum, оскільки професор зазвичай читає лекції.

Можливо, ви можете замінити щоденні стояки менш жорсткою формою, коли вона найкраще працює для студентів. Також не кожному потрібно брати участь у кожній зустрічі.

• Оцінювання точок/годин важко, оскільки учні не мають досвіду і тому не можуть точно передбачити, як довго щось займе.

Оцінювання календарного часу ще складніше, з тих самих причин :-) З точки оповідання ви не оцінюєте, як довго щось займе: ви оцінюєте його відносний розмір. Тривалість виводиться.

• Scrum найкраще працює з розробниками, які співпрацюють на повну ставку, але студенти не є ні. Найбільше студенти присвячують 15-20 годин на тиждень курсу, а організація робочих зустрічей може бути надзвичайно важкою. Команди можуть мати до 10 студентів (і завжди є один або два слайсери).

Можливо, спробуйте з меншими командами? 10 на верхній шкалі для команди Scrum. Я думаю, що ви можете домогтися успіху і з нерозподіленими командами, а, звичайно, важче! Нехай це буде урок сам по собі.

• Професори жадають документації! Я не чув жодних звітів Scrum - лише відставання та викривлення (які, я не впевнений, буде достатньо, щоб заспокоїти вчених).

Scrum не диктує, яка документація потрібна. Власне кажучи, навіть обов'язкові графіки не є обов'язковими. Це не означає, що документація заборонена: команда повинна надати необхідну документацію, включаючи звіти, які професори вважають необхідними.

• Учні часто припускають, що agile означає "Перейти прямо і почати кодування, не озираючись назад". Це призводить до деяких найстрашніших кодів, які можна собі уявити. Таким чином, я шукаю спосіб забезпечити належний дизайн, не вимагаючи 50-сторінкового документа або купи діаграм UML.

Не тільки студенти :-) Більшість команд Scrum використовують такі практики XP, як TDD (Test Driven Development) і refactoring: Я пропоную вам включити це в навчальні плани.

Крім того, чи варто вивчати модель водоспаду?

Так, принаймні з двох причин: По-перше, не впевнено, що ваші студенти будуть використовувати Scrum у своїй роботі, а по-друге, я вважаю, що легше зрозуміти суть гнучкого розвитку, якщо ви маєте щось порівняти.

1
додано
джерело

Суть академічного курсу програмної інженерії полягає в тому, щоб навчити фундаментальним етапам життєвого циклу програмного забезпечення - аналізу, проектуванню, впровадженню, тестуванню разом з використанням фактичних стандартів якості програмного забезпечення замість звичайного коду якості домашньої роботи.

There is value in demonstrating the practice using a non-waterfall process, however, due to the reasons you meantioned SCRUM is not a suitable process - students take many courses per semester, many also have real jobs while studying, therefore you can not have 100% dedicated team members or conduct daily meetings.

Розгляньте можливість використання менш гнучких ітераційних процесів, таких як UP (RUP).

To show the value compared to the waterfall process, change requirements between iterations. This will show the difference between UP and the waterfall and hint towards the value of using agile processes.

Демонстрація водоспаду після цього буде зайвим, оскільки UP охоплює всі етапи водоспаду.

Оскільки семестри відносно короткі, 2 малі ітерації були б реалістичними.

Надайте студентам широкі рамки для використання, оскільки акцент цього курсу не повинен бути глибиною реалізації, існують інші курси для цього, замість цього слід підкреслити стандарти кодування та модульне тестування.

Під час курсу лекції викладають теорію декількох процесів, наприклад водоспад, UP, XP, SCRUM і Kanban (разом з іншими темами, наприклад, вимоги до написання, UML, тестування і т.д.).

Для студентів, які пройшли вищезазначений курс, розгляньте окремий семінар SCRUM як факультативний курс, який проходить повний робочий день протягом двох тижнів протягом літнього семестру.

0
додано
джерело

Моя порада полягає в тому, щоб відокремити і ізолювати те, що ви намагаєтеся навчити. Якщо це курс з розробки програмного забезпечення або іншої тематики інженерії програмного забезпечення (алгоритми або інше), зосередьтеся на цьому. Якщо залучення SCRUM стає перешкодою (як ви натякаєте на це), не турбуйтеся.

Як ми це робили, коли я навчався в коледжі, мав спеціальний курс для гнучкої методики. Курс включав в себе проект розвитку, який мав бути запущений відповідно до SCRUM або XP. Фактичне програмне забезпечення, яке повинно бути доставлене, було тривіальним, оскільки фокус курсу не був програмуванням або розробкою, а процесом. Причина тут така ж, як і тому, чому ви не повинні змішувати "жорстких" суб'єктів розробки програмного забезпечення з предметами методології, оскільки один має тенденцію затьмарювати інших, і студенти в основному не готові або кваліфіковані для того, щоб обробляти обидва етапи.

Результати курсів були такими, як звіти з планування спринту, щотижневі звіти про прогрес, ретроспективи, звітні випуски плюс щотижня ми проводили, як мінімум, дві сесії, які включали зустріч з групами стоячи/scrum, де ТП могли б циркулювати і слухати.

Цей курс також містив TDD (Test Driven Development) і це спрацювало дуже добре.

Крім того, чи варто вивчати модель водоспаду?

Це, безумовно, є. Багато компаній використовують версії цієї моделі для своїх проектів (PPS, RUP, PROPS і т.д.). Багато хто знаходить (правильно, на мій погляд), що "чистий" SCRUM краще підходить для поточного обслуговування, ніж проекти. SCRUM (і Agile в цілому) вимагає певної гнучкості за обсягом і можливості узгодження вимог і доставки на цьому шляху. Не всі проекти працюють так, вони двійкові: доставляють X в момент Y, все інше - це провал.

0
додано
джерело

Це звучить трохи схоже на тему, яку я взяв один раз.

Деякі думки:

  • Ви б дійсно мали змогу зустрітися з усією командою? Чи працюватимуть субтемати?
  • Якщо "без огляду" означає відсутність рефакторингу, то оцініть доказ рефакторингу?
  • Оцінити рефлексію та документацію - змусити студентів вести блог своєї діяльності. (Насправді це дуже корисна навичка для робочого місця - набагато більше, ніж більшість офіційної документації)
  • Якщо оцінки є поганими, ми сподіваємося, що вони дізнаються - чи можуть вони відстежувати відмінності між оцінками та реальністю, відображати відмінності та демонструвати, що вони щось дізналися?
  • Чи існують менш формальні способи документування дизайну, які були б доречними?
  • Чи було б Skype чи Gchat чи щось достатньо для деяких зустрічей з scrum?
0
додано
джерело