Как мне представить функции v. Задачи в FogBugz 6?

Question

В FogBugz 6, как я представляю понятия «функция» вместо «задача»? Как определено Джоэлем Спольски , владельцем Fog Creek Software (которая делает FogBugz), функция, по сути, является видимой для пользователя возможностью. Чтобы оценить время для реализации функции, разработчик должен разбить реализацию на короткие задачи (не более 2 дней), чтобы они думали о каждом шаге.

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

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

Answer 1

Для FogBugz 6.0 и более ранних версий:

Составьте кейс для каждого рабочего элемента (задачи). FogBugz называет их «Особенности», только чтобы отличить их от ошибок, но вы хотите один случай для каждой задачи.

Лучший способ сгруппировать кучу задач - сделать Релиз (Fix-For) и назначить все задачи этому релизу.

Answer 2

Ответ на комментарий / вопрос AviD к Джоэлу :

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

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

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

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

Тем не менее, я думаю, что пункт 6 является наиболее интересным, потому что именно здесь у вас действительно плотный график. Например, если у разработчиков возникают проблемы с оценкой более крупной задачи, они разбивают ее на подслучаи еще дальше. Обратите внимание, как моя оценка «наилучшего уровня полезности» может отличаться (возможно, сильно) от человека, которому действительно нужно выполнить работу.

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

PS: Создание личной цели, чтобы этот ответ был оценен выше, чем у Джоэла ....; -)

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

Answer 3

Возможно, вам удастся задать свои вопросы на FogBugz Дискуссионном форуме

Answer 4

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

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

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

Надеюсь, это поможет.

Answer 5

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

определенно должна быть какая-то продвинутая группировка задач в fogbugz.

Answer 6

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

Мы используем Fogbugz, и единственная известная мне «функция» относится к категории, и я не думаю, что вы можете связать ее с подзадачами.

Вы можете ввести «Дело N» - это функция для этой задачи, если вы просто хотели сослаться на нее в тексте дела.

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