"Простая последовательность действий" (vs. "методология") разработки Интернет Проектов

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

На досуге решил не примере одного простенького сайта (того самого который я буду пробовать реализовывать в том числе и на PHP) попробовать отработать "Простую последовательность действий" (в противовес громоздкому слову "методология"):

1. Опишите требования - по одному абзацу (или даже строчке) на требование.
2. Сформулируйте "срез" первой версии (feature fix) исходя из имеющихся средств и времени.
3. Создайте статические макеты всех страниц (это крайне важно ибо позволяет оценить все ли продумано).
4. Опишите все структуры данных (и возможно подправьте макеты).
5. Только теперь можно начать программировать (после пункта 3 и 4 это будет просто и быстро и вы не пожалеете времени потраченного на 3 и 4).
6. Приделайте недостающий дизайн (основную usability необходимо продумать на 3-м этапе).

Еще раз повторюсь - все это подразумевает простой и типичный интернет-проект (именно такие чаще всего изготовляются при помощи PHP).

Я почти уверен что мало кто из присутствующих здесь делает именно так, но мне кажется что это должно работать ибо в отличие от крупных проектов, для мелких за время производства врядли поменяются требования к системе (что очень часто если не сказать всегда портит нормальную разработку), а также простой проект всегда можно "охватить одним взглядом", так что более подробное документирование и сложное проектирование чрезмерны.

Что вы по этому поводу думаете? Пропустил ли я что-нибудь существенное?

Прекрасная схема. Вроде бы ничего не упущено. Что касается описания структур данных заранее, то это сработает только для небольших сайтов (я бы сказал, микросайтов). Для чего-то поболее удастся сформулировать лишь основные структуры, но не все (так же, как не получается с первого раза придать сайту нужный дизайн и юзабилити, пвсегда потом приходится что-то подправлять).

Дмитрий Котеров:
На самом деле, как показывает практика если все макеты сделаны и продуманы (обсуждены с заказчиком), то сделать по этому схему (структуру БД) можно на все 100%, просто об этом нужно задуматься, а не просто набросать. Это же касается и дизайна с юзабилити - дорабатывать разве что нужно будет только графические элементы.
Все это, естественно, подразумевает, что первые 4-е пункта делают профессионалы способные "охватить одним взглядом" проект целиком.

Не совсем ясно, когда продумывается дизайн (в смысле структура сайта, тип навигации, общая концепция)? В п. 6 недостающие вещи "приделываются", а вот когда появляются то, к чему оно приделывается? Dо время п.3.?

Сергей, а может Вы как автор методики (ой, сорри, последовательности действий) распишите роли, которые должны эти действия выполнять (т.н. матрица ответственности)? Тогда бы понятнее стало – помимо того «что» и «как» делается, нужно знать еще и «кем» (а также, «когда», но в данном случае это не важно).

Сергей Чернышев AKA Drouk S. ;):
Реально, на больших проектах схема несколько изменяется.
пп1,2 - остаются.
следующим этапом начинается параллельное выполнение п5 (тесно связанного с п4, который все равно корректируется в процессе разработки) и п3-6.
Когда дизайн готов и утвержден - правятся шаблоны, разработанные и использованные в п.5 и процесс продолжается.

Евгений Бондарев aka Eugene Bond:

В больших проектах вообще "водопад" не применим, а Сергей описал именно водопадный, последовательный процесс. То, что написали Вы "... начинается параллельная..." уже не последовательность действий, точнее не линейная последовательность, пошла итеративность, пошли изменения требований в процессе...

z...:
Дизайн в смысле структуры, навигации и концепкии это все на этапе 3. Думаю это вполне реально так как мы делаем именно простой проект и можем все "обозрить" достаточно легко.

Роли. Ну, тут все сложно - я бы сказал что требуются даже более опытные (это не значит что более квалифицированные) проектировщики, тоесть люди которые смогут "обозрить" (что достигается исключительно опытом).

В принципе, первые 4-ре пункта должен по крайней мере сопровождать один человек (назовем его "руководитель проекта") так как не ведется серьезной документации, но есть необходимость "видеть" весь проект целиком, что, естественно легче сделать одной головой, особенно когда мы говорим о простом/небольшом проекте.

Пункт 1. должен делаться этим самым "руководителем" при общении с заказчиком.

Пункт 2. может делаться им, но скорее всего также должны участвовать и представители заказчика (так как нужно расставить приоритеты и установить сроки) и те, кто знает примерную нагрузку на команду в ближайшее время дабы оценить внутренние ресурсы.

Пункт 3. тут, как мне кажется, должны сидеть за одним монитором "руководитель", "дизайнер юзабилити" и "верстальщик"

Пункт 4. вместе с "руководителем" должен работать "архитектор БД" и "кодер(ы)" (лучше один кодер, что реально ибо проект простой и на него редко выделяют несколько человек, опять же несколько человек требуют коммуникации, а по Бруксу мы знаем, что это увеличивает время производства)

Пункт 5. "кодер" - никто больше на этом этапе не участвует (возможно если верстка не была заранее нарезана на блоки для кодинга, то тогда еще и верстальщик). Разве что "кодер" должен иногда спрашивать "руководителя" что к чему и возможно проводить промежуточные тестирования.

Пункт 6. "верстальщик" + "дизайнер графики".

В принципе, все это рассчитано на маленькую команду где зачастую все эти роли сводятся к 3-4м, а то и 1-2м людям, но думаю, что небольшое увеличение команды тоже возможно.

Сергей Чернышев AKA Drouk S. ;):
Я бы в п.4 уточнил, что в любом случае 1 кодер. либо единственный, либо ведущий.

Евгений Бондарев aka Eugene Bond:
Не уверен, что один кодер среди нескольких должен быть ведущим - возможно 2-3 равноправных кодера - тут вопрос не стоит о их разной квалификации (для "ведущести" есть "руководитель") - стоит вопрос только в распараллеливании задач за счет одновременного кодирования разных частей сайта.

Сергей Чернышев AKA Drouk S. ;):
Тут получается так, что руководитель занимающийся и дизайном с дизайнерами, и постановкой задачи с программистами, и проектированием с аналитиками, просто физически не может быть последней инстанцией. Поэтому, в основном у кодеров, появляются ведущие...

Евгений Бондарев aka Eugene Bond:
Вот это как раз спорный вопрос ибо огромное кол-во комманд держатся именно на таких вот "ведущих". Он, не всегда истина в последней инстанции, но он ведет разработку и достаточно хорошо в ней разбирается.

Возможно я ошибаюсь, но я вижу себя на этом месте (не очень скромно ;)) и мне кажется что таких как я достаточно много.

Сергей Чернышев AKA Drouk S. ;):
Главное, чтобы их было не больше, чем "ведущих" ;)
А вот то, что он ведет разработку - это да. И именно от его (в большей степени, чем от ведущих) профессионализма зависит судьба проекта.

Евгений Бондарев aka Eugene Bond:
Да, в таком проекте это допустимо ибо сроки маленькие, капиталовложения и цены, соответственно тоже.