Scrum и Fogbugz

Ответ 1

Теперь FogBugz (начиная с версии 7) поддерживает плагины, что значительно упростит использование Scrum.

Инструменты для Agile/Scrum

Ответ 2

Мы использовали FB для длинного времени, но недавно начали формализовать наше использование Scrum.

Нашел следующие вещи, ПОДЛЕЖАЩИЕ:

• Используется тег для каждого спринта Scrum.
• Спринт-тег вводится в каждый случай FB в этом спринте.
• У нас есть Wiki под названием "Scrum Sprint Reports"
• Внутри этой Wiki мы добавляем статью для каждого нового спринта (у нас есть их по неделям). Эта статья имеет те же теги, что и для спринта.

Затем следующие вещи помогают:

Во-первых, если вы просто выполняете поиск по тегу, вы найдете: все случаи и конкретную статью Wiki (которая даже в заголовке будет показывать вам цели)

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

Единственное, что мне не нравится в этом, это то, что я должен менять свои два фильтра каждую пятницу, но, по крайней мере, TGIF.

PS: Просто хотелось бы упомянуть, что редактор Wiki Wiki лучше, чем один в 7.0, но на самом деле должен быть версией 0.8. Это не менее 2 изданий от того, чтобы быть чем-то стабильным.

Ответ 3

После использования FOGBUGZ и JIRA для гибкости я решил, что ни один из инструментов не идеален для поддержки модели. Можете ли вы заставить работать. Да. JIRA на самом деле немного лучше из-за возможности настраивать больше (создавать истории пользователей и т.д.). Но если вы действительно хотите, чтобы ваша команда была в режиме SCRUM, вам нужно, чтобы все смотрели на график сгоревших, и все смотрели на отставание, и я думаю вы должны посмотреть на такие инструменты, как SCRUMWORKS. Базовая версия бесплатна, и она даст вам то, что вы хотите. Используйте JIRA и Fogbugz для того, что они должны были делать, отслеживать ошибки и запросы, но не быть полным инструментом управления SCRUM.

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

Ответ 4

На icanhascheezburger.com мы используем FogBugz, и мы обнаружили, что FogBugz отлично справляется со многими вещами, но он не так хорошо работает для гибкой разработки из коробки. Вот две вещи, которые мы делаем:

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

Мы также используем приоритет 7 для отставания. Чтобы найти все случаи отставания, просто выполните поиск:

priority:7 project:"project name"

API упростит работу с небольшим клиентом scrum.

Kanban плагин для FogBugz

Ответ 5

В настоящее время мы пытаемся опробовать FogBugz в проекте на основе SCRUM.

Мы все еще очень часто находим наши ноги с SCRUM (и FogBugz), поэтому то, что мы делаем, может быть не "чистым" SCRUM.

Прежде всего, мы используем Excel для отставания выпуска, например. что мы будем доставлять в версии x.xx

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

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

Мы сохраняем спецификации продукта в вики FogBugz и добавляем ссылки на это из каждой записи в отставании.

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

Прежде чем мы начнем спринт, мы выбираем, какие элементы отставания мы собираемся выполнить в этом спринте. В FogBugz я создаю новую версию и устанавливаю дату окончания на две недели. Затем мы разбиваем выбранные элементы отставания на задачи и добавляем их в выпуск как "элементы расписания".

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

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

Как вы видите, мы действительно просто используем FogBugz для управления задачами.

Мы выбрали его для EBS и Wiki.

Пока это работает очень хорошо, но проект, который я использую, это проект на 3 человека за 6 недель.

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

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

Ответ 6

FogBugz и Scrum работают вместе. Я думаю, что у вас вопросы хорошие, поэтому я буду придерживаться ответа на этот вопрос...

Как мы расставляем приоритеты в большом отставании с 7 уровнями приоритета, предоставляемыми Fogbugz? Мы можем изменить таблицы базы данных, чтобы добавить больше уровней, но является ли это подходящим в текущей/предполагаемой модели Fogbugz?

IMHO 7 слишком много для управления, я считаю, что верхние 3-4 являются управляемыми, и помимо этого я мог бы объединить все в один "более поздний" накопитель. Тем не менее, документация FogBugz или статьи KB иногда дают указания людям, которые добавили дополнительные уровни приоритета, поэтому, если FogBugz не собирается использовать вас, они, похоже, хорошо знают об этом и в основном поддерживают людей, которые это делают.

Как/где мы документируем цель спринта? У нас есть страница обзора "спринт" в вики для каждого проекта. Мы документируем самый последний спринт на вершине и делаем его одной огромной страницей (хотя, я думаю, мы в конечном итоге сохраним только последний год или что-то еще, так как эти страницы становятся ОГРОМНЫМИ). Спринт-обзор, который мы используем, прост и имеет набор полей, которые должны быть заполнены командой и PM. Перед спринтом мы документируем цель и SBL, после добавления полей для обзора.

Как мы документируем отмененный спринт?

На странице обзора спринта, упомянутой выше.

Как мы документируем обзор спринта? Как мы отслеживаем завершенные или отмененные спринты?

Я полагаю, вы можете догадаться, как мы имеем дело с этими двумя сейчас:)

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

-Скотт

Ответ 7

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

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

Ответ 8

Мы используем Scrumworks и JIRA.

SCRUM действительно не описывает, как вы реализуете процедуры QA/QC, часть гибкости может определять, улучшать, итерации процессов.

Ответ 9

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

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

Ответ 10

Мы используем FogBugz для scrum, используя "release" для backlog проекта, а затем создаем релизы для спринтов, перемещая элементы из выпуска backlog проекта в текущую версию спринта. У каждого элемента есть оценка, и из этого мы можем построить график сжигания, как показано в этом более раннем SO-вопросе.

Нет, это не идеально, но он работает достаточно хорошо.

Ответ 11

Trac с открытым исходным кодом имеет интеграцию FogBugz, а для части Scrum вы можете использовать Agilo for Scrum, который основан на trac и поддерживает Scrum всесторонне.