Как стать автором
Обновить

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

Backlog > Sprint Planning > Development > Sprint Demo > Feedback > Sprint Planning > Development > Sprint Demo >… > Release
С таким подходом эффективно и удобно работать с одним проектом, в студии обычно их намного больше и собираться по каждому из мелких этапов всю команду разработки может оказаться убыточно.
Собираться должна группа людей, непосредственно занятых в разработке + менеджмент (весь или отдельные делегаты). Если одни и те же разрабы работают сразу над несколькими проектами, то что-то здесь не так, на мой взгляд.
Даже Project Coordinator'у одному более чем на три проекта шариться сложно / рисковано / бестолково.
PS: в принципе на демо разрабов может даже не быть всех. Лид и ПМ достаточно может оказаться.
Обычный подход похож на вотерфолл, а вы заново изобрели agile похоже. Быстрое прототипирование, вместо тонн документации, быстрый релиз прототипа и обсуждение изменений с заказчиком и т.д., все эти принципы уже озвучены были лет 5 назад.
Я, наверное, плохо описал. Дело больше не в быстром прототипировании, а скорее в начале разработке сразу после прототипа, без ожидания пока будут согласованы и сверстаны дизайн-макеты.
А раньше вся команда ждала дизайнеров… вот это крайне странно. Очевидно, что есть вещи, которые не зависят от дизайна — модель данных, настройки окружения, сервера и сделать скелет сайта действительно можно без дизайнеров на основе бизнес логики. То есть в чем ваше новшество или прорыв в технологии сайтостроения не очень понятно. Может быть цифры подкинули бы какие то, раньше это занимало X часов, сейчас Y, эффективность разработки возросла на Z %.
При последовательном подходе, согласование макетов нужно для утверждения структуры сайта и выявление всех необходимых деталей. На практике, в процессе согласования, появляется много разных нюансов, которые значительно влияют на разработку. В техническом задании всего не учтешь и, как я и писал в заметке, все его понимают по разному, а клиент часто вообще не читает. Мы стараемся сделать максимально нужный продукт клиенту и не упираемся в буквы договора, а пытаемся простроить процесс так, чтобы малой кровью добиться лучшего результата. Поэтому делаем прототип, по которому и начинается параллельная работа, другого способа на данный момент я не вижу.

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

Цифры по времени разработки не очень верная метрика (как бы удивительно это не было), так как они во многом зависят от клиента, но вся разработка без согласований и занесением контента укладывается в цикл от 4 до 6 недель.
Расскажите еще как у вас получается по срокам (допустим, интернет-магазин)? Какой состав команды?
Интернет-магазин интернет-магазину рознь :) Мы стараемся уложить первый цикл разработки в 4-6 недель. Если клиент приходит с чем-то большим и сложным, то бьем задачу на этапы. В пример с интернет-магазином, плотную интеграцию с системой учета (бронирование заказов в самой системе) и хитрый расчет доставки можем вынести в отдельный этап.

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

Команда состоит из проектировщика-руководителя проекта, дизайнера, иллюстратора, программиста и технолога. Если мы сами заносим контент на сайт, то дополняется контент-менеджером.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории