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

Ми використовуємо JIRA для відстеження проблем у наших програмних проектах. Один із ефектів, який ми помітили, - це те, що ми часто створюємо нову проблему, але ми ще не знаємо, коли / якщо проблема буде вирішена взагалі. Таким чином, ми винайшли фальшиву віху "Далеке майбутнє", до якої вирішуються такі проблеми.

Як це трапляється, купу питань, приписаних цій віхові, постійно зростає, тому, здається, це не гарний підхід. На сьогодні їх так багато, що переглядати їх на предмет дійсності було досить багато. Деякі з них стали недійсними, оскільки компонент, який вони пов’язані з вами, був видалений. Деякі з них дублювались іншими випусками. Деякі з них мають такий погано сформульований опис, що ніхто більше насправді не знає, про що йдеться.

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

Це хороші перші помилки контактів, які потрібно виправити для нових розробників, які щойно приєдналися до вашої компанії. Або для молодших розробників розширити свої знання про систему.

Якщо ні, ви можете позначити їх як "звичайні виправлення", якщо вони недостатньо серйозні, щоб виправдати час, який знадобиться для виправлення.

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

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

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

Деякі компанії не записують рядок нового коду, якщо ще є помилки. Інші не турбуються до етапу тестування перед доставкою.

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

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

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

Я не використовую JIRA, у мене є fogbugz на роботі, але я впевнений, що це стосується більшості трек-помилок. Коли я писав це, я зрозумів, що спосіб роботи я спритніший, ніж водоспад, терміни для мене не конкретні, і що важливо - це пріоритет.

• Якщо ваш начальник піклується про занадто багато відкритих квитків, в першу чергу не створюйте дрібниць. Ви повинні бути дошкільним і не додавати жодних функцій / виправлень, які не мають жодних переваг. Якщо це полегшить ваше життя, щоб полірувати якийсь код або налаштувати інтерфейс користувача, тоді обов'язково додайте його. Не просто працюйте над собою, намагаючись виправити незначні недоліки у виробі, нічого не ідеального.
• Помістіть неважливі помилки / функції в поточну віху, але з низьким пріоритетом. Якщо стосовно проблеми згадується більше скарг / запитів, то ви можете підкреслити пріоритет.
• Закрити / вирішити те, що ви не можете виправити, не вдається відтворити, копіювати і т. Д. Деякі помилки надто тривіальні для виправлення, або вони є запитами на функції, які займуть занадто довго. Іноді просто потрібно сказати людині, яка запитує ці виправлення / функції, "Ні вибачте, у нас немає часу".
• Визначте пріоритетні помилки та упорядкуйте свій список квитків за пріоритетом та важливим етапом.
• Якщо вони не збираються робити віху, тоді перенесіть їх у майбутній рубіж.
• Якщо квиток залежить від заповнення іншого квитка, позначте його як заблокований або організуйте квитки в ієрархію, так що очевидно, що ticket-x і ticket-y пов'язані.
• Якщо для квитка потрібен певний відгук від когось, призначте його цій людині.

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

Ми використовуємо JIRA та маємо додатковий стан роздільної здатності Suspended- якщо функція / помилка - це те, від чого ми просто мусимо відмовитися на деякий час, воно вирішується як призупинено. Таким чином, він не змішується ні зі списком поточно активних проблем, на які ми маємо тримати свою увагу, ні зі списком вирішених питань, які, як ми знаємо, були оброблені задоволеними, і він все ще знаходиться в базі даних.

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

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