 | Эта статья содержит контент, который написан как реклама . ( Январь 2017 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
| Разработка программного обеспечения |
|---|
Scrumban - это методология гибкого управления, описывающая гибриды Scrum и Kanban, и изначально была разработана как способ перехода от Scrum к Kanban . [1] [2]
История [ править ]
Как Kanban метод становится все более популярным [ править ] , Scrumban был разработан [3] как попытка сделать его проще для существующих Scrum команды , чтобы приступить к изучению Lean и Kanban концепции [ править ] .
Первая статья о Scrumban, в которой используется написание «Scrum-ban», описывает несколько уровней перехода от Scrum к Kanban . [1]
Метод [ править ]
В Scrumban командная работа организована в виде небольших итераций и контролируется с помощью визуальной доски, аналогичной скрам- доскам и канбан-доскам . Чтобы проиллюстрировать каждый этап работы, команды, работающие в одном пространстве, часто используют стикеры или большую доску. В случае децентрализованных команд часто используется программное обеспечение для визуального управления, такое как Assembla , Targetprocess , Eylean Board , JIRA , Mingle или Agilo for Trac . [1] Встречи по планированию проводятся, чтобы определить, какие истории пользователей нужно завершить в следующей итерации. Затем пользовательские истории добавляются на доску, и команда завершает их, работая над минимальным количеством пользовательских историй за раз, насколько это возможно (незавершенная работа или незавершенная работа). Чтобы сократить количество итераций, используются пределы незавершенного производства, и устанавливается триггер планирования, чтобы знать, когда планировать следующее - когда незавершенное производство падает ниже заранее определенного уровня. В Scrumban нет предопределенных ролей; команда сохраняет роли, которые у них уже есть. [4]
Итерации [ править ]
Итерации работы в Scrumban остаются короткими. Это гарантирует, что команда может легко адаптироваться и изменить свой образ действий в быстро меняющейся среде. Продолжительность итерации измеряется неделями. Идеальная продолжительность итерации зависит от рабочего процесса каждой команды, и рекомендуется, чтобы итерации не превышали двух недель. [5] Скорость (показатель производительности) часто используется командой для оценки проблем и тенденций в ее пропускной способности, чтобы поддерживать постоянное улучшение.
Планирование по запросу [ править ]
Планирование в Scrumban основано на спросе и происходит только при срабатывании триггера планирования. Триггер планирования связан с количеством задач, оставшихся в разделе «Задачи» на доске - когда оно уменьшается до определенного числа, событие планирования проводится. Количество задач, которые должны вызвать событие планирования, заранее не определено. Это зависит от скорости работы команды (как быстро она может завершить оставшиеся задачи) и от времени, необходимого для планирования следующей итерации. Задачи, запланированные для следующей итерации, добавляются в раздел доски «To Do».
Приоритезация [ править ]
Рекомендуется расставить приоритеты задач во время мероприятия по планированию. Это означает, что задачи добавляются на доску с отмеченными приоритетами. Это помогает членам команды знать, какие задачи следует выполнить в первую очередь, а какие можно выполнить позже. Расстановку приоритетов можно выполнить, добавив числа к задачам или добавив дополнительный столбец приоритета, где наиболее важные задачи помещаются вверху, а менее важные задачи - внизу.
Планирование размера ковша [ править ]
Планирование размера ковша дает возможность долгосрочного планирования в Scrumban. Он основан на системе трех сегментов, через которые рабочие элементы должны пройти, прежде чем они попадут на доску Scrumban. Три периода представляют собой три различных этапа плана и обычно называются 1-летним, 6-месячным и 3-месячным периодами. Годовой сегмент предназначен для долгосрочных целей, которые ставит компания, например, проникновения на новый рынок, выпуска нового продукта и т. Д. Когда компания решает продвигаться вперед с планом, он перемещается в 6-месячный сегмент, где выкристаллизованы основные требования этого плана. Когда компания готова приступить к реализации плана, требования переносятся в трехмесячный период и делятся на четкие задачи, которые должна выполнить команда проекта.Именно из этого ведра команда рисует задачи во время совещания по планированию по требованию и начинает работу над задачами.[6]
Доска [ править ]
Основная доска Scrumban состоит из трех столбцов: To Doing, Doing и Done. После собрания по планированию задачи добавляются в столбец To Do, когда член команды готов работать над задачей, он перемещает его в столбец Doing, а когда он / она завершает его, он перемещает его в столбец Готово. Доска Scrumban наглядно отображает прогресс команды. Столбцы доски задач адаптируются и расширяются в зависимости от прогресса команды. Наиболее распространенные надстройки включают столбцы приоритета в разделе To Do и столбцы, такие как Design, Manufacturing, Testing, в разделе Doing.
Ограничения WIP - чтобы гарантировать, что команда работает эффективно, методология Scrumban гласит, что член команды должен работать не более чем над одной задачей одновременно. Чтобы убедиться, что это правило соблюдается, Scrumban использует лимит незавершенной работы (WIP). Это ограничение отображается в верхней части раздела «Выполнение» на доске (также может быть в каждом столбце этого раздела) и означает, что в соответствующем столбце одновременно может находиться только такое количество задач. Лимит WIP обычно равен количеству людей в команде, но может быть расширен в зависимости от специфики работы команды.
Ограничения на выполнение - для более продуктивных встреч по планированию количество задач в разделе «Задачи» также может быть ограничено. Как и в случае с ограничениями незавершенного производства, он записывается в верхней части раздела «Задачи» или в верхней части соответствующих столбцов и ограничивает количество задач в разделе «Задачи» или определенных столбцах.
Команда [ править ]
Scrumban не требует определенного количества членов команды или командных ролей. Роли, которые команда выполняла до внедрения Scrumban, сохраняются при внедрении Scrumban. Их подкрепляют члены команды, которые сами выбирают задачи. Командные роли в Scrumban более специализированы и менее кросс-функциональны, чем то, что ожидается в scrum-командах.
Принцип вытягивания [ править ]
В Scrumban задачи не назначаются членам команды руководителем группы или менеджером проекта. Каждый член команды выбирает, какую задачу из раздела To Do они собираются выполнить дальше. Это гарантирует бесперебойный процесс, при котором все члены команды всегда одинаково заняты.
Заморозка функции [ править ]
Замораживание функций используется в Scrumban, когда приближается крайний срок проекта. Это означает, что можно по-прежнему работать только с теми функциями, которые команда уже имеет для разработки, и никакие дополнительные функции не могут быть добавлены. [7]
Triage [ править ]
Сортировка обычно происходит сразу после остановки функции. По мере приближения крайнего срока проекта менеджер проекта решает, какие функции в разработке будут завершены, а какие останутся незавершенными. Это гарантирует, что команда сможет сосредоточиться на завершении важных функций до крайнего срока проекта и забыть о менее важных. [8]
Условия [ править ]
- Планирование размера ведра. Подход к долгосрочному планированию в Scrumban основан на продвижении планов через несколько этапов.
- Время ведения и цикла - время, которое проходит от создания задачи или начала работы над задачей до ее завершения.
- Техника планирования по требованию , которая выполняется только тогда, когда есть потребность в новых задачах на доске.
Инструменты [ править ]
Как и другие методы, Scrumban может быть реализован с помощью различных инструментов. Самая простая реализация Scrumban - это физическая доска с липкими заметками. Также доступны электронные решения , похожие на электронные доски scrum и kanban. Они предлагают полную автоматизацию доски, при этом ее должны обновлять только члены команды. Электронные доски часто также предоставляют автоматические отчеты, возможность вложения и обсуждения задач, учет времени, а также интеграцию с другим широко используемым программным обеспечением для управления проектами. [9]
См. Также [ править ]
- Канбан (разработка)
- Список философий разработки программного обеспечения
- Scrum (разработка программного обеспечения)
Ссылки [ править ]
- ^ a b Ладас, Кори. «Скрам-бан» . Бережливая разработка программного обеспечения .
- ^ Редди, Аджай. «Scrumban [R] Evolution - Получите максимальную отдачу от Agile, Scrum и Lean Kanban» . Пирсон .
- ^ Ladas, Corey (январь 2009). Scrumban: Очерки канбан-систем для экономичной разработки программного обеспечения. Modus Cooperandi Press. ISBN 978-0578002149
- ^ Василиаускас, Vidas. «Scrumban - сочетание гибкости и поджарости» . Проверено 22 декабря 2014 . CS1 maint: обескураженный параметр ( ссылка )
- ^ Дон, Уэллс. «Итеративное планирование» . Гибкий процесс . Проверено 14 января 2015 года . CS1 maint: обескураженный параметр ( ссылка )
- ^ Miseviciute, D. "Scrumban: по запросу против долгосрочного планирования" . Блог Eylean .
- ^ "Замораживание функции" . OpenStack . OpenStack . Проверено 14 января 2015 года . CS1 maint: обескураженный параметр ( ссылка )
- ^ "Программное обеспечение сортировки" . Липкие умы . Проверено 14 января 2015 года . CS1 maint: обескураженный параметр ( ссылка )
- ^ "Scrumban" . Eylean Board . Проверено 22 декабря 2014 . CS1 maint: обескураженный параметр ( ссылка )
