Работаю на большом проекте уже довольно давно и в системе управления проектом (JIRA) на мне (как и на многих других разработчиках нашей команды) скопилось куча тикетов, которые либо никто никогда не сможет сделать, либо никто никогда не будет делать либо они вообще ни о чём, а так "чтобы висело". В результате получается, что на человеке 18 тикетов, реально же он занимается двумя-тремя задачами, а может и вообще без работы по факту сидеть. Менеджмент о ситуации осведомлён, но глаза закрывает -- это как выкидывать из дома ненужный хлам, для каждой фигни когда возникает желание отнести её на помойку, возникает мысль "а вдруг когда-нибудь пригодится, а под рукой не будет", так и тут, даже откровенно мусорные тикеты что-то значат, просто взять и закрыть их нельзя, вдруг там через год всплывёт.
Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
Здравствуйте, Tilir, Вы писали:
T>возникает мысль "а вдруг когда-нибудь пригодится, а под рукой не будет", так и тут, даже откровенно мусорные тикеты что-то значат, просто взять и закрыть их нельзя, вдруг там через год всплывёт.
Проводить тотальную чистку хлама раз в полгода-год. Или в период по вкусу.
Не обращать внимания на вопли и стенания тех, кто говорит, что в этих тикетах содержится очень-очень нужная информация, которая когда-нибудь может пригодиться и так обходиться с тикетами — это попросту выкидывать важнейшие знания и опыт в мусорку. Обычно в этом усердствуют QA, обосновывая полезность и необходимость болтания в системе сотни некритичных багов.
А вообще, на самом деле, у вас ВСЕГО 18 тикетов на человека. Можно не париться, их даже администрировать легко. Вот когда за 50 переваливает...
Здравствуйте, Tilir, Вы писали:
T>Hi,
T>Работаю на большом проекте уже довольно давно и в системе управления проектом (JIRA) на мне (как и на многих других разработчиках нашей команды) скопилось куча тикетов, которые либо никто никогда не сможет сделать, либо никто никогда не будет делать либо они вообще ни о чём, а так "чтобы висело". В результате получается, что на человеке 18 тикетов, реально же он занимается двумя-тремя задачами, а может и вообще без работы по факту сидеть. Менеджмент о ситуации осведомлён, но глаза закрывает -- это как выкидывать из дома ненужный хлам, для каждой фигни когда возникает желание отнести её на помойку, возникает мысль "а вдруг когда-нибудь пригодится, а под рукой не будет", так и тут, даже откровенно мусорные тикеты что-то значат, просто взять и закрыть их нельзя, вдруг там через год всплывёт.
T>Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
T>--- T>With best regards, Konstantin
А кто сроки по задачам ставит исполнителям? Просто на исполнителе не должны висеть задачи без даты окончания или с просроченной датой. Соответсвенно все что без даты ( на будущее и т.д.) как хлам на антресоли ( в общий пул). А дальше пусть руководетель его планирует. Если по задачи никто не приходит с вопросом "когда же!!!", то они ни кому не надо. Если пришли — тогда договариваться о сроках.
Здравствуйте, Tilir, Вы писали: T>Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
Зарастать не нужно. На самом деле, весь хлам вместе со свежачком стоит взвалить на одного руководителя. В идеале — менеджера продукта или системы. Раз в недельку, а то и раз в две недельки его задача — отсортировать весь списочек с точки зрения бизнес-приоритетов. Если тикетов обычно собрается 100-200, то берем абстрактную цифру 1000, обзываем ее 1000 долларов, и просим этого руководителя разделить ее с точки зрения приоритетности между тикетами. Как правило, важное и горящее получит по 20-30 долларов, тогда как хламу может и по 1 не достанется.
Как только руководитель продукта готов с его оценками, собираем триаж-команду (обычно управляющий продуктом и старший команды программистов) — и на этот раз пробегая по списку сверху в низ делаем оценку трудоемкости. Сколько дней одному программисту потребуется на завершение данной работы. Вписали эти цифры. Кстати, эту работу можно делать параллельно. А на триаж митинг принести список, отсортированный по отношению долларовой оценки к часовой.
Таким образом перед вами будет лежать список требуемых к исполнению работ, отсортированный по принципу максимально полезного использования времени команды. На митинге иногда возникают несогласия — можно пересмотреть что-то, но после того, как обе стороны согласились с правильностью оценок, делается еще одна оценка — оценивается объем работ, который реально возможно завершить за неделю, скажем. Делается это просто, если в команде 5 программистов, и работают они по 40 часов в неделю каждый, то логично полагать, что команда успеет справиться только с первыми несколькими тикетами. Но зато они будут наиболее важные. Вот после этого начинается раздел тикетов. Лучше предоставить возможность команде выбирать, кто что делать будет. Тикеты берутся по мере важности, но добровольно. По завершению работы программист просто берет следующий тикет из списка.
После 5-6 таких циклов руководителю продукта надоедает самому тягать длинныый список хлама, и он тогда сам принимает решение сдать хлам в архив. Но это уже его проблемы.
Здравствуйте, Tilir, Вы писали:
T>Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
Что значит "выкидывать"? Закрытые таски вед не изымаются из БД, правда? Обычно весь хлам помечается особым образом (назначается milestone "Future", закрывается, ставится особый таг, name it yourself...) и отфильтровывается из запросов по-умолчанию. По желанию все такие задачи можно перекинуть на людей ответственных за то или иное направление, чтобы у них была возможность планировать работу подчиненным на время простоя (ели такой случится).
Здравствуйте, Tilir, Вы писали:
T>Hi,
T>Работаю на большом проекте уже довольно давно и в системе управления проектом (JIRA) на мне (как и на многих других разработчиках нашей команды) скопилось куча тикетов, которые либо никто никогда не сможет сделать, либо никто никогда не будет делать либо они вообще ни о чём, а так "чтобы висело".
Сделай еще статус. Хотя я бы разобрался с текущими
В джире можно сделать отдельную версию, "помойку", и туда сложить все тикеты. Затем можно перейти к двухнедельным (например) итерациям. На очередную итерацию создается версия в джире и планируются работы (переносятся тикеты из "помойки", создаются новые), раздаются соответственно таски/баги. Каждому члену команды раздается тикетов на 70/80 часов. В конце инерации подводятся итоги, что сделали, что нет и почему. Ну а какие работы, тикеты выполнять в первую очередь, определяется людьми, которые отвечают за развитие продукта.
Здравствуйте, Tilir, Вы писали:
T>Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
Если не бороться с сорняками, то скоро и полезного не будет заметно.
Важно найти для себя подходящий метод сортировки. Обычно она многоуровневая, то есть рассматриваем некритичный баг с различных сторон, возможно даже разными людьми. Цель — разместить их в различные группы, одна из которых "решено не исправлять". По изменению запросов группы можно иногда пересматривать, ну или, например, после очередного релиза.
Здравствуйте, Ведмедь, Вы писали:
В>А кто сроки по задачам ставит исполнителям? Просто на исполнителе не должны висеть задачи без даты окончания или с просроченной датой. Соответсвенно все что без даты ( на будущее и т.д.) как хлам на антресоли ( в общий пул). А дальше пусть руководетель его планирует. Если по задачи никто не приходит с вопросом "когда же!!!", то они ни кому не надо. Если пришли — тогда договариваться о сроках.
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, Ведмедь, Вы писали:
В>>А кто сроки по задачам ставит исполнителям? Просто на исполнителе не должны висеть задачи без даты окончания или с просроченной датой. Соответсвенно все что без даты ( на будущее и т.д.) как хлам на антресоли ( в общий пул). А дальше пусть руководетель его планирует. Если по задачи никто не приходит с вопросом "когда же!!!", то они ни кому не надо. Если пришли — тогда договариваться о сроках.
T>"Общий пул" это как?
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, Lloyd, Вы писали:
L>>Статус postponed в jira есть?
T>Нет. Только unresolved, resolved и closed (последнее после проверки автором тикета)
Плохо.
В Request Tracker есть явный статус hibernated с указанием момента автоматического выхода из этого статуса, а кроме того можно назначать дополнительные признаки.
В Bugzilla есть сложные статусы closed/later, closed/remind и так далее, по которым можно фильтровать и затем вручную поднимать нужное.
Если в Jira нет таких возможностей и не получается их легко добавить, с моей точки зрения она в принципе не выполняет своё назначение и потому подлежит замене.
BTW, "после проверки автором тикета" (если это единственный вариант) тоже грубая нелепость: для существенной части запросов это обязан быть не автор (который вообще мог уже уволиться), а внутренний QA.
N>Плохо. N>В Request Tracker есть явный статус hibernated с указанием момента автоматического выхода из этого статуса, а кроме того можно назначать дополнительные признаки. N>В Bugzilla есть сложные статусы closed/later, closed/remind и так далее, по которым можно фильтровать и затем вручную поднимать нужное. N>Если в Jira нет таких возможностей и не получается их легко добавить, с моей точки зрения она в принципе не выполняет своё назначение и потому подлежит замене.
Для Resolved есть resolution status. Можно туда добавить hibernated, три клика.
Здравствуйте, Tilir, Вы писали:
T>Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
Мы задачам, которые не собираемся делать в ближайшее время ставим Fix Version: Later и переводим на специального юзера Project Coordinator. Вобщем back log получается.
На програмистах обычно 1-2 режe 3-4 issue.
WBR, Igor Evgrafov
Re: Захламление дохлыми тикетами
От:
Аноним
Дата:
11.09.11 09:42
Оценка:
Здравствуйте, Tilir, Вы писали:
T>Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
В JIRA есть отличная штука — "резолюции". Закрываешь с резолюцией "не будет сделано". Потом всегда можно будет найти и переоткрыть.
Второй вариант — завести приоритет "когда-нибудь", "Не сегодня", или "Маньяна", и настроить фильтры так, чтобы задачи с этим приоритетом не мозолили глаза.
Здравствуйте, GarryIV, Вы писали:
T>>Вопрос -- тут тусуется много практикующих менеджеров. Вы как-нибудь боретесь с таким зарастанием ваших подчинённых сорняками или это нормальная практика?
GIV>Мы задачам, которые не собираемся делать в ближайшее время ставим Fix Version: Later и переводим на специального юзера Project Coordinator. Вобщем back log получается.
T>>Нет. Только unresolved, resolved и closed (последнее после проверки автором тикета)
N>Плохо. N>Если в Jira нет таких возможностей и не получается их легко добавить, с моей точки зрения она в принципе не выполняет своё назначение и потому подлежит замене. N>BTW, "после проверки автором тикета" (если это единственный вариант) тоже грубая нелепость: для существенной части запросов это обязан быть не автор (который вообще мог уже уволиться), а внутренний QA.
Не верьте! И насчет статусов и насчет проверки АВТОРОМ тикета. Статусов может быть сколько угодно и более того, может быть сколько угодно workflow, построенных на этих статусах. А закрывать работу может тот, кому это разрешено в Permission Scheme. Немножко надо матчасть изучить. Уж в гибкости настроек JIRA в лидерах.
А по теме решение включать такие задачи в спец. версию с датой релиза 31.12.2099 самое подходящее ИМНО Ну и пользователя можно сменить. Хотя это уже по вкусу.
Если дату поставить поближе — будет повод посмотреть на задачи и часть даже сделать. Далее можно подвинуть дату версии вперед, а лучше создать новую с датой следующей ревизии и закрыть старую. При этом есть опция перебросить в новую версию все незакрытые задачи.
Просто кто-то должен ее разгребать
