Scrum или Kanban?
Краткий обзор методологий гибкого проектного управления
На базе статьи Генри Портмана
В начале разработки продукта Скрам очень уместен!
Приведенная ниже статья вольная интерпретация и абстракт статьи Генри Портмана A new new bird’s eye view on the Agile forest. Да простят меня авторы за использование их текста.
Внимание! Статья не для новичков в Agile. Для Новичков будет написана более простая статья.
В 1986 году Хиротака Такеучи и Икуджиро Нонака опубликовали в журнале Harvest Business Review свою статью “Новая игра по разработке новых продуктов “. Это стало отправной точкой для разработки Scrum Кеном Швабером и Джеффом Сазерлендом.
На данный момент существует около сотни известных и менее известных agile-подходов, фреймворков или методов.
Когда команды начинают работать с Agile, часто выбирают Scrum. Это очевидный выбор, но вопрос в том всегда ли это правильный выбор?
В блоге Романа Пихлера проведена связь Scrum с жизненным циклом продукта.
Во время первой фазы жизненного цикла коммерческого продукта, в которой коммерческий продукт впервые выходит на рынок, неопределенность высока, и основное внимание уделяется своевременной поставке первого продукта, готового к продаже. Установлен крайний срок, и этот срок должен быть соблюден. На этом этапе вся команда сосредоточена на предоставлении коммерчески востребованного продукта. Эта разработка идеально подходит для Scrum с его итерационным подходом, способностью справляться с неопределенностью и совместной работе над результатом (коммерческим продуктом). По желанию может быть проведен второй запуск со следующим набором важных функциональных возможностей, так что в конечном итоге на рынок выходит зрелый продукт. В течение дальнейшего жизненного цикла продукта, мы видим, что количество неопределенностей и требуемых изменений уменьшается. В этот момент вы можете использовать Kanban. В непрерывном потоке пользовательские истории могут подхватываться, разрабатываться и внедряться один за другим отдельными членами команды. Если рассматривать зачастую сложный перенос в производственную среду, то время выхода на рынок можно сократить, правильно организовав перенос и сократив количество ошибок при переносе, когда команды разработчиков и производственников объединены.
Scrumban – это комбинация Scrum и Kanban. Вначале он был задуман как переходная модель для перехода от Scrum к Kanban и для того, чтобы команда могла познакомиться с концепциями Lean- и Kanban. Сегодня это подход, при котором команда решила работать по Scrum со спринтами, но использовать систему Kanban для постоянного просмотра и улучшения своего метода работы, чтобы оптимизировать поток единиц работы (например, пользовательских историй). Leanscrum- это Скрам, выполненный в контексте принципов Lean.
Obeya (в переводе с японского – “большая комната”) – это физическое пространство, которое используется для согласования операционных команд и руководства в их усилиях по воплощению стратегии в значимую повседневную работу и результаты. Оно помогает развить способность проводить совещания, которые создают значимый контекст и избегать отвлекающих факторов, таких как предвзятость, эго и чрезмерная сложность. При использовании в рамках всей организации, он поддерживает развитие систематического подхода к руководству, который позволяет последовательное, согласованное и эффективное принятие решений. В Obeya пять ключевых обязанностей визуализированы: вести успешные стратегии, стимулировать производительность, обеспечивать ценность, решать проблемы и действовать, и реагировать. Но только визуализация не принесет пользы, если не применять принципы на практике. Команда также должна следовать семи принципам поведения: мыслить системно и подотчетно, делиться контекстом и проблемами визуально, развивать людей, ритм и рутину (ката), продолжать совершенствоваться, идти и видеть, каскадировать и соединять.
Масштабирование на уровень продукта или программы
Для того чтобы использовать agile-метод работы в организации большого размера, недостаточно просто иметь отдельные agile-команды. Необходимо расширить масштабы agile-метода работы и, по возможности, институционализировать всеобъемлющее согласование. Для управления зависимостями и интеграции между различными постоянными agile-командами существуют различные методы, включая:
– Nexus, как описано в The Nexus Guide, является структурой для разработки инициатив по созданию продукта или программного обеспечения с тремя-девятью Scrum-командами, в спринтах продолжительностью до тридцати дней. Nexus – это ответ Кена Швабера, одного из основателей Scrum, на вопрос о масштабируемости Scrum. Для этого требуется нечто большее, чем просто желание и гибкое поведение различных Scrum команд для совместной работы над созданием интегрированного продукта. Nexus основан и опирается на Scrum и правилах и ролях, сформулированных в “Руководстве Scrum”.
– Scrum at Scale (S@S, разработан Джеффом Сазерлендом) – это модульная структура. Отправной S@S заключается в том, что всеобъемлющая универсальная система не может быть создана, но что каждый раз мы должны рассматривать масштабирование основополагающих принципов Scrum. Система может быть адаптирована для вашей организации путем добавления необходимых модулей S@S. S@S основывается на хорошо известной концепции Scrum. По аналогии с Nexus можно сказать, что S@S — это ответ Джеффа Сазерленда рядом с Кеном Швабером, другим отцом-основателем Scrum, о масштабируемости Scrum.
– Крупномасштабный Scrum (LeSS, разработанный Крейгом Ларманом и Басом Водде) — это agile framework с правилами, основанная на принципах и проведении экспериментов. Компания LeSS предлагает свободно доступную базу знаний (less.works), содержащую интегрированный подход, принципы, описания процессов, определения, роли, примеры и т.д. для крупномасштабной, в основном связанной с ИТ, разработки продуктов. Прозрачность также является ключевой концепцией LeSS. Первая версия датируется 2005 года, и с тех пор постоянно ведется работа по использованию и дальнейшему развитию LeSS. LeSS.
– Scaled Agile Framework (SAFe, разработанный Дином Лиффингвеллом) – это структура, позволяющая масштабирования agile-команд с целью создания более совершенных систем, повышения вовлеченности сотрудников и использования правильных затрат. вовлеченности сотрудников и использования правильных соображений стоимости. Это миссия организации Scaled Agile и основателя SAFe Дина Леффингвелла. Организация Scaled Agile предлагает базу знаний, которая находится в свободном доступе для каждого (www.scaledagileframework.com) с интегрированным подходом в виде процессов. описаний, определений, ролей, примеров и т.д. для Lean / Agile разработки продуктов. SAFe базируется на семи основных компетенциях.
Цель фреймворка Flow (разработанного Майком Керстеном) – привнести концепции Scrum и Agile в бизнес, чем тот, с которым ежедневно работают команды agile. Этот фреймворк использует три способа DevOps – поток, обратную связь и непрерывное обучение – на весь бизнес. Пользовательские истории и сюжетные точки наслаиваются на четыре элемента потока: особенности (новая ценность для бизнеса), дефекты (качество), риски (безопасность, управление, и долг (устранение препятствий для будущей поставки). Распределение Flow делает приоритеты видимыми. Использование структуры Flow при наличии структуры масштабирования, такой как SAFe, LeSS или Nexus, может привести к большему успеху. Рассматривайте структуру Flow как своего рода дополнение.
