Основная задача ТЗ в программном проекте - не фиксация объема работ, не защита от переработки, не инструмент "заморозки" требований. Нет, это просто возможность заказчику(пусть зачастую и при помощи разработчиков) подумать над тем, что он вообще хочет.
Можно конечно сделать проект "самостоятельно" и сдавать его итеративно, но, как показывает практика, в этом случае думать над ним заказчик начнет как раз в момент сдачи. И запросто окажется, что "когда я говорил мне нужен дом - я имел ввиду вышку аэропорта".
Другими словами ТЗ - это "рыба" проекта, которую можно делать сразу, просто и очень дешево менять. А письменный он должен быть потому, что иначе мозг может и не включиться. П%;:ть, как грится, не мешки ворочать.
PS термин "техническое задание" спорный, но выбран как самый простой, для обобщения
PPS да, agile конечно штука, но не каждый заказчик готов по нему работать
UPD: мысль оказалась далеко не новой - Джоэль о том же пишет.
4 комментария:
Мдя. По поводу ТЗ, ты конечно, прав. А вот по поводу agile так, и хочется закричать: "О, великий agile, яви мне, простому смертному, в каком из проектов ты вообще применяешься? Кроме "библий" методологий..."
На одной из презентаций один из архитекторов Dimension'а сказал о таких проектах - slideware, то есть такие проекты, которые существуют только в виде слайдов презентаций :)
А в любом проекте. Аджайл, по сути, сборник мелких разумных вещей, которые так или иначе применяются всеми :)
Ага.
Так и запишем - здравый смысл = agile.
А чо? Ярко, гламурно и нихто все-равно не рубит в этом :))))))))))
:))))))))))
Уел :-D
Но в живую еще как-нить поспорим :))
Отправить комментарий