Kanban/Scrum Boards

Ответ 1

Мы используем что-то, вдохновленное известными Scrum и XP из траншей от Henrik Kniberg, причем столбцы адаптируются в зависимости от контекста (часто: TODO, ON GOING, TO TESTED, DONE):

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

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

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

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

Отлично работает.

Если вы ищете более "ориентированный на канбан" материал, возможно, посмотрите Kanban vs Scrum, Однажды в Канбанской земле и Kanban and Scrum - практическое руководство от того же Хенрика Книберга. Отличный материал тоже.

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

Ответ 2

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

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

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

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

Ответ 3

раскадровка Scrum/Extreme.

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

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

Имена столбцов: Не запускается, только что начато, на полпути, почти выполнено, готово к показу (передано QA)

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

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

Ответ 4

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

Ответ 5

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

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

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

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

и поле в углу для Blocked.

Пост-это записка представляла каждую историю.

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

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

Ответ 6

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

• У нас 6 разработчиков
• Когда рассказ находится в dev, он находится на dev-столе. Аналогично, когда вы проверяетесь, являетесь QA'd и т.д. Это означает, что каждая карта на доске представляет и действительный элемент, а также обеспечивает прилично точный снимок хода итерации. Правило состоит в том, что только в исключительных случаях у вас на столе больше одной карты.
• Мы согласились не иметь более двух карт "нагромождение" в столбце "Ожидание обзора". Это поддерживает степень "потока".

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 может 't QA элемент, пока мы не развернули его на своем сервере - мы развертываем 3/4 раза в течение 2-недельной итерации.

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

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

Ответ 7

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

| (Sprint) Backlog | In Progress | Done |

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

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

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

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

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

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

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

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

Ответ 8

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

История, не начатая, Req/Des/Dev *, Peer Review, QA, Done

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

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

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

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

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

Ответ 9

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

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

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

• Вручную перемещает сообщение, после чего становится больно. Наша команда QA в основном управляет перемещением билетов - и это постоянное усилие, чтобы синхронизировать их с TFS.
• Пост-он действительно может быть перемещен столько раз, прежде чем они больше не будут липкими. Если билет отправляется обратно из тестирования и помещается в "Выполняется", а затем возвращается к тестированию и т.д. И т.д.... для него не требуется многого, чтобы он оказался на полу.
• Иногда огромный объем заметок подавляющий. Заметки должны быть уложены в стек, чтобы быть даже удаленно видимыми - мы накладываем их таким образом, чтобы мы могли видеть каждый уникальный идентификатор примечаний (насколько это возможно)... но тогда у вас есть стопка из 10 заметок, и вам нужно получить 5-й из стека, и вы быстро вносите свой вклад в снижение липкости, которая закончится нотами на полу.
• Когда билеты заканчиваются на полу, это достаточно раздражает, чтобы узнать, куда они должны идти. Был ли этот билет разработчика? Или B? И это было в Тестировании? Или это было сделано? Вернитесь в TFS, найдите эти билеты, а затем переместите post-its соответственно.

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

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