После прочтения та же мысль. Проблема не в фреймворка, а в менеджменте в целом. Не просчитали риски изменений. Ну и логирование времени совершенно обычная практика для аутсерса. Странно что это вызвало такой коллапс в отделе. А в серами вообще нет времени, есть только SP, которые про сложность задач. Оценка в часах и привязка к 40 часам в рабочей неделе от бизнеса.
Вы при планировании спринта учитываете время на тестирование и багфикс в зависимости от сложности задач? Или смотрите только на производительность по оценкам фич?
Спасибо за ответы.
Всех благ и терпения в дальнейшей работе над сервисами. Был опыт участия в разработке двух панелей управления и биллингов у разных хостеров в роли product owner очень трудоемкое мероприятие особенно дальнейшая поддержка и доработка.
Просто меня смутило то, что в клиентском интерфейсе есть раздел «Биллинг».
Скажите, пожалуйста, а какие задачи/проблемы вы пытались решить создавая свой биллинг? Почему не использовали имеющиеся на рынке?
Также из описания запутался в функциях внутренней панели, в которой можно платить и функцией биллинга, где тоже клиент платит. Как это все работает можете подробней рассказать?
Да, в курсе, читал, но как уже говорил выше мне не хотелось плодить сущности, в то время как Atlassian наоборот делает упор на то, что разделить эти сущности очень важно. Я не претендую на то, что мой способ самый лучший, мне он больше подходит по ряду причин, может кому-то еще подойдет.
Присмотрюсь пристальней и к вашему варианту, может при тормозах, из-за большого количества плагинов, надо будет что-то выкинуть. Но пока мне нравится, что за ограничения отвечает Permisson, а не Transition.
Global Transition — мне показалось менее красивым решением, особенно в свете того, что мне не постоянно администрировать JIRA, а надо настроить, написать руководство пользователя/администратора и «отдать». В любом случае JIRA очень мобильна и получить необходимый результат можно множеством способов.
Здравствуйте. Да, можно настроить через «multi user picker». В моем случае было принято решение не плодить отдельные сущности и использовать уже существующую «watchers». Если говорить об отличиях, то в Permission Scheme можно управлять правилом «Manage Watchers», тем самым разрешить или запретить пользователю/группе/роли редактировать «watchers». С «multi user picker» это будет возможно только через правило «Edit Issues», что менее гибко и не всегда необходимо давать возможность править Issue только ради добавления «watchers».
После прочтения та же мысль. Проблема не в фреймворка, а в менеджменте в целом. Не просчитали риски изменений. Ну и логирование времени совершенно обычная практика для аутсерса. Странно что это вызвало такой коллапс в отделе. А в серами вообще нет времени, есть только SP, которые про сложность задач. Оценка в часах и привязка к 40 часам в рабочей неделе от бизнеса.
Всех благ и терпения в дальнейшей работе над сервисами. Был опыт участия в разработке двух панелей управления и биллингов у разных хостеров в роли product owner очень трудоемкое мероприятие особенно дальнейшая поддержка и доработка.
Просто меня смутило то, что в клиентском интерфейсе есть раздел «Биллинг».
Также из описания запутался в функциях внутренней панели, в которой можно платить и функцией биллинга, где тоже клиент платит. Как это все работает можете подробней рассказать?
За совет спасибо, учту на будущее!