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

В настоящее время на моем рабочем месте мы используем FogBugz для управления всеми нашими функциями и ошибками для наших различных веб-приложений.

Когда новая функция должна быть добавлена ​​в одно из наших веб-приложений, создается новый случай. Например, «Создать форму загрузки CSV».

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

Если в этой функции есть какие-либо ошибки, мой Менеджер проектов затем повторно открывает дело и присваивает его мне с помощью списка пунктов ошибки.

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

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

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

Правильно ли я заявляю, что ошибки следует открывать как новое дело? И каковы плюсы / минусы каждого способа управления этим?

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

Для таких случаев, как ваш, я использую подход подзадач для задач высокого уровня / низкоуровневых (концепция, которую я выбрал из JIRA , не может сказать, поддерживает ли FogBugz, явно ли ^{она выглядит} ). Таким образом, маркированные списки, ориентированные на клиента, переходят к задачам высокого уровня, а важные для меня «итерации разработчика» отражаются в подзадачах.

Когда задача высокого уровня «открывается», я создаю новую подзадачу, чтобы отследить дополнительные усилия для себя .

Этот способ позволяет разработчику четко отразить все перестановки, извращения и повороты, пройденные спецификацией функции, и в то же время позволяет менеджеру представлять его клиентам как-будто-идеально. Кстати, идеальная презентация имеет ценность для меня как для разработчика, потому что ее легче читать клиентам помогает получить более точные корректировки.

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

_{Что касается отслеживания времени для каждой задачи или подзадачи - поскольку JIRA позволяет включать отслеживание подзадач в сводку более высокого уровня, для менеджера приемлемо отслеживать время в подзадачах. Однако даже если бы это было не так, я мог бы жить с формальным отслеживанием времени в «родительской» задаче - в этом случае я бы просто использовал комментарии подзадач, чтобы указать, сколько времени было потрачено на конкретную итерацию.}

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

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

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

Ошибки для завершенной функции могут быть связаны с основным случаем для функции (в FogBugz, путем использования имени тега или перекрестной ссылки или путем создания их подслучаев). Я вижу, что вашему руководителю нужно немного больше для консолидации информации по нескольким случаям, но часто имеет смысл разделять время, затрачиваемое на первоначальную разработку, и время, затрачиваемое на обслуживание, особенно для контрактов с фиксированной ценой, и вы теряете способность делать это, если складываете все в одно дело.

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

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

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

Обнаружены ли ошибки до или после того, как продукт был «отправлен / выпущен» покупателям?

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

Если это происходит после релиза, у каждой ошибки должен быть свой билет.

Там, где я работаю, только QA люди могут закрыть дело. У нас есть флажки для Проверенного кода, Проверенного инженера и Демонстрации заинтересованному лицу (в вашем случае Менеджер проекта). Если команда QA увидит случай, помеченный как «Готово», в котором не отмечены все эти поля, она отметит его как отмененный и отправит его нам.

После того, как дело прошло все эти этапы, и QA закрыло дело, любые обнаруженные проблемы регистрируются как ошибки.

Эта система, кажется, работает хорошо для нас.

Я думаю, что вы можете аргументировать оба пути. Я попытался бы сесть с премьер-министром и объяснить, почему вы думаете, что наличие отдельных проблем поможет вам. Я лично хочу, чтобы у каждого предмета был свой билет, но я понимаю, почему он так хочет.