А зачем вообще что-то проектировать?

[Simply-Art]

Здравствуйте. Хочу подискутировать на тему создание проектов в программировании. Раньше, я как студент, создавал простые программы, не нуждающиеся в особом составлении проекта, всё было в голове. Позже я устроился на работу программистом. И только тут, работая с базами данных, со множеством выходных/входных форм, я понял, что неплохо бы это все структурировать, расписать "проект". А то через годик уже и не вспомню, откуда у отчета ноги растут. Конечно это не совсем так должно было быть, вроде сначала проект, а потом уже делаем все, но именно тогда я задумался об этом в первый раз.
А вы составляли проекты для написания своих программ и какой опыт получился?

[Alex11223]

Это в этот раздел наверно http://programmersforum.ru/forumdisplay.php?f=50
А тут видимо про всякие CAD'ы.

[Stilet]

А вы составляли проекты для написания своих программ и какой опыт получился?

Я нет, и не планирую. Буду работать в команде - скорее всего планировка проекта будет обязательна.

[Illusiony]

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

[Vapaamies]

Вот я завтра или в субботу буду на Livecoding.tv развитие своей библиотеки обсуждать, если будет с кем. Как раз проектирование. Никто не придет -- одному кумекать придется.

[rrrFer]

Я даже простые проекты всегда проектировал. Как иначе то? Ну а если вы работаете в команде, то как без проектирования (хоть в каком то виде) вы распределите работу и обеспечите ее параллельное выполнение?

Если вы будете разрабатывать проект по ГОСТ (в чем я сомневаюсь, но допустим), то будете использовать водопадную модель. При этом проектирование идет первым этапом и является самым важным, т.к. ошибки в нем будут фатальны.

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

Например, в Scrum выделяют нулевой спринт, на котором:
- формируется видение проекта;
- начальный список историй (задач) и эпиков (стратегических задач).
Но это ведь и есть проектирование?

Ну а затем, все в том же скраме проектирование в каком-то виде проводится на планировании спринта. Т.е. проектируется не весь продукт, а лишь часть функционала, выполняемая за спринт.

[Vapaamies]

Сообщение от rrrFer

Например, в Scrum выделяют нулевой спринт, на котором:
- формируется видение проекта;
- начальный список историй (задач) и эпиков (стратегических задач).
[...]
проектируется не весь продукт, а лишь часть функционала, выполняемая за спринт.

Ну вот, у меня в проекте так. Выходит, у меня аджайл и скрам? Ёкарный бабай!

[rrrFer]

Ну вот, у меня в проекте так. Выходит, у меня аджайл и скрам? Ёкарный бабай!

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

То, таки да, ты применяешь scrum.

[Gorychev]

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

[Vapaamies]

Сообщение от rrrFer

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

Практически все пункты есть, но в сильно упрощенном виде, поскольку работаю один, сам себе начальник, и коллег пока не предвидится.

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