Назим А.
116 сообщений
#16 лет назад
Собственно сабж, собираюсь реализовать довольно крупный проект, как думаете надо ли писать ТЗ для самого себя? =) Или не обязательно тратить на это время?
Станислав Малкин
1410 сообщений
#16 лет назад
ans-templates, конечно. Это позволит вам структурировать свои же мысли и зайти на шаг вперед и увидеть возможные проблемы до того, как начнете что-то делать и упретесь лбом в бетонную стену.
Виктор Брылев
226 сообщений
#16 лет назад
ans-templates, смотря как вы работаете. Если по-старинке (waterfall), то документация нужна. Если agile - можете не создавать.
Константин Т.
589 сообщений
#16 лет назад
Есть примеры крупных проектов, созданных как agile ?
Станислав Малкин
1410 сообщений
#16 лет назад
Pilat66, нет и не будет. При условии, что этим занималась большая команда. В большой команде принципы agile почти не действуют. С удаленщиками тоже самое. Поэтому приличные крупные проекты при agile возможны, но их нужно адаптировать и это уже немного не agile выходит.
Константин Т.
589 сообщений
#16 лет назад
Вот и мне это кажется...

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

Конечно, понятие большого проекта у каждого своё...
Виктор Брылев
226 сообщений
#16 лет назад
О какой большой команде, отсутствии ясности и удаленности идет речь в контексте вопроса автора топика? :-)
Вадим Т.
3240 сообщений
#16 лет назад
Agile придумали не от хорошей жизни. Прежде всего применяется этот метод, кстати и на крупных проектах тоже, когда нет четкой исходной постановки задачи. При этом исполнитель делает минимально достаточное количество действий, направленных на решение того, что ему известно по задаче. Когда приходят новое требование, он перескакивает на него, вплоть до полного рефакторинга кода (при этом могут строиться новые модели, обновляются все артефакты - код, проектная документация, и т.д.)...

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

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

У нас тут в Харькове есть целые конторы, которые работают исключительно по Agile, рекламируют эту методологию, и от кандидатов на работу на собеседованиях требуют понимания и опыта работы по Agile, и т.д.
Вадим Т.
3240 сообщений
#16 лет назад
Подытожу.

Для толстых заказчиков, которые платят по T&M, и которые принимают сами живое участие в проекте - Agile отлично подходит.
Для своих собственных проектов - Agile подходит вообще идеально.

А вот для проектов по Fixed Price, то есть для которых бюджет или лимит бюджета определен заранее (таких проектов на фрилансе подавляющее большинство), Agile не подходит.
Вадим Т.
3240 сообщений
#16 лет назад
ans-templates, я писал сам для себя ТЗ в нескольких своих проектах. Потом впоследствии понял, что, хоть делал и без красивого оформления, как это делаю заказчикам, а под себя, но все равно зря потерял немало времени. Лучше бы сразу заранее написал руководство пользователя и хелп к разрабатываемому проекту, и использовал бы это в качестве замены ТЗ.
Николай М.
1895 сообщений
#16 лет назад


Я обычно на листике пишу основные моменты и другой всяческий бред, память итак не резиновая. Если будете привлекать посторонних людей, то нужно конечно ТЗ. Вот щас на столе пылиться набросок своего сайта, жаль ПХП меня огорчил, посему все забросил нафик
Прикол в том, что ТЗ для себя - невостребовано, вот я делаю так, то что для себя, ну для заказчиков конечно покрасивее, но убивать время просто так нет смысла.
Константин Т.
589 сообщений
#16 лет назад
Мне кажется, что какой-то план работ должен быть. Сколько я ни писал без плана для себя, каждый раз приходилось многое переделывать.
Дмитрий К.
137 сообщений
#16 лет назад
Pilat66, поддерживаю. В случае с сайтом хотя бы разделы этого сайта должны быть указаны. Но в случае если другие люди тоже будут учавствовать ТЗ обязательно, сам убедился, когда мне понадобились доработки движка моего проекта, и пришлось строчить в ICQ что да как.
Назим А.
116 сообщений
#16 лет назад
Большое спасибо всем за полезные советы!
Вадим С.
18 сообщений
#16 лет назад
Оффтопик
Цитата ("MMM_Corp"):
Вот щас на столе пылиться набросок своего сайта, жаль ПХП меня огорчил, посему все забросил нафик

Обидели мышку, написяли в норку? 8)
Олег Г.
45 сообщений
#16 лет назад
Цитата ("tvv"):
ans-templates, я писал сам для себя ТЗ в нескольких своих проектах. Потом впоследствии понял, что, хоть делал и без красивого оформления, как это делаю заказчикам, а под себя, но все равно зря потерял немало времени. Лучше бы сразу заранее написал руководство пользователя и хелп к разрабатываемому проекту, и использовал бы это в качестве замены ТЗ.


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


Вы знаете как будет работать проект, какие технологоие и методы используются для функционирования системы? Опишите их. Досконально. Как можно подробнее. Чтобы система превратилась в единый рабочий организм, который выполняет необходимую функциональность, иначе при разработке столкнётесь с непредвидимыми обстоятельствами, которые не так просто сможете решить.