Платы Kanban/Scrum [закрываются]

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

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

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

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

и прямоугольником в углу для Заблокировано .

Каждая история была представлена ​​в заметках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| (Sprint) Backlog | In Progress | Done |

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

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

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

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

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

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

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

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

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

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