Ответ 1

вот как я предлагаю вам это сделать (то есть, как мы это пытались)

Pre-sprint 0: убедитесь, что у вас есть хорошее видение того, что вы хотите сделать. Не нужно быть супер подробным, но не должно быть "мы хотим создать веб-сайт, который является социальным"

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

В это время дизайнер делает каркасы. Их цель состоит в том, чтобы делать базовые каркасы для большей части сайта, как вы думаете, что вам нужно (подумайте о карте сайта и потоках не полей и пикселей). Затем, когда это будет сделано, поработайте с PM, что самое главное, и вдайтесь в подробности об этом - каркасе. Не пикселы YET.

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

Это может занять более одного спринта. начните с одного (рекомендую 2-3-недельные спринты - 1 слишком короткий, 4 слишком длинный), посмотрите, сколько вам еще нужно делать и т.д.

Итак, в конце спринта 0 у вас есть:

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

Итак, вы начинаете спринт 1

Имейте в виду, что в течение первых 3-4 спринтов вы не будете знать, сколько работы вы можете сделать в спринте, так что ОЖИДАЙТЕ, чтобы он ошибался! Снимите столько работы (в приоритетном порядке бизнес /PM поставил их), как вы думаете, вы можете ЗА УВЕРЕНЫ сделать. вы всегда можете взять более поздно!

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

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

Конечно, у них тоже может быть процесс схватки, только раньше они начали спринт!

теперь повторяются до тех пор, пока вы не закончите работу

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

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

Не забывайте:

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

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

О, и прочитайте в сюжетных точках - не оценивайте истории в часах или днях. Используйте точки. Чтобы загрузить это, просто сделайте первый рассказ, который вы оцениваете (скажем) 8 (последовательность 1,2,3,5,8,13,21,40,60,100, бесконечная). Затем возьмите второй рассказ и оцените его по сравнению с первым - это удвоение работы (13)? половина работы (5)? о том же (8)?

В конце спринта добавьте, сколько очков вы сделали, и что ваша скорость. Максимальный объем работы, которую вы можете COMMIT делать в следующем спринте, - это сумма. Вы МОЖЕТЕ всегда останавливать спринт раньше или просто откладывать больше работы с отставанием и т.д., Если вы закончите рано. По мере продвижения ваша скорость будет стабилизирована.

Черт, я уверен, что есть книги и т.д. о том, как запустить его, поэтому я остановлюсь:)

Ответ 2

Я категорически не согласен с ответом Джейсона. Весь смысл Scrum - избавиться от метода, когда дизайнеры сначала "делают свое дело", а затем переходят к другим вещам. Это полностью и 100% против всех принципов бережливого /Scrum!

Как включить дизайнеров в процесс Scrum? Бросьте их в микс! Удостоверьтесь, что вы не просто обволакиваете проект водопада в Scrum, как лучший путь к неудаче! Scrum работает только тогда, когда он реализован без исключений. "Scrum, но..." - худшая модель проекта. Организуйте работу, чтобы можно было параллельно разрабатывать и разрабатывать. Не переусердствуйте с первоначальным дизайном, но сделайте его толкающим, где обе стороны монеты влияют на другую. Точка Scrum - это итерация, итерация и итерация, поэтому в полной мере используйте это.

Кроме того, он довольно склонен к тому, чтобы фактически полностью отказаться от традиционного дизайна на основе Photoshop. Вы можете узнать больше об этом из этого превосходного сообщения в блоге в Signal vs. Noise: http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop

Ответ 3

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

Я думаю, мы привыкли видеть большой изображение и движение к нему

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

Ответ 4

Для части дизайна в спринте 0 вы можете использовать такую ​​технику, как Styletyles (http://styletil.es), чтобы определить графический стиль, необходимый для проект. Таким образом, вам не нужен большой дизайн заранее и по-прежнему будьте проворны, когда вы бежите.

Ответ 5

Это простое peasy!:) Ну, позвольте мне поделиться, как мы это делаем.

Первый спринт

1) Владелец продукта создает проводные рамки и добавляет к отставанию (мы используем Yodiz, www.yodiz.com) 2) Наш графический дизайнер создает макеты и помещает их в инструмент обмена макетами (www.concept.ly) 3) Наши разработчики работают над настройкой серверов. Если все уже готово, у нас есть довольно умный владелец продукта, у вас всегда будут элементы в отставании для выбора.

Sprint Two

1) Разработчик начинает работу над финализированными макетами, которые были окончательно доработаны. 2) Дизайнерская работа на другой проводной рамке, добавленной владельцем продукта в отставание.

Я сказал вам это легко!

Ответ 6

Я хотел бы поделиться. Я мастер схватки для команды разработчиков будущего социального приложения. У этой команды есть 1 дизайнер пользовательского интерфейса, 1 пользовательский дизайнер (я), 1 разработчик интерфейса (css, ajax и т.д.) И 3 программиста.

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

Это может быть сделано лучше. Изложите каждую задачу на основе этой истории и оцените время для каждой задачи. Например, во время отставания продукта мы могли оттуда создавать их в порядке: Карты сайтa > Потоки задач > Каркасы

Теперь вопрос в том, делаем ли мы все это в спринте? Или мы должны делать это еще до любого спринта? Поражает цель схватки, если мы делаем из спринтов правильно?

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

Каркас очень важен на протяжении всего проекта. Это похоже на план здания, где его используют от начала до конца.

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

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

Таким образом, работайте рука об руку на каждой итерации. Для новичков (например, я) дайте SCRUM шанс работать на вас. Если это может работать для таких компаний, как fantasyinteractive.com, так это может работать для вас n me:)

p.s. для больших каркасов используйте omnigraffle (mac), это шиит!

Ответ 7

Если бы мы использовали методы Scrum, как это будет происходить?

хотя этот пост довольно старый, это побудило меня исследовать самостоятельно. я нашел Джеффа Паттона "Двенадцать новых практик" для дизайнеров/практиков UX, которые, как я думал, были склонны к этому вопросу, и довольно полезный набор кадров:

• Привод: практикующие UX являются частью команды клиента или владельца продукта.
• Исследование, модель и дизайн впереди - но только достаточно.
• Разделите свои дизайнерские работы.
• Используйте параллельную разработку дорожек, чтобы работать вперед и следовать за ней.
• Покупайте время разработки со сложными инженерными историями.
• Культивировать группу проверки пользователей для использования для непрерывной проверки пользователей.
• Расписание непрерывных исследований пользователей в отдельном треке от разработки.
• Использовать время пользователя для нескольких действий.
• Используйте RITE для итерации пользовательского интерфейса перед разработкой.
• Прототип с низкой точностью.
• Использовать прототип в качестве спецификации.
• Станьте координатором проекта.

если вы хотите копать глубже, jeff произносит agileproductdesign.com.