затем возникнет вопрос "как научить менеджеров и координаторов работать в гитхаб", "как объяснить заказчику гитхаб и зачем ему туда права", "где найти столько передастов из гитхаба на сторону заказчика для согласований". У workflow трекеров и средств типа Confluence нет этой боли.

вот второй инструмент из новых, который я искал полчаса: https://agilespecs.com/

Про обучение согласен, но что такое Workflow Tracker  ?

Sparx Enterprise Architect неплох же весьма

или Axure RP

Игорь, вы о чём вообще?

workflow tracker +-= учётная система

инструменты, позволяющие работать с единицами работы как множествами и управлять их жизненным циклом

У нас сейчас каждая задача имеет три лейбла - приоритет, стадия/статус, тип и через waffle легко визуализируется в виде kanban board. Это оно?

это у вас простейший вариант issue tracker, как ядра учётной системы

Да

@DenisIzmaylov & @beskov Наверное, под workflow tracker понимается workflow движок, issue трэкают, workflow это же схема, как же схему трэкать можно

У нас на прошлой работе использовали jira для бизнес-требований и jazz для разделывания БТ на куски , потом они покрывались ТЗ , разработкой и тестированием. Но не помню, чтоб это было удобно🤔

У нас Jira + HP ALM. Плюс интеграция с bamboo и confluence. Вроде для всего своё место, но синхронизация страдает

Владимир, а что за система hp alm? У нас ее используют для заведения дефектов вроде, но я на гуглила плотно что это такое

На одной из прошлых работ стоял выбор между Jira и Redmine в качестве трекера задач. В итоге выбрали Jira с учётом удобства тесной интеграции с Confluence. В последующем Jira стала использоваться в качестве общего пула заявок не только на разработку в ИТ департамент. Тип issue выбирается заявителем и дальше трэкается по соответствующему workflow. Аналитические issue растипизировали и каждому из них определили свой wf

И, да, конечно же, Jirа по прежнему используется по своему изначальному предназначению по работе обработки заявок типа Bug спецами по QA

Первое назначение — завести тест кейсы, которые полностью должны покрыть BRD. Я как аналитик ревьюил, нет ли упущенных моментов.
Второе — заведение дефектов, которые позже проваливаются в Jira. Они требуют анализа - разработки - тестирования - UAT.
Проблема была в том, что тестировщики не хотели лазить в jira, бизнес не имел доступ в hp alm, и ещё синхронизация работала через раз. За два года разработки и внедрения одной системы мы повидали и выслушали многое)
Сейчас перешли полностью на скрамбан в jira. Довольно удобно

У Atlassian вопрос с лицензированием очень тонкий и сумма отчислений зависит от числа пользователей. Не знаю решился ли вопрос с лицензированием, у нас мало кто за винду то отчислять микрософтовцам хочет.

Во, у меня сейчас намечается похожее. Интеграция двух систем в одной, баги по одной заводятся в alm, а вторые товврищи работают в jira, и как и ктт будет в жиру закидывать - неясно😤