Канбан / Скрам Доски
Мне любопытно, что другие люди используют для физических плат Kanban/Scrum в своих компаниях. Я ценю, что из-за конфиденциальной деловой информации вы не сможете предоставить фотографию доски объявлений. Я смотрю, чтобы узнать, как выглядит ваша доска объявлений, и как вы организуете пользовательские истории и задачи, когда они проходят типичный спринт / итерацию?
Обычно я работал в местах, которые организовывают доску следующим образом с каждым
User Story | Todo | In Progress | Ready for QA | Done |
UC-001 | Domain Object, Service | DAO(Bob) | | |
UC-002 | Payment UI Screen | | Payment Srv (Don)| |
UC-003 | | | UC-003 | |
| | | | UC-004 |
| | | | UC-005 |
Итак, подведем итог:
- Задание для UC-001 выполняется одним из членов команды (Бобом). Список задач, которые другие люди должны выполнить, находится в столбце "Тодо", но его может взять другой член команды, который координирует свою работу с Бобом, чтобы выполнить работу.
- Для UC-002 задача платежного сервиса была выполнена, и для QA было выполнено автоматическое тестирование, позволяющее им тестировать сервис без UI. Если тест не пройден, ошибка поднимается и перемещается вместе с задачей "Платежный сервис" обратно в фазу QA
- Все задачи для UC-003 были выполнены и перемещены в Ready for QA.
- Все задачи для Uc-004 и UC-005 были выполнены, поэтому пользовательская история была перемещена в Готово.
Это работает как осязаемая белая доска, которая вовлекает людей, взаимодействующих с каждой из задач / пользовательских историй (представленных в виде заметок). Электронная версия создается до спринта / итерации и обновляется только в конце спринта / итерации, соответствующей текущей ситуации. Комментарии и критика приветствуются:)
11 ответов
Мы используем что-то, вдохновленное знаменитыми Scrum и XP из Trenches от Henrik Kniberg, колонки адаптируются в зависимости от контекста (часто: TODO, ON GOING, TO TESTED, DONE):
http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png
Элементы журнала незавершенного производства (PBI) печатаются как "физические карточки" (формат A5) для совещания по планированию спринта (по крайней мере, самое важное). После того, как команда выбрала PBI для следующей итерации, элементы разбиваются на задачи / действия (на заметках). После встречи все идет на Scrum Board, и я предлагаю использовать магнитофон или магнитофон. PBI упорядочены по важности, наиболее важные в верхней части платы, менее важные в нижней части. Команда должна сначала работать над самым важным пунктом, пока он не будет выполнен. Во-первых, активность после ее перемещения слева направо. Затем PBI переходит к Готово. Неожиданные задачи добавляются в зону "Незапланированные предметы" (чтобы учесть их в таблице выгорания). Будущие PBI остаются видимыми в "следующей" зоне (если все элементы завершены во время итерации, мы выбираем новый). Довольно просто
Эти практики позволяют визуально обнаружить запахи, например:
- зависшие задачи (то есть задачи, которые не движутся), которые показывают потенциальное препятствие
- команда делает вещи в неправильном порядке и не сосредотачивается на приоритетных предметах, как на вашем образце:)
- слишком много работы в процессе, ничего не сделано
- незапланированные предметы, которые убивают спринт
Работает отлично.
Если вы ищете более "ориентированный на канбан" материал, возможно, взгляните на Канбан против Скрама, " Один день на Канбан-Ланде" и " Канбан и Скрам" - практическое руководство от того же Хенрика Книберга. Отличная вещь тоже.
А для большего количества изображений попробуйте Google Images с scrum + board, kanban, scrumban, scrum + kanban.
Вот наша доска Канбан, которую мы используем в TargetProcess. Мы работаем не на уровне задач, а только на уровне пользовательских историй и ошибок. Иногда мы создаем задачи, но они явно не отслеживаются на доске.
Мы не оцениваем пользовательские истории и ошибки, но пытаемся разделить истории на более мелкие (со смешанным успехом). Столбцы говорят сами за себя. Мы накапливаем элементы в столбце Tested, затем создаем ветку, тестируем ее и выпускаем новую сборку. Обычно мы выпускаем новую сборку каждые две недели.
Также на плате показаны загруженность разработчиков и тестеров и классы сервисов с помощью цветовой кодировки.
UPD. Теперь у нас есть несколько небольших команд и мы используем одну доску для отслеживания прогресса всех команд на http://www.targetprocess.com/3
Scrum / Extreme программирование раскадровки.
http://www.flickr.com/photos/dafydd_ll_rees/4138686549/
Работа появляется на втором-от левого столбца, и прогрессирует через доску через различные стадии завершенности.
Названия столбцов: не начато, только начато, на полпути, почти готово, готово к демонстрации (пройдено тестирование)
Первая строка специально зарезервирована для исправления ошибок - как фиксированный, приоритет для устранения ошибок.
Персонажи Симпсонов представляют каждого члена команды. Они перемещаются, чтобы мы могли видеть, кто над чем работает.
Я предлагаю вам взглянуть на доску Eylean. 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 разработчиков
- Когда история в dev, она на столе разработчика. Аналогично проверке, проверке качества и т. Д. Это означает, что каждая карта на доске представляет собой элемент, который можно выполнить, а также обеспечивает достаточно точный снимок прогресса итерации. Правило состоит в том, что только в исключительных случаях у вас есть более одной карты на вашем столе.
- Мы договорились, что в столбце "Ожидание обзора" не будет больше двух карт. Это поддерживает степень "потока".
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 недели итерации.
Одна вещь, которую я заметил из отображения потока создания ценности на " информационном радиаторе", заключается в том, что он волшебным образом фокусирует людей на фактической работе с добавленной стоимостью, которая должна быть выполнена, и это, кажется, ускоряет темпы развития бизнес-ценности и сохраняет набирает обороты.
Надеюсь, это поможет!
Наша доска разбита на следующие столбцы:
Story, Not Started, Req / Des / Dev *, Peer Review, QA, Готово
Самые приоритетные истории идут сверху вниз. Каждая история может иметь несколько задач, поэтому мы используем большой пост для истории и меньшие для задач. Задачи перемещаются слева направо. Каждый день мы проверяем, чтобы убедиться, что мы работаем над приоритетными историями.
Мы используем липкую белую вкладку в каждой задаче, где человек, работающий над ней, ставит свои инициалы. Когда они закончат и переместят их, новая белая вкладка будет помещена поверх старой, чтобы показать, что она доступна любому. Когда все задачи выполнены, история также перемещается в столбец "Готово", а в режиме ожидания все выполненные работы подсчитываются и перемещаются вверх по доске, чтобы освободить место внизу для других историй.
У нас также есть цветные вкладки для историй и заданий, указывающие на блокировку для прохождения (синий указывает на блокировку от другой команды, красный - на просьбу помощи мастера схватки). Мы говорим о контрольно-пропускных пунктах на каждом стенде.
Мы можем видеть, когда в одном конкретном столбце слишком много задач, и сместить акцент, чтобы перейти к "Готово". Мы намеренно добавили колонку отзывов, чтобы подчеркнуть, что работа должна была быть рассмотрена кем-то, кроме человека, выполняющего ее, прежде чем она попала в QA.
* Требования / Дизайн / разработка
Мы экспериментируем с несколькими различными структурами правления в нескольких разных проектах, которые мы выполняем. Один проект имеет самую базовую структуру, которую мы можем использовать:
| (Sprint) Backlog | In Progress | Done |
Насколько это возможно, мы стараемся сделать один пост-это, чтобы представить как историю разработки, так и QA для истории.
Вышеприведенная структура, кажется, работает хорошо для разработчиков проекта, но члены QA изо всех сил пытались узнать, когда история завершила разработку, чтобы они могли выполнить свои тесты для этой истории. Мы переместили истории в "дальнюю сторону" раздела In Progress, чтобы показать, что работа Dev была выполнена и что QA может взять эту историю. Это очень быстро стало совершенно неуправляемым, так как раздел In Progress заполнился.
Это привело ко второй итерации структуры платы для другого проекта:
| (Sprint) Backlog | In Progress | Ready for Test | Done |
Недавно добавленный раздел Ready for Test по сути стал формальным разделом доски, который ранее был "дальней стороной" раздела In Progress. На первый взгляд, это должно было прояснить ситуацию для членов QA, но это все же вызвало некоторую путаницу, поскольку у людей были разные интерпретации того, что означало Ready for Test (я не буду утомлять вас различными интерпретациями здесь).
Это привело к последней итерации структуры платы, которую мы используем в другом проекте:
| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |
Это, безусловно, довольно далеко от простых разделов " Журнал ожидания", " В процессе" и " Выполнено" первой итерации, но, похоже, это хорошо работает для команды. У них есть четкое понимание того, что значит перемещать историю по различным разделам доски, и для любой отдельной истории она дает четкую картину того, где в жизненном цикле находится эта конкретная история. Мы использовали эту структуру только с начала текущего спринта (мы 9 дней в 10-дневном спринте), поэтому мы рассмотрим эту структуру более подробно в нашей ретроспективе завтра. Я уверен, что он не идеален, но если он продолжит работать для команды, которая его пилотирует, мы постараемся распространить ее на другие команды нашей организации.
Мы пошли со следующей структурой правления в нашей компании.
Backlog | Next sprint | Current sprint | Done
Buffer | Working
Дорожки назначаются конкретным участникам. У каждого участника своя работа в нашем офисе, поэтому задачи различаются. Мы добавляем то, над чем мы должны работать, в наш журнал, а затем перемещаем его в следующий спринт, если он приближается к сроку. Заблокированные зеленые задачи используются для непрерывных задач, над которыми нужно работать ежедневно. Красные карточки указывают на важность задания и должны быть завершены как можно скорее. Наш совет позволяет нам свободно сотрудничать и добавлять задачи друг к другу, если нам нужно что-то сделать в другом отделе.
Мы используем KanbanTool (Kanbantool.com) для визуализации нашего рабочего процесса и управления проектами. Это действительно интуитивно понятный и простой в использовании. Командное общение нашей команды значительно улучшилось.
Наши доски, как правило, развиваются сверхурочно по мере нашего продвижения в команде. Я предпочитаю отдавать предпочтение физическим карточным картам, если вы работаете в команде, поскольку это способствует лучшему общению лицом к лицу, как правило, исходя из моего опыта. Очевидно, что накладных расходов больше, но стоит того, чтобы команда работала вместе. Другое преимущество, которое я видел с физическими досками, - то, что это помогает с деловым взаимодействием. Удаленные заинтересованные стороны не могут просто войти в систему и увидеть прогресс в текущем спринте и вывести вещи из контекста, поскольку иногда карты не рассказывают всю историю. Они должны поговорить и прийти к доске, что может быть полезно, поскольку все можно объяснить, а также значит, что их можно поощрять, чтобы помочь устранить препятствия. Однако это не только для физических плат, но это помогает.
Как уже упоминалось, наши доски развиваются сверхурочно с учетом потребностей команд. Часто мы начинаем с разборок в учебниках, но поощряем постоянное улучшение и, как правило, заканчиваем скрамбанным решением. Эти изменения отражены путем визуализации нового рабочего процесса через доски. Я недавно написал пост о наших последних изменениях, если вы заинтересованы, посмотрите на наши песочные часы Scrum / Kanban Board
Я думаю, что команда должна быть вовлечена в создание досок, поскольку это помогает команде понять рабочий процесс, а не стать бункером. Также, если команда приложила руку к созданию доски, она лучше контролирует свои собственные процессы, что помогает самоорганизации, поскольку это продукт, который они внесли.
Наш выглядит довольно похоже. У каждого разработчика есть столбец, и у нас есть строки для "Готово", "В процессе тестирования", "Работа в процессе", "Журнал ожидания".
И мы используем настоящие заметки в стиле post-it, которые мы физически движемся по мере прохождения каждой фазы.
Лично я считаю, что система не хватает...
- Перемещение вручную после этого становится болью через некоторое время. Наша команда QA в основном управляет перемещением билетов - и постоянно старается синхронизировать их с TFS.
- Пост может действительно быть перемещен только столько раз, пока он больше не будет липким. Если заявка отправляется обратно из тестирования и помещается в "Выполняется", а затем возвращается в тестирование и т. Д. И т. Д., То это не займет много времени, чтобы оказаться на полу.
- Иногда объем нот просто огромен. Примечания должны быть сложены, чтобы быть видимыми даже удаленно - мы налагаем их на слои так, чтобы мы могли видеть уникальный идентификатор каждого примечания (как можно лучше)... но тогда у вас есть стопка из 10 примечаний, и вам нужно получить Пятый из стека, и вы быстро вносите свой вклад в снижение липкости, которое закончится заметками на полу.
- Когда билеты оказываются на полу, довольно утомительно узнавать, куда они должны идти. Был ли это билет разработчика А? Или б? И было ли это в тестировании? Или это было сделано? Давайте вернемся в TFS, посмотрим на эти билеты и переместим сообщение соответственно.
Лично я не думаю, что заметки после публикации являются подходящим инструментом здесь. Есть несколько цифровых инструментов, которые делают такие вещи абсолютно беспроблемными. Мы используем сервер Team Foundation - и я видел несколько действительно хороших, надежных, бесплатных и даже открытых инструментов, которые будут взаимодействовать с сервером Team Foundation и управлять всем этим для вас в режиме реального времени.
http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx