Нет, проектов как раз много, и на каждом свой бэк-лог, причем достаточно большой (несколько десятков задач).
Вы могли бы сделать скриншот типового талона в Вашем рэдмайне, чтобы понять схему использования?
А откуда взялось ограничение на один день? Я, например, не вижу проблем, если сложная задача на 200 часов разработки будет выполняться в одном талоне. Тут важную роль, на мой взгляд, играет квалификация исполнителя: если это junior, то ему надо давать максимально детализированные и декомпозированные задачи. А опытному сотруднику можно дать и задачу в общем виде, чтобы он решал ее целостно, думал на 2 шага вперед. Консолидация всех комментариев, данных о коммитах (при настроенной интеграции с VCS) в дальнейшем позволит значительно эффективнее восстановить историю работы с задачей.
Но при этом вторая предложенная мной схема позволяет декомпозировать единую задачу разработки на подзадачи типа «Разработка», длительность каждой из которых будет менее 8 часов, если так построен Ваш рабочий процесс.
А тут в одной задаче целый мини-проект.
Действительно, задача типа «Общая задача» может рассматриваться как мини-проект. Опять же, не вижу ничего страшного. если редмайн будет инструментом не только для разработчиков. но и для менеджеров :-) Как минимум, исполнителям это никак не помешает выполнять свои задачи.
Спасибо за ссылку. Нет, не пробовали, в ближайшее время посмотрю.
У нас в компании не используют Scrum в чистом виде. Да и я сам не ярый его сторонник, но некоторые возможности, думаю, будут полезны
Мы достаточно давно использовали Рэдмайн, но не было единой концепции его применения. Т.е. были трекеры типа «Ошибка», «Улучшение», «Консультация» и схемами перехода типа «из любого состояния в любое». С одной стороны, это удобно, поскольку ни руководитель, ни исполнитель никогда не ощущали никаких ограничений в своей работе. С другой стороны, это не позволяло выстроить процесс, когда, например, задача перед началом разработки обязательно должна была пройти через системного аналитика, либо перед закрытием обязательно пройти через тестирование.
Данная схема в первой версии также не имеет совсем жестких ограничений, однако тут есть хотя бы общая идея, которую я описал.
Извиняюсь за задержку с ответом — этой мой первый пост, ожидал подтверждения прохождения модерации на почту, а тут оказывается все уже пройдено :-)
По первым двум пунктам, к сожалению, согласен :-(
Плюсы — в универсальности. Предполагается (и в принципе ожидания оправдались), что каждый проект или отдел сможет выстроить удобную для себя схему, применяя предложенный инструмент. И при этом не нужно будет выдумывать совсем индивидуальные схемы для каждого.
Мы работаем по второй схеме, но не с подзадачами, а со связями между задачами и объединением задач в проекты/версии.
Вы имеете в виду, что не используете типы деятельности как трекеры? Или все же используете?
Все задачи, которые планируется взять в работу (не зависимо от того, когда работы реально начнутся) вводятся в систему сразу или менеджер/ответственный за проект вводит задачи по мере начала работ с ними?
Задачи обычно вводятся сразу, по мере поступления информации. Они образуют бэклог (висят неназначенные в статусе «Новая»). Я считаю, что задачи должны поступать в трекер, как только становится о них известно. поскольку это позволяет оценивать и планировать объем работ.
Как исполнитель узнает, что через некоторое время ему придется активно поработать?
Мы как раз стараемся исполнителя отгородить от этого. У нас фиксированные рабочий день по 8 часов, и исполнителю всегда будет работа. к чему ему знать размер бэклога? По предложенной схеме исполнитель получает задачи в статусах «В очереди» либо «Готова к <вид деятельности>». Я сторонник коротких недельных спринтов (мы их называем оперативными планами), т.е. каждому исполнителю составляется очередь задач на неделю (набираем суммарную трудоемкость в 32 часа с буфером). Подробнее о том, как реализуем работу с этими оперативными планами, напишу в ближайшее время и выложу сюда ссылку.
Вы могли бы сделать скриншот типового талона в Вашем рэдмайне, чтобы понять схему использования?
Но при этом вторая предложенная мной схема позволяет декомпозировать единую задачу разработки на подзадачи типа «Разработка», длительность каждой из которых будет менее 8 часов, если так построен Ваш рабочий процесс.
Действительно, задача типа «Общая задача» может рассматриваться как мини-проект. Опять же, не вижу ничего страшного. если редмайн будет инструментом не только для разработчиков. но и для менеджеров :-) Как минимум, исполнителям это никак не помешает выполнять свои задачи.
У нас в компании не используют Scrum в чистом виде. Да и я сам не ярый его сторонник, но некоторые возможности, думаю, будут полезны
Данная схема в первой версии также не имеет совсем жестких ограничений, однако тут есть хотя бы общая идея, которую я описал.
По первым двум пунктам, к сожалению, согласен :-(
Плюсы — в универсальности. Предполагается (и в принципе ожидания оправдались), что каждый проект или отдел сможет выстроить удобную для себя схему, применяя предложенный инструмент. И при этом не нужно будет выдумывать совсем индивидуальные схемы для каждого.
Вы имеете в виду, что не используете типы деятельности как трекеры? Или все же используете?
Задачи обычно вводятся сразу, по мере поступления информации. Они образуют бэклог (висят неназначенные в статусе «Новая»). Я считаю, что задачи должны поступать в трекер, как только становится о них известно. поскольку это позволяет оценивать и планировать объем работ.
Мы как раз стараемся исполнителя отгородить от этого. У нас фиксированные рабочий день по 8 часов, и исполнителю всегда будет работа. к чему ему знать размер бэклога? По предложенной схеме исполнитель получает задачи в статусах «В очереди» либо «Готова к <вид деятельности>». Я сторонник коротких недельных спринтов (мы их называем оперативными планами), т.е. каждому исполнителю составляется очередь задач на неделю (набираем суммарную трудоемкость в 32 часа с буфером). Подробнее о том, как реализуем работу с этими оперативными планами, напишу в ближайшее время и выложу сюда ссылку.