Как Вы применяете Толпу к части дизайна веб-разработки? [закрытый]
Перейдите в командную строку на этом пути,
C:\Program Files (x86)\MySQL\MySQL Server 5.0\bin>
Затем передайте эту команду для экспорта вашей базы данных (без пробела после -p)
mysqldump -u[username] -p[userpassword] yourdatabase > [filepath]wantedsqlfile.sql
5 ответов
вот то, как я предложил бы, чтобы Вы сделали это (т.е., как мы попытались сделать это)
Предварительный спринт 0: удостоверьтесь, что у Вас есть хорошее видение того, что Вы хотите сделать. Не должен быть супер детализирован, но не должен быть, "мы хотим создать веб-сайт, который является социальным"
Sprint 0 : Developers оборудует - устанавливают серверы CI, работу над сценариями развертывания и т.д., таким образом, вся основная платформа сделана. В конце этого необходимо быть в состоянии нажать кнопку (худший случай: выполните единственную команду на Удаленном сервере), который берет код в Вашей системе управления исходным кодом, сборки это, упаковывает его, запускает все тесты, которые Вы хотите на нем, сообщает это, и, если возможно, устанавливает его на тестовом сервере (или по крайней мере приводит к пакету, который можно установить на тестовом сервере).
В это время, разработчик делает каркасы. Их цель состоит в том, чтобы сделать основные каркасы для такого количества сайта, как Вы думаете, что Вам нужно (думайте карта сайта и поток не поля и пиксели). Затем когда это сделано, разработайте с премьер-министром, что является самым важным, и вдавайтесь в подробности об этом - каркас. Не пиксели ВСЕ ЖЕ.
Менеджеры проектов и т.п. работают с разработчиком и бизнесом/заинтересованной стороной, описывая истории и задачи для Вас партия, чтобы сделать и отследить. Очевидно, у них должна быть идея карты сайта и т.д., чтобы сделать это.
Это может взять больше чем один спринт. запустите с одного (я рекомендую, чтобы спринты 2-3 недель - 1 были слишком коротки, 4 является слишком длинным), посмотрите, сколько все еще необходимо сделать и т.д.
Так в конце спринта 0, Вы имеете:
- Партии историй, в первоочередном заказе (Вы CAN добавляют больше позже, заражают Вас, всегда будет, когда требования изменяются)
- карта сайта А (т.е., общее представление о том, что все это собирается содержать)
- Каркасы для первого блока работы
- , Все Ваши инструменты работают и устанавливают
- Вы, CI, отслеживание ошибок, управление исходным кодом и системы развертывания существуют
Таким образом, Вы начинаете, спринт 1
Имеют в виду, что для первых 3-4 спринтов, Вы не будете знать, сколько работы можно сделать в спринте, поэтому ОЖИДАТЬ понимать его превратно! Снимите столько работы (в первоочередном заказе, бизнес/PM вставил их), сколько Вы думаете, что можете НАВЕРНЯКА быть сделаны. можно всегда брать больше позже!
Вы партия разрабатывают те страницы и каркас разработчика (разработчиков) следующий блок страниц (как определено премьер-министром). Возможно, разработчик делает искусство для тех страниц, таким образом, можно сделать это в следующем спринте
Так, Вы разрабатываете то, что Вы имеете, и разработчики работают над материалом для Вашего следующего спринта.
, Конечно, у них мог быть процесс толпы, идущий также, просто они запустили спринт ранее!
теперь повторение, пока Вы не работаете без работы
во время спринта, если (говорят), что требование изменяется или что-то новое добавляется, тогда новая история записана для этого, и это планируется в работу. Если это - супер высокий приоритет, это может пойти наверху и является главным объектом для следующего спринта (который будет на расстоянии в 1-2 недели, обычно). Или это может быть хорошее, чтобы иметь, таким образом, это идет внизу - бизнес решает.
потребность PM/разработчиков знать они могут изменить вещи, но изменения ДЕЙСТВИТЕЛЬНО имеют последствия, таким образом, это не находится в их (финансовом) интересе прервать и возвратить и передать. но требования ДЕЙСТВИТЕЛЬНО изменяются, и XP и соглашение о Толпе с этим лучше, чем водопад.
не забывайте:
- можно остановить спринт в любое время и вернуться к планированию, например, если требования изменятся слишком много, или Вы работаете без работы
- , то можно запланировать больше работы, чем у Вас есть время, чтобы сделать, пока та работа не посвятила себя (т.е., это "дополнительно" или работа "фрагмента")
, Ваш PM должен быть в состоянии предсказать, когда проект закончится - смотрят на то, сколько работы Вы сделали в последнем спринте (Ваша скорость) и делите объем работы, оставленный тем числом, и Вы заставляете количество спринтов идти. Легкий.
, О, и читают на точках истории - не оценивают истории в течение многих часов или дней. Используйте точки. Для начальной загрузки этого просто сделайте первую историю, которую Вы оцениваете (говорят), что 8 (последовательность 1 2 3 5 8 13 21 40 60 100, бесконечна). Тогда возьмите вторую историю и оцените, что она относительно первого - удваивает это работа (13)? половина работы (5)? о том же (8)?
В конце спринта, сложите, сколько точек Вы сделали, и это - Ваша скорость. Макс. объем работы можно ФИКСИРОВАТЬ делать выполнение в следующем спринте, является той суммой. Вы CAN всегда останавливает спринт рано или просто вытягивает больше, отделываетесь от отставания и т.д., если Вы выбегаете рано. Как Вы продвигаетесь, Ваша скорость стабилизируется.
Проклятый, я уверен, что существуют книги и т.д. по тому, как выполнить его, таким образом, я остановлюсь:)
Я категорически не согласен с ответом, предоставленным Джейсоном. Смысл Scrum заключается в том, чтобы избавиться от метода, при котором дизайнеры сначала «делают свое дело», а затем переходят к другим вещам. Это полностью и на 100% против всех принципов Lean / Scrum!
Как включить дизайнеров в процесс Scrum? Брось их в микс! Убедитесь, что вы не просто включаете проект водопада в Scrum, так как это лучший путь к провалу! Скрам работает только тогда, когда Реализовано без исключений. «Scrum, но ...» - худшая модель проекта. Организуйте работу так, чтобы это было возможно для параллельного проектирования и разработки. Не переусердствуйте с первоначальным дизайном, но сделайте его двухтактным, когда обе стороны монеты влияют на другую. Смысл Scrum состоит в том, чтобы повторять, повторять и повторять, так что извлеките из этого все преимущества.
Кроме того, довольно склонно вообще избегать традиционного дизайна на основе Photoshop. Вы можете прочитать больше об этом из этого отличного поста в блоге «Сигнал против шума»: итерируйте и итерируйте, так что извлеките из этого все преимущества.
Кроме того, довольно склонно вообще избегать традиционного дизайна на основе Photoshop. Вы можете прочитать больше об этом из этого отличного поста в блоге «Сигнал против шума»: итерируйте и итерируйте, так что извлеките из этого все преимущества.
Кроме того, довольно склонно вообще избегать традиционного дизайна на основе Photoshop. Вы можете прочитать больше об этом из этого отличного поста в блоге «Сигнал против шума»: http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop
Я сделал это прежде, где Разработчики сделали свою вещь в ранних повторениях, и их продукт работы использовался командой разработчиков в более поздних повторениях. Когда команда разработчиков запустила работу, разработчики продвинутся вперед к другим частям проекта, или возможно к другим проектам.
я думаю, что мы привыкли видеть большое изображение, и управлять к нему
можно все еще сделать это. Ваши разработчики могут сделать больший первичный дизайн, и команда разработчиков может использовать Толпу для итерации к этому.
Если бы мы использовали методы Scrum, как бы это происходило?
, хотя этот пост довольно старый, он побудил меня заняться исследованиями самостоятельно. я нашел «Двенадцать появляющихся практик» Джеффа Паттона для дизайнеров / практиков UX, которые, как мне показалось, были особенно интересны для этого вопроса, и довольно полезный набор кадров:
- Драйв: практики UX являются частью команда заказчика или владельца продукта.
- Исследуйте, моделируйте и проектируйте заранее - но только достаточно.
- Разделите ваши дизайнерские работы
- Используйте параллельную разработку треков, чтобы работать впереди и следовать за ней.
- Купить время проектирования со сложными инженерными историями.
- Создание группы проверки пользователей для использования при непрерывной проверке пользователей.
- Планирование непрерывного исследования пользователей отдельно от разработки.
- Использование времени пользователя для нескольких видов деятельности.
- Используйте RITE для итерации пользовательского интерфейса перед разработкой.
- Прототип с низкой точностью.
- Рассматривать прототип как спецификацию.
- Станьте фасилитатором дизайна.
Если вы хотите копать глубже, Джефф излагает это agileproductdesign.com.
Я хотел бы поделиться. Я - мастер схватки в команде разработчиков будущего социального приложения. В этой команде 1 дизайнер пользовательского интерфейса, 1 дизайнер пользовательского интерфейса (я), 1 разработчик интерфейса (css, ajax и т. Д.) И 3 программиста.
Это наш первый проект, использующий среду SCRUM, поэтому это было довольно сложно. Тенденция во время наших ежедневных совещаний по схваткам заключается в том, что наша работа по дизайну никогда не заканчивается, потому что в нашем первоначальном бэклоге продукта были истории вроде «Пользователь хочет, чтобы его убедили подписаться», а затем мы добавили к этой истории «способ демонстрации», так что от там мы могли бы определить, что нужно сделать (т.е. нам нужно сделать каркас, сделать копирайтинг и т.д.)
Это можно было бы сделать лучше. Составьте список каждой задачи на основе этой истории и оцените время для каждой задачи. Например, во время отставания по продукту мы могли бы создать их по порядку: Карты сайта> Потоки задач> Каркасы
Теперь вопрос в том, делаем ли мы все это в спринте? Или мы должны сделать это еще до любого спринта? Поражает цель схватки, если мы делаем это вне спринтов, верно?
Те, кто занимался проектированием пользовательского интерфейса, знают, что для подготовки этих задач требуется довольно много времени. Так почему бы не сделать все это частью спринта? Вовлекайте и программистов в эти задачи.
Каркасные схемы очень важны на протяжении всего проекта. Это похоже на план здания, где он используется от начала до конца.
Итак, сделайте начальный каркас на основе невыполненных работ по продукту во время вашего первого спринта. И соответствующим образом корректируйте каркас во время каждого второго спринта. Наши программисты спроектируют свой код на основе потока задач, а затем создадут его визуально на основе каркаса.
О, кстати, не беспокойтесь о том, как будет выглядеть продукт (хотя наличие первоначального макета дизайна - это всегда хорошо). Вместо этого сосредоточьтесь на потребностях и желаниях пользователя и создайте очень ориентированный на пользователя поток для достижения именно этого. Позже наш дизайнер решает, какой интерфейс он собирается разработать. Если каркас сделан правильно, у дизайнера будет очень мало проблем с проектированием пользовательского интерфейса. То же самое и с копирайтингом.
В общем, работайте рука об руку на каждой итерации. Для новичков (таких как я) дайте SCRUM шанс поработать на вас. Если он может работать для таких компаний, как fantasyinteractive.com , то может ли он сработать и для вас:)
ps для отличных каркасов,