Как я представляю функции v. задач в FogBugz 6?

Для FogBugz 6.0 и ранее:

Изложите доводы для каждого объекта работы (задача). FogBugz называет их "Функциями", только для различения их от ошибок, но Вы действительно хотите один случай для каждой задачи.

Лучший способ сгруппировать набор задач состоит в том, чтобы сделать Выпуск (Зафиксируйте - Для), и присвойте все задачи к тому выпуску.

Ответ на комментарий/вопрос AviD Joel:

Так, если у Вас есть 10 новых возможностей, существующих следующей версии с каждой функцией, нуждающейся в 5 задачах реализовать, Вы рекомендуете создать 10 выпусков? И как я определяю это, это функции / "выпуски", которые должны быть включены в предстоящий выпуск?

Вот то, как мы имели дело с этой определенной проблемой в нашем процессе разработки:

1. Во-первых, мы сделали обычный план выпуска: ежемесячные внутренние выпуски и ежеквартальные внешние выпуски. Это расписание никогда не изменяется, но присвоение задачи / завершение функции делает. Это чрезвычайно важно с точки зрения упрощения нашего межчеловеческого общения: не пытайтесь спорить с календарем.
2. Основные функции ("10 новых возможностей" в Вашем примере) превращены в случаи (например, случай 101 для преобразования регистра 110).
3. Каждая задача, которая является субкомпонентом основной функции также, создается как подслучай с описанием того, что делает этот блок из работы важной частью изображения большего размера. Ранее, в Fogbugz 6, мы использовали функцию "See also", позволив этому искать текст нас ("Это - субкомпонент случая 101", например). Это было эффективно тем же самым, но менее эстетичный.
4. Теперь, когда мы сломали работу к ее самому прекрасному уровню полноценности, мы приносим фактическим разработчикам в обсуждение. Каждая задача и основная функция индивидуально присвоены конкретному разработчику.
5. Разработчик определяет, когда они могли сделать свою порученную работу путем выбора соответствующей внутренней даты выпуска, что они думают, что могут согласиться.
6. На данном этапе у нас есть грубый эскиз того, что будет сделано для каждого выпуска. Дальнейшие улучшения продолжаются, поскольку трудящиеся на самом деле оценивают часы, что они должны будут сделать работу, включая планирование на основе фактических данных, и т.д.

Для вопроса AviD, тем не менее, ему решил бы проблему присвоения выпуска шаг 5 выше.

Однако я думаю, указывают 6, является самым интересным, как это - то, где Вы действительно получаете основательное расписание. Например, если разработчики испытывают затруднения при оценке большей задачи, они разламывают их на подслучаи еще больше. Заметьте, как моя оценка "самого прекрасного уровня полноценности" может отличаться (возможно, значительно) от человека, который действительно должен был сделать работу.

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

PS: Создание его персональная цель получить этот ответ, оцененный выше, чем Joel.... ;-)

PPS: Мой исходный ответ теперь преодолен событиями, так как Fogbugz 7 имеет прекрасные подзадачи. Диспетчеры программ любят те отчеты.

У Вас может быть лучшая удача при задавании вопросов в Дискуссионном форуме FogBugz

это - хороший вопрос, я попросил что сам, также.. мы в настоящее время тест-драйв fogbugz в течение 45 дней в группе из 5 разработчиков, и мы в настоящее время создаем "выпуск" для основных функций. на самом деле мы не выпускаем его, но несколько выпусков вместе, когда что-то готово.

должна определенно быть своего рода усовершенствованная задача, группирующаяся в fogbugz.

ха-ха, та статья имеет правовую оговорку, но я понимаю то, что Вы говорите.

Мы используем Fogbugz и единственную 'Функцию', о которой я знаю, находится под категорией, и я не думаю, что Вы можете, связал его с подзадачами.

Можно ввести в 'Случае N', функция этой задачи, если Вы просто хотели сослаться на него в тексте случая.

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

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

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

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

Надежда, которая помогает.