Есть таск/юзерстори с бизнес требованиями, есть декомпозиция на тех. таски с минимально разумным описанием, полученным в ходе плэннинга командой. При необходимости - есть тестовая документация и чек листы на это.

Ничего космического и инновационного.

Пока нет рокет саенса, и тз не нужно

Есть таск/юзерстори с бизнес требованиями, есть декомпозиция на тех. таски с минимально разумным описанием, полученным в ходе плэннинга командой. При необходимости - есть тестовая документация и чек листы на это.

думаю, когда человек говорил "просто нет ТЗ" имел ввиду без вообще любых формальных описаний, требований.

Круды пилить

думаю, когда человек говорил "просто нет ТЗ" имел ввиду без вообще любых формальных описаний, требований.

Ну, чаще всего достаточно описания в формате "есть такая вот проблема, надо решить".

Пока нет рокет саенса, и тз не нужно

Да, в авиастроении тз нужно, согласен

Всем, утра доброго. Вопрос есть. Как доказать начальнику отдела бизнес анализа, разработки, что чем лучше описано ТЗ, а точнее чем детальнее описано ТЗ тем лучше будет разработано, протестировано и меньше будет вопросов к аналитику?

Остается вопрос, как сделать детально описанное ТЗ, если конечный результат большей частью неизвестен.

Может кто-нить может поделится примерами ТЗ?

Может кто-нить может поделится примерами ТЗ?

"сделать красиво"

Ну если у кого-то прямо не супер конфиденциально

"сделать красиво"

Не, так не прокатит

«сделай красиво и чтоб работало»

«сделай красиво и чтоб работало»

доработки ТЗ пошли)

А вообще ТЗ на нашем рынке вещь довольно редкая и местами даже вредная. Как уже описывали выше, вполне достаточно хорошей таски + описания на местном вики

А вот можно пример, когда ТЗ было вредным? Ни разу не сталкивался с таким

Работаю только по ТЗ и ФТ

А вот можно пример, когда ТЗ было вредным? Ни разу не сталкивался с таким

Всегда, когда вотерфолл модель разработки не подходит.

тз бывает не только вредным, по и писец как написанным. Иногда от одного предложения голову сломать можно

мне кажется проблема в людях, которые относятся к ТЗ как к Аксиоме - а не как к вспомогательному инструменту

Лол

Всегда, когда вотерфолл модель разработки не подходит.

Тз, постепенно меняющееся с процессом != отсутствию тз. Или я тебя не правильно понял

Тз, постепенно меняющееся с процессом != отсутствию тз. Или я тебя не правильно понял

Регулярно меняющиеся требования хуже их отсутствия.

если требования регулярно меняются, это значит что Бизнесс не знает чего хочет ) тут проблема уже не в Разработке )

Не согласен. Продукт живет → появляются насущные проблемы → постепенно (!!) меняется ТЗ. Я сейчас не про "переделать все-все"

если требования регулярно меняются, это значит что Бизнесс не знает чего хочет ) тут проблема уже не в Разработке )

Бизнес никогда не знает, чего хочет. Это проблема не В разработке, это проблема ДЛЯ разработки.

если требования регулярно меняются, это значит что Бизнесс не знает чего хочет ) тут проблема уже не в Разработке )

Зависит от скорости разработки. Если разработка успевает сделать требование до его изменения все ОК. Высший пилотаж - сделать до изменения требований так, как они изменятся )

бизнес всегда знает чего хочет, это бабос.

Зависит от скорости разработки. Если разработка успевает сделать требование до его изменения все ОК. Высший пилотаж - сделать до изменения требований так, как они изменятся )

это уже вопрос управления: Всегда есть что-то что можно сделать в указанный срок: При этом придется попустится Качеством, например - или Полнотой реализации

а получение максимальных выгод требует гибкости

другой разговор, что если бизнесс требует в Срок и с Качеством и с Полнотой - а разработка не может объяснить, что все разом не получится и придется где-то сделать допущения: это вопрос управления )

Не согласен. Продукт живет → появляются насущные проблемы → постепенно (!!) меняется ТЗ. Я сейчас не про "переделать все-все"

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

а получение максимальных выгод требует гибкости

мы походу об одном и том же )

все об одном и том же)

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

Мы о разных вещах говорим же. Постоянно меняющиеся требования - плохо. Постепенно меняющиеся требования, которые отображаются в ТЗ - лучше чем отсутствие ТЗ

Мы о разных вещах говорим же. Постоянно меняющиеся требования - плохо. Постепенно меняющиеся требования, которые отображаются в ТЗ - лучше чем отсутствие ТЗ

Постоянно меняющиеся бизнес требования - это нормально.

Техническое задание при таком темпе - пустая трата времени и сил.

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

Ну и ТЗ все же != требования. Требования есть всегда, нужно их только найти)

Техническое задание при таком темпе - пустая трата времени и сил.

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

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

нет, не выстрел. в определенных процессах на ТЗ нет времени

пока ты пишешь свое ТЗ, конкуренты выпустят 2 версии продукта

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

ТЗ примерно противоположно влияет на степень знания о продукте.

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

Необязательно. Доводилось мне работать по чему-то типа канбана с ежедневными релизами. Получили утром от клиента список требований, вечером зарелизили. Работало прекрасно, но, понятное дело, только на том проекте

Т.к. Работа с неявными требованиями подразумевает значительно лучшее понимание и технической и бизнесовой части продукта.

На маленьких проектах, где все понятно, можно жить и без ТЗ. А чем больше и сложнее проект, тем хуже без ТЗ, потому что он банально в голове не помещается, и все начинают путаться

нет, не выстрел. в определенных процессах на ТЗ нет времени

Вы невнимательно читали сообщение. Времени всегда не хватает. вопрос в приоритетах - пока конкуренты выпустили 2 версии продукта вы хоть 5 можете выпустить. Но без ТЗ через время это превратится в кучу говнокода.

При этом ТЗ может быть в любом виде, хоть описание задачи в Джире, хоть отдельный гроссбух на полкило бумаги. Главное, чтобы была возможность по нему проверить

Воот, где написано ТЗ - отдельный вопрос. Таск в джире с требованиями - это тоже вполне себе ТЗ, которое не потеряется.

При этом ТЗ может быть в любом виде, хоть описание задачи в Джире, хоть отдельный гроссбух на полкило бумаги. Главное, чтобы была возможность по нему проверить

Для больших проектов нужны юниты и техническая документация.

Тз все ещё не нужно, если вы не пилите фичи по три месяца.

Тз все ещё не нужно, если вы не пилите фичи по три месяца.

Если вы работаете со сверхчеловеками с идеальной памятью и коммуникациями

Если вы работаете со сверхчеловеками с идеальной памятью и коммуникациями

Еще раз, зачем тебе сверхидеальная память при отсутствии тз?

Тз все ещё не нужно, если вы не пилите фичи по три месяца.

А в каком тогда виде приходят требования? Просто интересно

У тебя есть задача, у которой срок реализации неделя, декомпозированная до тасок со сроком реализации до одного дня.

Вбегает менеджер/тех.лид/заказчик и орёт на офис "Ребята, надо переписать авторизацию!" И все кидаются переписывать?

Есть документация по проекту.

На кой тебе там тз?

У тебя есть задача, у которой срок реализации неделя, декомпозированная до тасок со сроком реализации до одного дня.

Ну вот это и будет ТЗ в виде задач и тасок

Ну вот это и будет ТЗ в виде задач и тасок

Окей, если у вас юзерстори - это тз, то снимаю шляпу.

Ну вот это и будет ТЗ в виде задач и тасок

быстро на ходу переобулся, одобряю

быстро на ходу переобулся, одобряю

Переобулся? Я выше писал: "При этом ТЗ может быть в любом виде, хоть описание задачи в Джире, хоть отдельный гроссбух на полкило бумаги. Главное, чтобы была возможность по нему проверить"

Это правда не техническое и не задание, т.к. Не содержит описания и способов реализации функционала, а только проблему, которую нужно решить, но пусть будет ТЗ.

Если вы понимаете ТЗ в строгом смысле как отдельный формальный артефакт с подписями и прочим, то это уже другой разговор

Вбегает менеджер/тех.лид/заказчик и орёт на офис "Ребята, надо переписать авторизацию!" И все кидаются переписывать?

Погуглите формирование бэклога, планирование спринта и всякое такое.

ERROR: S client not available

Если вы понимаете ТЗ в строгом смысле как отдельный формальный артефакт с подписями и прочим, то это уже другой разговор

ТЗ это техническое задание.

а как ТЗ еще понимать? ТЗ это ТЗ :)

Оно обладает рядом признаков.

юзерсторя не ТЗ

Как минимум, содержит конкретный технический способ реализации функциональности.

Я крайне не рекомендую включать детали реализации в ТЗ, которое за подписями (ГОСТ 34.602), для сколько нибудь сложных систем. Не включайте туда юзкейсы.

Так и запишем: Сергей Мартыненко не рекомендует

Объяснение тут: https://www.youtube.com/watch?v=zVtTrXcHH2M&t=478s

30 мин.

(нашей жизни)

(С плохим звуком)

(И так себе дикцией)

А слайды есть?

Чтобы 5 минут?

И с фокусом на идею, а не лектора?

Что делать. Не сдудия. Из слайдов не понять ничего.

Тогда это плохая идея

вон же идея

Если не нужны аргументы, то ради бога.

"не рекомендую включать детали реализации в ТЗ"

Не надо выдирать фразу из контекста.

Смысл меняется.

что то у Вас лого клиентов обрезает

(С плохим звуком)

нормально всё слышно

а эти компании - чьи это клиенты?

Ну, Влада балина почитайте. "Документация неуловимый Джо"

а эти компании - чьи это клиенты?

Ну судя по всему Сергея Мартыненко и\или его партнеров.

Интересно, что они делают для Варгейминг.

Вот тоже здорово