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


15

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

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

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


1
Похоже, вы говорите о моем рабочем месте, очень тревожно. Удачи вам в этом, я сейчас немного поболтаю и не спешу прогрессировать в этом вопросе. Управление, кажется, не беспокоит, пока у нас не так много мусора, что мы больше не можем его игнорировать.
Deadalnix

Почему это нужно исправить? Если это не важно и никогда не будет исправлено, тогда это прекрасно.
B 7

Ответы:


11

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

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


3
+1 Ибо не исправят, это может быть как социальной, так и технической проблемой. Иногда нужно просто сказать НЕТ. Если вы продолжаете исправлять ошибки, особенно тривиальные или лишние запросы функций, ожидания людей возрастут, и они будут продолжать просить большего.
Кейо

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

6
@MarcoDinacci - Это зависит от того, что вы вкладываете в «экономически эффективный». С краткосрочной точки зрения вы правы. Но если проект длится долго, предоставление заданий «исправлять ошибки» младшему программисту может рассматриваться как инвестиция.
Mouviciel

2
@mouviciel Я думаю, что есть лучшие и более стимулирующие способы обучения младших программистов, чем позволить им работать над ошибками, но я согласен, что это способ изучения кодовой базы. Другая проблема с этим подходом состоит в том, что старшие разработчики могут в конечном итоге просто написать код, не заботясь о появлении ошибок, потому что есть младшие разработчики, которые все равно исправят их.
Trasplazio Garzuglio

3
@MarcoDinacci, позвольте мне сказать иначе: если старшим разработчикам нужен внешний процесс, чтобы заставить их производить качественную работу, у команды есть фундаментальная проблема. ИМХО любой хороший разработчик - но особенно пожилые люди - должен иметь внутреннюю мотивацию для качества. Если у мотивирующего лидера (ов) команды отсутствует такая мотивация, проект почти неизбежно потерпит неудачу, так или иначе, и никакие процессы не могут ему помочь.
Петер Тёрёк

11

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

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

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

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

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

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


6

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


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

2

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

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

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


2

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

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


1

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.