Чому так важко змусити співробітників оновити трекер випусків?

Мені завжди доводилося боротися за те, щоб люди оновлювали свої проблеми як у моїй компанії, так і на роботі. У мене було кілька випадків, коли люди насправді роблять це з доброго серця, але ~ 70% часу мені доводиться гнати людей.

Будучи тією, яка зазвичай виконує ту чи іншу форму управління (я в першу чергу розробник), головна причина, яку я намагаюся дати, - це те, що я не хочу переслідувати людей і перебивати запити про прогрес, але я не хочу ' t думаю, врешті-решт, люди пам'ятають, що багато чого просять. У деяких рідкісних і крайніх випадках я закінчую оновлення їхніх квитків (коли мені потрібно створювати звіти).

Отже, чи стикалися ви з цією проблемою? Як ти заохочував розробників часто оновлювати трекер проблем? Який рівень успіху у вас був?

Причина полягає в тому, що вони не грозять, чому вони повинні оновлювати трекер проблем, крім того, що ви так говорите.

Чому так? Моя здогадка полягає в тому, що оновлення трекера не впливає на їх роботу жодним значущим чином, тому рішення, ймовірно, полягає у впровадженні системи відстеження, яка насправді допомагає виконувати свою роботу краще.

Це важко, адже працівники чітко відчувають, що оновлення трекера проблем не важливо. Ви повинні це змінити, але є улов. Спілкування важке. Ефективне спілкування насправді важче, ніж ви могли подумати. Настільки важко, що спілкування зазвичай не вдається, за винятком випадково .

Покажіть, не кажіть. Напр. не кажіть, що вам (або вашому начальнику) потрібні дані для звіту. Показати від співробітників точки зору , як уточнений відстеження проблем впливає і допомагає їм.

Подавати приклад.

Я розробник і намагаюся використовувати трекер проблем, який ми маємо на роботі. Це прикро, тому що я всі для них, щоб все було організовано. Наразі моє рішення - використовувати особистий інструмент відстеження та посилатися на нього, щоб говорити про прогрес у наших щоденних розвагах.

Ось що б змусило мене весь час використовувати трекер:

• Безпроблемна інтеграція з IDE та керуванням джерелами. Ми використовуємо кілька незграбних веб-сайтів, тому що ліцензії вже були придбані для цього. Створювати / оновлювати завдання потрібно назавжди та має деякі заплутані функції інтерфейсу. На жаль, використання цього є поза контролем нашої команди.

• Простота. Під цим я маю на увазі не прийняття 10 полів, заповнених вручну, просто для додавання завдання. Погодинні оцінки та час завершення, вручну вводячи проект / компонент / тощо. у кількох полях тощо просто збільшуйте кількість часу.

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

Перш за все: що ви маєте на увазі під "людьми, що оновлюють свій прогрес"?

Ви маєте на увазі "розробники, які оновлюють поточну оцінку", або "розробники не встановлюють проблему для вирішення", а точніше "замовники / тестувальники не закривають вирішену проблему", або всі разом?

З точки зору розробника, це суміш мислення та культури.

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

Мій досвід такий: культура вам потрібна, щоб принаймні вказати в правильному напрямку. Далі допомагає визначити DoD (визначення поняття "зроблено") - якщо розробник (працює і для інших ролей) може сказати, що він виконав весь список, це полегшує позначити проблему вирішеною та рухатися далі без потреби. озирнутися назад.

Перестаньте питати про прогрес кодування (його зазвичай довільний відсоток все одно викрадений з повітря) доти, доки квиток не закриється. Якщо головне, що ви вимірюєте - кількість закритих квитків, це покращиться.

Зауважте, однак, що всі показники можуть бути ігровими, а показники, як правило, працюють краще при об'єднанні з додатковими показниками, наприклад, ви, мабуть, також хочете розглянути проблеми, які повторно відкриваються, оскільки це означає, що вони передчасно закриті

Як вказується в деяких інших відповідях, правильне питання тут, мабуть, чому: у вас є інструмент для відстеження проблем. Хороша відповідь на це питання (не тільки з точки зору управління, але і з точки зору розробника) є обов'язковою, якщо ви хочете, щоб система відстеження проблем справді працювала і регулярно оновлювалася.

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

На мій досвід, єдиний спосіб дійсно мати розробники (а також тестери, управління тощо) ефективно використовувати систему відстеження проблем - це інтегрувати її в процес розробки. Це означає, що вихід однієї частини процесу стає входом до наступної частини процесу.

Щоб надати повноваження системі відстеження помилок, я б запропонував таке:

• Розробники працюють лише над помилками / функціями, зафіксованими в трекері випусків, і поза ним не виконується жодна робота. Усі ідеї, проекти рефакторингу, нові функції, спеціальні інструменти, які потрібно розробити тощо, також повинні записуватися в журнал.
• Питання опрацьовуються в порядку черговості. Пріоритет повинен частково визначатися керівництвом, але розробники обов'язково повинні мати слово і у визначенні пріоритетів. Особливо це стосується питань обслуговування та реконструкції.

Щодо обробки, ви можете використовувати щось на зразок наступного:

• статус "новий" вказує на те, що розробник ще не вибрав проблему і все ще знаходиться в черзі з пріоритетними проблемами
• статус 'присвоєний' означає, що він був призначений розробнику. Це може зробити розробник або хтось інший, наприклад керівник команди. Я вважаю, що добре працює, тому що кожному розробнику присвоєно кілька проблем, і зазвичай це поєднання «важких підйомів», таких як нові функції та легкий вибір, таких як прості помилки або прості роботи з технічного обслуговування. Це дозволяє розробникам вибирати роботу залежно від їх настрою.
• статус "незавершений" означає, що розробник працює над проблемою. Лише одне чи два питання на розробника повинні бути "в процесі роботи" в будь-який момент часу.
• Після вирішення проблеми розробник може змінити статус проблеми на "потребує тестування" та змінити власника на тестер. Це важливий крок, оскільки це також черга роботи тестерів.
• тестери можуть змінити статус або на "невдале тестування" і змінити право власності на розробника, що означає, що він переходить у верхню чергу черги для розробника, або вони можуть змінити статус на "готовий до розгортання".
• проблеми зі статусом "готові до розгортання" можуть бути об'єднані та випущені відповідно до циклу випуску тим, хто відповідає за випуски.

Якщо коротко: зробіть систему відстеження проблем важливою частиною процесу розробки, і вам не доведеться турбуватися про те, що проблеми не оновлюються.

Можливо, вони вважають за занадто багато роботи, щоб відкрити браузер, увійти, знайти квиток і заповнити його. Можливо, ви можете спробувати заохотити їх гачками . Сьогодні загальною особливістю є те, що в повідомленні git / hg [я припускаю, що ви використовуєте одне із них] ви можете ввести щось на кшталт сподобалось FIXED # 123, і квиток автоматично зміниться, як тільки ви натиснете на ваше виконання. Таким чином, для розробника майже немає роботи [якщо він працює над кожним випуском в окремій гілці - у нього вже є ідентифікатор квитка], і, швидше за все, він додасть ці пару символів у повідомлення комісії. Якщо цього рішення недостатньо, можливо, це означає, що обсяг квитків занадто великий, і його слід розділити на багато менших квитків?

Це звучить як питання культури компанії більше, ніж усе інше. Хто запровадив необхідність використання трекера? Якщо це щось, що одна людина чи група кинула туди, і очікує, що всі інші просто приймуть та використають, удачі. Якщо люди не зрозуміють, що це таке, не знають, як ним користуватися, і не приймуть, що це насправді полегшує їхнє життя (їхнє життя, НЕ ваше), вони не використовуватимуть його, якщо їх не примусить керівництво. При цьому, якщо використання трекера - це рішення компанії, то для його виконання слід керувати керівництвом. Якщо ваша роль не включає відповідальність і повноваження отримувати / змушувати людей використовувати трекер (це звучить як ні, як ви вказали, що ви розробник), ви не збираєтеся далеко доходити, незалежно від того, чим займаєтесь (реально, IMHO ).

Це, мабуть, схоже на те, чому так важко змусити людей регулярно вводити свій час. Це копітка робота ...

Багато трекери випусків інтегруються з IDE. Наприклад, Tracker Work Item Tracker дозволяє позначити завдання як вирішене під час реєстрації. Навіть є можливість вимагати, щоб реєстрація була пов’язана із завданням. Перетворення оновлення робочого елемента в процес перевірки спрощує речі. Альтернативою є відкриття трекера проблем у окремому інтерфейсі для виконання змін.

Інший варіант - це проведення зборів зі статусом (або під час щоденного резервного огляду), де хтось відкриває трекер і оновлює завдання, коли люди надають статус.

Одне, що слід враховувати, - це те, що сам GUI є перешкодою. Наприклад, деякі перешкоди можуть включати:

• Занадто багато кліків
• Неоптимізований або недооцінений сервер застосувань Tracker Application
• Погана зручність чи доступність

Розкриття API дозволить оновлювати відстежувач проблем за допомогою сценаріїв, таких як технічні артефакти (покриття коду, звіти про випробування блоку, стан збірки тощо).

Список літератури

• Scrumwise - API

• JIRA Cloud REST API Reference

• API інтерфейсу Alfresco Content Services