О гибких (agile) методологиях по разработке программных продуктов информации довольно много. Но, мне пока нигде не попадалась информация (на русском) о применении agile для разработки сайтов. Я имею ввиду достаточно крупные проекты, например социальные сервисы, где подразумевается постоянное совершенствование продукта и где важен ранний запуск бета-версии. В частности, меня интересует вопрос планирования параллельной разработки дизайна и программной части проекта.
Рассмотрим типичную ситуацию. У нас есть идея проекта. Далее есть 2 пути:
Стоп. А где же здесь дизайн? Как разрабатывать дизайн на часть проекта? Да еще в рамках спринта? Ведь для того, чтобы разработать т.н. дизайн-концепцию, необходимо целостное видение функциональности проекта. И инкрементальный подход (сначала спрограммировали и нарисовали профиль пользователя, затем механизм публикации и т.д.) противоречит основному принципу разработки дизайна — от общего к частному.
После того, как базовая функциональность проекта, достаточная для запуска в эксплуатацию, разработана, вполне можно в рамках спринтов разрабатывать и дорабатывать дизайн отдельных интерфейсов, не выходя за рамки дизайн-концепции или стилевого решения проекта. Но, как спланировать именно разработку стилевого решения в условиях итеративной разработки?
Вот что у меня получилось в теории:
Для наглядности, декомпозиция процесса разработки дизайн-концепции не отображена. Она традиционна.
Таким образом, в закрытой фазе разработки, созданная функциональность отображается в технологических шаблонах, без какого-то ни было оформления. А параллельно, на основе идеи и с учетом промежуточных релизов разрабатываются дизайн-концепция и интерфейсы проекта. В рамках последнего перед публикацией проекта спринта, дизайн и программная часть воссоединяются и предстают перед публикой. Этот торжественный момент отмечен красной линией на схеме.
Но, это теория. Хорошо бы узнать мнение практиков.
И еще немного теории в обзоре методологии Scrum Асхата Уразбаева (500 КБ, .pdf). Очень рекомендую.
Рассмотрим типичную ситуацию. У нас есть идея проекта. Далее есть 2 пути:
- Традиционный: сначала пишем подробное ТЗ на весь продукт, затем одновременно программируем строго по ТЗ и рисуем не строго по ТЗ ;), а затем все мучительно скрещиваем;
- Альтернативный (по мотивам методологии Scrum): пишем спецификацию на часть проекта, программируем, оцениваем результат и цикл повторяется, функциональность наращивается.
Стоп. А где же здесь дизайн? Как разрабатывать дизайн на часть проекта? Да еще в рамках спринта? Ведь для того, чтобы разработать т.н. дизайн-концепцию, необходимо целостное видение функциональности проекта. И инкрементальный подход (сначала спрограммировали и нарисовали профиль пользователя, затем механизм публикации и т.д.) противоречит основному принципу разработки дизайна — от общего к частному.
После того, как базовая функциональность проекта, достаточная для запуска в эксплуатацию, разработана, вполне можно в рамках спринтов разрабатывать и дорабатывать дизайн отдельных интерфейсов, не выходя за рамки дизайн-концепции или стилевого решения проекта. Но, как спланировать именно разработку стилевого решения в условиях итеративной разработки?
Вот что у меня получилось в теории:
Для наглядности, декомпозиция процесса разработки дизайн-концепции не отображена. Она традиционна.
Таким образом, в закрытой фазе разработки, созданная функциональность отображается в технологических шаблонах, без какого-то ни было оформления. А параллельно, на основе идеи и с учетом промежуточных релизов разрабатываются дизайн-концепция и интерфейсы проекта. В рамках последнего перед публикацией проекта спринта, дизайн и программная часть воссоединяются и предстают перед публикой. Этот торжественный момент отмечен красной линией на схеме.
Но, это теория. Хорошо бы узнать мнение практиков.
И еще немного теории в обзоре методологии Scrum Асхата Уразбаева (500 КБ, .pdf). Очень рекомендую.
