Не так давно мы публиковали материал о организции работы над пользовательским интерфейсом в командах с гибким процессом разработки http://blog.sibirix.ru/2012/11/26/agile-and-ux/. Основая идея — запуск параллельных потоков дизайна и разработки, управляемых на одном бэклоге. Причем поток дизайна идет впереди на одну итерацию. В этом небольшом переводе Дамона Диммика [Damon Dimmick] мы рассмотрим альтернативный подход к организации работы над дизайном в agile-командах. Оригинал статьи можно почитать тут: http://uxdesign.smashingmagazine.com/2012/11/06/design-spikes-fit-big-picture-ux-agile-development/.

Быстрые темпы для UX-дизайна могут привести к близоруким дизайнерским решениям. А в гибких методологиях разработки темпы именно быстрые. Но дизайнер, сосредотачиваясь на решении конкретных пользовательских историй в рамках спринта, пренебрегает «большими» задачами. А это ему аукнется. Позже.

Иногда UX-дизайнерам просто нужно немного времени для того, чтобы проработать «большую» дизайнерскую задачу, которая не вписывается в текущую пользовательскую историю или конкретный спринт. Эта статья рассматривает решение подобных проблем. «Дизайн-пики», подход, который я разработал специально для больших проектов, — это своеобразные «буферы времени», которые позволяют дизайнерам сосредоточиться на «больших» вопросах UX-дизайна и при этом оставаться в рамках Скрама. У дизайнеров появляется эффективный инструмент: они начинают контролировать выполнение «больших задач», неправильное понимание которых может аннулировать работу, проделанную командой.

Туннельное зрение и проблема с нулевым спринтом

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

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

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

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

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

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

Что такое дизайн-пик и в чем его особенности?

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

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

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

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

Итак, что происходит с бэклогом, Product Owner’ом и традиционными спринтами?

Дизайн-пик сохраняет роль Product Owner’а, но также вводит в процесс другую «решающую» фигуру: Design Owner. Этот человек обычно является тимлидом или руководителем отдела дизайна. Также эта роль может выполняться руководителем отдела маркетинга — всё зависит от структуры конкретной организации. Ключевой момент в следующем: этот человек должен иметь «дизайнерское видение» проекта и должен уметь принимать решения о целесообразности предлагаемых командой идей (относительно других продуктов, шаблонов проектирования, стиля и т.д.)

Дизайн-оунер также частично отвечает за утверждение степени готовности результатов, полученных по завершению дизайн-спринта. И продакт-оунер и дизайн-оунер должны прийти к согласию относительно того, что считать за «готово» (Definition of Done). Определение «готовности» вырабатывается во время митинга перед дизайн-пиком и предполагает согласие по поводу его критериев между всеми участниками: продакт-оунером, дизайн-оунером и командой. В большинстве случаев это будет степень завершенности отдельных дизайн-артефактов, получение результатов исследований или прототипов.

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

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

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

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

Длительность дизайн-пиков не регламентирована по времени, но команда дизайна должна стремиться закончить пик так быстро, как это возможно, — так что команда не бездействует. Продакт-оунер может назначить какие-то временные рамки, если это необходимо, но предвидеть, как много времени потребует пик, может только дизайн-оунер. Дизайн-пики наиболее эффективны, когда они длятся недолго, но происходят часто — так собирается качественная обратная связь со стейкхолдеров. Рекомендуемая продолжительность дизайн-шипа — 1-2 недели. Пик будет продолжаться в форме дизайн-спринта, пока продакт-оунер и дизайн-оунер не решат, что пик достиг своих целей. Затем все усилия будут направлены на то, чтобы вернуть команду к привычному графику спринта.

Все знакомые по Скраму этапы также остаются на месте: оценка задач, планирование спринта, ретроспектива и т.п.

Когда заканчивается пик дизайна и что происходит потом?

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

Заключение

Дизайн-пики дают UX-командам инструмент для проработки общей картины дизайна, и всё это внутри Скрам-процесса. Пики дизайна создают «временные пузыри» или «буферы» внутри Скрама.

Дизайн-пики позволяют команде рассматривать вопросы UX на макро-уровне, привлекать высших стейкхолдеров (в том числе продакт-оунера), их опыт и рекомендации — всё это для выработки дизайнерских решений.

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

Оригинал: http://uxdesign.smashingmagazine.com/2012/11/06/design-spikes-fit-big-picture-ux-agile-development/

Асхат Уразбаев
Управляющий партнер в ScrumTrek

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

Как решать проблему? Есть, грубо говоря, два способа:

1) Дизайнер проекта помогает понять команде, что такое UX design. Он доносит до команды и PO идею целостности продукта и показывает, как проектировать взаимодействие. Он дает команде инструменты проверки дизайна. Команда учится этому, через некоторое время они понимают продукт и сами эффективно проектируют взаимодействие.

Это долго и непонятно.

Второй способ:

2) Мы никому ничего не объясняем. Мы вводим новую роль, задача которой (по факту) бороться с PO, отстаивая интересы Дизайна. Раньше, пока наш отдел тормозил, выдавая Идеально Продуманный Дизайн, команда успевала убежать дальше и отказывалась имплементировать наши задумки. Теперь мы ее остановим на две недели. За это время мы все гениально придумаем и только потом разрешим всем двигаться дальше. Чтобы agile-people не выпендривались, мы назовем это словом из Agile словаря. Spike — звучит круто, не страшно, что по факту это что-то совсем противоположное.

За время спайка мы основательно перетряхнем их отстойный баклог и полностью сохраним контроль над решениями!

Что будет потом? Проблема введением новой роли не решена. Теперь есть конфликты между PO и DO (design owner). Идеи дизайнеров по-прежнему наталкиваются на непонимание команды. Борьба переходит в политическую плоскость. Захватить власть проще, чем кому-то что-то объяснять.

Юрий Гугнин
Управляющий партнер в Бизнес-школа РИК

Дизайн-пики — полезная практика. Они напоминают рефакторинг-итерации, которые мы в ADV применяем для разработки крупных проектов. Суть дизайн-пиков и рефакторинг-итераций одинакова: рано или поздно некоторым участникам команды надо дать время спокойно подумать, переосмыслить сделанное, спроектировать крупный объем работ на будущее.

Сам Скрам-процесс с его высокими скоростями вынуждает команду постоянно накапливать «технический долг». Рано или поздно этот долг придется «отдавать» и проводить служебные итерации.