Найкращі практики та типові помилки в робочих процесах Jira

Про

зміст

  • Додому
  • Віта
  • вірчі грамоти
  • Консультаційні послуги
  • Внутрішнє навчання
  • Відкриті тренінги
  • Зв'язок
  • відбиток

Робочі процеси Jira: найкращі практики та типові помилки

Коли я йду в компанію, у мене завжди є список найкращих практик та типових помилок для початківців для Джири. Цей список дуже вдячний моїм клієнтам, оскільки помилок часто можна уникнути і кожна помилка критично оцінюється, особливо на початковій фазі нової системи. У наступних серіях статей я поділюсь частиною цього списку із спільнотою Джири та з нетерпінням чекаю нових пропозицій та коментарів.

найкращі

Надвиробництво

Робочі процеси Jira зазвичай моделюються на основі реальних робочих процесів у компанії. Наразі такий підхід правильний, але слід створити розумний баланс між картографуванням реального робочого процесу та максимальною зручністю для користувачів у Jira. Цей крок є одним із найскладніших і вимагає певного досвіду можливостей та обмежень Джири. На моєму досвіді, золотим правилом робочих процесів у Jira є:

Скільки потрібно, якомога менше!

(Або також принцип "ПОЦІЛУЙТЕ": Будьте короткими та простими). Це означає: якомога більше кроків робочого процесу, але якомога менше. Який із реальних етапів роботи необхідний як крок робочого процесу в Jira, не можна відповісти в принципі, оскільки завжди доводиться враховувати конкретні обставини компанії та працівників. Однак є кілька питань, за допомогою яких можна перевірити, чи потрібен крок:

  • Відбувається зміна відповідальності?
  • Цей крок можуть виконувати лише певні люди або групи користувачів?
  • Повідомлення потрібно надсилати?
  • Чи повинен я мати можливість фільтрувати після цього кроку, тобто мати можливість бачити огляд усіх процесів у зв’язаному стані?

Чим більше на ці запитання відповідають "так", тим надійніше цей крок також повинен бути відображений у Jira. Часто занадто багато кроків вбудовується в робочий процес на етапі задуму, що призводить до надмірного проектування, згаданого на початку. Такий робочий процес технічно правильний, але його складність викликає нерозуміння у користувачів - результатом є неправильна робота та відмова від нового інструменту. Негативний приклад:

Фіктивна компанія RequirementsUnlimited хотіла б запровадити управління внутрішніми вимогами разом з Jira. Отже, це створює робочий процес, який відображає технічний процес, коли вимога реєструється. Перші 4 кроки для виду діяльності "Вимога": Відкритий, За погодженням, Затверджений, Запланований.

Поки що звучить досить добре. Однак: для того, щоб прийняти нову вимогу, потрібно 4 кроки робочого циклу, через які користувач повинен “натиснути” на випадок сумнівів. Тож тут слід перевірити, чи дійсно всі кроки необхідні. Наприклад, з RequirementsUnlimited, єдина різниця між статусом "Затверджено" та "Заплановано" полягає в тому, що процес у цьому переході статусу призначається певному випуску (у Jira, версія рішення). На запитання, чому для цього необхідний окремий статус, керівник проекту відповідає: "Я хочу мати можливість фільтрувати, які процеси розпізнані, але ще не заплановані!". З цією інформацією ви тепер можете з чистою совістю рекомендувати видалити крок "Заплановано": Ви також можете використовувати фільтр для відображення всіх процесів, які мають статус "Затверджено" і не призначені для жодної версії рішення. Якщо параметр фільтра був єдиною вимогою для кроку "Заплановано", його можна видалити та налаштувати існуючі фільтри.

У цьому прикладі спочатку може здатися тривіальним, чи має робочий процес один більш-менш крок - із більшими та складнішими робочими процесами, проте кожен наступний крок створює новий рівень складності та залежностей. Дотримання цього низького рівня є метою чистого та зручного робочого процесу.

Погана назва при переході статусу

Популярним джерелом низької зручності використання робочих процесів є іменування переходів статусу. При створенні функціонального робочого циклу існує тенденція називати переходи статусу відповідно до того, що сталося в останньому статусі, замість того, що відбуватиметься в наступному статусі. Ви повинні знати, що імена переходів стану відображаються користувачеві як доступні кроки робочого циклу:

У більшості випадків користувачі Jira знають, що щойно сталося з процесом, і замість цього хочуть побачити на дисплеї доступні кроки, до яких призведе подальший статус кожного кроку. Негативний приклад:

Перехід статусу "Голосування закінчено" неминуче призводить до запитань "Що це означає?", "Що станеться, якщо я натисну на нього зараз?" Результат ще раз - невизначеність та неправильна робота. У цьому прикладі перехід статусу повинен бути таким:

З позначенням «Процес процесу» користувач може відразу бачити подальший статус, в який його дія призведе його. Отже, правилом іменування переходів стану є: Ім'я переходу статусу повинно відображати подальший стан процесу.

Це були лише два з численних прикладів, які слід враховувати при проектуванні та налаштуванні робочих процесів у Джирі (серед іншого: використання вирішеного та закритого статусу, глобальні переходи статусу, призначення умов робочого циклу та багато іншого). На цьому етапі, звичайно, моє останнє запитання: з якими помилками чи проблемами ви стикалися під час створення робочих процесів? Я з нетерпінням чекаю вашого коментаря!

Подібні статті

28 листопада 2012 р. Себастьян Хене
Категорії: Джира | Теги: Найкращі практики, Jira, Робочий процес | 7 коментарів