Войти
ПрограммированиеФорумОбщее

Управление задачами проекта (4 стр)

Страницы: 1 2 3 4
#45
2:27, 27 июля 2015

Ghost2
> Какой смысл в багтрекере без интеграции с VCS?

А кстати да, какой смысл в непременной интеграции?
При том что задачи могут быть не связаны (напрямую, или вообще никак) с написанием кода.


#46
18:06, 27 июля 2015

rcsim
> А кстати да, какой смысл в непременной интеграции?
Чтобы иметь цельную базу знаний для проекта. Ты всегда можешь посмотреть, какие коммиты были сделаны для данной задачи (если были) и  с какой целью был сделан тот или иной коммит. Через пару лет когда ты полезешь поднимать старые таски это очень поможет. Ну и вообще, знание в какой именно ревизии/ветке баг был починен очень нужно. Если конечно ты ведешь одноразовые проекты на год-два, которые потом сдал и забыл, то понятно дело вообще нахер ничего не надо.

rcsim
> При том что задачи могут быть не связаны (напрямую, или вообще никак) с
> написанием кода.
Ну и прекрасно. Зато написание кода всегда связано напрямую с задачами.

#47
21:08, 27 июля 2015

9К720
> какие коммиты были сделаны для данной задачи
Я ведь вроде написал:
rcsim
> задачи могут быть не связаны (напрямую, или вообще никак) с написанием кода.

Я знаю, когда интеграция нужна. И написал о тех случаях, когда она НЕ нужна. Вот типичные примеры:
- Над проектом не работают кодеры.
- Над проектом работают не только кодеры.
- Над проектом работают кодеры, но стратегия работы не предполагает обязательной/однозначной связи revision# и issue#.

#48
21:37, 27 июля 2015

rcsim

> Над проектом не работают кодеры
Какой продукт выдают эти не кодеры?

#49
0:50, 28 июля 2015

rcsim
> И написал о тех случаях, когда она НЕ нужна. Вот типичные примеры:
> - Над проектом не работают кодеры.
> - Над проектом работают не только кодеры.
И что? И прекрасно. У этих некодеров нет отслеживания задач, они не знают что они делают сейчас и зачем делают этот коммит?


>- Над проектом работают кодеры, но стратегия работы не предполагает обязательной/однозначной связи revision# и issue#.
Это как? Каждый комитит что хочет, когда хочет, куда хочет, кто чем занимается непонятно... Это не стратегия, а дерьмо собачье.

#50
2:38, 28 июля 2015

Ghost2
> Какой продукт выдают эти не кодеры?

Да любой, где есть управление задачами. Услуги. CRM. Управление документтами. Биллинг.
Даже при создании ПО -элементарно тикеты техподдержки, техписатели, art-исты, архитекторы, менеджеры, сисадмины.

9К720
> ... и зачем делают этот коммит?
В третий раз пытаюсь сказать, что никакого комита может и не быть.

> Это как?
Это к примеру когда реп > 1. Когда есть промежуточные ревизии, не закрывающие задачу. Когда баг есть, а багрепорта нет. И масса других вариантов.

>>- Над проектом работают кодеры, но стратегия работы не предполагает обязательной/однозначной связи revision# и issue#.
> Каждый комитит что хочет, когда хочет, куда хочет, кто чем занимается непонятно....
Логики не понял. Как это связано?

#51
3:05, 28 июля 2015

rcsim
> В третий раз пытаюсь сказать, что никакого комита может и не быть.
И? Не любая же задача должна иметь коммит, но те в которых он (они) есть связывать надо.

#52
8:54, 28 июля 2015

rcsim
> В третий раз пытаюсь сказать, что никакого комита может и не быть.
Ну и прекрасно. У задачи может не быть комита, а у коммита ВСЕГДА есть задача. Для тебя разница непонятна что ли? Я это уже который раз пишу.
rcsim
> Когда баг есть, а багрепорта нет.
Значит багрепорт надо завести в системе контроля, и проставить ему теги.

rcsim
> Логики не понял. Как это связано?
Ещё раз, для особо одаренных. Если стол дубовый, он деревянный. Если стол деревянный, ещё не значит что он дубовый.
У задачи может не быть коммитов. Но у любого коммита есть задача, программисты же занимаются чем то, и менеджер разработки/лид знает чем, верно?
rcsim
> Когда есть промежуточные ревизии, не закрывающие задачу
Ну и у задачи будет несколько коммитов, из неё можно будет все их посмоплагины.

Интеграция не нужна в одном единственном случае - когда контроля версий в проекте нет, и в принципе не будет. Если говорить про CRM, то очевидно в системе управления проектами должна быть интеграция с CRM значит. Из любой таски должен быть способ перейти на профиль клиента, посмотреть список его покупок и т.д.

Jira короче, и пиши/качай к ней плагины. Я не знаю, что там тяжёлого у ТС, 10 баксов в месяц нет что ли.

#53
10:42, 28 июля 2015

Bishop
> Не любая же задача должна иметь коммит

Я именно так и говорил (в ответ на)
Ghost2
> Какой смысл в багтрекере без интеграции с VCS?

> но те в которых он (они) есть связывать надо.
И здесь полностью согласен.

9К720
> у коммита ВСЕГДА есть задача.
А для не особо внимательных, тема называется "Управление задачами проекта", т.е. про issue tracker, а не "Какие коменты писать в коммите".

#54
19:24, 28 июля 2015

rcsim
> И здесь полностью согласен.
rcsim
> какой смысл в непременной интеграции?
Ты уж определись.

rcsim
> а не "Какие коменты писать в коммите".
Ты как-то странно прыгаешь с темы на тему. Я разве говорил про то, какие комменты писать? (ну, если не считать того, что все известные мне системы связывают коммиты с тасками по комментам)

#55
21:33, 28 июля 2015

> rcsim
> > какой смысл в непременной интеграции?
9К720
> Ты уж определись.

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

Если кто не понял, моя мысль такова: баг-трекер и репозиторий - разные инструменты.
Да, их удобно (но не обязательно, а иногда в реалиях жизни невозможно) использовать совместно.
О чем и была моя фраза в ответ на
Ghost2
> Какой смысл в багтрекере без интеграции с VCS?
Которая удивительна еще и тем, что добавить кастом поле "revision_id" в задачу позволяют даже самые простецкие.

9К720
> Я разве говорил про то, какие комменты писать?
Если честно я вообще не понял, о чём ты говорил. Поскольку много шума про дерьмо собачье, и классификацию пород деревьев.

ps. Все системы, которые связывают, делают это опционально. Вопреки чьим-то догмам.

Страницы: 1 2 3 4
ПрограммированиеФорумОбщее

Тема в архиве.