как уже ранее писал - с т.з. создания именно модели требований - попробуйте Archimate / Archi. В т.ч. вот неплохой в принципе пример использования в статье с Хабра: https://habr.com/ru/companies/axenix/articles/1038916/
Это понятно. Только в том-то и смысл ТЗ, что версионируется набор - в рамках которого есть тоже итерации по каждому требованию. Просто реализовывать можно в конкретный момент времени только конкретную версию ТЗ. Иначе это не ТЗ, а реально просто гибкая разработка с беклогом... И ТЗ тогда сжимается до ЧТЗ под каждую конкретную задачу. А разработка в целом происходит эволюционным путем - методом проб и ошибок и др - без попыток охватить картину в целом.
В общем ведение пунктов ТЗ в виде задач - идея не новая, но достаточно костыльная - особенно в случаях, когда есть нефункциональные требования и, фактически, во всех задачах они будут превращаться в чек-лист того, что нужно проверить / учесть разработчику при реализации конкретной фичи.
Ну и ТЗ - это в т.ч. первичное описание целевой архитектуры - хотя бы требований к ней...
ЗЫ: и если уж совсем быть строгими - после ТЗ идет техпроект, техпаспорт и т.п. Но это для систем, которые внедряются в критичный прод - например, связанный с производством, ТЭК и т.п., где цена ошибки/просчета слишком высока, чтобы работать без предварительного ТЗ и понимания критериев приемки работы.
С технологиями уходит рутина и остается творчество.
Это показывают и примеры новостей с так называемыми "открытиями ИИ". По факту там речь идет о том, что ИИ перебирал все возможные варианты, что ест-но человек сделать не может с такой же скоростью (пример - Мендеелеев перепробовал кучу вариантов в течении длительного времени, пока ему не "приснилась" итоговая таблица элементов).
Узким местом становится уже человек, который должен успевать обрабатывать те результаты, которые выдает ему ИИ и принимать решение - классический пример - кодревью кода ИИ. Иначе у нас все превратится в ваб-ливинг - когда все делает ИИ - и работает, и принимает работы... и живет :). и тогда "скрипач не нужен". И возникает вопрос - а нужен ли тогда ИИ?
Тут еще вторая западня - прогресс ИИ будет влечь за собой регресс людей. И в итоге остается опасность самоопыления ИИ с постепенной деградацией - уже и ИИ и людей... как говорится "будешь как Великий Нехочуха". Но, думаю появятся люди, которые уйдут в Зеон и будут делать все "руками", думать сами, читать книги и др.
Как не убил ширпотреб штучного производства в XIX веке. Да, луддиты побастовали - но мир не остановился. Просто оставшиеся мастера стали цениться выше и доступны узкому кругу.
Только если бы все было так просто - при чтении аналитических отчетов от ИИ не возникало бы каждый раз ощущение общения со смоляным чучелком.
Ключевое, что отличает человека - это не только явные знания, но и опыт, воспоминания, ощущения - все, что связано с физическим миром. Не даром "мысль изреченная - есть ложь" - внутренний мир (неявные знания) человека намного богаче и сложнее, чем он может это описать. И пока все неявные знания не будут переведены в явные - ИИ будет уступать. Это как с "отвернувшимися" у Лю Цисиня в "Темном лесе".
ИИ сможет приблизиться к человеку, когда он получить возможность полноценной физической жизни, с полным спектром переживаний... Вопрос только - нужен ли нам такой гомункул ? А с т.з. экспериментов - да, если дать ИИ самому проводить физические эксперименты - он сможет методом подбора найти новые составы веществ, технологии производства и др... правда есть при этом вероятность, что он "сожрет" кучу материи на неудачные опыты... как сейчас сжигает кучу энергии на неудачные генерации и нейрослопы. И, к слову, пока что даже в программировании, ИИ не может полностью самостоятельно дать себе обратную связь и сыграть за всю команду разработки, сам провести нужные эксперименты и др - все равно пока требуется наличие того, кто первично отстраивает систему.
Я бы воспринимал ИИ как очень активного студента, который прочитал кучу книг и впитал в себя все теоретические знания. Чем он отличается от студента - студент такой объем забудет сразу после сессии - потому что нет подкрепления. А ИИ запомнит все - и полезное, и бесполезное - но без эмоционально, механистически. А человек запоминает только через практику, через применение знаний в своих действиях - причем. желательно. в ближайшие несколько суток.
ну, тогда вот и получится, что одно и то же требование как задача в Jira будет висеть все релизы незакрытая.... в общем это все попытка натянуть трекер задач на RMS, хотя при этом от таск-трекера вообще берется по факту то, что он содержит в себе БД :-)
ЗЫ: вот про 1С обидно было... :-) пусть в меня кинут камень, но уровень большинства программистов 1С мне с трудом позволяет назвать их ИТ-специалистами/программистами/проектировщиками... Очень редко на рынке 1С-разработчиков встречаются грамотные команды - и причиной тому сама платформа, которая загоняет в некие рамки и сажает в свою песочницу. Примерно как программирование на учебных языках типа "Кумир".
Поэтому сравнивать мою работу с примерами на 1С я бы не стал :-)
Вы пока слишком оптимистичны в отношении ИИ. Да, сейчас можно, теоретически, написать даже достаточно сложную систему, особенно используя SDD-подход.
Но, надо понимать, что это просто очередной шаг эволюции. Когда-то программы писали на машинном языке или Асме - и представители бизнеса/ученые/инженеры отдавали свои алгоритмы/модели на бумаге бородатым дядькам или тетям, которые их забивали в перфокарты и запускали в мейнфреймы, а потом делали длинные распечатки с результатами. Потом появились специалисты на стыке бизнеса/науки/аналитики и программирования - потому что в итоге появились языки верхнего уровня. Но все равно приходилось осваивать уже работу с этими инструментами. А сейчас ИИ пишет код. При этом, все прекрасно понимаю, что как на языке верхнего уровня уже не написать так элегантно, как на асме, так и на ИИ вы получите код не просто не оптимальный - а заполненный определенным процентом нейрослопа.
Но, в любом случае, как только система становится проще обычной утилитки - встает необходимость управления ТЗ и применения SDD.
Ну и эффект "самоопыления" никто не отменял - ИИ вам не предложит нового решения - он просто "выровняет" вас с рынком. Условно - ну, вот подскажет, что есть класс систем RMS, расскажет про мировой опыт и сделает проект "на уровне" который уже достигнут - но ничего нового он не предложит - потому что этого нигде еще нет. Человеческое творчество - это не подбрасывание игральных костей - это сложный процесс, в котором есть даже детерменизм - только просчитать его также бесполезно пока что, как смоделировать поведение атомов в кусочке сахара, растворяемом в чае
э... я нигде не писал, что требования поступают от заказчика в готовом виде.. Обычно заказчик приходит с проблемой, а не с требованиями - и даже не с пониманием, что ему нужно - новая система, или и.б. просто нужно людей обучить работать с текущими инструментами, или вообще просто это проблема процесса, а не ИТ. Но закреплять требования по итогам обследования и работы аналитиков нужно с заказчиком - потому что иначе в какой-то момент возникнет вопрос, что работа должна быть оплачена, результаты приняты, бюджеты потрачены... и у заказчика должно быть понимание - на что и с каким выхлопом
Меня еще в институте учили, что ТЗ ВСЕГДА пишет исполнитель :) Но заказчик формулирует заказ
да, еще немного "не раскрыта тема сисек" с т.з. того, что вы понимаете под требованиями. На вскидку есть как минимум такие варианты: 1) что должно быть 2) как должно быть учтено
И вот требования вида "что" хорошо укладываются в задач... А вот требования "как" - должны соблюдаться при выполнении всего проекта и с т.з. использования трекера - это будут постоянно активные задачи, которые будут просто висеть в общей помойке задач и никак не "жить", не влиять на другие задачи и др. Пример задачи "как" - "интерфейс должен соответствовать требованиям стайл-гайда...", "все модули должны работать на Java не ниже версии..." и т.п. - причем это могут быть и функциональные и нефункциональные требования
А вообще то, что вы описываете под ТЗ в Jira - это по сути бэклог. Просто по правилам большинства гибких методологий: 1) задача не берется в текущую работу, пока ее не уточнили (это как раз этап формализации требований аналитиками) 2) допустима иерархия задач (те же "эпики" в скраме)
А почему вы пишете, что в Jira нет версионности задач ?
Да, и важный момент, который является плюсом классического ТЗ - его можно закрепить при обсуждении с заказчиком - его можно версионировать как описание системы на конкретный момент времени.
А вообще в свое время поиск подходящей RMS меня привел к Archimate / Archi - как к более комплексному подходу с возможностью поддержания сложной системы связей между разными уровнями требований и в связи между техническими и функциональными требованиями, целями/задачами бизнеса, инфраструктурными ограничениями и возможностями и др ;-)
да, хотел здесь возразить, что в целом подход с использованием ИИ для получения когда PlantUML / Mermaid - это не моделирование в полном смысле - потому что модели как таковой нет. Модель подразумевает концепцию "один источник - множество точек зрения - множество представлений" - см. ГОСТ Р 57100-2016 (IEEE 42010:2011).
В целом к вашему обсуждению хотел добавить, что есть сам язык Archimate, который по факту просто позволяет описать архитектуру систему от целеполагания до конечной реализации, а есть конкретные инструменты (Archi, EA и др). Так вот моделировать в обсуждаемомо контексте (когда мы закладываем некую не только структурную, но и математическую модель) позволяют в первую очередь инструменты. И здесь, если, например, говорить про Archi, логичным было бы навайбкодить плагин на JS, который бы это моделирование осуществлял, пробегаясь по онтологии модели - дело только за самой мат. моделью, которая будет определять сам код алгоритма и набор свойств, которые нужно создать для элементов (ну и м.б. перечень специализаций)
Возможно резали на кусочки большой файл, который был сгенерирован постранично или еще как - чтобы повторялись заголовки - т.е. для печати и др. И не там порезали... или недоскролили до конца в Excel и вставили заголовок ... вариантов море :-)
P.S.: с другой стороны - в вашем примере вообще отдельная тема - это внечеловеческий разум - кто разберет этих ардритов :-)
то, что для PlantUML нужно держать сервер, а Mermaid работает фактически на клиенте - скачалась JS-библиотека - и алга... Т.е. физически встроить это проще скажем даже в статический сайт с документацией, генерируемый из кода или модели и др. Аналогично это проще встроить в любое веб-решение 0 не нужно наличие каких-то дополнительных сервисов (ни на сервере системы, ни на стороннем сервере).
как уже ранее писал - с т.з. создания именно модели требований - попробуйте Archimate / Archi.
В т.ч. вот неплохой в принципе пример использования в статье с Хабра:
https://habr.com/ru/companies/axenix/articles/1038916/
ну, в случае новой системы не будет "ДО" - и ТЗ в итоге будет содержать полный набор требований вида "должен/должна" и т.п.
Это понятно.
Только в том-то и смысл ТЗ, что версионируется набор - в рамках которого есть тоже итерации по каждому требованию.
Просто реализовывать можно в конкретный момент времени только конкретную версию ТЗ.
Иначе это не ТЗ, а реально просто гибкая разработка с беклогом...
И ТЗ тогда сжимается до ЧТЗ под каждую конкретную задачу.
А разработка в целом происходит эволюционным путем - методом проб и ошибок и др - без попыток охватить картину в целом.
В общем ведение пунктов ТЗ в виде задач - идея не новая, но достаточно костыльная - особенно в случаях, когда есть нефункциональные требования и, фактически, во всех задачах они будут превращаться в чек-лист того, что нужно проверить / учесть разработчику при реализации конкретной фичи.
Ну и ТЗ - это в т.ч. первичное описание целевой архитектуры - хотя бы требований к ней...
ЗЫ: и если уж совсем быть строгими - после ТЗ идет техпроект, техпаспорт и т.п.
Но это для систем, которые внедряются в критичный прод - например, связанный с производством, ТЭК и т.п., где цена ошибки/просчета слишком высока, чтобы работать без предварительного ТЗ и понимания критериев приемки работы.
Это не ко мне вопрос, а к автору поста :-)
С технологиями уходит рутина и остается творчество.
Это показывают и примеры новостей с так называемыми "открытиями ИИ". По факту там речь идет о том, что ИИ перебирал все возможные варианты, что ест-но человек сделать не может с такой же скоростью (пример - Мендеелеев перепробовал кучу вариантов в течении длительного времени, пока ему не "приснилась" итоговая таблица элементов).
Узким местом становится уже человек, который должен успевать обрабатывать те результаты, которые выдает ему ИИ и принимать решение - классический пример - кодревью кода ИИ. Иначе у нас все превратится в ваб-ливинг - когда все делает ИИ - и работает, и принимает работы... и живет :).
и тогда "скрипач не нужен".
И возникает вопрос - а нужен ли тогда ИИ?
Тут еще вторая западня - прогресс ИИ будет влечь за собой регресс людей. И в итоге остается опасность самоопыления ИИ с постепенной деградацией - уже и ИИ и людей... как говорится "будешь как Великий Нехочуха".
Но, думаю появятся люди, которые уйдут в Зеон и будут делать все "руками", думать сами, читать книги и др.
Как не убил ширпотреб штучного производства в XIX веке. Да, луддиты побастовали - но мир не остановился. Просто оставшиеся мастера стали цениться выше и доступны узкому кругу.
Только если бы все было так просто - при чтении аналитических отчетов от ИИ не возникало бы каждый раз ощущение общения со смоляным чучелком.
Ключевое, что отличает человека - это не только явные знания, но и опыт, воспоминания, ощущения - все, что связано с физическим миром.
Не даром "мысль изреченная - есть ложь" - внутренний мир (неявные знания) человека намного богаче и сложнее, чем он может это описать.
И пока все неявные знания не будут переведены в явные - ИИ будет уступать.
Это как с "отвернувшимися" у Лю Цисиня в "Темном лесе".
ИИ сможет приблизиться к человеку, когда он получить возможность полноценной физической жизни, с полным спектром переживаний...
Вопрос только - нужен ли нам такой гомункул ?
А с т.з. экспериментов - да, если дать ИИ самому проводить физические эксперименты - он сможет методом подбора найти новые составы веществ, технологии производства и др... правда есть при этом вероятность, что он "сожрет" кучу материи на неудачные опыты... как сейчас сжигает кучу энергии на неудачные генерации и нейрослопы.
И, к слову, пока что даже в программировании, ИИ не может полностью самостоятельно дать себе обратную связь и сыграть за всю команду разработки, сам провести нужные эксперименты и др - все равно пока требуется наличие того, кто первично отстраивает систему.
Я бы воспринимал ИИ как очень активного студента, который прочитал кучу книг и впитал в себя все теоретические знания.
Чем он отличается от студента - студент такой объем забудет сразу после сессии - потому что нет подкрепления. А ИИ запомнит все - и полезное, и бесполезное - но без эмоционально, механистически.
А человек запоминает только через практику, через применение знаний в своих действиях - причем. желательно. в ближайшие несколько суток.
ну, тогда вот и получится, что одно и то же требование как задача в Jira будет висеть все релизы незакрытая....
в общем это все попытка натянуть трекер задач на RMS, хотя при этом от таск-трекера вообще берется по факту то, что он содержит в себе БД :-)
ЗЫ: вот про 1С обидно было... :-)
пусть в меня кинут камень, но уровень большинства программистов 1С мне с трудом позволяет назвать их ИТ-специалистами/программистами/проектировщиками...
Очень редко на рынке 1С-разработчиков встречаются грамотные команды - и причиной тому сама платформа, которая загоняет в некие рамки и сажает в свою песочницу.
Примерно как программирование на учебных языках типа "Кумир".
Поэтому сравнивать мою работу с примерами на 1С я бы не стал :-)
Вы пока слишком оптимистичны в отношении ИИ.
Да, сейчас можно, теоретически, написать даже достаточно сложную систему, особенно используя SDD-подход.
Но, надо понимать, что это просто очередной шаг эволюции.
Когда-то программы писали на машинном языке или Асме - и представители бизнеса/ученые/инженеры отдавали свои алгоритмы/модели на бумаге бородатым дядькам или тетям, которые их забивали в перфокарты и запускали в мейнфреймы, а потом делали длинные распечатки с результатами.
Потом появились специалисты на стыке бизнеса/науки/аналитики и программирования - потому что в итоге появились языки верхнего уровня. Но все равно приходилось осваивать уже работу с этими инструментами.
А сейчас ИИ пишет код. При этом, все прекрасно понимаю, что как на языке верхнего уровня уже не написать так элегантно, как на асме, так и на ИИ вы получите код не просто не оптимальный - а заполненный определенным процентом нейрослопа.
Но, в любом случае, как только система становится проще обычной утилитки - встает необходимость управления ТЗ и применения SDD.
Ну и эффект "самоопыления" никто не отменял - ИИ вам не предложит нового решения - он просто "выровняет" вас с рынком.
Условно - ну, вот подскажет, что есть класс систем RMS, расскажет про мировой опыт и сделает проект "на уровне" который уже достигнут - но ничего нового он не предложит - потому что этого нигде еще нет.
Человеческое творчество - это не подбрасывание игральных костей - это сложный процесс, в котором есть даже детерменизм - только просчитать его также бесполезно пока что, как смоделировать поведение атомов в кусочке сахара, растворяемом в чае
э... я нигде не писал, что требования поступают от заказчика в готовом виде..
Обычно заказчик приходит с проблемой, а не с требованиями - и даже не с пониманием, что ему нужно - новая система, или и.б. просто нужно людей обучить работать с текущими инструментами, или вообще просто это проблема процесса, а не ИТ.
Но закреплять требования по итогам обследования и работы аналитиков нужно с заказчиком - потому что иначе в какой-то момент возникнет вопрос, что работа должна быть оплачена, результаты приняты, бюджеты потрачены... и у заказчика должно быть понимание - на что и с каким выхлопом
Меня еще в институте учили, что ТЗ ВСЕГДА пишет исполнитель :)
Но заказчик формулирует заказ
да, еще немного "не раскрыта тема сисек" с т.з. того, что вы понимаете под требованиями.
На вскидку есть как минимум такие варианты:
1) что должно быть
2) как должно быть учтено
И вот требования вида "что" хорошо укладываются в задач...
А вот требования "как" - должны соблюдаться при выполнении всего проекта и с т.з. использования трекера - это будут постоянно активные задачи, которые будут просто висеть в общей помойке задач и никак не "жить", не влиять на другие задачи и др.
Пример задачи "как" - "интерфейс должен соответствовать требованиям стайл-гайда...", "все модули должны работать на Java не ниже версии..." и т.п. - причем это могут быть и функциональные и нефункциональные требования
А вообще то, что вы описываете под ТЗ в Jira - это по сути бэклог.
Просто по правилам большинства гибких методологий:
1) задача не берется в текущую работу, пока ее не уточнили (это как раз этап формализации требований аналитиками)
2) допустима иерархия задач (те же "эпики" в скраме)
А почему вы пишете, что в Jira нет версионности задач ?
Да, и важный момент, который является плюсом классического ТЗ - его можно закрепить при обсуждении с заказчиком - его можно версионировать как описание системы на конкретный момент времени.
А вообще в свое время поиск подходящей RMS меня привел к Archimate / Archi - как к более комплексному подходу с возможностью поддержания сложной системы связей между разными уровнями требований и в связи между техническими и функциональными требованиями, целями/задачами бизнеса, инфраструктурными ограничениями и возможностями и др ;-)
да, хотел здесь возразить, что в целом подход с использованием ИИ для получения когда PlantUML / Mermaid - это не моделирование в полном смысле - потому что модели как таковой нет. Модель подразумевает концепцию "один источник - множество точек зрения - множество представлений" - см. ГОСТ Р 57100-2016 (IEEE 42010:2011).
.
В целом к вашему обсуждению хотел добавить, что есть сам язык Archimate, который по факту просто позволяет описать архитектуру систему от целеполагания до конечной реализации, а есть конкретные инструменты (Archi, EA и др).
Так вот моделировать в обсуждаемомо контексте (когда мы закладываем некую не только структурную, но и математическую модель) позволяют в первую очередь инструменты.
И здесь, если, например, говорить про Archi, логичным было бы навайбкодить плагин на JS, который бы это моделирование осуществлял, пробегаясь по онтологии модели - дело только за самой мат. моделью, которая будет определять сам код алгоритма и набор свойств, которые нужно создать для элементов (ну и м.б. перечень специализаций)
P.P.S.: вот что коммент в хабре животворящий делает - уже починили ресурс :))))
Возможно резали на кусочки большой файл, который был сгенерирован постранично или еще как - чтобы повторялись заголовки - т.е. для печати и др. И не там порезали...
или недоскролили до конца в Excel и вставили заголовок ... вариантов море :-)
P.S.: с другой стороны - в вашем примере вообще отдельная тема - это внечеловеческий разум - кто разберет этих ардритов :-)
Mermaid встроен в gitlab - так что просто начинаешь писать прямо в корпоративном репе - что в самом репе, что в Wiki оно поддерживается
то, что для PlantUML нужно держать сервер, а Mermaid работает фактически на клиенте - скачалась JS-библиотека - и алга...
Т.е. физически встроить это проще скажем даже в статический сайт с документацией, генерируемый из кода или модели и др.
Аналогично это проще встроить в любое веб-решение 0 не нужно наличие каких-то дополнительных сервисов (ни на сервере системы, ни на стороннем сервере).
поддержку, на Windows, Android проблем нет.
С iOS детально эксперименты не проводились
Для этого достаточно подписаться на указанный канал и периодически подбирать прокси из списка, имея несколько для автлпереключения при блокировках.
Там все прозрачно - просто нажать "Connect"