Как реализовать Пользовательские истории в Bugzilla? [закрытый]
несколько человек у меня на работе собрались вместе, чтобы сформировать группу, целью которой является анализ преимуществ внедрения некоторые разработки / управления проектами принципы.
Как разработчик, я вижу большую пользу в пользовательских историй. Мы хотим собрать информационный радиатор, который можно использовать для мониторинга этапов текущего выпуска и планирования будущих выпусков. Я хотел бы использовать пользовательские истории для этого процесса.
сейчас мы использование Bugzilla для отслеживания проблем. Большая часть планирования выпуска выполняется с использованием ошибок из этой системы. Использование Bugzilla, вероятно, не изменится. Он обеспечивает большую часть того, что нужно по нужной цене ($0).
одной из проблем является сопоставление Пользовательских историй с ошибками. Управление релизами в настоящее время выполняется с использованием номеров ошибок. Проблема в том, что одна история пользователя может включать три ошибки или наоборот.
в случае наличия нескольких ошибок для одного пользователя один идея состоит в том, чтобы иметь ошибку истории пользователя, которая излагает историю и устанавливает зависимости от дочерних ошибок, которые составляют эту историю. Я беспокоюсь, что это может оказаться слишком сложным и создать путаницу среди заинтересованных сторон, развития и QA. Кроме того, это будет загромождать Bugzilla совсем немного.
кто-нибудь уже был на этой дороге? Если да, то что вы сделали? Должен ли я отказаться от идеи Пользовательских историй в Bugzilla? Есть ли более простое решение?
любые мысли были бы оцененный.
3 ответов
Я делал подобные вещи раньше в Bugzilla, и решение, которое я нашел, не заключалось в реализации иерархических "ошибок истории" или тому подобного; мы также решили, что это вызовет путаницу и просто слишком сложно для того, что мы хотели. Решение, которое я использовал раньше, было просто поместить номер истории пользователя в описание ошибки; вы также можете бросить ссылку туда, чтобы облегчить разыменование. Это немного patchworkish, но он работает довольно хорошо.
Я бы сказал, что если вашим историям пользователей нужно больше одного случая ошибки - они слишком большие. С хорошей абстракцией требуемой функциональности вы можете разделить свои истории пользователей на меньшие, которые требуют только одного случая на историю, а затем планировать и действовать таким образом.
мы попытались использовать подход @McWafflestix описывает, со ссылками из случаев на официальный (wiki) документ истории пользователя, но через некоторое время мы обнаружили, что создание меньшего пользовательские истории лучше - это также приводит к лучшему дизайну приложения, потому что каждая пользовательская история реализуется как можно более абстрактно, обеспечивая лучшую тестируемость и ремонтопригодность кода.
независимо от того, используются ли ссылки зависимостей в Bugzilla для отслеживания истории, я настоятельно рекомендую использовать ключевое слово в ваших историях. Мы используем слово "история". Использование ключевого слова позволяет легко отслеживать истории и ошибки в деревьях продуктов. Я бы также рекомендовал использовать отслеживание времени в установке Bugzilla; даже если время отслеживается только на историях.