2. Создавать под одним именем один проект или под каждое направление (веб, мобилька, десктоп) свой проект? Например: Название проекта "Хабр" и этот проект будет включать задачи и для сайта и для моб. приложение или делать так, несколько проектов: "Хабр Web", "Хабр Mobile", "Хабр Android", "Хабр iOS" и т.д.? Как будет грамотно? Например, если один проект, то задачи Добавить кнопку лайк в мобильное приложение, Добавить кнопку лайк в веб приложение и т.д, А если проект под каждую платформу, то просто в каждой будет задача Добавить кнопку лайк. Как на практике лучше?
В вашей терминологии. Если воркфлоу для всех одинаков, то один проект - один продукт, внутри него каждое направление - это компоненты. Типы задач стандартные - task, sub-task, bug, new feature, new feature, improvement, epic (что-то может лишнее - смотрите сами). "добавить лайк" - это не тип задачи, а скорее кастомное поле списком и обязательность его заполнения при создании задачи, например. По этому же полю фильтры для графиков или уведомлений.
3. Вы соблюдаете иерархию задач? Т.е. Сначала должен быть создан Эпик, потом уже только Задачи входящие в эпик (это если рассматривать современные шаблоны, если классчиеские или скрам, то там история есть еще)...
ничего плохого в том чтобы большие задачи делать эпиками и разбивать на задачки - нет. Маленькие задачи, улучшения, баги - ради них создавать эпик не имеет смысла
4. Как лучше называть эпик задачу? Например есть Личный кабинет, и нужно сделать модуль Уведомления. Значит я создаю Эпик "Уведомления", и подздаачи создать страницу ... создать виджет и т.д. Так ?
похоже на правду. Только не подзадачи создаешь, а задачи внутри эпика
5. Я так понимаю, если эпик будет выполнен и все входящие в него задачи, то он как бы закрыт, но вдруг нужно добавить новую фичу в уведомления или баг исправить, мне же не нужно создавать новый эпик, достаточно добавить новую задачу в уже существующий?
да. Либо вообще не привязываться к эпику. И открою секрет - в джире еще есть версии. Кажется в этом случае как раз версии могут быть полезны. Или нет.
Все выше - смесь бест практис от атлассиан и свой опыт. Поэтому в целом можно сказать, что IMHO, но не истина в последней инстанции. Выше пишут что сначала постройте процессы, а потом уже кладите их на джиру - тоже неплохо. Но если ни процессов нет, ни джиры, то в джире в общем-то много что неплохо реализовано и строить процессы по ней может быть не самой плохой идеей
Сложный
Простой
