Комментарии 13
>Этот торжественный момент отмечен красной линией на схеме
Этот торжественный момент как правило вписывается в один из спринтов, и является его целью или одной из них.
А проблема разрабтки концепта дизайна имхо несколько преувеличина, поскольку изначально ведь всегда известна общая концепция и функционал системы, это описывается в основном бэклоге (Product backlog, если правильно помню). И относительно него вполне можно сформировать требования к дизайну. Т.е. допустим в первый спринт можно отрисовать лого, определится с цветами и внешним видом общих элементов страниц(кнопки,формы,шрифты и тд.). А далее уже выносить дизайн для конкретных элементов,модулей и т.д. По крайней мере на практике, там где я работаю, это выглядело именно так =)
Этот торжественный момент как правило вписывается в один из спринтов, и является его целью или одной из них.
А проблема разрабтки концепта дизайна имхо несколько преувеличина, поскольку изначально ведь всегда известна общая концепция и функционал системы, это описывается в основном бэклоге (Product backlog, если правильно помню). И относительно него вполне можно сформировать требования к дизайну. Т.е. допустим в первый спринт можно отрисовать лого, определится с цветами и внешним видом общих элементов страниц(кнопки,формы,шрифты и тд.). А далее уже выносить дизайн для конкретных элементов,модулей и т.д. По крайней мере на практике, там где я работаю, это выглядело именно так =)
Наверное из моего текста это не очевидно, но меня как раз интересовала проблема синхронизации процессов разработки дизайна и программной части. Ведь вопросы функциональности, рассматриваемые на ревью спринта имеют мало общего с разработкой логотипа.
Про логотип я написал для примера, так же как и цвета и прочее, т.е. общий внешний вид проекта, от которого потом отталкиваться при разработке дизайна составных частей. Это все изначально определяется и потом программисты и дизайнеры могут синхронно идти: программеры пишут модуль, дизайнеры рисуют и верстают морду. Ну вот так в общем виде.
ну вот момент, когда они начинают идти синхронно я и предпринял попытку определить в своих рассуждениях :)
Я не практик, но почему это два отдельных процесса? Что если их объединить? Нарисовали дизайн - запрограммировали?
*не весь дизайн конечно, а по частям (для которых и будет написан код)
по частям, после пилотного запуска проекта, вполне. Речь идет о том, чтобы как можно быстрее запустить базовый функционал.
Я предлагаю сделать дизайн конкретного интерфейса (того же профайла пользователя) частью процесса разработки. Не важно как он будет выглядеть, какой там логотип. Важно чтобы им можно было пользоваться (ну и он примерно напоминал что должно выйти в итоге). А параллельно дизайнеры могут заняться именно логотипом/картинками и стилем всей страницы.
зачем? чтобы программист вместо того, чтобы показать чистый
функционал копался со стилями?
Скорее, процесс разработки дизайна должен идти исходя из общей концепции и функциональности описанной в бэклоге (как уже писал zarincheg), но без жесткой привязки к спринтам по времени.
Момент запараллеливания, зависит от специфики проекта. Если в проекте довольно сложные интерфейсы, отображение которых требует отдельного программирования (AJAX-фичи и т.п.), то все необходимые для пилотного запуска интерфейсы вместе со всей дизайн-концепцией и логотипом должны быть готовы не перед последним спринтом, разумеется.
функционал копался со стилями?
Скорее, процесс разработки дизайна должен идти исходя из общей концепции и функциональности описанной в бэклоге (как уже писал zarincheg), но без жесткой привязки к спринтам по времени.
Момент запараллеливания, зависит от специфики проекта. Если в проекте довольно сложные интерфейсы, отображение которых требует отдельного программирования (AJAX-фичи и т.п.), то все необходимые для пилотного запуска интерфейсы вместе со всей дизайн-концепцией и логотипом должны быть готовы не перед последним спринтом, разумеется.
Разница в подходе. Дизайн - это всегда от общего к частному. Не случайно zarincheg упомянул про логотип. Без этой фитюлки, не имеющей никакого отношения к разработке модулей, невозможно определиться со стилевым решением сайта. А логотип в свою очередь определяется названием и общей концепцией проекта.
Параллелить и привязывать к рамкам спринта разработку логотипа и модуля пользователи бессмысленно.
Параллелить и привязывать к рамкам спринта разработку логотипа и модуля пользователи бессмысленно.
мое мнение:
даем дизайнеру столько времени сколько потребует на проект (в рамках разумного конечно)
он продумывает все (можно оставить 404 и логотип с иконками на потом :) параллельно консультируясь у прогеров (мало ли что дизайнер на придумывает). Когда концепт готов его следует «обкатать» всей толпой на выявление логических дыр (посредством «мозгового штурма»). Убедившись, что все «работает» кодим, дизайнера отправляем в отпуск дабы что-нибудь еще не придумал.
После этого правки можно (в дизайн) вносить не значительные: кнопочку побольше, линки другого цвета и т.д. — это не сложно.
В день «релиза» если дизайнер говорит «я придумал кое-что покруче» вручаем ему книжку по пхп в зубы и ссылку в сибирь :) шучу, оставляем на версию 2.0
Идеальной схемы просто быть не может — всегда можно сделать лучше. Тема кстати говорил, что бывают они сделают весь проект (завтра сдавать), но в последний момент все стопят, потому-что в голову пришла «светлая мысль».
даем дизайнеру столько времени сколько потребует на проект (в рамках разумного конечно)
он продумывает все (можно оставить 404 и логотип с иконками на потом :) параллельно консультируясь у прогеров (мало ли что дизайнер на придумывает). Когда концепт готов его следует «обкатать» всей толпой на выявление логических дыр (посредством «мозгового штурма»). Убедившись, что все «работает» кодим, дизайнера отправляем в отпуск дабы что-нибудь еще не придумал.
После этого правки можно (в дизайн) вносить не значительные: кнопочку побольше, линки другого цвета и т.д. — это не сложно.
В день «релиза» если дизайнер говорит «я придумал кое-что покруче» вручаем ему книжку по пхп в зубы и ссылку в сибирь :) шучу, оставляем на версию 2.0
Идеальной схемы просто быть не может — всегда можно сделать лучше. Тема кстати говорил, что бывают они сделают весь проект (завтра сдавать), но в последний момент все стопят, потому-что в голову пришла «светлая мысль».
release early release often ;)
жаль, что не все в это верят
жаль, что не все в это верят
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкая разработка сайта: программирование + дизайн