Beyond Sprint 0: альтернатива интеграции команд

Scrum — самая популярная методология управления проектами в мире: более 72% команд используют Scrum или его гибрид. Скорее всего, если вы работаете в веб-разработке, вы используете Scrum в той или иной форме.

Текущей тенденцией в Scrum является «Спринт 0» или его более искусный родственник «Дизайн-спринт». Много было написано о том, являются ли они настоящими спринтами (это не так), но меньше было сказано о том, почему они вообще существуют, почему они так упорно держатся и какие существуют альтернативы.

Я лично люблю Scrum и всегда ищу способы постепенно улучшить то, как я его реализую. В этой статье я хотел бы поделиться методами, которые я включил в свой рабочий процесс, и одним, который я считаю полезным при объединении UX / UI и разработки, а также при создании более четкого видения проекта.

Несколько быстрых определений, прежде чем мы начнем:

• Спринт 0
  Первоначальные усилия команды по созданию руководящих документов, необходимых для scrum-проектов: видение, бэклог продукта и оценки выпуска продукта.
• Дизайн Спринт
  Первоначальные усилия команды по созданию основного дизайна для остальной части выпуска.
  

Почему существуют Sprint 0 и Design Sprint

Все правильно и хорошо, когда говорят: «Спринт 0 — это не настоящий спринт, не делайте этого». Но эти спринтерские приспособления существуют не просто так. Многие команды принимают их, потому что в их проекте есть неудовлетворенные потребности, выходящие за рамки Scrum. По моим наблюдениям, Sprint 0 и дизайнерские спринты чаще всего используются для решения следующих ситуаций:

1. Отсутствие сильного направляющего видения;
2. Отсутствие интеграции дизайна в рабочий процесс разработки.

Процесс Scrum предполагает, что владелец продукта разработал и сообщил о нем четкое видение. Но поднимите руку, если вы работали над проектами, где видение слабое, неправильное или невидимое. Я тоже! Спринт 0 — это попытка команды разработчиков заполнить пробел в видении. Это не самая плохая идея, так в чем проблема? С точки зрения Agile Sprint 0 не является итеративным, не использует таланты всей команды и дает туманные результаты. И прежде чем вы скажете: «Эй, настоящая проблема здесь в том, что скрам-команды не должны выполнять работу владельца продукта», я на самом деле считаю, что междисциплинарная agile-команда — одна из лучших сред для разработки сильного, реалистичного видение и цели.

Я предлагаю более гибкий метод создания видения, который я успешно использовал в проектах без передачи полномочий. Я рассмотрю обе ситуации, в которых используются эти адаптации, подобные спринтам, и опишу, как этот альтернативный первый спринт лучше поддерживает гибкий рабочий процесс.

Видение и спринт прототипа

В первой ситуации, когда отсутствует сильное видение, руководящая документация или идеи слишком слабы, чтобы действительно начать проект Scrum. Для любого процесса (включая Scrum) вам нужно руководство, прежде чем начать путешествие. Agile отлично подходит для определения наилучшего способа достижения цели, но создание первоначального видения не входит в его задачи. На самом деле, в Scrum полностью отсутствует описание необходимого видения для начала процесса разработки. Действительно ли это Scrum или нет, Sprint 0 — это просто веб-команда на передовой, использующая имеющиеся у них инструменты, пытающаяся выяснить, что им нужно сделать, прежде чем они начнут это делать.

Настоящим недостатком Спринта 0 является то, что создание руководящего документа для проекта в то время, когда у вас меньше всего информации, имеет низкую ценность для последующего процесса разработки.

Руководящие концепции проекта, которые не согласуются с итеративно формирующейся реальностью, либо должны пройти через дорогостоящий процесс еще одного спринта 0, либо, что чаще всего, просто игнорируются.

Лучшей альтернативой является спринт прототипа: первый спринт, в котором участвует вся команда, фактически создавая сам первоначальный прототип.

Процесс видения прототипа спринта

Идеи мозгового штурма переводятся в низкую визуальную точность, работая прототип как можно быстрее. Прототип написан на функциональном интерфейсе HTML и CSS, то есть на общем языке команды. Не каждый может понять спецификацию или заявление о видении. Каждый может понять веб-сайт, и общение становится проще и включает более широкий спектр дисциплин.

К концу первого спринта прототип готов к начальному тестированию по нескольким направлениям, включая общее удобство использования, доступность и мобильную отзывчивость. В моих командах это действительное и важное приращение. Спринт прототипа также создает первоначальный бэклог продукта. По мере того, как элементы невыполненной работы будут завершены в будущих спринтах, точность прототипа возрастет. Прототип — это не одноразовый код — это основа.

В некоторых проектах письменное видение создается по мере создания прототипа. Но во многих проектах прототип — это видение. Он говорит на общем языке команды и, конечно же, никогда не отстает от продукта.

Пример

В приведенном ниже примере показан рабочий прототип приложения для электронной коммерции, созданный на основе грубого наброска в первоначальном запросе предложений. Каким бы грубым это ни было, это помогло сосредоточить энергию команды в продуктивном направлении, обойти множество потенциальных отвлекающих факторов и ловушек, чтобы сосредоточиться на функциональных критериях.

Первоначальный прототип часто приводит к изменениям в требованиях, которые являются просто лучшими предположениями, пока не будут рассмотрены в свете пользовательского опыта. Например, один из выводов, который мы получили из показанного выше прототипа спринта, заключается в том, что цена и кнопка «Купить» изначально располагались на странице слишком низко. Первоначальный запрос состоял в том, чтобы разместить их ниже информации о продукте и над рекомендациями, но функциональный прототип быстро показал, что иерархия не очень функциональна.

Еще одна обнаруженная функциональность заключалась в том, что изображения галереи изначально должны были быть большими и растягиваться на всю ширину страницы. Вместо того, чтобы излагать заинтересованным сторонам гипотетические причины, почему это не сработает, прототип смог продемонстрировать проблемы на общем языке, понятном всей команде. В ходе мощного сеанса с заинтересованными сторонами мы быстро реорганизовали эту страницу в общепринятую иерархию.

Поскольку прототип рождается доступным и отзывчивым, мы можем сразу приступить к тестированию на нескольких устройствах и технологиях. Несмотря на то, что дизайн (если его вообще можно так назвать на этом раннем этапе) намеренно сделан с низкой точностью, сразу стало очевидно, что обмен сообщениями переключателя года на настольных компьютерах был слишком большим для мобильных устройств и мешал удобству использования (слева). Мы быстро обновили прототип, чтобы использовать переключатель меньшего размера в заголовке (справа).

Несколько других проблем быстро выявились во время этого спринта прототипа:

• Клиент, щелкнув функциональную навигацию, сразу понял, что пропустил важный функциональный компонент в своей спецификации: блог. Это повлияло на оценку и сроки, но мы смогли быстро скорректироваться.
• Для команды пользовательского интерфейса было очевидно, что отображение цен было слишком сложным и запутанным. Вместе с клиентом мы изучили другие возможности и смогли быстро создать прототип и протестировать несколько решений во время спринта прототипа.

Вместо того, чтобы видение потенциально могло стать препятствием или устаревать, как только начинается разработка, в спринте прототипа видение и функциональные критерии разрабатываются вместе и поддерживают друг друга. И поскольку видение генерируется командой , команда не передает его другим и легко избегает этого рискованного периода в процессе разработки.

Дизайн и прототип спринта

Во второй ситуации — отсутствие интеграции дизайна с разработкой — часто используется «дизайн-спринт». Я нахожу это направление даже более контрпродуктивным, чем спринт 0. Проблемы интеграции дизайна в сложный процесс разработки реальны, но дизайн-спринт — это саморазрушительный подход. Дизайн-спринт — это маскировка симптома — задачи создания интегрированных команд — но она не решает основную проблему — задачу понимания и удовлетворения потребностей пользователей. Фронтальная загрузка дизайна в один спринт позволяет избежать проблемы интеграции, но преимущества интегрированного и поэтапного процесса проектирования и окно, которое он открывает для понимания и взаимодействия с пользователями, полностью теряются.

Спринт прототипа, который я использую в проектах без передачи, является продуктивной и полностью гибкой альтернативой спринту дизайна. Он является совместным и объединяет как UI/UX, так и разработку с самых ранних стадий проекта. Даже самая опытная команда дизайнеров может извлечь выгоду из участия представителей других дисциплин, и, что особенно важно, это гарантирует, что цели кода и дизайна не противоречат друг другу.

Часто от дизайнерского спринта также ожидают конкретизации видения. Это отчаянный шаг, основанный на смутном, но проницательном понимании того, что процесс проектирования лучше подходит для создания видения, чем для разработки. Однако дизайнерское видение — плохая замена реальной совместной работе всей команды.

Бедные дизайнеры обременены созданием конечного продукта для запуска разработки без междисциплинарной информации, необходимой для того, чтобы сделать эти усилия действительно ценными. Хотя у дизайнера с техническими знаниями и большим опытом будет больше шансов сделать это правильно, это все равно очень рискованно. В отсутствие потенциально поставляемого продукта в конце фазы для проверки догадок продолжается разработка. Если дизайн не попал в цель или если спецификации изменились, это может привести к длительным задержкам, когда он вернется к команде дизайнеров. Agile по своей сути является процессом управления рисками, и мы можем добиться большего успеха, чем начинать наши agile-проекты с заведомо рискованного проектного спринта.

Процесс разработки прототипа спринта

Самое важное отличие от более традиционного дизайнерского спринта заключается в том, что во время спринта прототипа команда переходит прямо от бумаги к прототипу и пропускает использование Sketch, InVision, Photoshop или других программ цифровой верстки. На этом этапе они действуют как визуальный костыль, очень быстро привнося ценность (потому что хорошие дизайнеры делают красивые вещи), но реальная ценность высокоточного макета на таком раннем этапе очень низка, а потенциальная опасность, которую он представляет — брак стейкхолдеров с неправильными решениями — высок.

Эти инструменты лучше всего подходят для высокоточных плоских макетов, но первоначальный прототип не является ни высокоточным, ни плоским. Белая доска, карандаш и бумага позволяют команде быстро обрабатывать идеи, не привязываясь к ним. Затем как можно скорее воплотите это мышление в функциональный прототип.

Каждый член команды, включая дизайнеров, должен ознакомиться с прототипом и иметь возможность работать над ним непосредственно на этапах лоу-фай. Но если это невозможно (или это долгосрочная цель, и вам нужно двигаться вперед сейчас), то парный подход, когда дизайнер и разработчик работают бок о бок, хорош. Эскизы могут быть описаны дизайнером и интерпретированы разработчиком вместе, расширяя их общее понимание каждой точки зрения.

Пример

В приведенном ниже примере показан наш процесс преобразования глубокого анализа существующего веб-сайта непосредственно в функциональный прототип. Это позволило оценить результаты отчета в родной веб-среде, что сильно отличается от интеллектуального анализа рекомендаций в печатном документе:

Кроме того, в отличие от документа с углубленным анализом (каким бы полезным он ни был), функциональный прототип свободен от жаргона и использует общий словесный и визуальный язык, понятный каждому. Он открывает диалог на визуальном дисплее для всех членов команды и дисциплин.

Наш главный вопрос при создании этого шаблона заключался в том, сколько деталей дизайна нужно включить. Поскольку у нас был богатый документ, полный анализа, мы могли бы развить прототип дальше. Но, помня о том, что визуальные эффекты могут быстро (и непреднамеренно) переходить из области идеи в область фактов, мы сохранили макет ни к чему не обязывающим и сосредоточили документ только на его основных элементах и ​​значении.

Внутреннее тестирование позволило нам приблизиться к более ориентированному на пользователя решению, обойдя многие потенциальные проблемы, но мы сознательно избегали принятия каких-либо уточненных проектных решений на столь раннем этапе процесса. Важно постоянно сопоставлять все идеи и предложения, включая предложения клиента, с известными данными и помнить, что наш объем знаний на данном этапе меньше, чем на любом другом этапе проекта.

Еще одна причина, по которой крайне важно сохранить первоначальный прототип лох-файным и не включать какие-либо элементы «дизайна», заключается в том, что заинтересованность команды может быть подорвана нерелевантными визуальными элементами, вызывающими непреднамеренные внутренние реакции. Мы избегаем цвета и даже не включаем логотип клиента (вместо этого используйте пустое место или светло-серую рамку в качестве заполнителя). Разговор должен постоянно вестись по функциональным критериям, таким как иерархия контента, доступность, удобство использования, язык и смысл. Убедите команду, что «веселое» будет, но не на таком раннем этапе.

На самом деле, важная цель успешного спринта прототипов состоит в том, чтобы принимать как можно меньше предварительных дизайнерских решений. Успешный дизайн подпитывается пользовательским опытом, поэтому дайте время новым знаниям о проекте для информирования пользовательского интерфейса.

Когда завершится спринт прототипа

Спринт считается завершенным, когда прототип и сопутствующие артефакты одобрены всей командой (включая клиента), и прототип считается готовым к первоначальному тестированию на удобство использования и доступность.

Ранний функциональный прототип воплощает в жизнь видение проекта благодаря масштабу (количество страниц, область навигации и другие основные элементы пользовательского интерфейса), будущей сложности (контент-заполнитель с полезными дескрипторами, возможно, некоторые закодированные ранние функции) и выявлению потребностей (необходимы конкретные технологии). , где они будут развернуты, любые зависимости). Решения относительно инструментов, рабочей среды и стека кода будут приниматься с участием всей команды.

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

Некоторые распространенные проблемы, на которые следует обратить внимание во время спринта прототипа

Вот несколько распространенных проблем, на которые следует обратить внимание при реализации спринта прототипа:

• Примите ценность низкой точности и избегайте акцента на визуальные эффекты. Будьте бдительны в этом вопросе, так как командам, которые плохо знакомы с этим подходом, может понадобиться помощь и уверенность, поскольку они переходят от «где логотип» и сосредотачиваются на более глубоких вопросах функциональности и иерархии.
• Другой аспект вышеизложенного: также будьте бдительны, чтобы не привязываться к своим собственным идеям дизайна / макета. Во время спринтов прототипов полезно помнить, что ничего ценного не создается, и оставаться отстраненными от конечных результатов. Кроме того, это еще одна причина, по которой прототипы должны быть минимальными и, честно говоря, довольно уродливыми. Это служит цели удержания пользователей отстраненными.
• Заинтересованность руководства в процессе на раннем этапе имеет решающее значение . Поскольку в процесс вовлечена вся команда, ваш клиент, ваш начальник и разработчики должны поддерживать и развивать процесс своим участием, творческим подходом и временем. Не будьте одиноким чирлидером, вся ваша команда должна махать своими помпонами!
• Плохая коммуникация — ахиллесова пята всей командной работы . Спринт прототипа не решит постоянные проблемы с коммуникацией, но выведет их на первый план раньше, поскольку вся команда почти сразу погружается в совместный рабочий процесс. Любые уже существующие проблемы с коммуникацией будут возникать рано и часто в спринте прототипа, когда вы работаете над достижением консенсуса и своего первого шага. Воспользуйтесь возможностью улучшить общение и вовлеките всю команду в поиск решений.
• Выберите правильный интерфейсный фреймворк . Если у вас его еще нет, вам, возможно, придется опробовать различные интерфейсные фреймворки, прежде чем вы найдете тот, который соответствует рабочему процессу вашей команды. Я рекомендую обратить внимание на минимальные фреймворки, такие как Fomantic или Bulma, и не зацикливаться на наворотах. Тем не менее, правильный фреймворк — это всегда тот, который работает для вашей команды.
• Команде UI/UX необходимо разработать уровень комфорта и доступ к интерфейсной структуре. В идеале они будут работать непосредственно над прототипом, избегая ненужной передачи и необходимости перевода с одного носителя на другой (то есть из Sketch в прототип). Если ваша фронтенд-команда не знакома с CSS и HTML, то парный подход (когда один дизайнер и один программист работают вместе над фреймворком) также работает хорошо.
• И последнее, но не менее важное: помните, что в команде вы станете лучше и быстрее ! Проведение продуктивного спринта прототипов — это навык, который развивается с практикой.

Что будет дальше

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

Спринт прототипа — отличное начало любого скрам-процесса, но в моих проектах наш следующий шаг — перейти к двойному рабочему процессу, в котором UI/UX работает на половину или весь спринт раньше разработки, исследуя и визуально обновляя прототип до отражать новые идеи.

Прототип органично развивается и становится все более совершенным, подпитываемый исследованиями UX и реалистичными функциональными потребностями. Эта информация, недоступная во время спринта прототипа, появляется постепенно по мере продвижения проекта. UI/UX и разработка дополняют рабочие процессы друг друга посредством гибкого двухстороннего процесса.

Нет передачи дизайна в разработку, которую нужно построить, или разработанного приложения в дизайн, чтобы скрыть. Вместо этого спринт прототипа вовлекает всю группу с самого начала и формирует прочную основу для совместного гибкого рабочего процесса на протяжении всего проекта.

Руководящее видение, возникающее в результате спринта прототипа, не будет идеальным и, вероятно, будет меняться по мере того, как будет узнаваться больше, но признание того, что в начале мы знаем меньше, чем на любом другом этапе проекта, лежит в основе гибкого рабочего процесса. Когда мы применяем ту же самую философию к появлению видения и дизайна проекта посредством спринта прототипов, то в результате получается действенный шаг, действительно полезные артефакты, общая заинтересованность и модель командной работы и сотрудничества, которые можно поддерживать на протяжении всего проекта. .

Примечание о настройках агентства

Если вы работаете в агентстве, вы можете подумать, что такой подход будет навязчивым. К сожалению, вы, вероятно, правы. Многие агентства по своей природе не гибки и активно стремятся к полной передаче проекта, часто с официальной подписью и тщательно документированными последствиями внесения изменений в будущем. Пропаганда прототипного спринта в организации, не поддерживающей Agile, не имеет смысла: это просто не в их ДНК. Как только организация объединяет гибкие и междисциплинарные команды, они могут легко решить, улучшит ли их процесс спринт без передачи прототипа.

Заключение

Спринт 0 и проектные спринты решают реальные проблемы, с которыми сталкиваются многие скрам-команды: отсутствие видения, отсутствие интегрированного дизайна или и то, и другое. Это понятные и логичные ответы, но они не представляют большой ценности и не способствуют созданию сильных agile-команд.

Замена их прототипным спринтом — это практичный способ устранить недостатки спринта 0 и проектных спринтов, одновременно закладывая основу для более тесного гибкого сотрудничества во время будущих спринтов.

Спринт прототипа использует таланты всей команды, генерирует необходимое видение, приводит к первому сделанному командой шагу и позволяет избежать передачи проекта. Посредством этого процесса команды создают общую ответственность за видение проекта и прочную основу для междисциплинарного сотрудничества в духе Agile.

Дальнейшее чтение на SmashingMag:

• Стать лучшим фасилитатором
• Адаптация Agile для команд, работающих неполный рабочий день
• Важность ретроспектив проекта
• Улучшение процесса проектирования в вашей организации