Канбан / Скрам-доски [закрыты]
https://stackoverflow.com/questions/1807100
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Мне любопытно, что другие люди используют для физических досок 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.Список задач, которые должны выполнить другие люди, находится в столбце Todo, но он может быть выполнен другим членом команды, который координирует выполнение работы с Бобом.
- Для UC-002 задача платежного сервиса была выполнена, и для QA был завершен автоматизированный тестовый пакет, позволяющий им тестировать сервис без пользовательского интерфейса.Если тест завершается неудачей, обнаруживается ошибка и переносится вместе с задачей платежного сервиса обратно в фазу контроля качества
- Все задачи для UC-003 были выполнены и перенесены в раздел Ready for QA.
- Все задачи для Uc-004 и UC-005 были выполнены, поэтому история пользователя была перенесена в раздел "Сделано".
Это работает как материальная белая доска, на которой люди взаимодействуют с каждой из задач / пользовательских историй (представленных в виде заметок post it).Электронная версия создается до начала спринта / итерации и обновляется только в конце спринта / итерации, соответствующей текущей ситуации.Комментарии и критика приветствуются :)
Решение
Мы используем что-то, вдохновленное знаменитыми Scrum и ОПЫТ из Окопов от Хенрика Книберга, колонки адаптируются в зависимости от контекста (часто:ЗАДАЧА, В ПРОЦЕССЕ ВЫПОЛНЕНИЯ, ДЛЯ ПРОВЕРКИ, ВЫПОЛНЕНО):
альтернативный текст http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png
Элементы невыполненной работы по продукту (PBI) печатаются в виде "физических карточек" (формат A5) для совещания по планированию Спринта (по крайней мере, наиболее важные).Как только команда подберет PBI для следующей итерации, элементы разбиваются на задачи / действия (на стикерах).После собрания все выносится на Scrum-доску, и я предлагаю использовать скотч, или кнопки, или магниты.PBI упорядочены по важности: самые важные - вверху таблицы, менее важные - внизу.Команда должна сначала поработать над самым важным пунктом, пока он не будет выполнен.Во-первых, сообщение об активности - его перемещение слева направо.Затем PBI переходит к режиму Готово.Неожиданные задачи добавляются в зону "Незапланированные элементы" (чтобы учесть их в таблице выгорания).Будущие PBI остаются видимыми в "Следующей" зоне (если все элементы завершены во время итерации, мы выбираем новый оттуда).Довольно просто.
Эти методы позволяют визуально определять запахи, например:
- застрявшие задачи (т.е.задачи, которые не выполняются), которые указывают на потенциальное препятствие
- команда делает что-то в неправильном порядке и не фокусируется на первоочередных элементах, как на вашем примере :)
- слишком много незавершенной работы, ничего не сделано
- незапланированные предметы, которые убивают спринт
Отлично работает.
Если вы ищете более "ориентированный на канбан" материал, возможно, взгляните на Канбан против Схватки, Один день в Стране Канбан и Канбан и Scrum - практическое руководство от того же Хенрика Книберга.Тоже отличная штука.
А для получения дополнительных изображений попробуйте использовать Google Images с помощью схватка + доска, канбан, схватка, scrum+ канбан.
Другие советы
Вот наша доска Канбан, которую мы используем в Целевой процесс.Мы работаем не на уровне задач, а только на уровне пользовательских историй и ошибок.Иногда мы создаем задачи, но они явно не отслеживаются на доске.
Мы не оцениваем Истории пользователей и ошибки, но пытаемся разделить Истории на более мелкие (с переменным успехом).Столбцы не требуют пояснений.Мы накапливаем предметы в Проверенный столбец, затем создайте ветку, затем протестируйте ее и выпустите новую сборку.Обычно мы выпускаем новую сборку каждые две недели.
Также на доске отображается загрузка разработчиков и тестировщиков и классы сервисов с помощью цветового кодирования.
UPD.Теперь у нас есть несколько небольших команд, и мы используем единую доску для отслеживания прогресса всех команд в http://www.targetprocess.com/3
Scrum / Раскадровка экстремального программирования.
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:
У нас было два доски объявлений - одно с карточками для предстоящих историй, чтобы мы могли рассказать, что будет дальше, и одно с результатами текущего спринта.Наши колонки на текущей доске объявлений sprint были просто
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 |
Насколько это возможно, мы стараемся создавать единую публикацию, чтобы представлять как действия разработчиков, так и контроль качества для истории.
Описанная выше структура, казалось, работала нормально для разработчиков проекта, но участники контроля качества изо всех сил пытались узнать, когда работа над историей была завершена, чтобы они могли выполнить свои тесты для этой истории.Мы обнаружили, что переносим истории на "дальнюю сторону" В процессе раздел, указывающий на то, что работа разработчика была выполнена и что отдел контроля качества мог бы подхватить эту историю.Это очень быстро стало совершенно неуправляемым, поскольку В процессе секция заполнена.
Это привело ко второй итерации структуры правления для другого проекта, который является:
| (Sprint) Backlog | In Progress | Ready for Test | Done |
Недавно добавленный раздел Готов к тестированию по существу, стала формальной частью правления, которая ранее была "дальней стороной" В процессе Раздел.На первый взгляд, это должно было прояснить ситуацию для участников контроля качества, но это все еще вызывало некоторую путаницу, поскольку у людей были разные интерпретации того, что Готов к тестированию подразумевалось (я не буду утомлять вас здесь различными интерпретациями).
Затем это привело к последней итерации структуры платы, которую мы используем в другом проекте:
| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |
Это, безусловно, довольно далеко от простого Отставание в работе, В процессе и Выполнено разделы первой итерации, но это, похоже, хорошо работает для команды.У них есть четкое понимание того, что значит перемещать историю по различным разделам доски, и для любой отдельной истории это дает четкое представление о том, на каком этапе жизненного цикла находится эта конкретная история.Мы используем эту структуру только с начала текущего спринта (у нас 9 дней из 10-дневного спринта), поэтому мы рассмотрим эту структуру более подробно в нашей завтрашней ретроспективе.Я уверен, что это не идеально, но если это продолжит работать для команды, которая его пилотирует, мы попытаемся внедрить это в других командах нашей организации.
Наша белая доска разбита на эти столбцы:
История, Не начата, Запрос / Des / Dev *, Экспертная оценка, QA, Выполнено
Истории с наивысшим приоритетом идут сверху вниз.У каждой истории может быть несколько задач, поэтому мы используем большую публикацию для истории и меньшие - для задач.Задачи перемещаются слева направо.Каждый день мы проверяем, чтобы убедиться, что работаем над самыми приоритетными историями.
Мы используем липкую белую вкладку для каждой задачи, где человек, работающий над ней, ставит свои инициалы.Когда они закончат и переместят его, новая белая вкладка будет помещена поверх старой, чтобы показать, что она доступна любому пользователю.Когда все задания выполнены, история также перемещается в колонку "Сделано", а в конце вся проделанная работа подсчитывается и перемещается вверх по доске, чтобы освободить место внизу для других историй.
У нас также есть цветные вкладки для историй и задач, чтобы указать препятствия для прогресса (синий указывает на блокировку со стороны другой команды, красный запрашивает помощь scrum master).Мы говорим о препятствиях на каждом этапе.
Мы можем видеть, когда в одной конкретной колонке слишком много задач, и смещать акцент, чтобы сделать больше.Мы намеренно добавили колонку "Обзор", чтобы подчеркнуть, что работа должна быть проверена кем-то другим, а не человеком, ее выполняющим, прежде чем она попадет в QA.
*Требования/Проектирование/Разработка
Наши выглядят довольно похоже.У каждого разработчика есть столбец, и у нас есть строки для "Выполнено", "В тестировании", "Незавершенная работа", "Отставание".
И мы используем настоящие заметки в стиле post-it, которые мы физически перемещаем по мере прохождения каждого этапа.
Лично я нахожу, что этой системе не хватает...
- Ручное перемещение поста - через некоторое время это становится мучением.Наша команда контроля качества в основном управляет перемещением билетов - и это постоянные усилия по их синхронизации с TFS.
- На самом деле постеры можно перемещать не так много раз, прежде чем они перестанут быть липкими.Если тикет отправлен обратно из тестирования и помещен в "Выполняется", а затем перемещен обратно в тестирование и т.д., etc...it для того, чтобы он оказался на полу, не требуется много времени.
- Иногда сам объем заметок ошеломляет.Заметки должны быть сложены в стопку, чтобы их можно было видеть даже отдаленно - мы раскладываем их таким образом, чтобы можно было видеть уникальный идентификатор каждой заметки (насколько это возможно)...но тогда у вас есть стопка из 10 банкнот, и вам нужно достать 5-ю из стопки, и вы быстро способствуете уменьшению липкости, что приведет к тому, что банкноты окажутся на полу.
- Когда билеты все-таки оказываются на полу, довольно неприятно выяснять, куда они должны пойти.Это был билет разработчика А?Или Б?И было ли это при Тестировании?Или это было сделано?Давайте вернемся в TFS, поищем эти билеты, а затем соответствующим образом переместим post-its.
Лично я не думаю, что заметки post-it являются здесь подходящим инструментом.Существует несколько цифровых инструментов, которые делают подобные вещи абсолютно беспроблемными.Мы используем Team foundation server - и я видел пару действительно отличных, надежных, бесплатных инструментов с открытым исходным кодом, которые будут взаимодействовать с Team foundation server и управлять всем этим за вас в режиме реального времени.
http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx
Наши доски, как правило, развиваются со временем по мере того, как мы прогрессируем как команда.Я склоняюсь к физическим карточным доскам, если у вас есть совместная команда, поскольку, по моему опыту, это способствует лучшему личному общению в целом.Очевидно, что накладных расходов больше, но это того стоит, если заставить команду работать вместе.Еще одно преимущество, которое я увидел у физических досок, заключается в том, что это помогает в вовлечении бизнеса.Удаленные заинтересованные стороны не могут просто войти в систему и увидеть прогресс в текущем спринте, вырвав все из контекста, поскольку иногда карточки не рассказывают всей истории.Они должны провести беседу и прийти к правлению, что может быть полезно, поскольку все может быть объяснено, и это также означает, что их можно поощрить помочь устранить препятствия.Однако это относится не только к физическим платам, но и помогает.
Как уже упоминалось, наши доски развиваются со временем в соответствии с потребностями команд.Часто мы начинаем с хрестоматийного scrum, но поощряем постоянное совершенствование и обычно заканчиваем решением в стиле scrumban.Эти изменения отражены в визуализации нового рабочего процесса с помощью досок.Недавно я написал пост о нашем последнем изменении, если вам интересно, взгляните на наш схватка в песочных часах / доска Канбана
Я думаю, что команда должна участвовать в создании досок, поскольку это помогает команде понять рабочий процесс, а не замыкаться в себе.Кроме того, если команда приложила руку к созданию правления, они лучше контролируют свои собственные процессы, что помогает самоорганизации, поскольку это продукт, в который они внесли свой вклад.
В нашей компании мы придерживались следующей структуры правления.
Backlog | Next sprint | Current sprint | Done
Buffer | Working
Полосы движения назначаются конкретным участникам.У каждого участника своя работа в нашем офисе, поэтому задачи разные.Мы добавляем то, над чем нам нужно поработать, в наше отставание, затем переносим это в Следующий спринт, если он приближается к крайнему сроку.Заблокированные зеленые задачи используются для непрерывных задач, над которыми приходится работать ежедневно.Красные карточки указывают на важность задания и должны быть выполнены как можно скорее.Наше правление позволяет нам свободно сотрудничать и добавлять задачи друг к другу, если нам нужно, чтобы что-то было сделано другим отделом.
Мы используем KanbanTool (Kanbantool.com) для визуализации нашего рабочего процесса и управления проектами.Это действительно интуитивно понятный и простой в использовании.Общение в нашей команде значительно улучшилось.
