Проводятся ли исследования о недостатках использования систем отслеживания проблем? [закрыто]

Мне не нравятся системы отслеживания проблем, потому что:

• Требуется слишком много времени, чтобы описать проблемы в нем. Это препятствует его использованию.
• Вы создаете место для хранения ошибок. И если для них есть место, люди обычно не слишком заботятся об исправлении ошибки, потому что они могут ее исправить, чтобы когда-нибудь кто-то мог ее исправить (или нет).
• Со временем списки ошибок становятся настолько длинными, что никто больше не может с ними справиться, отнимая у нас много времени.

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

Я здесь один? Существуют ли исследования (книга / статья / что угодно) о недостатках (или больших преимуществах) использования систем отслеживания проблем?

Требуется слишком много времени, чтобы описать проблемы в нем. Это препятствует его использованию.

Если вы даже не можете описать ошибку, как начать исправлять ее?

Вы создаете место для хранения ошибок. И если для них есть место, люди обычно не слишком заботятся об исправлении ошибки, потому что они могут ее исправить, чтобы когда-нибудь кто-то мог ее исправить (или нет).

Это проблема вашей команды, а не программного обеспечения.

Со временем списки ошибок становятся настолько длинными, что никто больше не может с ними справиться, отнимая у нас много времени.

Опять вы описываете проблему с вашей командой.

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

ИМО ваша отправная точка смещена. Если разработчики не могут исправить ошибки, проект обречен на провал, независимо от того, отслеживают ли они ошибки с помощью надлежащего инструмента отслеживания ошибок, пост-его, резьбы по камню или нет вообще. Это не вина инструмента, если он не используется или используется не по назначению. (Тем не менее, есть, конечно, плохие трекеры ошибок / проблем ... Я работал над проектом, используя совершенно неадекватный инструмент для этой работы, поэтому я думаю, что знаю, насколько он может быть плохим. Но есть и хорошие, которые требуют минимальных церемоний и накладных расходов, что позволяет сосредоточиться на соответствующей информации.)

Однако, если разработчикам все равно, и проект больше, чем тривиальный по размеру, и в нем больше одного разработчика, и в нем задействовано какое-то управление (все это довольно часто встречается в реальных проектах). ), скоро возникнут вопросы типа:

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

Можете ли вы ответить на такие вопросы [обновить] повторно, надежно и эффективно [/ update] на основе ваших заметок?

Да, ввод данных об ошибках в систему отслеживания проблем влечет за собой некоторые накладные расходы. Однако это более чем компенсируется затраченным временем и усилиями при поиске и создании отчетов, подобных приведенным выше, из сохраненных данных об ошибках.

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

Некоторые статьи / исследования, которые могут вас заинтересовать, включают в себя эту статью, в которой обсуждается использование Jira компанией Zend, и это французское исследование, посвященное использованию систем отслеживания ошибок.

Там могут быть исследования, но еще лучше трудный опыт людей в этой области. Большинство систем отслеживания проблем страдают от процессов, которые определяют их дизайн. Для отслеживания проблем часто требуется поддержка двух отдельных классов пользователей:

1. Команда разработчиков
2. Пользователи системы

Кэл Хендерсон (ранее из Flickr) написал отличный пост о дизайне многих трекеров и почему он предпочитает трекер GitHub (как и я). Также Гаррет Даймон рассказал о дизайне Sifter и проиллюстрировал способ упрощения процесса для более эффективного отслеживания проблем . Я применил некоторые идеи из обеих публикаций, чтобы упростить процесс отслеживания проблем моей команды.

Все, что сказано, все еще сводится к людям по процессу и инструментам. Мое общее мнение состоит в том, что средства отслеживания проблем имеют тенденцию создавать это отставание, которым вы должны управлять. Во время сортировки люди более склонны рационализировать, что является или не является ошибкой. В нашем процессе мы принимаем решения почти сразу после того, как ошибка обнаружена, является ли это проблемой. Как только это решение принято, ошибка попадает в Pivotal Tracker. Разница здесь в том, что мы используем Tracker для расстановки приоритетов , а не в качестве ручки для вещей, которые мы не хотим делать. Фактически, когда Icebox начинает становиться слишком большим, я активно удаляю элементы, включая ошибки. Если проблема достаточно велика, чтобы ее нужно было обработать, она возникнет снова.

Нам редко нужна история ошибок. Иногда кто-то может упомянуть симптом ошибки, и мы можем выполнить поиск, чтобы выяснить, связано ли это с какой-то проблемой, с которой мы уже справились. Но это редко.

TL; DR Сконцентрируйтесь на своем процессе, выбирайте простые инструменты и решайте проблемы по мере их появления.

убивать важные ошибки, как только они появляются

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

• Да и часть "как они появляются" довольно скользкая, кстати. В одном проекте у нас была важная ошибка, которая угрожала вывести из строя весь продукт (что может быть важнее?). Это было очень сложно (ошибка архитектуры), и мы знали, что это займет много времени, чтобы это исправить. Клиенты любезно согласились дать нам год на исправление (перед тем, как уронить наш продукт), и мы сделали это примерно через год.

Что касается трекеров, я использую их почти десять лет, и, как правило, все программисты вокруг меня проводят довольно мало времени с трекером (заметьте, я говорю о программистах; менеджеры - другая история). Я видел случаи (редко), когда это было не так - во всех этих случаях что-то было серьезно сломано.

Что касается исследований разговоров лицом к лицу с отслеживанием проблем, опять же, вы чувствуете, что вы входите в открытую дверь здесь. Отслеживание проблем - типичное письменное сообщение; Есть много исследований, показывающих, что общение по лицу намного эффективнее, чем по телефону, что, в свою очередь, гораздо эффективнее, чем записано .

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

списки ошибок становятся такими длинными

По моему опыту, выше это преимущество, а не проблема.

С длинным списком ошибок разработчики могут настроить очередь и планировать исправления далеко вперед. Это настолько продуктивно, насколько это возможно; для меня это в основном нирвана, когда у меня есть такая очередь для работы. Первая ошибка - исправлено - сделано, вторая ошибка - исправлено - сделано, следующая ошибка - исправлено - сделано и т. Д. И т. Д. Нет глупых прерываний, нет болезненных отвлекающих моментов с очень эффективными беседами, чистый поток .

• Я помню только один случай, когда длинные списки ошибок были проблемой. Это случилось, когда какой-то идиот из высшего руководства выбрал политику, которая заставляла разработчиков выбирать следующую ошибку из кучи 50-100 почти ежедневно. Какая трата. Нам потребовалось несколько месяцев боли, пока мы не поняли, как обострить это через его голову и исправить это.
  Через некоторое время после того, как нам удалось установить удобный рабочий процесс, мы обнаружили, что наше «бесконечное отставание» волшебным образом опустошилось.