Коли починається новий проєкт, часто виникає проблема організації командної роботи, щоби дизайнер гармонійно приєднався в процес розробки. Найбільш відомим і простим способом організації процесів є Scrum Framework. Багато людей сприймають його лише як інструмент для розробників, і часто в Scrum процеси не залучають  дизайнера. Також дизайнери не розуміють або не хочуть розуміти, що таке Scrum і навіщо він потрібен, тому не наполягають, щоб їх включили. Це суттєво впливає на співпрацю між командною та дизайнером. 

Telegraf.Design публікує переклад матеріалу Ірини Драгунцевої.

Що таке Scrum?

Згідно зі Scrum Guide, це фреймворк для управління процесів розробки комплексних продуктiв. Scrum допомагає командам до десяти учасників розбити свою роботу на цілі, які можуть бути виконані в межах спринтів тривалістю не більше одного місяця. У Scrum команда перевіряє прогрес упродовж 15 хвилин щодня – робить Daily Scrum. Наприкінці спринту команда проводить Sprint Review, щоби продемонструвати виконану роботу, і робить Sprint Retrospective  для подальшого поліпшення проєкту.

Так виглядає робочий процес Sprint графічно

Усе здається зрозумілим і простим. Але, на жаль, Scrum не має конкретного етапу попереднього проєктування та аналізу, а також не має конкретних рекомендацій щодо дизайну.

Окрім того, дизайн-процес у Scrum Framework, має такі основні проблеми:

• Scrum-команди фокусуються на фінальних макетах в процесі планування, що загрожує переходом зi Scrum на Waterfall методу управління процесів (послідовний метод розробки програмного забезпечення) у впродовж розробки, що знижує гнучкість до змін.
• Дизайн має бути готовий до того, як розробники почнуть свою роботу. Так дизайнери вимушені готувати чорнові та фінальні макети перед фактичним спринтом. Це означає, що дизайнери не залучені до командного спринту, а їхня робота вилучається із загального процесу.
• Дизайнери розподілені між командами і мають обмежений час для кожної команди. Це ускладнює комунікацію та розуміння ролі дизайнера на проєкті.
• Інше мислення. Scrum намагається уніфікувати робочі процеси для людей із різними типами мислення. В основному, робота дизайнера – це дослідження і прийняття рішень, а розробники мають отримати готове рішення для роботи, щоб його впровадити. І такі методи роботи вимагають різних часових проміжків, планування і підходів.

Як можна вирішити ці проблеми за допомогою Scrum?

1.Dual Track

Dual Track – це гнучка методологія з двома окремими треками роботи одночасно. Перший трек – the discovery track, зосереджений на дослідженні, проєктуванні, тестуванні та перевірці ідей продукту. Другий трек – the delivery track, який розробляє ці ідеї на реальний продукт. Головна ідея полягає  в тому, що ці треки працюють паралельно. У кожного треку є своя команда: команда дослідників і команда розробників.

1.1. Dual Track зі Scrum

Команда дослідження готує беклог для команди разробникiв. Виходить, що дизайнери та бізнес-аналітики працюють на крок попереду aбо на спринт попереду.

Так Dual Track зі Scrum виглядає в Jira

1.2. Dual Track із Kanban і Scrum

Це той самий подвійний трек, але трек розробки використовує дошку Kanban. Це дозволяє треку дослідження бути гнучкішим до змін.

2.Spikes

Згідно з SAFe, Spikes – це тип завдань, якi репрезентують такі види діяльності: дослідження, дизайн, розслідування та прототипування. Їхня мета – отримати необхідні знання для зниження ризику.

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

Так Spikes виглядає в Jira

Scrum також може легко розв’язувати загальні проблеми проєктів:

• Брак фідбеку мiж дизайнерами та розробниками. Дизайнерам зазвичай непросто дати фідбек команді інженерів. Окрім того, немає процедури презентації дизайну команді розробників.

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

• У дизайн важко вносити зміни. Логіка та візуальне представлення незавжди чітко розділені в базі коду, це ускладнює зміни стилю. Немає ні дизайн-системи, ні часу на її реалізацію.

Перевага Scrum: вимагає самоорганізації. Дизайнер має бути організованим і допомагати розробникам організовувати процес роботи з елементами дизайну.

• Дизайнери не беруть участі в Scrum-заходах. Часто розробники й дизайнери вважають регулярні зустрічі згаяним часом.

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

Telegraf.Design працює за підтримки спільноти. Підтримуйте Telegraf.Design на Patreon.