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