А давайте мерятся абстрактными числами

[metaclass]

У кого сколько задач в баг-трекере? У меня получается так:
За последний год/два года:
123/178 открытых
240/450 закрытых

У ребе belnetmon за аналогичные периоды:
13/18 открытых
216/540 закрытых

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

PS: А теперь, внезапно, кто больше всех работает: kometa_zxc
47/0 открытых
274/575 закрытых

Comments

[metaclass.livejournal.com]

Subversion и Mercurial

[wildman.livejournal.com]

счастливчики (по поводу hg), бедные (по поводу svn) :)

зы. столкнулся с хреновой поддержкой git редмайном :(

[berezovsky.livejournal.com]

[vp.livejournal.com]

А мы не смешиваем редмайн с VCS, как-то считаем, что эти вещи должны жить разной жизнью.
А вам оно зачем? :)

Зы до сих пор не пришли к единому мнению, что когда лучше использовать, свн или хг.

[vp.livejournal.com]

обратите внимание. Макбук.

[vp.livejournal.com]

Только взял в руки макбук = хопа! сразу же сзади пристроился мужик.

[wildman.livejournal.com]

для своих поделий я юзаю git
на работе т.к. корпоративный стандарт svn - юзаю git-svn

редмайн в комплекте с vcs позволяет быстро просматтривать какие коммиты с каким багом т.к. поддерживает распознавание номеров багов в комментариях к коммитам
не киллерфича, но приятное дополнение

[metaclass.livejournal.com]

Кто тебе сказал что не смешиваем?:)
Я периодически code review делаю в редмайне.

[zelanton.livejournal.com]

я к тому что сравнение будет точно так же ничего не значащим. У кого-то в багтрекере куча херни, у кого-то пара-тройка мегазадач.

[vp.livejournal.com]

Мегазадачи разбиваются на подзадачи

[zelanton.livejournal.com]

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

[bydl0coder.livejournal.com]

лучше youtrack.
redmine очень плохой и фиг переедешь с него.

[dair-spb.livejournal.com]

Спасибо, узнал, что JetBrains делает и это тоже.

Но youtrack стоит денег, увы. Денег мне не дадут :-)
И ещё это Java, которую к серверной стороне подпускать не хочется.

[mr-s-o-u-l.livejournal.com]

ммм,если не затруднит, просвятите вообще, и в чем собсно проблема переезда частности?

[vp.livejournal.com]

Я не думаю, что на порядки. Смысл багтрекера как средства учета рабочего времени (работы наз конкретной задачи) тогда сильно теряется. Хотя да, бывают большие куски, но желательно, конечно, чтобы по этому делу однозначно оценивалась активность работника, а не висящее 1 год задание типа "сделать все" :)

[zelanton.livejournal.com]

Система планирования.
Во-первых учёт прошедшего времени задача менее приоритетная, чем грамотное планирование времени будущего. Кроме собственно механического распределения работ это даёт менеджерам удобный инструмент для определения наличия ресурсов и расстановки приоритетов.
Во-вторых в подобных системах более развиты средства собственно оценки (отчёты и т.п.)
В-третьих, календари, обсуждения лучше интегрируются именно с системами планирования.
В-пятых системы планирования лучше интегрируются с канцелярским документообором.

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

А дублировать смысла нет, актуальная информация должна быть в одном месте.

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

А в багтреккере висит задача например "переписать продукт такой-то под, хехе, облако, срок 4 месяца, ответственный тот-то". Больше там ничего не нужно.

И глубина детализации планов отличается очень значительно, именно что на порядки. Особенно это от характера задачи зависит.

[vp.livejournal.com]

Мы привычно называем словом "багтрекер". На самом деле, пользуемся системой управления проектами. Там и планы, и контроль активности, не только баги. Целых два раздела - сугубо информация о клиентах, например. Там же ведется трекинг обслуживания.

[zelanton.livejournal.com]

а, ну тогда ок

[zelanton.livejournal.com]

у нас багтреккер - отдельная система. Туда автоматом складываются текущие баги, и хотелки и связанная с ними переписка. Конкретные планы - отдельно.

[vp.livejournal.com]

А чем вы пользуетесь для управления проектами?

[zelanton.livejournal.com]

менеджеры от внедрения и маркетинга - MS Project
менеджеры от программирования - частично MS Project, частично собственная разработка.

[bydl0coder.livejournal.com]

например в том, что стандартные экспортеры не понимают русские буквы. из базы чото как-то не хочется.

[zelanton.livejournal.com]

Причём багтреккеров тоже два - один helpdesk для автоматизации работы с почтой, второй - на базе собственной разработки, благо разрабатываемая система управления данными позволяет и не такое. Собственно "собственная система управления проектами" сейчас в её контексте реализуется.

То есть контекст внешнего взаимодействия с клиентами слегка отделён от внутренней кухни. Оно тесно взаимодействует, хотя там ещё есть над чем работать.

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

[mr-s-o-u-l.livejournal.com]

Ну рсс у меня отлично работал искаропки, а пдф пропатчил за минут по мануалу. кстати о базах =там yaml-ом их можно оч. неплохо переконвертить если что.
а под чем стартовали -под апачем или под монгрелом?

[bydl0coder.livejournal.com]

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