Разрушение

Scrumban — это подход к доставке продуктов, ориентированный на Agile , который представляет собой гибрид Scrum и Kanban . Scrumban изначально разрабатывался как способ перехода от Scrum к Kanban .

История

Scrumban был разработан как попытка облегчить существующим Scrum-командам изучение концепций Lean и Kanban. ^[1]

Метод

В Scrumban командная работа организуется небольшими итерациями и контролируется с помощью визуальной доски, аналогичной Scrum и канбан-доскам . Чтобы проиллюстрировать каждый этап работы, команды, работающие в одном помещении, часто используют стикеры или большую доску. В случае децентрализованных команд программное обеспечение для визуального управления, такое как Assembla , Targetprocess , Eylean Board , JIRA , Mingle или Agilo for Trac . часто используется ^[2] Совещания по планированию проводятся для определения того, какие пользовательские истории необходимо завершить в следующей итерации. Затем пользовательские истории добавляются на доску, и команда дополняет их, работая над как можно меньшим количеством пользовательских историй одновременно (незавершенная работа или WIP). Чтобы сделать итерации короткими, используются ограничения незавершенного производства и устанавливается триггер планирования, чтобы знать, когда планировать следующее — когда незавершенное производство упадет ниже заранее определенного уровня. В Scrumban нет заранее определенных ролей; команда сохраняет те роли, которые у нее уже есть. ^[3]

Итерации

Рабочие итерации в Scrumban выполняются короткими. Это гарантирует, что команда может легко адаптироваться и изменить свой образ действий в быстро меняющейся среде. Продолжительность итерации измеряется неделями. Идеальная продолжительность итерации зависит от рабочего процесса каждой команды, однако не рекомендуется, чтобы итерации превышали две недели. ^[4] Скорость (показатель производительности) часто используется командой для оценки проблем и тенденций в производительности, чтобы поддерживать постоянное улучшение.

Планирование по требованию

Планирование в Scrumban основано на спросе и происходит только тогда, когда срабатывает триггер планирования. Триггер планирования связан с количеством задач, оставшихся в разделе «Сделать» на доске — когда оно снижается до определенного числа, событие планирования проводится. Количество задач, которые должны вызвать событие планирования, не определено заранее. Это зависит от скорости работы команды (насколько быстро удастся выполнить оставшиеся задачи) и от времени, необходимого для планирования следующей итерации. Задачи, запланированные на следующую итерацию, добавляются в раздел доски «Сделать».

Расстановка приоритетов

Во время планирования мероприятия рекомендуется расставлять приоритеты задач. Это означает, что задачи добавляются на доску с отмеченными приоритетами. Это помогает членам команды знать, какие задачи следует выполнить в первую очередь, а какие можно выполнить позже. Расстановку приоритетов можно выполнить, пронумеровав задачи или добавив дополнительный столбец приоритетов, в котором наиболее важные задачи располагаются вверху, а менее важные — внизу.

Планирование размера ковша

Планирование размера сегмента дает Scrumban возможность долгосрочного планирования. Он основан на системе трех сегментов, через которые должны пройти рабочие элементы, прежде чем они попадут на доску Scrumban. Три сегмента представляют собой три различных этапа плана и обычно называются сегментами на 1 год, 6 месяцев и 3 месяца. 1-летний период предназначен для долгосрочных целей компании, таких как проникновение на новый рынок, выпуск нового продукта и т. д. Когда компания решает продолжить реализацию плана, он перемещается в 6-месячный период. , где кристаллизованы основные требования этого плана. Когда компания готова приступить к реализации плана, требования переносятся в трехмесячный период и делятся на четкие задачи, которые должна выполнить команда проекта. Именно из этого корзины команда извлекает задачи во время совещания по планированию по требованию и начинает над ними работать. ^[5]

Совет

Базовая доска Scrumban состоит из трех столбцов: «Сделать», «Делать» и «Готово». После планерки задачи добавляются в столбец «Сделать», когда член команды готов работать над задачей, он перемещает ее в столбец «Выполнение», а когда он ее выполняет, он перемещает ее в столбец «Выполнение». столбец «Готово». Доска Scrumban визуально отражает прогресс команды. Столбцы доски задач адаптируются и расширяются в зависимости от хода работы команды. Наиболее распространенные надстройки включают столбцы приоритетов в разделе «Задачи» и такие столбцы, как «Проектирование», «Производство» и «Тестирование» в разделе «Выполнение».

Лимиты незавершенного производства -- Чтобы гарантировать эффективную работу команды, методология Scrumban гласит, что член команды должен работать не более чем над одной задачей одновременно. Чтобы убедиться в соблюдении этого правила, Scrumban использует лимит WIP (незавершенной работы). Это ограничение отображается в верхней части раздела «Выполнение» доски (также может быть в каждом столбце этого раздела) и означает, что только определенное количество задач может одновременно находиться в соответствующем столбце. Лимит WIP обычно равен количеству человек в команде, но может быть увеличен в зависимости от специфики работы команды.

Ограничения на действия -- Чтобы совещания по планированию проходили более продуктивно, количество задач в разделе «Сделать» также можно ограничить. Так же, как и лимиты НЗП, он прописывается вверху раздела «Сделать» или над соответствующими столбцами и ограничивает количество задач в разделе «Сделать» или отдельных столбцах.

Команда

Scrumban не требует какого-либо определенного количества членов команды или командных ролей. Роли, которые команда имела до внедрения Scrumban, сохраняются и при внедрении Scrumban. Они подкрепляются тем, что члены команды сами выбирают задачи для выполнения. Роли в команде в Scrumban более специализированы и менее кросс-функциональны, чем ожидается в scrum-командах.

Принцип вытягивания

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

Заморозка функций

Замораживание функций используется в Scrumban, когда приближается крайний срок проекта. Это означает, что работать можно только над теми функциями, которые у команды уже есть для разработки, и никакие дополнительные функции не могут быть добавлены. ^[6]

сортировка

Сортировка обычно происходит сразу после заморозки функции. По мере приближения крайнего срока проекта руководитель проекта решает, какие из функций, находящихся в разработке, будут завершены, а какие останутся незавершенными. Это гарантирует, что команда сможет сосредоточиться на завершении важных функций до истечения срока проекта и забыть о менее важных. ^[7]

Оснастка

Самая базовая установка Scrumban — это физическая доска с стикерами. электронные решения Также доступны , аналогичные электронным доскам Scrum и Kanban. Они предлагают полную автоматизацию доски, при которой ее должны обновлять только члены команды. Электронные доски часто также предоставляют автоматические отчеты, возможность вложений и обсуждений задач, учет времени, а также интеграцию с другим часто используемым программным обеспечением для управления проектами. ^[8]

См. также

Ссылки

^ Ладас, Кори (январь 2009 г.). Scrumban: Очерки систем Канбан для бережливой разработки программного обеспечения. Модус Куперанди Пресс. ISBN 978-0578002149
^ «Вопросы и ответы о Scrumban [R] Evolution» .
^ Василяускас, Видас. «Scrumban — сочетание гибкости и бережливости» . Ютуб . Проверено 22 декабря 2014 г.
^ Дон, Уэллс. «Итеративное планирование» . Гибкий процесс . Проверено 14 января 2015 г.
^ Мисевичюте, Д. «Scrumban: по требованию или долгосрочное планирование» . Блог Эйлин .
^ «Заморозка функций» . ОпенСтек . Проверено 14 января 2015 г.
^ «Программная сортировка» . Липкие умы . Проверено 14 января 2015 г.
^ «Скрамбан» . Эйлин Борд . Проверено 22 декабря 2014 г.

[1] Ладас, Кори (январь 2009 г.). Scrumban: Очерки систем Канбан для бережливой разработки программного обеспечения. Модус Куперанди Пресс. ISBN 978-0578002149

[2] «Вопросы и ответы о Scrumban [R] Evolution» .

[3] Василяускас, Видас. «Scrumban — сочетание гибкости и бережливости» . Ютуб . Проверено 22 декабря 2014 г.

[4] Дон, Уэллс. «Итеративное планирование» . Гибкий процесс . Проверено 14 января 2015 г.

[5] Мисевичюте, Д. «Scrumban: по требованию или долгосрочное планирование» . Блог Эйлин .

[6] «Заморозка функций» . ОпенСтек . Проверено 14 января 2015 г.

[7] «Программная сортировка» . Липкие умы . Проверено 14 января 2015 г.

[8] «Скрамбан» . Эйлин Борд . Проверено 22 декабря 2014 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]