Где дизайн должен быть включен в agile-процесс?

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

Работа над дизайном выполняется в спринте

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

По мере того, как наши итерации становились короче, и мы сгорали от того, что все больше историй блокировалось в ожидании утверждения дизайна, мы пытались:

Дизайн как отдельные истории

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

Мы сейчас делаем:

Дизайн является частью нашего определения готовности

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

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

Есть три причины для оценки:

• Чтобы выяснить, сколько команда может взять на себя в каждом спринте
• Чтобы определить, сколько времени потребуется для завершения релиза, учитывая наличие команды.
• Позволить команде прийти к общему пониманию объема работы.

На самом деле они касаются не объема работы, а того, сколько вы можете вместить в свой конвейер разработки.

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

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

Я обнаружил, что полезно заставить дизайнеров думать о том, что можно легко изменить позже — текст, цвета, размещение и т. д. — и сосредоточиться на наброске каркаса, который разработчики могут использовать для размещения правильных элементов управления на странице или экране. . Затем они могут работать совместно на более позднем этапе спринта, чтобы исправить мелкие детали. Я обнаружил, что это также полезный подход с анализом и деталями, такими как проверка, сообщения об ошибках, или с архитектурой и фактическим содержанием сообщений HTML/XML, ключевыми словами RESTful и т. д. Легкость изменения позже делает анализ перед спринтом очень удобным. намного проще и может помочь командам более эффективно сотрудничать, независимо от их роли.

Это то, с чем борется и моя команда.

И это заставило меня задать другой вопрос моей команде.

«Если вы не знаете, что такое дизайн, как вы можете составить историю и принять ее в итерацию»?

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

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

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

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

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

Джефф

При работе с программным обеспечением я считаю, что правильно выполненный дизайн всегда имеет место. Я смотрю на истории как на бизнес/пользователей, а не на разработку. История типа "Получить статусы из базы". ориентирована на развитие и приведет ко многим проблемам. Рассказ типа "Отображение статуса заказа". больше ориентирован на бизнес/пользователя. Если вы решите разбить эту историю на задачи (что я на самом деле не рекомендую), то я бы разбил ее так, чтобы каждая задача включала все слои вашей архитектуры.

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

Надеюсь, это поможет.

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

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

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

Я думаю, что хорошее определение DONE полезно в этом случае. Моя команда будет знать, что если они пометят пользовательскую историю как ВЫПОЛНЕННУЮ, ее следует проанализировать, спроектировать, внедрить, реорганизовать, протестировать, рецензировать и интегрировать в сборку — история потенциально может быть отправлена. Обратите внимание на дизайн. Их оценки отражают это.

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

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

У нас есть «предпроект» до начала реального проекта. В этом проекте США дорабатываются, создаются разумные варианты использования и создаются каркасы.

Таким образом, у нас есть отправная точка, когда мы начинаем «настоящий» проект. Дизайнер может работать над преобразованием wf в дизайн, внешний интерфейс может выполнять свои функции внешнего интерфейса, а разработчики .Net и SQL могут выполнять свою работу. Вся команда вместе в одной SCRUM-команде.

Конечно, в «настоящем» проекте еще есть место для изменений и улучшений.