Перевод оригинальной статьи. Украинскую версию статьи можно прочесть тут.
Бас Водде — коуч, консультант, программист, тренер и автор публикаций на тему agile- и lean-подхода к разработке программных продуктов. Родился в Голландии, а сейчас живет в Сингапуре. Бас ведет блог, где можно узнать многое о нем и его взглядах на agile-разработку программного обеспечения в его блоге.
Вначале были эксперименты, эмпирика и накопление опыта. Далее появились структура, стандарты и настройка системы. Фреймворк LeSS вырос на плодородной почве практических примеров от гуру масштабирования Баса Водде и Крейга Лармана.
Большинство фреймворков для масштабирования используют подход нескольких скрам-команд. Ключевой вопрос, который они задают: «Как сделать так, чтобы несколько Agile/Scrum-команд работали вместе?» LeSS же выбирает подход многокомандного скрама. Вопрос в начале масштабирования, который задают при использовании LeSS: «Как применять Scrum, когда у нас много команд?» В результате принимаются совсем другие решения о способе масштабирования.
Между подгонкой сложного процесса под свои нужды (tailoring down) и масштабированием есть важная разница. Традиционный безопасный подход к процессам — сформировать их слишком много, а потом попросить сотрудников убрать лишнее, т.е. сузить до собственного процесса. С другой стороны, agile-подход состоит в масштабировании и формулировании минимального количества процессов, причем сотрудники могут добавлять новые только если они абсолютно необходимы.
Почему подгонка вредна? Большая часть таких решений принимается в начале проекта. В этот момент объем глубоких знаний о продукте, рынке или методологии очень невелик, и люди склонны принимать безопасные решения, чтобы сохранить больше ролей, процессов и артефактов, чем им на самом деле нужно.
LeSS избегает ослабления ценностей и принципов Agile во время масштабирования, работая с большей комплексностью и традиционными организациями. Мы все равно хотим производить доступные к выдаче части продукта каждую итерацию. Мы все еще хотим иметь возможность поменять направление в любое время. Нам нужно личное общение и тесное сотрудничество с клиентами. Мы хотим, чтобы у нас были сильные самоорганизующиеся команды, развивалась архитектура и дизайн. Некоторые фреймворки для масштабирования относятся к ценностям и принципам Agile попустительски, а другие — нет. LeSS из вторых.
LeSS существует уже давно. Правила, рекомендации и само название – новые, но основаны на более чем 10 годах экспериментов с широкомасштабной agile-разработкой в очень разных компаниях, производящих широкий ассортимент продуктов.
«Изначально мы не хотели создавать фреймворк, — признается Бас Водде. – Возможно, это прозвучит странно, но нам с Крейгом нравится работать с организациями и командами над практическими проблемами. Мы оба верим в эмпирику, или эмпирический контроль процесса, когда команды используют собственные способы работы, экспериментируют, учатся и становятся лучше. Поэтому сама идея процесса или даже фреймворка всегда казалась противоположной тому, что мы хотели делать, а именно сосредоточиться на экспериментах, которые работают в определенном контексте».
Соответственно, LeSS никто специально не разрабатывал, но он развивался сам по себе. Лишь в 2014 году партнеры Бас Водде и Крейг Ларман начали использовать термин LeSS и создали правила фреймворка LeSS. До того LeSS представлял собой подборку выводов из задокументированных экспериментов – того, что они пробовали, работая со многими масштабными группами разработчиков. Так они научились акцентировать на повышении прозрачности, уменьшении расходов на организацию и большей значимости работы и контроля над ней внутри команд.
Значительную часть этих выводов можно найти в книгах Scaling Lean & Product Development (2008) и Practices for Scaling Lean & Agile Development (2010). Но проанализировав отзывы на свои книги, Водде и Ларман поняли, что им необходимо обращаться и к читателям, которые только пришли к Agile и масштабированию и спрашивали о понятных отправных точках. В процессе написания следующей книги Large-Scale Scrum: More with LeSS, которая уже скоро будет опубликована, им пришлось разрешить конфликт между предоставлением большего количества правил и предписаний и полной передачей контроля над процессом командам, чтобы они могли экспериментировать, учиться и становиться лучше в собственном контексте; авторы описали этот конфликт как «контроль процесса над процессом» или «контроль команды над собственным процессом».
«Когда выдаешь командам много процессов и рекомендаций, они будут следовать им без понимания изначальных целей, не думая, и впоследствии такая работа станет бесполезной… или даже вредной, — говорит Бас Водде. – И тут мы осознали, что Scrum решает это противоречие, поскольку состоит из небольшого количества правил. Проанализировав их, понимаешь, что большинство касаются создания обратной связи и обеспечения прозрачности. Так команды могут лучше контролировать работу. Наш конфликт был разрешен!»
Правила LeSS, повышающие прозрачность и усиливающие контроль в требуемом масштабе, поместились на трех страницах. «Эти правила легко понять, но сложно внедрить, — говорит Бас Водде. – Они также часто оказываются разрушительными для организаций».
В целом LeSS состоит из четырех частей:
Первыми появились эксперименты, так как именно склад ума, поощряющий экспериментирование, инспекции, адаптации и постоянное улучшение, является самой основой LeSS. Правила описывают два фреймворка: базовый LeSS (2-8 команд) и LeSS Huge (8+ команд). Рекомендации объясняют, как применять правила в различных типах организаций.
Первая часть LeSS состоит из 10 принципов, но они появились последними. Сейчас эти принципы делятся на три типа. Первый – принципы на основе Scrum, такие как «прозрачность», «эмпирический контроль процессов» или «LeSS – это Скрам». Второй тип — это уже скорее не принципы, а разделы знаний, такие как бережливое мышление и системное мышление. Последний тип — принципы, относящиеся только к LeSS, например «ориентация на клиента», «акцент на целостном продукте» и «больше с LeSS».
«Базовые правила LeSS объясняют, как применять Scrum к нескольким командам, описывая, как масштабируются роли, события и артефакты, — говорит Бас Водде. — LeSS, в отличие от Scrum, также использует правила для организационной структуры. Мы с Крейгом очень много раз убеждались, что если организационная структура остается нетронутой, то принятие Scrum/LeSS будет поверхностным или не состоится вообще. Поэтому мы добавили несколько структурных правил, таких как специально выделенные команды, работающие на одной локации, большинство команд элементов и скрам-мастера на полную ставку».
По мнению Баса Водде, сила LeSS в минималистическом подходе к фреймворку для масштабирования. Он не добавляет ненужных сложностей и остается небольшим, как можно более гибким и бережливым.
«Мы часто говорим, что LeSS нужен для масштабирования разработки и демасштабирования организации. Звучит как противоречие, но на самом деле это не так. LeSS значительно увеличивает ответственность команды, вследствие чего образовываются менее традиционные роли, процессы и артефакты. Поэтому и организационные структуры становятся проще».
Вся прелесть организационного демасштабирования в том, что она приводит к упрощению – меньше ролей, артефактов и процессов.
«Мы получаем большую ответственность команд, более вдумчивую и эффективную работу, больше контроля, увлеченности делом и улучшений, — утверждает Бас Водде. — Больше результатов. Потому принцип так и называется – больше с LeSS!»
Недавно мы решили, что пришло время делать крутой и эксклюзивный контент. Поэтому в декабре мы запустили Agile Friday - видеопередачу, в которой Евгений Лабунский, управляющий партнер Scrum Ukraine, будет общаться с крутыми экспертами в сфере Agile на самые горячие темы. В них мы будем говорить …
Large Scaled Scrum (LeSS), как и Scrum, не предписывает вам практически ничего. Это легкий каркас, который позволяет вам добавить в него только то, что вам нужно.
В LeSS все, что вы добавляете от себя, называется экспериментом. Лично мне очень нравится такое название, потому что, как и любой …
Сегодня вышел новый выпуск Agile Friday от Scrum Ukraine, в которой мы поговорим на тему роли Scrum Master в enterprise.
