Как вы справляетесь с постоянно растущими кучами проблем, которые необходимо решить «когда-нибудь»?

Мы используем JIRA для отслеживания проблем в наших программных проектах. Один эффект, который мы заметили, заключается в том, что мы часто создаем новую проблему, но пока не знаем, когда / если проблема будет решена вообще. Таким образом, мы придумали фиктивную веху «Далекое будущее», к которой относятся такие проблемы.

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

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

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

Если нет, вы можете пометить их как «не исправить», если они недостаточно серьезны, чтобы оправдать время, которое потребуется, чтобы исправить.

Вы должны исправить ошибку, только если приложение более ценно без ошибки.

Если текстовое поле не выровнено и для его исправления требуется три дня, тогда, вероятно, стоимость слишком высока, и вам следует ее оставить. Напротив, если пользователи вообще не могут писать в текстовое поле, вам следует исправить это и быстро.

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

Некоторые компании не пишут строки нового кода, если все еще ожидают ошибок. Другие не беспокоятся до фазы тестирования перед доставкой.

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

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

В нашей системе отслеживания ошибок есть статус «запрещен по времени». Если проблема существует в течение нескольких месяцев или даже лет, и ни один клиент не призывает или повторно не решает проблему, тогда этот статус используется в качестве окончательного. Это делается не автоматически, а вручную, когда менеджеры просят нас убрать открытые вопросы. Во время этого процесса также вероятно, что некоторые из проблем устранены, потому что их легко исправить и / или относительно важно (несмотря на то, что их не подталкивают и не перезаписывают).

Я не использую JIRA, у меня есть fogbugz на работе, но я уверен, что это относится к большинству трекеров ошибок. При написании этого я понял, что способ работы более гибок, чем водопад, сроки не являются конкретными для меня, и что является приоритетным.

• Если ваш начальник заботится об открытии слишком большого количества билетов, просто не создавайте тривиальные. Вы должны быть prgamatic и не добавлять какие-либо функции / исправления, которые не имеют никаких преимуществ. Если вам будет легче отшлифовать некоторый код или настроить пользовательский интерфейс, добавьте его. Не просто работайте на себя, пытаясь исправить мелкие недочеты в продукте, ничто не идеально.
• Поместите несущественные ошибки / функции в текущий этап, но с низким приоритетом. Если о проблеме упоминается больше жалоб / заявлений, вы можете увеличить приоритет.
• Закройте / разрешите то, что вы можете, поскольку не можете исправить, не можете воспроизвести, дублировать и т. Д. Некоторые ошибки слишком тривиальны, чтобы их исправить, или это запросы функций, которые могут занимать слишком много времени. Иногда вам просто нужно сказать человеку, запрашивающему эти исправления / функции: «Нет, извините, у нас нет времени».
• Расставьте приоритеты по мере необходимости, и ваш список заявок будет отсортирован по приоритету и этапу.
• Если они не собираются делать веху, переместите их в будущую веху.
• Если тикет зависит от того, какой другой тикет был завершен, пометьте его как заблокированный или организуйте тикеты в иерархию, чтобы было очевидно, что тикет-х и тикет-у связаны.
• Если билет требует обратной связи от кого-то, назначьте его этому человеку.

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

Мы используем JIRA, и у нас есть дополнительное состояние разрешения, которое называется Suspended- если функция / ошибка - это то, от чего мы просто должны на некоторое время отказаться, то она разрешается как Приостановленная. Таким образом, он не перепутается ни со списком активных в настоящее время проблем, на которые мы должны постоянно обращать внимание, ни со списком решенных проблем, которые, как мы знаем, были обработаны удовлетворительно, и все еще находятся в базе данных.

Список приостановленных вопросов - это то, что я периодически пересматриваю (но не очень часто), чтобы вновь открывать по мере необходимости.

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