+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Скрам или Канбан - что лучше?

30.06.2015 08:36

Нет причин спорить: Скрам и Канбан - это методики Agile, которые могут дополнять друг друга. Скрам дает простые правила для постоянных итераций инспектирования и адаптации, из всех методологий Agile он наиболее распространен. Сравните это с канбаном, у которого правил немного: визуализируйте свой рабочий поток, ограничьте свою текущую работу и постоянно ищите пути оптимизировать время цикла. Надо ли выбирать между ними или лучше найти способ их объединить?

Роли

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

У Канбана вообще нет правил относительно ролей. Состав команды в Канбане может быть динамическим, но и кросс-функциональные структуры команд, как в Скраме, тоже часто практикуются.

Управление потребностями и реализацией

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

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

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

Планирование и управление требованиями

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

Финализация - это процесс завершения историй для команды с целью сдачи работы. В Скраме рекомендуется подготовка нескольких дополнительных историй в том же спринте, что может эффективно создать непрерывный поток работы. В Канбане финализация необходима, но не определена, поскольку широкий разброс размеров входных данных может создать непредсказуемые сроки реализации.

В заключении

Скрам и Канбан идеальны для различных ситуаций, но и их смешение может привести к хорошему эффекту. Пусть команды начинают с того, что кажется им наиболее комфортным, затем разрешите им быть гибкими в техниках и принимать инструменты, в то же время поддерживая разумные стандарты в плане сбора и разделения информации.

 

Об авторе

Арлен Бэнкстон - исполнительный вице-президент и управляющий партнер LitheSpeed, LLC. Арлен - признанный лидер в методологиях управления процессами разработки ПО, в том числе Lean, Six Sigma и BPM, а также таких Agile-методиках, как экстремальное программирование и Скрам. Обладает «Черным поясом по Lean Six Sigma» и сертификатом тренера скрам-мастеров. У него 12 лет опыта в дизайне продукта, где он применяет принципы информационной архитектуры, интерактивного дизайна и юзабилити, чтобы разработать инновационные продукты, отвечающие высказанным и невысказанным требованиям заказчика. Арлен возглавлял внедрение Agile и Lean и управлял процессом улучшения проектов у таких клиентов, как Capital One, T. Rowe Price, Freddie Mac и Armed Forces Benefits Association. Его недавняя работа направлена на объединение методов улучшения процесса Lean Six Sigma с Agile, чтобы коренным образом улучшить и скорость, и качество бизнес-результатов. Он также возглавлял интеграцию интерактивного дизайна и практик юзабилити в методики Agile, проводя тренинги как на отраслевых конференциях, так и для клиентов Fortune 100.

Оригинал: http://www.agileconnection.com/print/bet[...]ine-article/scrum-or-kanban-which-better

Перевод: Александра Родсет

Еще интересные статьи на эту тему: