Канбан/Scrum-доски

Мы используем что-то, вдохновленное знаменитым Scrum и XP from the Trenches. от Хенрика Книберга, столбцы адаптируются в зависимости от контекста (часто: ЗАДАЧА, В РАБОТЕ, ДЛЯ ПРОВЕРКИ, ГОТОВО):

http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png

Элементы невыполненной работы по продукту (PBI) печатаются в виде «физических карточек» (формат A5) для совещания по планированию спринта (по крайней мере, наиболее важные). После того, как команда выбрала PBI для следующей итерации, элементы разбиваются на задачи/действия (на стикерах). После встречи все отправляется на Scrum Board, и я предлагаю использовать скотч, кнопки или магниты. PBI упорядочены по важности, самые важные вверху доски, менее важные внизу. Команда должна сначала работать над самым важным пунктом, пока он не будет выполнен. Во-первых, активность после ее перемещения слева направо. Затем PBI переходит к Done. Неожиданные задачи добавляются в зону «Незапланированные задачи» (чтобы учесть их в диаграмме выгорания). Будущие PBI остаются видимыми в зоне «Далее» (если все элементы будут выполнены во время итерации, мы выберем оттуда новый). Довольно просто.

Эти приемы позволяют визуально обнаруживать запахи, например:

• зависшие задачи (т. е. задачи, которые не движутся), которые показывают потенциальное препятствие
• команда делает вещи в неправильном порядке и не фокусируется на первоочередных вещах, как на вашем образце :)
• слишком много работы в процессе, ничего не сделано
• незапланированные дела, которые убивают спринт

Прекрасно работает.

Если вы ищете материалы, более ориентированные на канбан, посмотрите Канбан против Скрама, Один день в стране Канбан и Канбан и Scrum — практическое руководство от того же Хенрика Книберга . Тоже отличные вещи.

И, чтобы получить больше изображений, попробуйте Google Images с помощью scrum+board, канбан, scrumban, scrum+kanban.

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

Мы не оцениваем Пользовательские Истории и Баги, а пытаемся разбить Истории на более мелкие (с переменным успехом). Столбцы говорят сами за себя. Мы накапливаем элементы в колонке Tested, затем создаем ветку, тестируем ее и выпускаем новую сборку. Обычно мы выпускаем новый билд каждые две недели.

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

УПД. Теперь у нас есть несколько небольших команд, и мы используем единую доску для отслеживания прогресса всех команд в http://www.targetprocess.com/3

Раскадровка Scrum/экстремального программирования.

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

Работа отображается во втором слева столбце и проходит через разные этапы завершения.

Имена столбцов: Не начато, Только что начато, На полпути, Почти готово, Готово к демонстрации (пройдено QA)

Первая строка специально зарезервирована для исправления ошибок — как фиксированный приоритет для устранения ошибок.

Персонажи Симпсонов представляют каждого члена команды. Они перемещаются, чтобы мы могли видеть, кто над чем работает.

Я предлагаю вам взглянуть на Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort он может удовлетворить все ваши потребности благодаря интуитивно понятному интерфейсу, статистике, приборной панели. Также он подходит для любого процесса и, самое главное, он очень прост в использовании. Эта доска позволяет представить несколько проектов на одной доске с помощью строк. Все строки могут быть видны одновременно или вы можете удалить выбранные из области видимости. Другим решением может быть группировка задач и фильтрация по категориям — тогда все задачи могут быть представлены на одной доске и в одной строке, но привязаны к разным категориям.

На практике организацию доски незавершенного производства лучше оставить команде, чтобы она определялась в зависимости от ваших обстоятельств и среды. (Agile == самоуправление.)

Тем не менее, вот что мы сделали в моей предыдущей команде, часть работы более 300 разработчиков, которая была относительно новой для Agile и Scum:

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

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

и ящик в углу для Blocked.

Стикеры представляли каждую историю.

У каждого из разработчиков был небольшой магнит, который они использовали каждое утро на стендапе, чтобы обозначить, кто над чем работает. Наша команда была довольно большой (~ 12 в какой-то момент), так что это действительно помогло выяснить, кто с кем в паре.

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

Мне очень нравится Lean/Kanban, и мы какое-то время повторяли наш процесс, первоначально через настраиваемый рабочий процесс в JIRA, но это не совсем гладко, учитывая сложность администрирования в корпоративной версии. Теперь мы расширили использование доски и решили некоторое время повторять наш процесс с использованием доски, прежде чем перекодировать его в JIRA. Вот пример нашего макета:

• Нас 6 разработчиков
• Когда история находится в разработке, она лежит на столе у ​​разработчиков. То же самое с рецензированием, контролем качества и т. д. Это означает, что каждая карточка на доске представляет собой элемент, требующий действий, а также обеспечивает достаточно точную картину хода итерации. Правило состоит в том, что только в исключительных случаях у вас на столе может быть больше одной карточки.
• Мы договорились, что в колонке «Ожидает проверки» не должно быть «стопки» более двух карт. Это поддерживает степень «потока».

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

Это очень похоже на сопоставление потока создания ценности, за исключением части ожидания развертывания, которая является хаком. чтобы исправить проблему, из-за которой QA не может проверить элемент, пока мы не развернём его на их сервере — мы развертываем 3/4 раза в течение 2-недельной итерации.

Я заметил одну вещь, сопоставляя поток создания ценности с «датчиком информации» заключается в том, что он волшебным образом фокусирует людей на фактической добавленной стоимости, которую необходимо выполнить, и это, кажется, ускоряет темпы развития ценности для бизнеса и поддерживает темп.

Надеюсь, это поможет!

Мы экспериментируем с несколькими различными структурами плат в нескольких разных проектах, которые мы выполняем. Один проект имеет самую простую структуру, которую мы можем использовать:

| (Sprint) Backlog | In Progress | Done |

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

Вышеупомянутая структура, казалось, работала нормально для разработчиков проекта, но члены QA изо всех сил пытались понять, когда работа над историей была завершена, чтобы они могли выполнить свои тесты для этой истории. Мы обнаружили, что перемещаем истории в «дальнюю сторону» раздела В процессе, чтобы показать, что работа разработчиков завершена и что QA может взять эту историю. Это очень быстро стало совершенно неуправляемым, так как раздел Выполняется заполнялся.

Это привело ко второй итерации структуры правления для другого проекта:

| (Sprint) Backlog | In Progress | Ready for Test | Done |

Недавно добавленный раздел Готово к тестированию, по сути, стал формальным разделом доски, который ранее был «дальней стороной» раздела Выполняется. На первый взгляд, это должно было прояснить ситуацию для членов отдела контроля качества, но все же вызвало некоторую путаницу, поскольку люди по-разному интерпретировали значение Ready for Test (не буду утомлять вас здесь разные толкования).

Затем это привело к последней итерации структуры платы, которую мы используем в другом проекте:

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |

Это, конечно, довольно далеко от простых разделов Backlog, In Progress и Done первой итерации, но, похоже, работает хорошо. для команды. У них есть четкое понимание того, что значит перемещать историю по различным разделам доски, и для любой истории это дает четкую картину того, где в жизненном цикле находится эта конкретная история. Мы используем эту структуру только с начала текущего спринта (у нас 9 дней в 10-дневном спринте), поэтому завтра мы рассмотрим эту структуру более подробно в нашей ретроспективе. Я уверен, что это не идеально, но если он продолжит работать в команде, которая его тестирует, мы попробуем распространить его на другие команды в нашей организации.

Наша доска разбита на следующие столбцы:

История, Не начато, Треб./Деск./Разработ.*, Экспертная оценка, Контроль качества, Готово

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

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

У нас также есть цветные вкладки для историй и задач, чтобы указать на препятствия для прогресса (синий цвет указывает на блокировку со стороны другой команды, красный — на помощь мастеру схватки). Мы говорим о блокпостах на каждом стендапе.

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

*Требования/Дизайн/Разработка

Наш довольно похож. У каждого разработчика есть столбец, а у нас есть строки для «Готово», «В тестировании», «В работе», «Незавершенная работа».

И мы используем настоящие заметки в стиле post-it, которые мы физически перемещаем по мере прохождения каждого этапа.

Лично мне системы не хватает...

• Перемещение стикеров вручную через некоторое время становится проблемой. Наша команда QA в основном занимается перемещением заявок, и мы постоянно стараемся синхронизировать их с TFS.
• На самом деле стикеры можно перемещать столько раз, прежде чем они перестанут быть липкими. Если заявка отправлена ​​обратно с тестирования и помещена в «В процессе», а затем перемещена обратно на тестирование и т. д., и т. д., для того, чтобы оказаться на полу, не требуется много времени.
• Иногда сам объем заметок ошеломляет. Заметки должны быть сложены, чтобы их можно было увидеть даже удаленно — мы накладываем их таким образом, чтобы видеть уникальный идентификатор каждой заметки (насколько это возможно)… но тогда у вас есть стопка из 10 заметок, и вам нужно получить 5-й из стека, и вы быстро способствуете уменьшению липкости, которая закончится нотами на полу.
• Когда билеты оказываются на полу, довольно утомительно выяснять, куда они должны идти. Это билет разработчика А? Или Б? И это было в Тестировании? Или это было сделано? Давайте вернемся в TFS, найдем эти билеты и переместим стикеры соответствующим образом.

Лично я не думаю, что стикеры для заметок — подходящий инструмент. Есть несколько цифровых инструментов, которые делают подобные вещи абсолютно беспроблемными. Мы используем Team Foundation Server, и я видел несколько действительно отличных, надежных, бесплатных инструментов с открытым исходным кодом, которые будут взаимодействовать с Team Foundation Server и управлять всем этим за вас в режиме реального времени.

http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Наши доски имеют тенденцию развиваться со временем, когда мы развиваемся как команда. Я склонен отдавать предпочтение физическим карточным доскам, если у вас есть совместная команда, поскольку это способствует лучшему общению лицом к лицу, как правило, исходя из моего опыта. Очевидно, что накладных расходов больше, но это того стоит, чтобы заставить команду работать вместе. Еще одно преимущество, которое я увидел в физических досках, заключается в том, что они помогают в бизнесе. Удаленные заинтересованные стороны не могут просто войти в систему и увидеть прогресс в текущем спринте и вырвать вещи из контекста, поскольку иногда карты не рассказывают полную историю. Они должны поговорить и выйти на доску, что может быть полезно, поскольку вещи могут быть объяснены, а также это означает, что их можно поощрять помочь решить препятствия. Однако это не относится только к физическим доскам, но помогает.

Как уже упоминалось, наши доски со временем развиваются вместе с потребностями команд. Часто мы начинаем со скрама по учебнику, но поощряем постоянное совершенствование и обычно заканчиваем скрам-решением. Эти изменения отражаются в визуализации нового рабочего процесса с помощью досок. Недавно я написал сообщение о наших последних изменениях, если вам интересно, посмотрите на нашу скрам в виде песочных часов/канбан-доска

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

Мы пошли со следующей структурой правления в нашей компании.

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

Дорожки назначаются конкретным участникам. У каждого участника своя работа в нашем офисе, поэтому задачи разные. Мы добавляем то, над чем нам нужно поработать, в наш Бэклог, а затем перемещаем его в Следующий Спринт, если он приближается к крайнему сроку. Заблокированные зеленые задачи используются для непрерывных задач, над которыми нужно работать ежедневно. Красные карточки указывают на важность задачи и должны быть выполнены как можно скорее. Наша доска позволяет нам свободно сотрудничать и добавлять задачи в дорожки друг друга, если нам нужно что-то сделать другим отделом.

Мы используем KanbanTool (Kanbantool.com) для визуализации нашего рабочего процесса и управления проектами. Он действительно интуитивно понятен и прост в использовании. Коммуникация в нашей команде значительно улучшилась.