Вступ
Ідея інтегрувати в навчальний процес модель командної роботи над проектом народилася зовсім не спонтанно. На третьому році роботи з учасниками гуртка «WEB-Miditaur» виникла потреба змоделювати процес розробки web сайту в умовах, максимально наближених до реальної практики роботи в WEB студії.
Тригером до початку руху ідей у цьому напрямку були висновки, зроблені під час численних зустрічей та спілкувань з представниками IT бізнесу та власний накопичений досвід. Їх суть полягає у необхідності набуття майбутніми WEB розробниками певних навичок командної роботи над проектом.
Один IT фахівець прямо сказав: «Яким би талановитим і майстерним програмістом не був Ваш учень, за умови відсутності навичок роботи в команді, він у майбутньому приречений на вічний фріланс.» З такими словами важко не погодитися, тому виникла ідея змоделювати роботу над реальним замовленням команди з трьох здібних учасників гуртка «WEB-Miditaur».
Сама по собі ідея видалась мені доволі актуальною, адже дозволить розробити правильну методику формування команди і виховування рис характеру комфортного для командної роботи типу. Це дослідження охоплює чималий кейс питань, з якими доводиться зіштовхуватися в процесі реалізації даної ідеї. Адже доводить приймати та застосовувати психологічні та практичні рішення, які мають на виході привести до конкретного результату, а саме створення прототипу справжньої web студії з ефективною командою FrontEnd розробників.
Дуже не хотілося винаходити велосипед, хоча моя творча натура дуже цього вимагала, я вирішив таки дослідити аналогічний досвід на теренах інтернету з метою пошуку інформації, яка мені допоможе підібрати та систематизувати досвід впровадження різноманітних сучасних методів та моделей навчання, які найбільш відповідають ідеї та меті майбутнього навчального проекту. Фактично нам доведеться мати справу з моделлю навчання 70-20-10, яка підкреслює важливість практичної складової в навчальному процесі. Про цю модель ми поговоримо пізніше на сторінках даного дослідження.
Намагання об’єднати здібних учасників гуртка у одну команду, яка б діяла як єдиний організм, заснований на принципах чесності, надійності, сміливості, відданості, працьовитості, доброти, співчуття, взаємоповаги , щирості, взаємодопомоги, толерантності наштовхнулося на низку певних проблем, пов’язаних з дуже розповсюдженою рисою характеру, яка чудово відображається в українському народному прислів’ї «На трьох українців – чотири гетьмани». Це прислів’я влучно характеризує дуже поширену рису характеру наших співвітчизників, яка носить яскраво виражені ознаки індивідуалізму. Наслідки індивідуалізму, який заснований на неконтрольованих проявах егоцентризму у його різноманітних варіаціях може стати деструктивним фактором ризику на початковому етапі створення ефективної команди розробників. Маючи трьох учасників гуртка з хорошими здібностями до навчання, виникла проблема об’єднання їх у єдину команду розробників проекту. Ця проблема і полягала у яскравих проявах індивідуалізму з ознаками гострого егоцентризму серед окремих кандидатів. Спочатку мене ця проблема завела в стан певного ступору, але усвідомлення того факту, що цю проблему потрібно вирішувати, спонукала до певних експериментів і дій, про які я хочу розповісти у даному дослідженні.
Звичайно, що умови, які склалися станом на сьогодні в нашій країні не передбачають умов очного навчання з безпосереднім спілкуванням, а враховуючи військовий фактор перспектива онлайн навчання передбачається з вірогідністю майже 100%. Ідею застосування методологій Agile, Scrum, Kanban у освітньому процесі при дистанційному навчанні виникла давно, навіть влітку 2022 року провели з вихованцями експеримент зі Scram методологією, але тут ще трапився чудовий вебінар, завдяки якому ця ідея починає окреслюватися в чітке уявлення про іноваційну систему EDU-SCRUM. Методологія може бути дуже доречною в наш складний час, адже дозволить у деякій мірі суттєво зняти психологічну напругу, пов'язану з навчальним процесом під час війни. Звичайно, що не зайвим також підвищити свої професійні знання і тому став у нагоді відповідний вебінар, у якому я прийняв участь.
Використання методології Scrum упрофесійній діяльності вчителя
Модель 70-20-10 для навчання та розвитку.
Модель навчання та розвитку 70-20-10 — це загальновживана формула в професії навчання для опису оптимальних джерел навчання успішних менеджерів. Вважається, що люди отримують 70% своїх знань із досвіду, пов’язаного з роботою, 20% із взаємодії з іншими та 10% із офіційних навчальних заходів.
Модель була створена у 1980-х роках трьома дослідниками та авторами, які працювали з Center for Creative Leadership, некомерційною освітньою установою в Грінсборо, штат Північна Кароліна. Троє, Морган Макколл, Майкл М. Ломбардо та Роберт А. Айхінгер, досліджували ключовий досвід розвитку успішних менеджерів.
Модель 70-20-10 вважається найбільш цінною як загальна настанова для організацій, які прагнуть максимізувати ефективність свого навчання та програм розвитку за допомогою інших видів діяльності та вкладів. Модель продовжує широко використовуватися організаціями по всьому світу.
Творці моделі вважають, що практичний досвід (70%) є найбільш корисним для співробітників, оскільки він дає їм змогу виявити та вдосконалити свої навички, пов’язані з роботою, приймати рішення, вирішувати проблеми та взаємодіяти з впливовими людьми, такими як боси та наставники всередині налаштування роботи. Вони також вчаться на своїх помилках і одразу отримують відгуки про свою роботу.
Співробітники вчаться в інших (20%) за допомогою різноманітних заходів, які включають соціальне навчання, коучинг, наставництво, спільне навчання та інші методи взаємодії з однолітками. Заохочення та зворотній зв’язок є головними перевагами цього цінного підходу до навчання.
Формула стверджує, що лише 10% професійного розвитку оптимально походить від формального традиційного навчання курсів та інших освітніх заходів, позиція, яка зазвичай дивує практиків з академічним середовищем.
Нові дослідження на цю тему.
Застосування цієї моделі було предметом нещодавнього дослідження, проведеного Training Industry.
Дослідження досліджували:
- Оновлений баланс між навчанням на робочому місці, соціальними та офіційними навчаннями.
- Нюанси, які можуть змінити коефіцієнт навчання для різних типів співробітників, компаній і країн.
- Як модель пов’язана зі стратегічними зусиллями L&D.
Дізнайтеся більше про цей дослідницький звіт «Оновлення 70-20-10 для 21-го століття» тут.
Наскільки модель 70-20-10 актуальна в епоху Інтернету?
Поява Інтернету та поточне поширення онлайнових і мобільних технологій навчання змінили погляди індустрії навчання на модель 70-20-10. Принаймні, зростаючий хор професіоналів з навчання стверджує, що застаріла модель не відображає стрімкого зростання акценту ринку на неформальному навчанні. Насправді нещодавні дослідження виявили нову концепцію для розмови про джерела навчання під назвою OSF (на робочому місці, соціальне, формальне) співвідношення . Коефіцієнт OSF може змінюватися залежно від галузі, організації та учнів.
Гнучкі методології управління проєктами
Aджайл
Aджайл – це підхід до організації роботи команди, описаний у Аджайл-маніфесті.
Цей документ розкриває філософію аджайлу через чотири основні цінності:
1) люди та взаємодії важливіші, ніж процеси й інструменти;
2) працююча програма важливіша, ніж вичерпна документація;
3) співпраця із Замовником важливіша за узгодження умов контракту;
4) готовність до змін важливіша, ніж правильність початковому плану.
Agile – це підхід, який допомагає командам швидко реагувати на відгуки про проєкт. Це дає можливість оцінювати можливі напрямки та вносити зміни в проєкт у процесі роботи над ним. Такий підхід також називається інтеративним.
Agile допомагає компаніям проєктувати та створювати правильний продукт.
Цей процес керування дуже корисний для IT-компаній, тому що він допомагає аналізувати та покращувати свій продукт упродовж всього процесу розроблення. Agile-підхід дає можливість створювати продукт із високою конкурентоспроможність.
Коротка історія
Після появи дослідження доктора Уінстона Ройса «Управління розробкою великих програмних систем» (Managing the Development of Large Software Systems) у 1970 році багато компаній розпочали пошук нового підходу до розробки, що допоміг би боротися з недоліками
каскадної моделі, розкритикованої у статті.
Назва «скрам» походить із дослідження Такеючі й Нонаки 1986 року «Розробка нових продуктів: нові правила гри» (The New New Product Development Game). У цій статті йдеться про те, що найкращий спосіб досягти мети – дати невеликій команді точний план дій.
У 1995 році Джеф Сазерленд і Кен Швабер привели скрам в систему у статті «Розробка програмного забезпечення за скрамом» (SCRUM Software Development Process).
Скрам як фреймворк управління проєктами
Скрам як фреймворк управління проєктами базується на тому, що самоорганізовані команди постачають закінчені продукти у фіксовані терміни, які також називаємо спринтами. Щоб успішно застосовувати скрам, потрібно використовувати його структуру. Вона складається з ролей, подій, правил і артефактів.
Ролі в скрамі
У скрамі існує три ролі, що разом утворюють скрам-команду.
1. Власник продукту – апологет продукту, який повністю розуміє його цінність для бізнесу. Ця людина доносить потреби замовника та стейкхолдерів до розробників, але не відповідає за технічний бік процесу. Власник продукту також відповідає за історії користувачів і визначає їх пріоритетність.
2. Розробники виконують усі технічні задачі. Вони кросфункціональні, їхня
кросфункціональність залежить від області роботи. Так чи інакше, розробники завжди відповідають за створення беклогу спринту, забезпечення якості відповідно до визначення готового, адаптацію плану щодо цілі спринту і власні експертні зони відповідальності.
3. Скрам-майстер виступає фасилітатором роботи скрам-команди. Скрам-майстер допомагає власнику продукту і розробникам виконувати роботу без перешкод і відволікаючих факторів. Уся комунікація людей з-поза команди з командою розробки відбувається через скрам-майстра. (Часом скрам-команди взаємодіють у форматі скраму скрамів, коли скрам-майстри команд мають власні окремі зустрічі).
Існує п’ять типів скрам-подій:
Спринт (Sprint) – самісіньке серце скраму, де ідеї набувають цінності.
Всередині спринту виконується вся робота, необхідна для досягнення цілі продукту, в тому числі планування спринту, дейлі скрами, огляд і ретроспектива спринту.
Планування спринту (Sprint Planning) – у ньому беруть участь усі члени скрам-команди. На цій зустрічі відбувається презентація продукту. Кожен член команди може висловитися про те, що цікавить або турбує його. Під час зустрічі встановлюються пріоритети й оцінюються терміни.
Дейлі скрам (Daily Scrum) – скрам-події, які проходять щодня під час спринтів. Вони короткі (до 15 хвилин) і призначені для планування денного розкладу розробників. На цих зустрічах обговорюють робочі труднощі, пояснюють незрозумілі історії користувачів. Дейлі є
обов’язковим для розробників. Присутність скрам-майстра необов’язкова.
Огляд спринту (Sprint Review)
Огляд спринту (Sprint Review) – демонстрація діючого продукту, розробленого протягом спринту. Ця подія відбувається наприкінці спринту та призначена в першу чергу для того, щоб детально продемонструвати досягнення стейкхолдерам.
Ретроспектива спринту (Sprint Retrospective)
Ретроспектива спринту (Sprint Retrospective) – це обговорення того, як команда спрацювала протягом спринту, і пошук, як підвищити якість її роботи в майбутньому.
Уточнення беклогу (Backlog Refinement)
На додаток до цих подій під час спринту команди можуть проводити також уточнення беклогу (Backlog Refinement) – обговорювати елементи беклогу й готуватися до наступного спринту. У межах цієї зустрічі можна обговорити пріоритетність елементів і розділити елементи беклогу на дрібніші складові.
12 СЛАЙД
Базовий проект
Вихованці гуртка Микола Купиро, Денис Сафонов та Антон Прядко з ентузіазмом сприйняли ідею та взялись за розробку онлайн-платформи, на якій саме молодь Краснопільської громади мала би можливість дискутувати, обговорювати майбутнє післявоєнної громади.
Практична мета
Але основною метою поряд з розробкою проекту – це можливість застосувати на практиці засвоєні знання та методи діяльності в реальному житті для розв’язання практичних завдань. Результатом роботи гуртка науково-технічного профілю і конкретно нашого гуртка, який вивчає основи WEB розробки може бути сайт, який дозволить на практиці застосувати набуті навички кодування і спонукатиме вихованців до творчого саморозвитку. Відкрию Вам один секрет – мене, як педагога зацікавила ідея в межах конкретного web проекту, випробувати на практиці сучасні моделі командної роботи, з метою розв’язання практичних завдань, максимально наближених до реального сектору виробничої діяльності у відповідному бізнес середовищі WEB розробників і дослідити перспективу інтеграції їх в навчальний процес.
Найважче у втіленні проекту – це навіть не технічний бік справи, а створення повноцінної команди однодумців. На це у мене пішло практично все літо, на першому етапі була впевненість, що учасники нашого гуртка, які взялись втілення експериментального проекту, із поставленою задачею справляться, – розповідає керівник гуртка «WEB-MIDITAUR» Юрій Чернієвський. – Створення такої платформи сама по собі цікава ідея, адже погляд сьогоднішніх підлітків щодо майбутнього громади значно різниться від дещо консервативного бачення життя дорослими, ми не завжди хочемо чути, а шкода, бо сучасній молоді є що запропонувати. До того ж робота над даним проектом дає можливість майбутнім програмістам бути в курсі нових трендів у сфері WEB розробки, застосовувати на практиці новітні технології та методики командної роботи.
Як не дивно це звучить, але своє бачення щодо проекту майбутньої онлайн-платформи його розробники обговорюють на… нарадах. У класичній формі - це звичайно пережиток минулого, с але я переконаний, що доволі поширена в світі, актуальна на сьогоднішній день для гуртка методологія Скрам (Scrum), передбачає проведення так званих нарад для учасників команди розробників – це щоденний скрам (Daily Scrum).
Ми проводимо щоденні скрами в онлайн, і не важливо, в якій точці планети знаходиться учасник нашої команди, ми завжди можемо відслідковувати прогрес досягнення мети проекту.
Вимоги до Скрам нарад.
Тривалість цих нарад не повинна перевищувати 15 хвилин, проводять їх майже завжди в один і той же час, і протягом цієї 15-хвилинної наради кожен учасник команди повинен відповісти лише на три питання: що зроблено учора? Що буде зроблено сьогодні? З якими проблемами зіткнувся?
Розробники можуть обирати будь-яку структуру та техніку роботи, але за умови, коли щоденний скрам фокусується на прогресі досягнення мети та створює план дій на наступний робочий день. Він не лише допомагає створювати та підтримувати фокус та покращує самоконтроль, він також покращує атмосферу спілкування, виявляє перешкоди, сприяє швидкому прийняттю рішень, отже, усуває потребу в іншого роду нарадах.
Мета scrum-наради.
Мета щоденної scrum-наради – тримати всю команду у курсі того, що відбувається та які проблеми виникають. Вирішувати конкретні проблеми потрібно вже в індивідуальному порядку,
– Головне на таких нарадах – почути думку кожного. Як на мене, цей принцип є дієвим і саме він має в перспективі допомогти у відбудові країни, нашої громади після війни. На жаль, наша головна проблема – ми не вміємо працювати в команді, а це ціла наука, яку вихованці гуртка поступово здобувають саме при роботі над подібними проектами. Розробляючи майбутню онлайн-платформу ми ще й вчимось працювати у команді і це на сьогодні головна мета. Не буде вдалої команди – не буде вдалого продукту на виході.
На виході.
Станом на сьогодні, з огляду на обставини, що склалися робота над проектом стала на паузу, але зовсім не припинилася - експеримент буде продовжуватися.
Публікація не завершена - далі буде...
Використані джерела:
0 Коментарів Підписатися на цей блог