Если коротко, там описывается как они используют jira для разработки confluence:
====
1) При подготовке к выпуску очередной версии они печатают все интересные баги.
2) Потом девелоперы разбирают эти бумажки, читают их и пишут каким-нибудь ярким фломастером сколько времени может занять исправление баги.
3) Опять смотрят и перебирают бумажки, может что-то нужно исправить в оценках ?
4) Находят кусок стены и вешают туда эти бумажки (фотка стены прилагается). Причем вешают не просто так, а группируют по функциональности.
5) А теперь работаем:
- девелопер снимает бумажку со стены и работает с этой задачей.
- девелопер не должен работать ни с чем, чего нет на стене.
- если появилась какая-то непредусмотренная задача, то ее нужно сначала внести в jira, распечатать, повесить на стену.
- когда с задачей закончили, девелопер складывает ее в отдельное место и пишет сколько на самом деле времени у него на задачу ушло.
===
Отзывы как все круто и насколько это прогрессивная методика поскипаны :-)
Если такое количество работы по управлению проектами (назначение ответственных, оценка сроков, оценка состояния проекта и т.п.) проходит мимо jira, значит там что-то с этим нечисто :-)
ИМХО в данном проекте JIRA выступает как CRM, т.е. с клиентов собираются требования, все управление проектом идет "на бумажках", а потом в JIRA клиентам сообщается что сделано, а что нет. Это очень хорошо видно по их hosted-системе - там баги обычно закрываются массово прямо перед релизом или через несколько дней после, это верный признак что туда данные просто переносятся из какого-то другого источника информации. Теперь понятно из какого :-)
Можно и для каждой задачи создавать свой набор статусов, и строить иерархические зависимости между задачами любого вида (внутри проекта может быть версия, но внутри версии проект создавать нельзя), и параллельно/последовательно задачи выполнять.
http://fishbowl.pastiche.org/2005/09/28/…
Если коротко, там описывается как они используют jira для разработки confluence:
====
1) При подготовке к выпуску очередной версии они печатают все интересные баги.
2) Потом девелоперы разбирают эти бумажки, читают их и пишут каким-нибудь ярким фломастером сколько времени может занять исправление баги.
3) Опять смотрят и перебирают бумажки, может что-то нужно исправить в оценках ?
4) Находят кусок стены и вешают туда эти бумажки (фотка стены прилагается). Причем вешают не просто так, а группируют по функциональности.
5) А теперь работаем:
- девелопер снимает бумажку со стены и работает с этой задачей.
- девелопер не должен работать ни с чем, чего нет на стене.
- если появилась какая-то непредусмотренная задача, то ее нужно сначала внести в jira, распечатать, повесить на стену.
- когда с задачей закончили, девелопер складывает ее в отдельное место и пишет сколько на самом деле времени у него на задачу ушло.
===
Отзывы как все круто и насколько это прогрессивная методика поскипаны :-)
Если такое количество работы по управлению проектами (назначение ответственных, оценка сроков, оценка состояния проекта и т.п.) проходит мимо jira, значит там что-то с этим нечисто :-)
ИМХО в данном проекте JIRA выступает как CRM, т.е. с клиентов собираются требования, все управление проектом идет "на бумажках", а потом в JIRA клиентам сообщается что сделано, а что нет. Это очень хорошо видно по их hosted-системе - там баги обычно закрываются массово прямо перед релизом или через несколько дней после, это верный признак что туда данные просто переносятся из какого-то другого источника информации. Теперь понятно из какого :-)
Подзадачи и статусы можно легко совмещать, пример реализации см. тут
http://www.trackstudio.ru/products.html
Можно и для каждой задачи создавать свой набор статусов, и строить иерархические зависимости между задачами любого вида (внутри проекта может быть версия, но внутри версии проект создавать нельзя), и параллельно/последовательно задачи выполнять.