Нужно ли ТЗ для собственного сайта?
116 повідомлень
#17 років тому
Собственно сабж, собираюсь реализовать довольно крупный проект, как думаете надо ли писать ТЗ для самого себя? =) Или не обязательно тратить на это время?
1410 повідомлень
#17 років тому
ans-templates, конечно. Это позволит вам структурировать свои же мысли и зайти на шаг вперед и увидеть возможные проблемы до того, как начнете что-то делать и упретесь лбом в бетонную стену.
226 повідомлень
#17 років тому
ans-templates, смотря как вы работаете. Если по-старинке (waterfall), то документация нужна. Если agile - можете не создавать.
1410 повідомлень
#17 років тому
Pilat66, нет и не будет. При условии, что этим занималась большая команда. В большой команде принципы agile почти не действуют. С удаленщиками тоже самое. Поэтому приличные крупные проекты при agile возможны, но их нужно адаптировать и это уже немного не agile выходит.
589 повідомлень
#17 років тому
Вот и мне это кажется...На самом деле, такой проект я сам веду - чистый agile и довольно большой . Причина - отсутствие ясности, что надо сделать, так как информация поступала постепенно, кусочками. Недостаток - исходная модель неправильная, и проблемы с расширяемостью. Теперь переписываем заново.
Конечно, понятие большого проекта у каждого своё...
226 повідомлень
#17 років тому
О какой большой команде, отсутствии ясности и удаленности идет речь в контексте вопроса автора топика? :-)
3240 повідомлень
#17 років тому
Agile придумали не от хорошей жизни. Прежде всего применяется этот метод, кстати и на крупных проектах тоже, когда нет четкой исходной постановки задачи. При этом исполнитель делает минимально достаточное количество действий, направленных на решение того, что ему известно по задаче. Когда приходят новое требование, он перескакивает на него, вплоть до полного рефакторинга кода (при этом могут строиться новые модели, обновляются все артефакты - код, проектная документация, и т.д.)...По сути дела, методология Agile в работе выглядит, будто бы как за спиной дизайнера стоит заказчик, который говорит ему где какую линию провести или каким цветом что закрасить. Дизайнер это делает, попутно фиксируя свои действия и обновляя документы, если они есть. Я утрирую конечно, но сводится именно к такому подходу. Исполнителям это выгодно, хоть и морально тяжело (прессинг, напряг). Выгодно - так как заказчик оплачивает человеко-часы, включая потраченные на его же ошибочные требования, за которые он же берет на себя ответственность...
Ну что я скажу, если заказчик сам не знает что он хочет, но имеет толстый бюджет, оплачивая месяцами работу команды, которая исполняет его хотелки (в том числе противоречащие друг другу), тогда Aglie - лучший выбор.
У нас тут в Харькове есть целые конторы, которые работают исключительно по Agile, рекламируют эту методологию, и от кандидатов на работу на собеседованиях требуют понимания и опыта работы по Agile, и т.д.
3240 повідомлень
#17 років тому
Подытожу.Для толстых заказчиков, которые платят по T&M, и которые принимают сами живое участие в проекте - Agile отлично подходит.
Для своих собственных проектов - Agile подходит вообще идеально.
А вот для проектов по Fixed Price, то есть для которых бюджет или лимит бюджета определен заранее (таких проектов на фрилансе подавляющее большинство), Agile не подходит.
3240 повідомлень
#17 років тому
ans-templates, я писал сам для себя ТЗ в нескольких своих проектах. Потом впоследствии понял, что, хоть делал и без красивого оформления, как это делаю заказчикам, а под себя, но все равно зря потерял немало времени. Лучше бы сразу заранее написал руководство пользователя и хелп к разрабатываемому проекту, и использовал бы это в качестве замены ТЗ.
1895 повідомлень
#17 років тому

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

Прикол в том, что ТЗ для себя - невостребовано, вот я делаю так, то что для себя, ну для заказчиков конечно покрасивее, но убивать время просто так нет смысла.
589 повідомлень
#17 років тому
Мне кажется, что какой-то план работ должен быть. Сколько я ни писал без плана для себя, каждый раз приходилось многое переделывать.
137 повідомлень
#17 років тому
Pilat66, поддерживаю. В случае с сайтом хотя бы разделы этого сайта должны быть указаны. Но в случае если другие люди тоже будут учавствовать ТЗ обязательно, сам убедился, когда мне понадобились доработки движка моего проекта, и пришлось строчить в ICQ что да как.
116 повідомлень
#17 років тому
Большое спасибо всем за полезные советы!
18 повідомлень
45 повідомлень
#17 років тому
Цитата ("tvv"):ans-templates, я писал сам для себя ТЗ в нескольких своих проектах. Потом впоследствии понял, что, хоть делал и без красивого оформления, как это делаю заказчикам, а под себя, но все равно зря потерял немало времени. Лучше бы сразу заранее написал руководство пользователя и хелп к разрабатываемому проекту, и использовал бы это в качестве замены ТЗ.
Если в ТЗ описывать всё состояние системы, вплоть до методов и методике её поведения, вы получите довольно хорошую документацию.

45 повідомлень
#17 років тому
Цитата ("ans-templates"):Собственно сабж, собираюсь реализовать довольно крупный проект, как думаете надо ли писать ТЗ для самого себя? =) Или не обязательно тратить на это время?
Вы знаете как будет работать проект, какие технологоие и методы используются для функционирования системы? Опишите их. Досконально. Как можно подробнее. Чтобы система превратилась в единый рабочий организм, который выполняет необходимую функциональность, иначе при разработке столкнётесь с непредвидимыми обстоятельствами, которые не так просто сможете решить.