прогресс для атомарных заданий — фикция, для агрегированных нужен лишь для отчетности и необходим только для каких-нить глубоковложенных разбиений, которые не охватить взглядом. Или если их много. В общем прогресс решает какие-то внешние по отношению к рабочему процессу проблемы.
приоритет для тасков нужен лишь на этапе планирования/перепланирования, хотя наверное важен для динамичных методологий. Но в целом малозначителен — важнее иметь зависимости.
Для багов нужен не приоритет а severity, хотя как ни называй… но это скорее в сторону отбражения SLA в трекинге.
Приоритеты нужны, а вот какие именно — очень интересный вопрос.
Пример — есть два проекта, можно занятся любым одним. Если у одного из них приоритет выше (например от реализации зависит выплаты по долгам/ЗП), то вопроса что делать не будет.
Прогресс тоже нужен, в аналогичной ситуации если есть проект с 99% — то лучше заняться им, а не распылятся на него и на другой у которого только 5% готово.
Мы не пользуемся ни приоритетом, ни прогрессом. У нас есть одно поле — срочность. Причём оно задано в виде цифры от минус бесконечности до плюс бесконечности — таким образом, в любой момент времени можно создать более срочный таск
My<cod/>.net
