@CaptainJustness

Как лучше организовать рабочий процесс в Jira Atlassian, Agile?

Всем привет. Пытаюсь освоить Jira Atlassian.

Появилось несколько вопросов:
1. Какие шаблоны лучше и перспективней использовать и почему: классические или нового поколения?
2. Создавать под одним именем один проект или под каждое направление (веб, мобилька, десктоп) свой проект? Например: Название проекта "Хабр" и этот проект будет включать задачи и для сайта и для моб. приложение или делать так, несколько проектов: "Хабр Web", "Хабр Mobile", "Хабр Android", "Хабр iOS" и т.д.? Как будет грамотно? Например, если один проект, то задачи Добавить кнопку лайк в мобильное приложение, Добавить кнопку лайк в веб приложение и т.д, А если проект под каждую платформу, то просто в каждой будет задача Добавить кнопку лайк. Как на практике лучше?
3. Вы соблюдаете иерархию задач? Т.е. Сначала должен быть создан Эпик, потом уже только Задачи входящие в эпик (это если рассматривать современные шаблоны, если классчиеские или скрам, то там история есть еще)...
4. Как лучше называть эпик задачу? Например есть Личный кабинет, и нужно сделать модуль Уведомления. Значит я создаю Эпик "Уведомления", и подздаачи создать страницу ... создать виджет и т.д. Так ?
5. Я так понимаю, если эпик будет выполнен и все входящие в него задачи, то он как бы закрыт, но вдруг нужно добавить новую фичу в уведомления или баг исправить, мне же не нужно создавать новый эпик, достаточно добавить новую задачу в уже существующий?
  • Вопрос задан
  • 233 просмотра
Решения вопроса 1
@icef
2. Создавать под одним именем один проект или под каждое направление (веб, мобилька, десктоп) свой проект? Например: Название проекта "Хабр" и этот проект будет включать задачи и для сайта и для моб. приложение или делать так, несколько проектов: "Хабр Web", "Хабр Mobile", "Хабр Android", "Хабр iOS" и т.д.? Как будет грамотно? Например, если один проект, то задачи Добавить кнопку лайк в мобильное приложение, Добавить кнопку лайк в веб приложение и т.д, А если проект под каждую платформу, то просто в каждой будет задача Добавить кнопку лайк. Как на практике лучше?

В вашей терминологии. Если воркфлоу для всех одинаков, то один проект - один продукт, внутри него каждое направление - это компоненты. Типы задач стандартные - task, sub-task, bug, new feature, new feature, improvement, epic (что-то может лишнее - смотрите сами). "добавить лайк" - это не тип задачи, а скорее кастомное поле списком и обязательность его заполнения при создании задачи, например. По этому же полю фильтры для графиков или уведомлений.
3. Вы соблюдаете иерархию задач? Т.е. Сначала должен быть создан Эпик, потом уже только Задачи входящие в эпик (это если рассматривать современные шаблоны, если классчиеские или скрам, то там история есть еще)...

ничего плохого в том чтобы большие задачи делать эпиками и разбивать на задачки - нет. Маленькие задачи, улучшения, баги - ради них создавать эпик не имеет смысла
4. Как лучше называть эпик задачу? Например есть Личный кабинет, и нужно сделать модуль Уведомления. Значит я создаю Эпик "Уведомления", и подздаачи создать страницу ... создать виджет и т.д. Так ?

похоже на правду. Только не подзадачи создаешь, а задачи внутри эпика
5. Я так понимаю, если эпик будет выполнен и все входящие в него задачи, то он как бы закрыт, но вдруг нужно добавить новую фичу в уведомления или баг исправить, мне же не нужно создавать новый эпик, достаточно добавить новую задачу в уже существующий?

да. Либо вообще не привязываться к эпику. И открою секрет - в джире еще есть версии. Кажется в этом случае как раз версии могут быть полезны. Или нет.

Все выше - смесь бест практис от атлассиан и свой опыт. Поэтому в целом можно сказать, что IMHO, но не истина в последней инстанции. Выше пишут что сначала постройте процессы, а потом уже кладите их на джиру - тоже неплохо. Но если ни процессов нет, ни джиры, то в джире в общем-то много что неплохо реализовано и строить процессы по ней может быть не самой плохой идеей
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
Robur
@Robur
Знаю больше чем это необходимо
Сначала думаете как лучше организовать свой рабочий процесс - а потом его переносите в Jira. У вас судя по всему этого процесса нет сформированного, и Jira сама по себе вам не поможет его сделать из ничего.
Ответ написан
dollar
@dollar
Лучше для чего или для кого? Вы спрашиваете, как лучше, но ничего не пишете про специфику своей работы.

В Jira можно замутить практически любую схему организации. Вопрос лишь в том, что вам надо и чего вы хотите. Скажем, если есть бюджет, но нет сроков - одна схема. Если есть сроки, но нет бюджета, то другая. И так далее. Множество условий может быть, которые ограничивают или предъявляют требования к организации процессов.
Ответ написан
dyfran
@dyfran
Вопрос конечно пальцем в небо, но расскажу как у нас

У нас один проект на все направления.
Есть минусы, воркфлоу получается жирный, так как охватывает всех и мне как РП мобилок зачастую нужны не все статусы и согласования. Но главный плюс в том, что если один воркфлоу, то можно и единые выгрузки делать по жире по проектам, иначе сравнивать задачи/деньги/сдвиги по срокам/инциденты в разных проектах с разным воркфлоу будет вообще нереально. Это то, что никогда не поймут разрабы, им подавай простые и прозрачные воркфлоу со статусами, так как 95% разрабов не понимают что происходит за границами их системы, но кричат конечно об обратном :) и на вопрос как считать глобальную доработку на 7 систем разводят руками. У нас из-за специфики это один из самых важных критериев, если вам не нужно, то лучше конечно отдельные проекты, но разбивать мобилы и веб в любом случае маразм, всем и так очевидно, что одна фича, это одна доработка на бэке и три на фронтах (веб и мобилы).

У нас доски скрамбаны, формируем спринты по скраму, работает по канбану, с кучей мелких доработок для удобства - отображаем статус связанной QA задачи, отображаем оценку и оставшиеся время и тд

Иерархию соблюдаем, но только из-за сложности проекта, на предыдущем месте работы например это было не нужно.

У нас идет:
1. Заявка на доработку ПО - где указывается аллокация, цели, бабло и тд
2а. Далее Доработка системы - где бьем системы Процессинг, АБС, ДБО (мобилы и веб вместе)
2б. Контроль качества - тут создаются задачи на тестирование и все баги
3. Технические таски в каждой доработке системы.

Тут главный критерий делать как удобнее и быстрее (с поправкой на хотелки начальства), а не как "правильнее". Наш пример только выглядит сложным, на деле это самая простая структура, которая выстроилась за несколько лет на глобальный проект в 450 человек.

Эпики как хочешь так и именуй, правило тоже самое (удобно/быстро/понятно). Хочешь по фичам, хочешь по релизам, хочешь по план сметам, хочешь по фазам луны.

Добавить задачу в эпик не проблема, добавить баг тоже. Мы для удобства баги добавляем с таким же эпиком ****_fix, т.е. эпик сам release_1, баги в release_1_fix. В задаче эпик будет только release_1, в баге будет два эпика release_1 и release_1_fix.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы