Чи є дослідження щодо недоліків використання систем стеження за проблемами? [зачинено]

Мені не подобаються системи відстеження проблем, тому що:

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

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

Я тут один? Чи є дослідження (книга / стаття / що завгодно) про недоліки (або великі переваги) використання систем стеження за проблемами?

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

Якщо ви навіть не можете описати помилку, як ви можете почати її виправляти?

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

Це проблема вашої команди, а не програмного забезпечення.

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

Знову описуючи проблему з вашою командою.

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

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

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

1. Який із відкритих помилок слід виправити спочатку? (зауважте: у здоровому проекті це повинно вирішувати власник продукту та / або керівництво, а не розробник - для чого вони повинні бути в першу чергу обізнані про всі відкриті помилки!)
2. Скільки у нас відкритих помилок і якої тяжкості?
3. Що з них потрібно виправити, перш ніж ми будемо готові випустити?
4. Скільки часу планувати ці виправлення - це часто призводить до: скільки часу потрібно, щоб виправити помилку в середньому?
5. скільки помилок повідомили клієнти в останньому випуску?
6. хто виправляв цю помилку, коли і які (код / ​​конфігурація / дані) зміни стосувалися виправлення?
7. які виправлення помилок включені до випуску, який ми збираємось опублікувати?
8. ...

Чи можете ви відповісти на такі запитання [оновлення] повторно, надійно та ефективно [/ оновити] на основі ваших пост-приміток?

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

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

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

Можливо, є дослідження, але ще краще - важко зароблений досвід людей на місцях. Більшість систем відстеження випусків страждають від процесів, які керують їх дизайном. Трекерам проблем часто потрібно підтримувати 2 різні класи користувачів:

1. Команда розробників
2. Користувачі системи

Cal Henderson (раніше Flickr) займає чудову посаду щодо дизайну багатьох трекерних випусків, і чому він віддає перевагу трекеру випуску GitHub (як і я). Також Гарретт Дімон висвітлював дизайн Sifter і ілюстрував спосіб спрощення процесу для більш ефективного відстеження проблем . Я прийняв деякі ідеї з обох цих публікацій, щоб спростити робочий процес відстеження проблем моєї команди.

Все, що сказано, все ще зводиться до людей через процес та інструменти. Моє загальне думка полягає в тому, що трекери випусків, як правило, створюють цей відставання, яким вам доведеться керувати. Під час триажу люди мають більше шансів раціоналізувати те, що є чи ні помилка. У нашому процесі ми приймаємо рішення майже одразу після появи помилки про те, чи це проблема. Як тільки це рішення буде прийнято, помилка переходить у Pivotal Tracker. Різниця тут полягає в тому, що ми використовуємо Tracker для розстановки пріоритетів , а не як ручки для того, що ми не хочемо робити. Насправді, коли Icebox починає надто великим, я активно видаляю елементи, включаючи помилки. Якщо питання досить велике, що його потрібно вирішити, воно з’явиться знову.

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

TL; DR Зосередьтеся на своєму процесі, виберіть прості інструменти та вирішіть проблеми, коли вони з’являться.

вбивство важливих помилок, як тільки вони з’являються

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

• О, і частина "як вони з'являються" є досить слизькою BTW. В одному з проектів у нас була важлива помилка, яка загрожувала викинути весь товар з бізнесу (що може бути важливішим?). Це було дуже складно (помилка архітектури), і ми знали, що це займе багато часу, щоб виправити це. Клієнти люб’язно погодилися дати нам рік на виправлення (перш ніж скинути наш товар), і ми зробили це приблизно за рік.

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

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

• Насправді, якщо ви запитуєте про f2f, це відчуває, що ви (неправильно) використовуєте трекер для обговорення речей - це не його мета. Щоб визначити його призначення, просто напишіть його ім’я повільно і чітко: видайте систему відстеження .

списки помилок стають такими довгими

На мій досвід, перевага - це не проблема.

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

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