Комментарии 5
Ну, то есть, никакого аджайла. Старый-добрый предиктивный подход, исследуем, пишем ТЗ, разрабатываем.
мне кажется это совсем разные вещи.
Вполне себе можно написать в ТЗ - создаём начальный макет за примерно такой то срок таким то примерно спринтом. Потом делаем от M до N количество недельных итерраций, из которых к итерраций могут быть направлены на такое то свойство Продукта, в j на такое-то. Более того, описав в ТЗ Более плотно требования - можно даже выбрать сразу задания на большие спринты, чтобы было из чего выбирать команде разработчиков.
Грамотно составленное ТЗ абсолютно не противоречит Agile подходу. Во всем нужен баланс. Да, работающий продукт важнее скрупулезно подготовленной документации, но, согласитесь, вы не можете работать над масштабным проектом, не имея вообще никакого плана.
Здесь речь идет о ТЗ не как о пошаговой инструкции, а как о некой канве проекта, которая одинаково важна и разработчикам, и заказчику.
Клиент видит, за что он платит деньги, когда и на каком этапе будут промежуточные результаты. Плюс здесь же он документирует свои видения и пожелания.
Разработчикам нужно ТЗ, чтобы собрать воедино как видение заказчика, так и соображения своих хардовых/софтовых команд. По итогу все может сильно отличаться от намеченного (и, скорее всего, так и будет), но без ТЗ как стартовой точки, не обойтись.
Понятно, что если проект типовой, из разряда “делали такое сто раз”, то расписывать все нет смысла. Но вот если клиент пришел с супер идеей (“хочу, чтоб девайс плавал, летал и крестиком вышивал”), то уж тут никак без ТЗ.
Какая же у вас антиреклама получилась - если у вас такая каша в Кедре, то как-то хочется обойти стороной. Смешались в кучу кони, люди - договора, исходные тех. требования, ТЗ, дорожные карты, спецификации.
В ТЗ очерчиваются примерные сроки исполнения заказа.
Сроки ВСЕГДА в договоре или приложению к договору. Максимум, если проект долгий, составляется дорожная карта с основными этапами. Какое отношение сроки имеют к техническому документу?
спецификации – документа, где будут зафиксированы требования к разрабатываемому решению, порядок работ, используемые компоненты и т.д.
Долго не мог понять откуда такая дичь пока в википедию не заглянул - там все это перечислено в контексте разных документов, процессов и этапов, а вы тут долбанули все в оду кучу.
Статью писала нейронка
Статья не соответствует времени: в 2023 году уже почти ни у кого не должно вызывать вопрос "Что такое и для чего нужно ТЗ?". Другое дело, что в современных реалиях разработки ПО ТЗ стало почти исключительно формальным документом, приложением к договору, но никак не спецификацией требований, которой может воспользоваться команда разработки. В общем, я к тому, что такие статьи периодически всплывают на Хабре, но не вызывают ничего, кроме удивления.
Техническое задание: как и зачем его писать, и почему без него не обойтись