Например, в TargetProcess на задачу можно ассайнить несколько человек, причём в разных группах. Например пару разработчиков (бэк, фронт), тестировщика и ПМа. И в зависимости от статуса нужной группе приходит письмо, что задачу перевели на их часть.
Flow примерно такой: кастомер рассказывает чего хочет, ПМ создаёт задачу (status: opened), обсуждается как чего делать, назначается спринт, оценивается по времени и статус переводится в planned, разработчики видят что им в очередь прилетела задача, сроки когда её нужно сделать и её приоритет и в рабочем порядке когда доберутся до неё переведут в In Progress. Когда закончат, переведут её в Coded. Когда заберётся мастер и всё это будет поставлено на тест статус меняется на Ready for testing - активная команда меняется на тестировщиков, заассайненные тестировщики видят что им прилетела задача. Ставят статус In testing, затем Verified. То что поверифаили можно вернуть в мастер и поставить клиенту (статус Deployed). И когда кастомер подтвердил что всё ок - статус переводится в Closed.
Так вот штатно в GitHub и GitLab так чётко вести всё стэп бай стэп не получается. В т.ч. не получается добавлять всякие кастомные поля (например адрес тестового сервера и бранч в котором задача делается). По умолчанию в GH нет даже эстимейтов времени. А всякие /Closes #123 закрывают задачу нафиг, а не переводят её далее по Flow.
В итоге приходится держать всякий зоопарк, терять время на таскание одних и тех же сущностей туда-сюда и играть в сломанный телефон. И разумеется всё это регулярно разваливается или вынуждено переезжать на новые костыли потому что Jira включила ссанкции и т.д..
Отдельно можно было бы выкинуть вообще тайм-трекинг, потому что можно было бы предлагать пользователю по умолчанию букать время как разницу между началом его части (In progress) и закрытием (Coded), округлить время вверх с учётом графика работы отдельного разработчика и для 90% задач забыть про геммор с ручным вводом.
|
