В современной разработке принято скептически относиться к насл | Господин Архитектор

В современной разработке принято скептически относиться к наследию прошлого. Это касается и знаменитого "ГОСТ 34". Знатоки амазона и специалисты по кубернетесам уверены, что это устарело, не нужно, да и вообще олицетворяет все самое плохое, что ассоциируется со словом "водопадная модель разработки". Хочу в нескольких важных пунктах описать, что такое ТЗ по ГОСТ 34.602-89, и почему он никак не устарел.

1. Начнем с заголовка. ГОСТ 34 звучит так: "Техническое задание на создание автоматизированной системы". Это не спецификация на систему (SRS, требования к ПО), а спецификация на процесс ее создания. То есть в этом документе описывается не столько система, сколько весь development lifecycle, связанный с конструированием и запуском. И согласно этому, там есть место для:
- замысла системы
- решаемых проблем
- оснований для создания системы: кто заинтересован, кто платит, как проверить, что сделали то, что нужно
- план выполнения работ: конструирование, пилотирование, сопровождение, и стоимость работ.

Если вы не можете перед началом работ описать проблемы, которые собираетесь решить, и как проверить, что результаты достигнуты, то дело, вероятно, совсем не в ГОСТе.

2. Если внимательно почитать сам стандарт, то в п. 2.2 можно найти замечательное (неточная цитата) "по согласованию сторон, допустимо переименовывать разделы, объединять, вводить новые и опускать неактуальные". Ну вы поняли, да? :) Можно оставить только нужные вам разделы, и это все равно по духу останется ГОСТом.

3. Поклонников Agile пугает пункт о плане: как можно предположить план, начиная разработку, ведь по канону план каждой итерации должен составляться по окончании предыдущей, и никто не знает, что будет делаться дальше, рынок покажет? И на это есть ответ. В плане пишем короткое и понятное: "в соответствии с ведомостью исполнения работ". Всё, работаем, ведомость заполняем из вашей скрам-тикетницы.

4. Что насчет требований, документации? Многие мыслят ТЗ в ГОСТ 34 как огромный талмуд с требованиями, а какие в Agile предварительные требования? И это легко решается. Вместе с замыслом работ у вас есть описание, что хочется получить, в конструктивной форме. Нарезаете его на сценарии, запускаете в разработку. Из этих сценариев, кстати, составляется документ "Программа и методика испытаний" для сдачи - пожалуй, единственный обязательный документ стандарта. Процесс сдачи это кумулятивное демо, а к демо в скраме относятся крайне благосклонно.
Остальная документация носит рекомендательный характер, можете ее писать, или не писать, можно в вики, можно в тикетах, где угодно.

—

В общем, оригинальная задумка ТЗ по ГОСТ 34 это не про требования. Это про то, как управлять разработкой, причем так, чтобы каждый инженер проекта смог внести максимальный вклад.