Пометка принимается, наши все энтерпрайз клиенты либо переезжали с HP на Омник, либо сразу с HP на Atlassian.
По вопросам:
1) У нас есть в работе кейс, где используем Insight для риск менеджмента, а внутри используем как контакт книгу, сразу можно связать с проектами, данными, запросами человека
2) Это вопрос на который нет ответа в прошлом времени) пока еще в работе, так как наша сфера ответственности напрямую на включает департамент разработки, он немного вынесен за поддержку. Но если говорить про то как есть и с чем мы работаем то: бизнес требования приоритезируются прокси стейкхолдерами, а-ля продакт оунер в праведном IT мире. Приходят они также через сервис деск и по внутренним каналам. После того как они приоритезированы, они попадают дальше на декомпозицию и работу. ПО Change request все проще, написано 40 скриптов на Power Script которые обрабатывают типовые ченджи, создается типовой чендж А и сразу к нему 8 связанных между собой задач на соответствующие линии поддержки. Ну и мы написали плагин чтобы забивать порядок задач marketplace.atlassian.com/apps/1221874/task-order-for-jira?hosting=server&tab=overview
Не типовые ченджи идут по флоу бизнес требований, то есть приоритизруюстя оцениваются и в работу, иногда понятно что чендж нетиповой и критичен, но это уже стратегии реагирования)
Хорошая идея про отдельную статью насчет Asset management. Краткие ответы по пунктам:
1) Проект сдан, сейчас фаза саппорта и уже доделывания/допиливания разных процессов
2) В банке была CMDB, мы давали рекомендации по ее ре-организации в продукте Insight Asset management, посмотрели на существующую структуру, сделали аналог +- в Insight и начали наполнять, параллельно вывели все это с условиями на портал чтобы можно было запросы сразу к ассетам линковать
3) Сейчас еще планируем поставить Discovery, чтобы автообновление было ассетов, будет отлично летать. Когда анализировали и собирали данные привлекали начальников разных отделов в IT департаменте — инфобез, инфраструктура, саппорт, развитие. В основном с ними общались, им задавали вопросы а дальше они уже собирали информацию внутри по своим системам, экселькам и людям
Добрый день, не знал что можно апрувать/деклайнить комментарии)
Спасибо за конструктивную критику, учту в следующих статьях. Согласен насчет аргументов, тоже думал что можно было бы вырезать кусок в начале и добавить больше про практические кейсы. Думаю, что в будущем буду писать статью на отдельный кейс, чтобы сохранить и подробность, и интерес, и полезность. Спасибо!
Спасибо! По поводу кастомизации:
Да, это можно сделать, нужно в режиме редактирования workflow выбрать нужный транзишн, например из To Do в In Progres, там есть Screen и выбрать экран, который будет показываться при этом транзишн. Экран нужно предварительно сделать) Для этого нужно иметь права администратора всей Jira
Вот не знаю, для энтерпрайща цена меньше раз в 10 от других тулов, для смол бизнеса и того меньше
Сам пока не сталкивался, что в сервере много ресурсов выделили, что в клауде работало ок. Много понятие растяжимое, у меня сейчас где то 80 проектов заведено, ну и задач от 10 до 300 в каждом
Про разметки согласен полностью, странное решение, но видимо отголоски прошлого
А точно речь не про клауд и поддержку? В целом как в любом инструменте наверное, он да, нужен человек который и в аналитике хорош и инструмент знает
Хороший вопрос, надо было указать. Из самых больших недостатков с которыми я сталкивался это:
1) Резистанс людей, когда вы внедряете систему. Люди работали в чем-то, работали как-то и они не хотят меняться
2) Сложность настройки. Минус в этом пункте в том, что нужно разбираться в системе, довольно плотно, у Atlassian есть пачка сертификаций даже. В общем не совсем нативно для админов, но весьма просто для юзера. Этот пункт я зацепил в статье
3) Из последнего еще это смена упора Atlassian в сторону клауда. Если раньше клауд и сервер разработка была плюс минус одинаковой, то с октября 2019 они решили развиваться клауд намного больше, чем сервер, и это выльется в стагнацию сервера через год-два, если комьюнити не продавят их
По вопросам:
1) У нас есть в работе кейс, где используем Insight для риск менеджмента, а внутри используем как контакт книгу, сразу можно связать с проектами, данными, запросами человека
2) Это вопрос на который нет ответа в прошлом времени) пока еще в работе, так как наша сфера ответственности напрямую на включает департамент разработки, он немного вынесен за поддержку. Но если говорить про то как есть и с чем мы работаем то: бизнес требования приоритезируются прокси стейкхолдерами, а-ля продакт оунер в праведном IT мире. Приходят они также через сервис деск и по внутренним каналам. После того как они приоритезированы, они попадают дальше на декомпозицию и работу. ПО Change request все проще, написано 40 скриптов на Power Script которые обрабатывают типовые ченджи, создается типовой чендж А и сразу к нему 8 связанных между собой задач на соответствующие линии поддержки. Ну и мы написали плагин чтобы забивать порядок задач marketplace.atlassian.com/apps/1221874/task-order-for-jira?hosting=server&tab=overview
Не типовые ченджи идут по флоу бизнес требований, то есть приоритизруюстя оцениваются и в работу, иногда понятно что чендж нетиповой и критичен, но это уже стратегии реагирования)
1) Проект сдан, сейчас фаза саппорта и уже доделывания/допиливания разных процессов
2) В банке была CMDB, мы давали рекомендации по ее ре-организации в продукте Insight Asset management, посмотрели на существующую структуру, сделали аналог +- в Insight и начали наполнять, параллельно вывели все это с условиями на портал чтобы можно было запросы сразу к ассетам линковать
3) Сейчас еще планируем поставить Discovery, чтобы автообновление было ассетов, будет отлично летать. Когда анализировали и собирали данные привлекали начальников разных отделов в IT департаменте — инфобез, инфраструктура, саппорт, развитие. В основном с ними общались, им задавали вопросы а дальше они уже собирали информацию внутри по своим системам, экселькам и людям
Спасибо за конструктивную критику, учту в следующих статьях. Согласен насчет аргументов, тоже думал что можно было бы вырезать кусок в начале и добавить больше про практические кейсы. Думаю, что в будущем буду писать статью на отдельный кейс, чтобы сохранить и подробность, и интерес, и полезность. Спасибо!
Да, это можно сделать, нужно в режиме редактирования workflow выбрать нужный транзишн, например из To Do в In Progres, там есть Screen и выбрать экран, который будет показываться при этом транзишн. Экран нужно предварительно сделать) Для этого нужно иметь права администратора всей Jira
Пару комментов по пунктам
1) Резистанс людей, когда вы внедряете систему. Люди работали в чем-то, работали как-то и они не хотят меняться
2) Сложность настройки. Минус в этом пункте в том, что нужно разбираться в системе, довольно плотно, у Atlassian есть пачка сертификаций даже. В общем не совсем нативно для админов, но весьма просто для юзера. Этот пункт я зацепил в статье
3) Из последнего еще это смена упора Atlassian в сторону клауда. Если раньше клауд и сервер разработка была плюс минус одинаковой, то с октября 2019 они решили развиваться клауд намного больше, чем сервер, и это выльется в стагнацию сервера через год-два, если комьюнити не продавят их