Использование системы отслеживания ошибок для обновления документации?

Question

Мы используем систему отслеживания проблем для отслеживания проблем с программным обеспечением: ошибок, новых функций, улучшений и т. Д. Очень часто изменение кода для решения проблемы требует обновления документации; например руководство пользователя, руководство по установке, процедура тестирования и т. д. Как правило, документация составляется другой группой людей - техническими авторами, группой обеспечения качества, - но для разработчика полезно дать краткий обзор необходимых изменений при решении проблемы. проблема исправлена.

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

1. Когда разработчик исправит ошибку, клонируйте как новую ошибку в компоненте «документация», обобщающем требуемое изменение документа.

2. Добавить состояние «документация в ожидании» в рабочий процесс между «разрешен» и «закрыт».

3. Добавьте настраиваемое логическое поле к проблемам, например, флаг «требуется обновление документации».

4. Добавьте настраиваемое текстовое поле к проблемам, содержащим предлагаемое резюме обновления.

Есть плюсы и минусы для каждого варианта; например # 1 приведет к большому количеству проблем, где обновление документации - это еще один шаг в рабочем процессе (# 2). С другой стороны, не все проблемы будут иметь обновление документа и должны пройти через рабочий процесс.

Какой метод вы считаете эффективным для отслеживания этих обновлений документации?

Answer 1

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

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

Answer 2

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

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

2. Лицо, ответственное заДокументация устраняет проблему и уведомляет правопреемника родительского вопроса о том, что он закончил.

3. Разработчик или руководитель проекта проверяют, что все в порядке, и наконец решают основную проблему.

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

Answer 3

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