LINUX.ORG.RU

Вопрос к разрабам на больших проектах

 проблемо-менеджмент, релиз-менеджмент


0

1

Есть ли какие-то тулзы, которые могут визуализировать элементы релиз-менеджмента (когда какой релиз выходит) и одновременно статус тикетов по проблемам конкретно вашей подсистемы? Чтобы еще и дедлайны как-то отображались, и зависимости между тикетами (типа, чтобы решить проблему тикета А, надо сначала решить проблему в тикете Б).

И интеграция с Jira чтобы была, типа, кнопочка с надписью «проблемаСсегфолтом» (я ее сам выбираю) а статус в джире цветом отображался. Нажимаю на такую кнопочку, и UI меня редиректит на таск в джире?

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

★★★★★

Jira Structure умеет в Gantt чарт + там есть сущности эпиков и релизов.

Вот эта штука еще удобной была: https://ganttpro.com/

PS Сам в итоге пришел к тому, что мне всеравно удобнее сделать выгрузку в эксель и раскидать там час по компетенциям и спланировать релиз (ну или подвинуть его, если так лучше по каким-либо соображениям).

PSS Будь внимателен к вопросу того, сколько времени на все эти рассчеты будет потрачено. Не увлекись)

Norgat ★★★★★
()

Кажется, ты пытаешься изобрести диаграммы ганта, тебе уже посоветовали тулзов (хотя ганты в джире которые я видел смотрятся крайне убого и неюзабельно), подброшу ещё microsoft project, который любят многие пмы (пользоваться не доводилось)

grazor ★★
()

А «большой» - это сколько в граммах? 1k, 10k, 100k задач?

В жире «из коробки» есть релизы.

Для подсистем можно настроить метки и фильтры. Зависимости я бы настраивал эпиками, но можно и ссылками накрутить. Сколько тикетов осталось прекрасно смотрится в репортах. В-общем, всё для менеджерского счастья есть, только настраивай.

fluorite ★★★★★
()
Ответ на: комментарий от fluorite

хм… мне пришла в голову идея, на каждый issue ticket (они у нас не в джире) создавать джира таск. А если место на сервере закончится, это не мои проблемы, разумеется.

К сожалению, наша проблемо-билетная система - кастомная внутренняя разработка, и никаких там интеграций с джира не предусмотрено.

seiken ★★★★★
() автор топика
Ответ на: комментарий от Goury

у нас есть эксперт по атлассиану, но в каких проектах он учавствует, определяет не мой бос. Т.е. между нами может быть два уровня боссов. Причем, этот эксперт на одном этаже со мной работает, и я его знаю. Но я не могу просто так подкатить к нему, и сказать «нам нужно больше автоматизации, помоги нам, пожалуйста, научи, расскажи». К тому же, у нас self-hosted атлассиан, и я не думаю, что вообще так просто можно расширения устанавливать, менять настройки проекта и проч.

seiken ★★★★★
() автор топика
Последнее исправление: seiken (всего исправлений: 1)

Ниже бред, не читай


А большой это сколько? У меня в игре про ЛОР за 5 дней уже 1200 строк лютого говнокода с 62мя записями FIXME и 12ти XXX , одно рыло и три листа бумажки.

Это я к чему, нокатываешь в vim Plugin 'gilsondev/searchtasks.vim' и дрыгаешь в релизной ветке исходников SearchTasks * Завели баг во вне, примерно прикидывешь где он проявляется, дуешь в код и вхерачиваешь коммент FIXME: БЛАБЛАБЛА когда весь этот мусор в коде будет уже бить по глазам, ты будешь смотреть на релизное окно и плакать выбирая из списка FIXME не то что манагер прописал переслав картинку из своего Jira, а то что реально надо исправлять тутава и сейчас. Плакать, стучать ножками, рвать волосы и исправлять. Ибо завтра Юля из соседней комнаты понапихает в код ещё десять FIXME

Коноечно всё это на уровне шутки, но всё же =)

(типа, чтобы решить проблему тикета А, надо сначала решить проблему в тикете Б).

Тогда надо завести шальную машинистку которая будет упарываться сортируя тикеты вручную составляя карты зависимостей, так как зависимость А от Б может быть техническая и выяснена только в процессе. Или писать тулзу которая по неким хз тегам или типа того будет строить дерево зависомостей отдного от другого и динамически его перестраивать. Тогда надо пилить эту тузлу.

Нужен ПМ, можно apt переделать под тикеты и будет. apt push проблемаСсегфолтом:id256 И разработчику устнавиливается «пакет» он такой apt show last и там список зависимостей тикетов. А ещё нужны маинтейнеры тикетов. В конце будет целая операционная система специального назначения для управления проектами. Целые здания, несколько отделов по разработке, десятки команд, подразделения и деловые связи. Всё для того чтобы не меняющий своего места дислокации Васька на стуле, получил в веб интерфейсе попап «Нада добавить вотета, но перед эти вот это» на что Васька скажет «А то я лять не знаю что для возможности делать SQL запросы надо сначала сам SQL внедрить».

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

Разупоролся, простите пожалуйстаАААААААААААААААААААААААААААААААААА

Просто список задач и проблем вручную отсортированных по важности и всё. Идея с зависимостями хорошая, но кто это и как будет отслеживать? Разве что только как выше, засовывать тикет (не целиком конечно) прям в код, тогда они будут удаляться естественным образом. А иначе вручную выискивать уже неактуальные которые были решены в процессе решения других на автомате. Можно неявно добавлять тикет на определённый участок кода, через нашлёпку/оверлей, когда тикет указывает на определённую часть кода, ссылается на него, при этом в теле кода ничего от тикета нету. При изменении учатка кода отвецтвенного, того на который ссылаетя тикет, тикет становится активным или либо требует ревью/проверки либо закрывается.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)

В Jira это все есть, и зависимости между билетами, и релизы, и т. д. Но нигде не видел чтобы это использовалось прямо во все поля, так как поддержка всего этого в Jira занимает очень много времени.
Хотя, могу себе представить, что в каком-то кровавом энтерпрайзе с релизами раз в полгода это может себя окупить.

каузальность

Не знаю что это.

urxvt ★★★★★
()