ре-фиксы в Канбане

[Pavel Aksonov]

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

Вот после тестинга или ревью тикет отправлен на доработку (ре-фикс). Это должна быть отдельная колонка? И у нее должен
быть выше приоритет чем у SELECTED ? То есть команда не берет новые пока есть ре-фиксы? Лимит ставить на эту колонку отдельно
или на весь девелопмент целиком?

Павел.

[Alexey Krivitsky]

что если возвращать в in progress с высоким приоритетом и пометкой (тегом), что это рефикс?

2009/12/7 Pavel Aksonov <aks...@gmail.com>

[Alexey Krivitsky]

в лине есть концепция "stop the line"
- когда при нахождении дефекта останавливается конвейер, дефект чиниться как срочно-важно и принимаются корректирующие действия для избежания возникновения подобных проблем.

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

2009/12/7 Alexey Krivitsky <alexeyk...@gmail.com>

[Alimenkou Nikolay]

Я бы выделил тут несколько случаев:

1) Задача еще в стадии девелопмента, но одна из последних колонок
называется "Код ревью". В этом случае я бы никуда ее не двигал, а
лимит выставлял бы на всю девелопмент стадию целиком. Тогда все
произошло бы натурально. А именно, данная задача мешала бы брать новые
и значит быстро бы пофиксилась.

2) Если же задача ушла на тестирование и в ней нашли проблемы. Тут все
чуть по-другому. Если проблемы могут быть сформулированы как баги, то
я бы ее не двигал (потому что фиксы надо будет тестировать), а баги с
максимальным приоритетом пихал в очередь на реализацию. Есть подход,
описанный Лешей, когда задача не двигается, а на нее наклеиваются
баги, о чем сообщается команде разработчиков. Это становится их
задачей номер 1. И опять же натурально, потому что тестировщик не
может взять больше, значит девелоперы не могут им отдать, а значит
вынуждены сначала пофиксить ботлнек.

3) Я бы советовал в случае ревью кода делать его парно и вместе сразу
же по горячим следам исправлять код. В таком случае риск того что
задача зависла в статусе не будет.

[Tim Yevgrashyn]

Согласен, что не нужна еще одна колонка.

Ре-фикс должен вернуться обратно в предыдущую колонку. (Development, in progress и ли как у вас называется).

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

С приоритетами тоже все само собой решилось - по идее "старый" реквест в статусе To Deploy уже автоматом имел более высокий приоритет чем любое, что еще не взято. Т.е. если мы его вернули, то он горячий и фиксим срочно. Да и здравый смысл подсказывает, что это нельзя откладывать.

Пытаемся все прикрутить к гринхопперу, пока хвастаться рано.

Tim Yevgrashyn,

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

2009/12/7 Alexey Krivitsky <alexeyk...@gmail.com>

[Yuriy Mann]

Всем привет.

Как раз разговаривал с Колей Алименковым на эту тему в субботу -
интересовался, как делают они. Оказалось, тема востребована :) Что
очевидно.

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

Вариант 1.
Для ревью и тестирования - отдельные колонки. В каждой колонке,
включая девелопмент, задачи расположены сверху вних по приоритетам. В
каждой есть рекомендованный максимальный WIP. Если найдены баги,
задача никуда не двигается, но остается в текущей колонке со своим
приоритетом. Собственно, гайдлайнами для выбора задач служат WIP и
приоритет. Смысл отдельной колонки для теста в том, что тестер как
специализированный ресурс не может выполнять многие работы по
программированию, поэтому для него - отдельный WIP, но с учетом того,
что в той же колонке лежат проверенные задачи с открытыми багами.

Вариант 2.
На весь девелопмент одна колонка. Важен приоритет (сверзу вниз) и
общий WIP. Девелоперы и тестер сами разбираются, что в какой стадии.
Пытались наклеивать бумажки разного цвета для разных стадий, чтобы
считать WIP для стадий, не двигая задачи, но это оказалось неудобным.

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

On Dec 7, 5:00 pm, Tim Yevgrashyn <yevgras...@gmail.com> wrote:
> Согласен, что не нужна еще одна колонка.
>
> Ре-фикс должен вернуться обратно в предыдущую колонку. (Development, in
> progress и ли как у вас называется).
> Возможно будет цепная подвижка, чтобы не нарушить ограничения, хотя наша
> личная практика показала, что такое редкость - обычно просто движение
> происходит синхронно и новый реквест не берется, а старый отодвигается
> одновременно.
>
> С приоритетами тоже все само собой решилось - по идее "старый" реквест в
> статусе To Deploy уже автоматом имел более высокий приоритет чем любое, что
> еще не взято. Т.е. если мы его вернули, то он горячий и фиксим срочно. Да и
> здравый смысл подсказывает, что это нельзя откладывать.
>
> Пытаемся все прикрутить к гринхопперу, пока хвастаться рано.
>
> Tim Yevgrashyn,
>
> Web:http://tim.com.ua
> Skype: spidertim
> Phone: +380 67 408 53 30
>

> 2009/12/7 Alexey Krivitsky <alexeykrivit...@gmail.com>

>
> > в лине есть концепция "stop the line"
> > - когда при нахождении дефекта останавливается конвейер, дефект чиниться
> > как срочно-важно и принимаются корректирующие действия для избежания
> > возникновения подобных проблем.
>
> > так что я думаю такие вещи должны как-то вытеснять все остальные задачи,
> > которые в работе.
>

> > 2009/12/7 Alexey Krivitsky <alexeykrivit...@gmail.com>

>
> > что если возвращать в in progress с высоким приоритетом и пометкой (тегом),
> >> что это рефикс?
>

> >> 2009/12/7 Pavel Aksonov <akso...@gmail.com>

[Tim Yevgrashyn]

Мне понравилась идея одного WIP на блок Development с возможными фазами внутри. Т.е. coding, review - будут колонки второго уровня.

В статье Хенрика были рисунки, кажется в Колиной презентации тоже похожие были. 

Я так понял, это почти тоже, что Юра описал в Варианте 2. 

Нужно у себя попробовать - действительно девелоперы 

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

Tim Yevgrashyn,

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

2009/12/8 Yuriy Mann <yury...@gmail.com>

[Alexey Krivitsky]

А вы не боитесь слишком сложной доски в этом случае?

Я бы попробовал цветные теги на разные фазы. Или отдельные стикеры для задачи coding, задачи review и т.д.

Леша

2009/12/8 Tim Yevgrashyn <yevgr...@gmail.com>

Мне понравилась идея одного WIP на блок Development с возможными фазами внутри. Т.е. coding, review - будут колонки второго уровня.

В статье Хенрика были рисунки, кажется в Колиной презентации тоже похожие были. 

Я так понял, это почти тоже, что Юра описал в Варианте 2. 

Нужно у себя попробовать - действительно девелоперы 

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

Tim Yevgrashyn,

Web: http://tim.com.ua

Skype: spidertie

[Tim Yevgrashyn]

Да, при первоначальном моделировании доска выглядит внушительно.

С другой стороны, мы вынуждены использовать визуальную тулзу, так как команда распределенная, примерно 50/50. В ходе обсуждения все сказали, что проще много колонок, чем угадывать по цветам и т.п....

Пока пробуем. Думаю в течении пары месяцев будут практические результаты. Расскажу как нибудь при случае. 

Tim Yevgrashyn,

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

2009/12/8 Alexey Krivitsky <alexeyk...@gmail.com>

[Yuriy Mann]

Про разноцветные бумажки, соответствующие стадиям: как я уже сказал,
мы пробовали. Не понравилось. Та команда, которая пробовала,
продолжает просто хранить все в одной колонке, без разделения на
стадии и под-колонки.

Второй команде (которая держит колонку для каждой стадии) сегодня
порекомендовал помечать бумажками без изменения колонки то, что не
прошло тестирование/ревью. По рекомендации Леши и Коли выше.
Посмотрим, как работает.

On Dec 8, 2:05 pm, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> А вы не боитесь слишком сложной доски в этом случае?
>
> Я бы попробовал цветные теги на разные фазы. Или отдельные стикеры для
> задачи coding, задачи review и т.д.
>
> Леша
>

> 2009/12/8 Tim Yevgrashyn <yevgras...@gmail.com>

>
> > Мне понравилась идея одного WIP на блок Development с возможными фазами
> > внутри. Т.е. coding, review - будут колонки второго уровня.
> > В статье Хенрика были рисунки, кажется в Колиной презентации тоже похожие
> > были.
>
> > Я так понял, это почти тоже, что Юра описал в Варианте 2.
>
> > Нужно у себя попробовать - действительно девелоперы
> > разберуться между собой, а уже следующие фазы типа "подготовка к
> > продакшену" и "деплой" будут отдельными колонками со своими WIP.
>
> > Tim Yevgrashyn,
>
> > Web:http://tim.com.ua
> > Skype: spidertie
> > Phone: +380 67 408 53 30
>

> > 2009/12/8 Yuriy Mann <yurym...@gmail.com>

[Alexey Krivitsky]

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

Что именно вы отображаете на доске - состояние спринта или беклог продукта?

Если спринта - то что если распределенные команды имели бы "каждая свой" спринт и таким образом пользовались каждая своей живой доской?

Плз расскажи, что заставляет вас использовать тулзу вместо доски.

Лёша

2009/12/8 Tim Yevgrashyn <yevgr...@gmail.com>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Tim Yevgrashyn]

Мы работаем как одна команда и мы не собираемся вводить команду "там" и "тут". Это не самый удачный подход, даже Юта Экштейн об этом упоминала.

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

Канбанизация (т.е. визуализация + лимит на WIP) нашего процесса привела к тому, что мы всего лишь расширили количество колонок, дабы четче видеть состояние каждого элемента бэклога. 

P.S.

Кстати, офф-топик и _не_ реклама. Я обнаружил, что в последней версии GreenHopper ввели понятие ограничения количества элементов в колонке. Т.е. ту самую канбан-метку. Если попробуешь переместить в эту колонку карточек больше лимита, то система уведомит об этом. Все следят за "модой" :-)

Tim Yevgrashyn,

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

2009/12/12 Alexey Krivitsky <alexeyk...@gmail.com>

--

[Alimenkou Nikolay]

Выложил свою презентацию тут: http://www.slideshare.net/alimenkou/kanban-vs-scrum-2725721.
Если у кого остались неотвеченные вопросы - пишите в личку.

[Alexey Krivitsky]

Думаю, если вопросы хорошие, то можно и публичку.

Крв

2009/12/16 Alimenkou Nikolay <lumii.su...@gmail.com>

[Alimenkou Nikolay]

Да, если есть что обсудить - конечно создавайте отдельные топики.

On 16 дек, 00:12, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> Думаю, если вопросы хорошие, то можно и публичку.
>
> Крв
>

> 2009/12/16 Alimenkou Nikolay <lumii.subscri...@gmail.com>

>
>
>
> > Выложил свою презентацию тут:
> >http://www.slideshare.net/alimenkou/kanban-vs-scrum-2725721.
> > Если у кого остались неотвеченные вопросы - пишите в личку.
>
> > On 7 дек, 15:24, Pavel Aksonov <akso...@gmail.com> wrote:
> > > Прежде всего хочу сказать спасибо Коле за продвижения Канбана в массы на
> > > IT-Jam и хороший доклад!
> > > Вопрос к знатокам.
>
> > > Вот после тестинга или ревью тикет отправлен на доработку (ре-фикс). Это
> > > должна быть отдельная колонка? И у нее должен
> > > быть выше приоритет чем у SELECTED ? То есть команда не берет новые пока
> > > есть ре-фиксы? Лимит ставить на эту колонку отдельно
> > > или на весь девелопмент целиком?
>
> > > Павел.
>
> > --

> > 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<agile-ukraine%2Bunsubscribe@goog legroups.com>