"возраст" тикета в GreenHopper

[Pavel Aksonov]

Вопрос немного специфический для тех кто работает используя GreenHopper

Как отобразить "возраст" тикета (то есть сколько дней он уже "висит" от даты создания) на электронной доске? Намечается ситуация когда есть два тикета с одинаковым приоритетом но с разным возрастом и иногда берется тот, который моложе. Дыроколы бы помогли с этим на настоящей доске, а вот как быть тут?

Я вижу что можно показать только Due Date то это поле не устанавливается автоматически и вообще, это немного не то.

[Pavel Aksonov]

Вопрос снимается - 1 марта вышла версия 4.3 где уже можно добавлять в "карточки" какие угодно jira поля, а не только из их набора (где даже не было creation date).

Также там сделали просмотр нескольких проектов на одной "доске".


05.03.2010, в 11:35, Pavel Aksonov написал(а):

[Borys Lebeda]

Круто раз уже появилось! - Я такое всегда хотел и использовал тег {sql}:

http://atriplex-on-software.blogspot.com/2009/03/jira-studio-tips.html

см. другие примеры полезных запросов здесь http://confluence.atlassian.com/display/JIRA/Example+SQL+queries+for+JIRA

2010/3/5 Pavel Aksonov <aks...@gmail.com>

Вопрос немного специфический для тех кто работает используя GreenHopper

Как отобразить "возраст" тикета (то есть сколько дней он уже "висит" от даты создания) на электронной доске? Намечается ситуация когда есть два тикета с одинаковым приоритетом но с разным возрастом и иногда берется тот, который моложе. Дыроколы бы помогли с этим на настоящей доске, а вот как быть тут?

Я вижу что можно показать только Due Date то это поле не устанавливается автоматически и вообще, это немного не то.

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Borys L.

[Tim Yevgrashyn]

Как вариант, если пока нет возможности обновиться до 4.3 (как у меня),
то можно использовать "Sorted fields".

Зайти в настройки GreenHopper, там в General панели будет секция
"Sorted fields" - это дополнительные поля по которые можно
использовать в Context для сортировки списка.

Если настроить дополнительные контексты, то списки в Planning Board и
Task Board можно отсортировать и по дате создания. Более того, можно
переключать контексты, только в тот момент, когда вам нужно уточнить
какая из историй "старее".

[Pavel Aksonov]

Спасибо!

Еще один вопрос "вдогонку"
Еще мои программисты предложили интересную идею - разделить In progress на стадии девелопмента - создание тестов, реализация, документация, тестирование, selenium, коммит. Таким образом можно четко отследить статус и затраченное время на стадию.

JIRA workflow это позволяет? (иерархию состояний, где in progress - родительское состояние)
Собственно вопрос - возможно ли создать контексты которые будут показывать только in progress "в развороте" (полезно для самого программиста) или наоборот где in progress будет свернут (для общего view, так сказать).


10.03.2010, в 17:14, Tim Yevgrashyn написал(а):

[Vova Oros]

On 10 Бер, 21:18, Pavel Aksonov <akso...@gmail.com> wrote:
> Спасибо!
>
> Еще один вопрос "вдогонку"
> Еще мои программисты предложили интересную идею - разделить In progress на стадии девелопмента - создание тестов, реализация, документация, тестирование, selenium, коммит. Таким образом можно четко отследить статус и затраченное время на стадию.
>

Мне кажется, что это плохая идея, вводить кучу новых состояний:

создание тестов, реализация, документация, тестирование, selenium,

коммит. Лучше разбить на раздельные задачи. Тем более что разработкой,
тестированием и документированием обычно занимаются разные люди.

[Pavel Aksonov]

У нас разработчики пишут юнит тесты, они же пишут javadocs и wiki / UML диаграммы к своим классам и они же пишут селениум тесты если затронут слой view.

Так же коммит может занять какое-то время если коммитятся несколько тикетов одновременно (teamcity Remote Run + merge + Remote RUn again..)

10.03.2010, в 22:54, Vova Oros написал(а):

[Ilya Sviridov]

2010/3/10 Vova Oros <pep...@gmail.com>

Привет всем

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

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

Минусы которые видно:

- много людей работает над задачей, поэтому ворк лог становится общим, т.е. получить время затраченное отдельным испонителем не удобно (такого плагина/функции не знаю идеи?)

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

Если такой flow не нужен в конкретной задаче, всегда можно перевести в конечное сосотояние.

Насчет "(иерархию состояний, где in progress - родительское состояние)" такого не видел.

Удачи

Илья

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
With best regards
Ilya  Sviridov

[Tim Yevgrashyn]

Павел,

Мы сами в ходе обсуждений с командой пришли к желанию визуализировать именно "состояния". Т.е. выделить отдельно Ready-Ready, In Progress, Done, Tested, Deployed. Это визуализация потока, можно сказать в стиле Канбан.

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

Сразу скажу, что связка JIRA+GreenHopper (желательно версии 4 и выше) прекрасно позволяет решить эту задачу.

Сама JIRA позволяет реализовать _любой_ Workflow, который вам нужен. Я просто создал новый и там добавил новых статусов и переходов между ними.

С GreenHopper еще проще - его TaskBoard настраивается и там можно для каждой колонки указать какие статусы отображать. Таким образом придуманный вами workflow легко визуализировать.

Более того, с 4й версии GreenHopper совсем "оканбанился" - они даже способ отображения TaskBoard так и назвали: Compact (Kanban). К тому же они ввели возможность ограничений на каждую колонку. Т.е. вы можете ограничить по количеству элементов (задач в работе), по оставшемуся времени, по Story Points (если используете это доп. поле).

Ну и практический совет - хорошенько подумайте, что выносить в колонки(статусы), а что действительно можно решать на уровне подзадач. Если будет больше 7 колонок, то просто визуально карточки будет сложно прочитать. Плюс, если будут "ненужные" фазы, то постоянно будете их перескакивать и люди будут только раздражаться.

С другой стороны, не бойтесь экспериментировать - мы потратили несколько часов только на обсуждение какие фазы нам нужны и до сих пор регулярно пересматриваем и подправляем новый workflow ;-)

Tim Yevgrashyn,

Web: http://tim.com.ua
Skype: spidertim
Phone: +380 67 408 53 30

2010/3/10 Pavel Aksonov <aks...@gmail.com>

[Oleg Iavorskyi]

Павел,

Мне кажется тут стоит задать себе вопрос, а какую информацию набор этих состояний будет давать команде? Все-таки дополнительных усилий по изменению тикетов в Greenhopper будет гораздо больше и, в случае если каждый член команды не следует практике перевода состояний безукоризненно, это может привести к неактуальной информации.

[Pavel Aksonov]

Мой вопрос чисто практический - возможно ли несколько вью одной и той же таскбоард для разных людей? Например часто мне нужно ли просто видеть что "в разработке". А иногда - на какой стадии в разработке те или иные тикеты. Greenhoper не позволяет иметь одновременно иметь "детализированные" колонки и общую "in progress" колонку которая бы объединила все под-стадии разработки - он  говорит что "уже есть колонку с таким состоянием".

Мы уже отдельно выделили deployed, tested, done, in progress, todo, need info (эта колонка появилась недавно - тикеты которые требуют уточнения, каких-то действий, зависимости и т.д.). То есть сейчас 6 колонок. Вот есть желание разбить in progress на unit tests, implementation, docs (wiki), commit

Такое желание обусловлено тем, что иногда разработчики элементарно забывают написать документацию и обновить wiki. 

Языком RDBMS я бы хотел выделить калькулируемое поле "In progress" которое бы объединило выше сказанные колонки. Тогда бы кто хочет увидеть общую картину - скрыли бы "детальные колонки" и открыли бы "агрегируемое" in progress.

11.03.2010, в 9:26, Tim Yevgrashyn написал(а):

[Tim Yevgrashyn]

Павел,

В описанной вами ситуации я бы предложил ввести дополнительные статусы (или просто дополнительные поля вида Yes/No).

Гринхоппер оставляете с такими же колонками, а с помощью Filter делаете себе выборку по нужному статусу и вешаете ее на свой Dashboard.

Некоторые выборки можно сделать общими и попросить всех вывести на свои дашборды.

Tim Yevgrashyn,

Web: http://tim.com.ua
Skype: spidertim
Phone: +380 67 408 53 30

2010/3/11 Pavel Aksonov <aks...@gmail.com>

[Pavel Aksonov]

Можно по-подробнее про статусы? Есть желание использовать workflow по-полной, то есть разработчик не сможет отдать тикет на тестирование если он не перенес его вначале в wiki/docs например. Изменять статусы (если я правильно понял Tested? Documented? Implemented?) наверное тоже можно но скорее всего не очень удобно (удобнее конечно "перетащить" карточку)

11.03.2010, в 14:59, Tim Yevgrashyn написал(а):

[Tim Yevgrashyn]

Павел, 

Если вопрос про дополнительные статусы все еще актуален, то попробую вкратце рассказать устройство JIRA+GreenHopper...

Если зайти в раздел администрирования JIRA, то там будет отдельный раздел "Statuses". Это общий справочник для всей системы, хотя дальше в конкретных Workflow могут использоваться только статусы, нужные вашей команде и вы не будете мешать другим.

Дальше вам нужно создать новый Workflow, который является описанием возможных переходов (Transitions) из статуса в статус. Можно, кстати, добавить всякие дополнительные проверки и действия для каждого перехода (например, заполненность нужного поля и т.п.)

В рамках Workflow Schema для каждого типа Issue (Feature, sub-task, Bug, Change и т.п.) присваивается свой workflow. В простейшем случае, вы можете использовать один workflow для всех типов Issue.

Ну и дальше, отдельно взятому проекту присваивается workflow schema с которой он и работает.

Таким образом, при желании, вы можете сделать новый Workflow, который будет использовать нужные вам статусы. Применить его на проекте, посмотреть и потом подправить.

GreenHopper настраивается еще проще. В конкретном проекте, заходите в конфигурацию GreenHopper (ссылка доступна в Planning или Task Board, если есть права) и там есть закладка "Task Board Mapping". Можно сделать произвольное количество колонок и каждой колонке указываются конкретные статусы, которые она может содержать. Когда делаете Drag&Drop из колонки в колонку, то работает Workflow по тем переходам, которые вы создали. 

Например, если есть переход из Done в Tested, то при перетаскивании из колонки в колонку меняется статус. Если колонка содержит больше чем один статус - появится выбор транзакции и т.п.

В целом все просто. Я потратил день на "придумывание" переходов и пару часов на конфигурацию.

Отдельный совет - сначала подумайте о вашем workflow на бумаге в виде колонок и договоритесь, что каждая колонка для вас означает. Колонка - это как очередь и если мыслить "в стиле Канбан", то нужно думать о том, зачем вы делаете эту очередь и кто отвечает за то, чтобы она опустошалась.

[Pavel Aksonov]

Спасибо, это я понял, просто не понял (и не понимаю), как это может помочь сделать разные виды доски - одна для менеджера (ему не важно, на каком именно этапе разработки (unit тесты, документация, implementation) находится тикет, нужно просто посмотреть что он in progress,

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

23.03.2010, в 14:27, Tim Yevgrashyn написал(а):

To unsubscribe from this group, send email to agile-ukraine+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Tim Yevgrashyn]

Да, Task Board один и он для команды.

Для Владельца Продукта (Product Owner) есть Planning board и плюс контекстные фильтры, которые он себе сам сделал.

Также ВП сделал себе фильтр и смотрит его на Dashboard. Причем в JIRA 4 появилась возможность выбирать какие колонки хочешь видеть и это ему дает всю необходимую информацию.

Также он себе сделал фильтр по Done статусу, чтобы своевременно реагировать.

Главное решить, чего вы хотите.

Tim Yevgrashyn,

Web: http://tim.com.ua
Skype: spidertim
Phone: +380 67 408 53 30

2010/3/23 Pavel Aksonov <aks...@gmail.com>