Гибкая разработка сайта: программирование + дизайн

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

    Рассмотрим типичную ситуацию. У нас есть идея проекта. Далее есть 2 пути:
    • Традиционный: сначала пишем подробное ТЗ на весь продукт, затем одновременно программируем строго по ТЗ и рисуем не строго по ТЗ ;), а затем все мучительно скрещиваем;
    • Альтернативный (по мотивам методологии Scrum): пишем спецификацию на часть проекта, программируем, оцениваем результат и цикл повторяется, функциональность наращивается.

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

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

    Вот что у меня получилось в теории:



    Для наглядности, декомпозиция процесса разработки дизайн-концепции не отображена. Она традиционна.

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

    Но, это теория. Хорошо бы узнать мнение практиков.

    И еще немного теории в обзоре методологии Scrum Асхата Уразбаева (500 КБ, .pdf). Очень рекомендую.
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 13

      0
      >Этот торжественный момент отмечен красной линией на схеме
      Этот торжественный момент как правило вписывается в один из спринтов, и является его целью или одной из них.
      А проблема разрабтки концепта дизайна имхо несколько преувеличина, поскольку изначально ведь всегда известна общая концепция и функционал системы, это описывается в основном бэклоге (Product backlog, если правильно помню). И относительно него вполне можно сформировать требования к дизайну. Т.е. допустим в первый спринт можно отрисовать лого, определится с цветами и внешним видом общих элементов страниц(кнопки,формы,шрифты и тд.). А далее уже выносить дизайн для конкретных элементов,модулей и т.д. По крайней мере на практике, там где я работаю, это выглядело именно так =)
        0
        Наверное из моего текста это не очевидно, но меня как раз интересовала проблема синхронизации процессов разработки дизайна и программной части. Ведь вопросы функциональности, рассматриваемые на ревью спринта имеют мало общего с разработкой логотипа.
          0
          Про логотип я написал для примера, так же как и цвета и прочее, т.е. общий внешний вид проекта, от которого потом отталкиваться при разработке дизайна составных частей. Это все изначально определяется и потом программисты и дизайнеры могут синхронно идти: программеры пишут модуль, дизайнеры рисуют и верстают морду. Ну вот так в общем виде.
            0
            ну вот момент, когда они начинают идти синхронно я и предпринял попытку определить в своих рассуждениях :)
              0
              Я не практик, но почему это два отдельных процесса? Что если их объединить? Нарисовали дизайн - запрограммировали?
                0
                *не весь дизайн конечно, а по частям (для которых и будет написан код)
                  0
                  по частям, после пилотного запуска проекта, вполне. Речь идет о том, чтобы как можно быстрее запустить базовый функционал.
                    0
                    Я предлагаю сделать дизайн конкретного интерфейса (того же профайла пользователя) частью процесса разработки. Не важно как он будет выглядеть, какой там логотип. Важно чтобы им можно было пользоваться (ну и он примерно напоминал что должно выйти в итоге). А параллельно дизайнеры могут заняться именно логотипом/картинками и стилем всей страницы.
                      0
                      зачем? чтобы программист вместо того, чтобы показать чистый
                      функционал копался со стилями?

                      Скорее, процесс разработки дизайна должен идти исходя из общей концепции и функциональности описанной в бэклоге (как уже писал zarincheg), но без жесткой привязки к спринтам по времени.

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

                        Посмотрим что скажут практики...
                  0
                  Разница в подходе. Дизайн - это всегда от общего к частному. Не случайно zarincheg упомянул про логотип. Без этой фитюлки, не имеющей никакого отношения к разработке модулей, невозможно определиться со стилевым решением сайта. А логотип в свою очередь определяется названием и общей концепцией проекта.
                  Параллелить и привязывать к рамкам спринта разработку логотипа и модуля пользователи бессмысленно.
          +3
          мое мнение:
          даем дизайнеру столько времени сколько потребует на проект (в рамках разумного конечно)
          он продумывает все (можно оставить 404 и логотип с иконками на потом :) параллельно консультируясь у прогеров (мало ли что дизайнер на придумывает). Когда концепт готов его следует «обкатать» всей толпой на выявление логических дыр (посредством «мозгового штурма»). Убедившись, что все «работает» кодим, дизайнера отправляем в отпуск дабы что-нибудь еще не придумал.
          После этого правки можно (в дизайн) вносить не значительные: кнопочку побольше, линки другого цвета и т.д. — это не сложно.
          В день «релиза» если дизайнер говорит «я придумал кое-что покруче» вручаем ему книжку по пхп в зубы и ссылку в сибирь :) шучу, оставляем на версию 2.0
          Идеальной схемы просто быть не может — всегда можно сделать лучше. Тема кстати говорил, что бывают они сделают весь проект (завтра сдавать), но в последний момент все стопят, потому-что в голову пришла «светлая мысль».
            0
            release early release often ;)
            жаль, что не все в это верят

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

            Самое читаемое