Насколько хорошо Bugzilla работает для управления проектами Scrum? [закрытый]
У нас есть MS Sharepoint -- что не так уж плохо для управления списком задач. Данные общедоступны, люди уведомляются об изменениях и назначениях.
Я думаю, что Bugzilla может быть немного проще для целей управления и отчетности. Хотя есть некоторые хорошие инструменты управления Scrum с открытым исходным кодом, я потратил много своего политического капитала и не могу просить слишком много больше, чем у нас есть сейчас. Деньги-это не цель, очевидно, это идея, что моя команда слишком много специализированных инструментов.
будет ли Bugzilla работать как более общий инструмент управления проектами-вне случаев использования исправления ошибок?
буду ли я горько разочарован и хотел бы, чтобы я загрузил что-то еще и сделал свое дело для лучшего инструмента управления проектами?
4 ответов
Bugzilla-отличная система отслеживания ошибок. Мы пытались использовать его для других задач управления проектами и результаты менее чем звездной. Я бы рекомендовал найти что-то, разработанное с учетом ваших целей.
попробуйте сами.
получить $ 15/месяц счета на wush.net и используйте его на некоторое время (никаких деловых отношений, кроме довольного клиента).
Bugzilla является мощным и имеет много вариантов конфигурации, которые могут быть запутанными.
Я лично использовал его три года назад в проекте, над которым работал. У меня не было менеджера проекта, и я был разработчиком, поэтому мне нужна была очень легкая система. Бугзилла дал мне это. Я поставил свою главную цель как улучшение "productionalized system", а затем я сделал зависимости, чтобы достичь этой точки. В итоге у меня было 160 узлов, зависящих друг от друга. По сути, это была структура разбивки работ. Я не утруждал себя расчетами времени и не утруждал себя созданием какой-либо другой проектной документации.
классным преимуществом было то, что, как я закодировал, если бы я заметил, что что-то нужно сделать, я бы просто вставил его в bugzilla (20-секундный процесс после его настройки), свяжите его как зависимость, и вернуться к тому, что я делаю.
всякий раз, когда я выполнял задачу, я смотрел на диаграмму зависимостей и находил самые внешние листья (ошибки, которые блокировали другие, но сами не были заблокированы) и работал над этим.
преимущество этого метода для меня заключается в том, что если бы задача выглядела простой и имела один узел, связанный с ней, но при выполнении самой вещи я понял, что она более сложная, я бы просто разделил ее на разные подзадачи. Это заняло всего минуту и совершенно не предполагал встречи с руководителем проекта.
другие люди в команде могли отслеживать мой прогресс, глядя на открытые ошибки,закрытые ошибки, отсортированные по датам и т. д. Они увидели действие и оставили меня в покое. Когда у меня были внешние иждивенцы, я делал ошибку, детализировал работу и отправлял этому человеку ссылку по электронной почте. Затем они могли понять, почему это необходимо, посмотрев на диаграмму зависимостей.
обратите внимание, что если ранее не согласовано, я не назначил им жук.
Он работал очень хорошо, и система была готова на месяц раньше.
Как это будет работать с SCRUM? Я только бегло взглянул на scrum, я не могу вам сказать. Но таков был мой опыт.
использование выделенного хоста позволит вам три вещи:
- поддержка
- легкие обновления (если у вас нет гуру в доме, управление bugzilla не просто-для меня, по крайней мере)
- пользователи по всей организации границы.
обратите внимание, что bugzilla имеет всевозможные функции безопасности, поэтому легко заблокировать пользователей до того, что им нужно увидеть.
мы очень успешно использовали Trac и Subversion для нескольких проектов.
основным преимуществом здесь является возможность адаптировать отчеты, некоторые очень специфичные для Scrum, для предоставления информации руководству.
мое автономное решение-DokuWiki + MantisBT + Subversion + Review Board, которое может быть интегрировано с относительной легкостью. Размещенные альтернатива Bitbucket.org. Обоснование писать рассказы пользователей Вики и ссылаться на них конкретных задач. Большие ошибки могут быть разработаны совместно, и ссылка "wiki" предоставляется в отчете об ошибке Mantis. Обзорная доска позволяет вам делать одноранговые обзоры кода против svn diff до того, как изменение будет зафиксировано.