Най-добрите практики и типични грешки в работните процеси на Jira

относно

съдържание

  • У дома
  • Вита
  • акредитивни писма
  • Консултантски услуги
  • Вътрешно обучение
  • Открити тренировки
  • Контакт
  • отпечатък

Работни процеси на Jira: Най-добри практики и типични грешки

Когато отида в компания, винаги имам списък с най-добрите практики и типични за Джира грешки за начинаещи. Този списък е много ценен от моите клиенти, тъй като грешките често могат да бъдат избегнати и всяка грешка се оценява критично, особено в началната фаза на нова система. В следващата поредица от статии ще споделя част от този списък с общността на Джира и ще очаквам нови предложения и коментари.

най-добрите

Превъзходство

Работните процеси на Jira обикновено са моделирани на реални работни процеси в една компания. Този подход засега е правилен - обаче трябва да се направи разумен баланс между картографирането на реалния работен процес и крайната удобство за потребителите в Jira. Тази стъпка е една от най-сложните и изисква известен опит относно възможностите и ограниченията на Джира. Според моя опит златното правило за работните процеси в Jira е:

Колкото е необходимо, колкото е възможно по-малко!

(Или също и принципа „KISS“: Нека бъде кратък и опростен). Това означава: колкото се може повече стъпки от работния процес, но възможно най-малко. Кои от истинските работни стъпки се изискват като стъпка на работен процес в Jira, по принцип не може да се отговори, тъй като винаги трябва да се вземат предвид конкретните обстоятелства на компанията и служителите. Има обаче няколко въпроса, които могат да се използват, за да се провери дали е необходима стъпка:

  • Налице е промяна в отговорността?
  • Тази стъпка може да извърши само определени хора или потребителски групи?
  • Известията трябва да бъдат изпратени?
  • Трябва ли да мога да филтрирам за тази стъпка, т.е. може да видите преглед на всички процеси в свързания статус?

Колкото повече отговори на тези въпроси са с „да“, толкова по-сигурно тази стъпка също трябва да бъде картографирана в Jira. Често твърде много стъпки са вградени в работен процес във фазата на концепцията, което води до свръхпроектиране, споменато в началото. Такъв работен поток е технически правилен, но неговата сложност причинява неразбиране сред потребителите - резултатът е неправилна работа и отхвърляне на новия инструмент. Отрицателен пример:

Фиктивната компания RequirementsUnlimited иска да внедри управление на вътрешните изисквания с Jira. Следователно той създава работен поток, който отразява техническия процес, когато дадено изискване е записано. Първите 4 стъпки за типа дейност „Изискване“ са: Отворена, В координация, Одобрена, Планирана.

До момента звучи доста добре. Въпреки това: за да се приеме ново изискване, са необходими 4 стъпки на работния процес, чрез които потребителят трябва да „щракне” в случай на съмнение. Така че тук трябва да проверите дали всички стъпки са наистина необходими. С RequirementsUnlimited има напр. единствената разлика между статуса "одобрен" и "планиран" е, че процесът се присвоява на конкретна версия (в Jira, версия на решение) в този преход на състоянието. На въпрос защо е необходимо отделно състояние за това, мениджърът на проекта отговаря: „Искам да мога да филтрирам кои процеси са разпознати, но все още не са планирани!“. С тази информация вече можете с чиста съвест да препоръчате да изтриете стъпката „Планирано“: Можете също така да използвате филтър, за да покажете всички процеси, които имат статус „Одобрен“ и не са присвоени на никоя версия на решението. Ако опцията за филтър беше единственото изискване за стъпката „Планирана“, можете да я изтриете и да коригирате съществуващите филтри.

В примера в началото може да звучи тривиално дали работният поток има една повече или по-малка стъпка - в по-големи и по-сложни работни потоци, обаче всяка допълнителна стъпка създава ново ниво на сложност и зависимости. Поддържането на това ниво е целта на чист и лесен за работа работен процес.

Лошо именуване при преходи на състоянието

Популярен източник на лоша използваемост на работните потоци е именуването на преходи на състоянието. Когато създавате функционален работен поток, има тенденция да се именуват преходи на състоянието според това, което се е случило в последното състояние, вместо това, което ще се случи в следващото състояние. Трябва да знаете, че имената на преходите на състоянието се показват на потребителя като налични стъпки на работния процес:

В повечето случаи потребителите на Jira знаят какво току-що се е случило с процеса и вместо това искат да видят на дисплея на наличните стъпки до какво следващо състояние ще доведе всяка стъпка. Отрицателен пример:

Преходът за състояние „Гласуването приключи“ неизбежно води до въпросите „Какво означава това?“, „Какво се случва, ако щракна върху него сега?“ Резултатът е отново несигурност и неправилна работа. Преходът на състоянието в този пример трябва по-добре да бъде както следва:

С обозначението „Процес на процеса“ потребителят може веднага да види последващия статус, в който действието му ще го доведе. Следователно правилото за преименуване на състоянието е: Името на преход на състояние трябва да показва последващото състояние на процеса.

Това бяха само два от многобройните примери, които трябва да бъдат взети предвид при проектирането и настройването на работни потоци в Jira (наред с други: използване на решен и затворен статус, глобални преходи на състоянието, определяне на условията на работния процес и много други). На този етап, разбира се, последният ми въпрос: Какви грешки или проблеми срещнахте при създаването на работни потоци? Очаквам с нетърпение вашия коментар!

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

28 ноември 2012 г. от Себастиан Хьоне
Категории: Джира | Етикети: Най-добри практики, Jira, Работен процес | 7 коментара