Каковы некоторые подходы к организации задач в Pivotal Tracker?

Question

Мы только начали использовать Pivotal Tracker для управления нашим списком задач для нашего основного приложения. Недавно мы запустили огромную новую функцию, поэтому последние 50 или около того задач связаны с этой функцией.

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

Итак, как вы можете организовать задачи в Pivotal Tracker (или в другой системе, если это необходимо)?

Вы создаете теги для каждой функции и каждого выпуска? Если ошибка связана с функцией, помечаете ли вы ее как таковую? Где вы проводите черту между тегируемой функцией и простым клиентским запросом?

Спасибо! Я очень хочу услышать ваши мысли!

Answer 1

Tracker является очень продуманным программным обеспечением, и он лучше всего работает с собственным конкретным рабочим процессом.Есть довольно подробное объяснительное видео на http://bit.ly/conceptsofpivotaltracker

Краткий ответ на ваш конкретный вопрос «Как вы организуете задачи?»:

• ярлык Feature Stories для группыих в треки (например, если вы собирали Amazon, треками могут быть такие вещи, как «Корзина», «Оплата», «Управление запасами» и «Рекомендации».).

• использовать Маркеры релизов (это другой тип истории, например, Feature или Bug) для обозначения релизов.Маркерами релиза обычно являются такие вещи, как «Показать инвесторам», «Корзина завершена», «Начать бета-тестирование» или «v2».

В вашем случае я бы дал эти 50задает метку "огромная новая функция" и делает исправление ошибкой.