Используем в нашей компании JIRA. Сейчас за каждым разработчиком числится по несколько десятков задач. Каждый раз, когда разработчик выполняет свою задачу, у него возникает ко мне (руководителю разработки) вопрос: какую задачу делать дальше?
И я беру весь список задач на этого человека, и каждый раз трачу время на то, чтобы определить, какая задача наиболее важна на данный момент.
Как мне оптимизировать решение этого момента? Что, по прежнему после выполнения каждой задачи говорить разработчику словами, что ему делать дальше? Или как-то можно обозначить список задач по приоритетам для этого разработчика?
Можно было бы решать вопрос приоритетами, но приоритетов в JIRA только 5. И задач каждого из приоритетов получается уже тоже по несколько штук (причем почти все из них являются Major).
Как все-таки определить разработчику, в каком порядке ему приступать к задачам?
Здравствуйте, VetalB, Вы писали:
VB>Всем привет!
VB>Используем в нашей компании JIRA. Сейчас за каждым разработчиком числится по несколько десятков задач. Каждый раз, когда разработчик выполняет свою задачу, у него возникает ко мне (руководителю разработки) вопрос: какую задачу делать дальше?
VB>Как все-таки определить разработчику, в каком порядке ему приступать к задачам?
Например, с помощью планирования релизов и roadmap-ов.
Здравствуйте, samius, Вы писали:
VB>>Как все-таки определить разработчику, в каком порядке ему приступать к задачам? S>Например, с помощью планирования релизов и roadmap-ов.
Это и так есть. Вот только на ближайший релиз у разработчиков уже по 5-6 задач висит в приоритете Major... А порядок этих задач в релизе имеет значение, так как некоторые из задач зависят от других задач, в том числе задач других разработчиков. А у меня нет никаких средств указать этот порядок, кроме того, что устно говорить после каждой задачи...
Здравствуйте, VetalB, Вы писали:
VB>Здравствуйте, samius, Вы писали:
VB>>>Как все-таки определить разработчику, в каком порядке ему приступать к задачам? S>>Например, с помощью планирования релизов и roadmap-ов.
VB>Это и так есть. Вот только на ближайший релиз у разработчиков уже по 5-6 задач висит в приоритете Major... А порядок этих задач в релизе имеет значение, так как некоторые из задач зависят от других задач, в том числе задач других разработчиков. А у меня нет никаких средств указать этот порядок, кроме того, что устно говорить после каждой задачи...
В JIRA есть возможность указывать зависимости задач.
Здравствуйте, samius, Вы писали:
VB>>Это и так есть. Вот только на ближайший релиз у разработчиков уже по 5-6 задач висит в приоритете Major... А порядок этих задач в релизе имеет значение, так как некоторые из задач зависят от других задач, в том числе задач других разработчиков. А у меня нет никаких средств указать этот порядок, кроме того, что устно говорить после каждой задачи... S>В JIRA есть возможность указывать зависимости задач.
И что? Допустим есть Саша и Сережа. Как Саше определять, что ему начинать делать? Например, у Саши 10 задач. 5 из них не зависят от других и другие не зависят от них. Две задачи зависят от задач Сережи. От трех задач зависят задачи Сережи. Как Саше определить, какую задачу ему делать в первую очередь?
Ведь некоторые задачи могут быть критичны не только потому, что от них зависят задачи Сережи, а от каких-нибудь внешних факторов, которые не отображены в JIRA (например, задача-эксперимент, от результатов выполнения которой зависят действия заказчика или проджект-менеджера, и дальнейший ход проекта). А если у него есть три задачи, от которых зависят задачи Сережи, то какую одну из них нужно начинать делать? ИМХО, алгоритм определения дальнейших работ должен быть однозначно и легко понятен для разработчика. Как быть?
Как по мне, здесь проджект-менеджер должен определять порядок действий каждого разработчика в зависимости от совокупности многих факторов. Вот только каким образом?
Здравствуйте, VetalB, Вы писали:
VB>Здравствуйте, samius, Вы писали:
VB>>>Это и так есть. Вот только на ближайший релиз у разработчиков уже по 5-6 задач висит в приоритете Major... А порядок этих задач в релизе имеет значение, так как некоторые из задач зависят от других задач, в том числе задач других разработчиков. А у меня нет никаких средств указать этот порядок, кроме того, что устно говорить после каждой задачи... S>>В JIRA есть возможность указывать зависимости задач.
VB>И что? Допустим есть Саша и Сережа. Как Саше определять, что ему начинать делать? Например, у Саши 10 задач. 5 из них не зависят от других и другие не зависят от них. Две задачи зависят от задач Сережи. От трех задач зависят задачи Сережи. Как Саше определить, какую задачу ему делать в первую очередь?
Если порядок не оговорен специально, то аналитически. Например, начать с тех задачь, от которых зависят другие задачи.
VB>Ведь некоторые задачи могут быть критичны не только потому, что от них зависят задачи Сережи, а от каких-нибудь внешних факторов, которые не отображены в JIRA (например, задача-эксперимент, от результатов выполнения которой зависят действия заказчика или проджект-менеджера, и дальнейший ход проекта).
Выполнение таких задач должно быть оговорено отдельно. Для большинства случаев возможностей JIRA вполне хватает.
VB>А если у него есть три задачи, от которых зависят задачи Сережи, то какую одну из них нужно начинать делать? ИМХО, алгоритм определения дальнейших работ должен быть однозначно и легко понятен для разработчика. Как быть?
Согласовать с Сережей.
VB>Как по мне, здесь проджект-менеджер должен определять порядок действий каждого разработчика в зависимости от совокупности многих факторов. Вот только каким образом?
Участием и общением. JIRA не заменяет общение с проджект-менеджером.
Например, разработчики начинают день с ознакомления с задачами. Потом 5-минутная оперативка с менеджером для уточнения формулировок, последовательности выполнения и пр. А потом, если разработчики будут вкурсе текущих задач и их актуальности не только по JIRA, то это упростит вопрос выбора задачи.
Здравствуйте, samius, Вы писали:
S>Участием и общением. JIRA не заменяет общение с проджект-менеджером.
Как по мне, много было бы вопросов автоматически снято, если бы можно было просто проджект-менеджеру вручную сортировать по важности все задачи одного приоритета. А при добавлении новой задачи чтобы проджект-менеджер просто определял бы место новой задачи в этом отсортированном списке. Это бы сэкономило кучу времени всем, а особенно проджект-менеджеру.
Наверное, буду такой список формировать при добавлении каждой задачи где-нибудь в Confluence, чтобы каждый разработчик видел, что ему делать в каждый момент времени... Как думаете?
Здравствуйте, VetalB, Вы писали:
VB>Здравствуйте, samius, Вы писали:
S>>Участием и общением. JIRA не заменяет общение с проджект-менеджером.
VB>Как по мне, много было бы вопросов автоматически снято, если бы можно было просто проджект-менеджеру вручную сортировать по важности все задачи одного приоритета. А при добавлении новой задачи чтобы проджект-менеджер просто определял бы место новой задачи в этом отсортированном списке. Это бы сэкономило кучу времени всем, а особенно проджект-менеджеру.
VB>Наверное, буду такой список формировать при добавлении каждой задачи где-нибудь в Confluence, чтобы каждый разработчик видел, что ему делать в каждый момент времени... Как думаете?
У вас разработчики маются от безделия, ссылаясь на неясность за что браться? В таком случае нужно что-то делать с мотивацией...
Если задачи запутываются в такой клубок, что без поллитра не понять, что за чем делать — тут надо что-то менять в планировании.
В позиции разработчика я рад наличию некоторой свободы при выборе задачи. Так есть шанс организовать работу с минимальными переключениями контекста (меньше времени чтобы врубиться в задачу и код). А если при выполнении задачи что-то где-то горит — то скорее всего позднее что-то придется переделывать.
Здравствуйте, samius, Вы писали:
VB>>Наверное, буду такой список формировать при добавлении каждой задачи где-нибудь в Confluence, чтобы каждый разработчик видел, что ему делать в каждый момент времени... Как думаете? S>У вас разработчики маются от безделия, ссылаясь на неясность за что браться? В таком случае нужно что-то делать с мотивацией...
Наоборот. Работы валом, и они хотят работать. Просто иногда берутся не за то, что оптимально с точки зрения менеджмента. Или же меня спрашивают что делать, потому что так неясно.
S>Если задачи запутываются в такой клубок, что без поллитра не понять, что за чем делать — тут надо что-то менять в планировании.
Так я ж вот поэтому и спрашиваю...
S>В позиции разработчика я рад наличию некоторой свободы при выборе задачи. Так есть шанс организовать работу с минимальными переключениями контекста (меньше времени чтобы врубиться в задачу и код). А если при выполнении задачи что-то где-то горит — то скорее всего позднее что-то придется переделывать.
Это я согласен. Но оптимальный порядок тоже нужно выбирать без танцев с бубнами...
Здравствуйте, VetalB, Вы писали:
VB>Как по мне, много было бы вопросов автоматически снято, если бы можно было просто проджект-менеджеру вручную сортировать по важности все задачи одного приоритета.
Здравствуйте, VetalB, Вы писали:
VB>Как мне оптимизировать решение этого момента? Что, по прежнему после выполнения каждой задачи говорить разработчику словами, что ему делать дальше? Или как-то можно обозначить список задач по приоритетам для этого разработчика?
1. Добавь к задачам CustomField "последовательность реализации" и вперед.
CustomField удобно редактировать прямо из фильтров, так что раскидать раз в две план работ — элементарно.
2. Посмотри на GreenHopper — это как раз планирование для Jira.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>1. Добавь к задачам CustomField "последовательность реализации" и вперед. ДФ>CustomField удобно редактировать прямо из фильтров, так что раскидать раз в две план работ — элементарно.
О, я к такому выводу и пришел самостоятельно! Сейчас так пока и делаю...
ДФ>2. Посмотри на GreenHopper — это как раз планирование для Jira.
Да смотрел уже когда-то... Вот только он платный, и стоит не копейки...
Здравствуйте, VetalB, Вы писали:
VB>Можно было бы решать вопрос приоритетами, но приоритетов в JIRA только 5. И задач каждого из приоритетов получается уже тоже по несколько штук (причем почти все из них являются Major).
Если задействованы не все приоритеты, значит, у вас проблема с трактовкой приоритета. Она должна быть достаточно точной. Простая схема:
1) У вас всегда два открытых релиза, один текущий, над которым вы работаете, второй — следующий. Выполнять надо только те задачи, которые приписаны к релизу.
2) Приоритет имеет следующее значение:
Приоритет 1 — задача выполняется вне плана, срочно. Результат приоритета 1 — хотфикс, который высылается клиенту вне очереди.
Приоритет 2 — без данного исправления релиз не выйдет.
Приоритет 3 — если исправление не успели сделать до окончания релиза, то он переходит на следующий релиз. Возможно, ему в этом случае будет поднят приоритет до 2, возможно нет.
3) Оптимальный порядок работ определяется на основании value-cost. То есть, в первую очередь делаются задания, имеющие максимальное соотношение значимости для клиента к затратам. Это означает, что Приоритет 1 надо понизить до 2 или 3 если дефект не удается исправить за разумное время. Потому, что тяжесть проявлений характеризуется не приоритетом, а severity.
Людям дается простая инструкция. Исправляете сначала текущий релиз, потом следущий. Работаете в порядке приоритетов. Дефекты с равным приоритетом — отбираете сами, начиная с самых легких и менее рискованных на ваш взгляд.
Вообще, это сложная тема. Я дал сейчас очень упрощенную схему работы группы поддержки, оставив за кадром схему работы тестеров и customer support, а также группы triage, которая планирует релизы. По сути, для нормальной работы вам надо сделать распределеный алгоритм планирования и принятия решений, и обработки дефектов, чтобы это работало как конвейр. Это сложная и интересная задача. Подумайте о критерии оптимальности, и о схеме принятия решения в целом.
Здравствуйте, VetalB, Вы писали:
VB>Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>>1. Добавь к задачам CustomField "последовательность реализации" и вперед. ДФ>>CustomField удобно редактировать прямо из фильтров, так что раскидать раз в две план работ — элементарно. VB>О, я к такому выводу и пришел самостоятельно! Сейчас так пока и делаю...
У нас это поле, "последовательность реализации", имеет тип "число с плавающей точкой",
чтобы можно было изменять порядок для одной задачи, не трогая остальные
А вообще IMHO это тоже отстой, и нифига толком не работает, т.к. это поле начинает противоречить приоритету
Было бы славно, если бы кто предложил более толковое решение, чем это..
