top of page
logo_scrum_ua_white.png
Фото автораScrum Ukraine

Успех крупномасштабной разработки — достичь большего с LeSS



Это перевод статьи Craig Larman - the co-creator of LeSS (Large-Scale Scrum), Certified LeSS Trainer. Оригинал статьи "Succeeding with Large-Scale Development - More with LeSS" размещен на веб-сайте SolutionsIQ по этой ссылке.


Спасибо, что нашли время прочитать (и посмотреть) это введение в LeSS (Крупномасштабный скрам)!


Если для знакомства с различными аспектами LeSS вы предпочитаете видео тексту, пожалуйста, посмотрите эти видео на LeSS website less.works. Из этого списка полезно начать с короткого видео Introduction to LeSS (short video) – Craig Larman.


История создания


Откуда взялся LeSS? В 2002 году я написал книгу Agile & Iterative Development: A Manager’s Guide. / “Гибкая и итеративная разработка: руководство для менеджера”.


В то время многие люди «знали», что гибкую разработку масштабировать невозможно. Но по моему опыту в компании Valtech, которая занималась аутсорсинговой разработкой – где я работал – нам удалось заметить, что это возможно.


Я начал получать от клиентов просьбы применить аджайл-концепции, в особенности фреймворк Scrum для крупномасштабной разработки, поскольку я был одним из первых инструкторов по скраму, начиная с конца 1990-х, и одним из первых Certified Scrum Trainer (Сертифицированных Тренеров Скрама). В конечном итоге, это привело к сотрудничеству с такими группами, как Ericsson, UBS, Bank of America Merrill-Lynch, JP Morgan и Nokia Networks и многими другими. (Кстати, Nokia Networks – это группа телекоммуникационной инфраструктуры, а не группа мобильных устройств Nokia, которую в конечном итоге купила Microsoft.)


Вы можете узнать больше о некоторых впечатлениях клиентов на сайте тематических исследований LeSS case studies site.

Главное, за что стоит ценить LeSS – он не был создан «на бумаге» или в теории. Он стал результатом нашего опыта работы со многими клиентами с 2005 года, которые занимались принятием крупномасштабного скрама.


Тем временем, в начале 2005 года, в Nokia Networks было очень приятно встретиться и начать работать с моим другом, Басом Водде/ Bas Vodde, соавтором LeSS. Бас сыграл ключевую роль в помощи группам в связи с принятием крупномасштабного скрама в Nokia Networks в составе их внутренней команды «Гибкая компания», а также был членом лидерской группы большой (приблизительно 1000 человек), распределенной продуктовой группы, принимавшей LeSS. Итак, Бас обладал огромным количеством всестороннего многолетнего опыта принятия и осуществления крупномасштабной гибкой разработки: от отладки крупных организаций до практической разработки встроенных систем. Он не был кабинетным педагогом или тем, кто просто провел несколько дней на собрании руководства, обсуждая масштабирование. Он много лет занимался всем этим на передовой. У него есть глубинные знания системного мышления, современных принципов менеджмента, а также в аджайл и лин-системах, включая скрам (поскольку он также является одним из первых сертифицированных тренеров скрама).


Бас был и остается для меня отличным партнером в коучинге и консалтинге по масштабированию гибкой разработки, и я многому у него научился. С другой стороны, мы оба многому научились у наших клиентов, переходивших на LeSS за эти годы. Таким образом, мы стали партнерами в коучинге и коммуникациям по LeSS, начиная с нашей первой книги на эту тему, которую мы написали в 2007 году на основе нашего опыта работы с клиентами, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum / “Масштабирование Лин и Аджайл Разработки: Мышление и Организационные инструменты для крупномасштабного скрама”. За ней в 2009 году последовал наш второй том о LeSS, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum / “Практики масштабирования Лин и Аджайл разработки: крупномасштабная, распределенная и оффшорная разработка продуктов в крупномасштабном скраме”.


Сейчас мы завершаем нашу третью книгу, представляющую собой простой учебник, который поможет людям успешно начать работу, Large-Scale Scrum: More with LeSS. /”Крупномасштабный скрам: достичь большего с LeSS”.


LeSS значит меньше


Если бы мне пришлось по-настоящему коротко описывать LeSS, я бы сказал одно: «LeSS относительно небольшой и простой». Видите ли, у меня есть опыт консультирования и коучинга в 1990-х годах по RUP (Рациональный Унифицированный Процесс). Один из ключевых выводов, которые я сделал из этого опыта, заключается в том, что фреймворки, изобилующие определениями и «предписанностью» (множеством полезных советов), на самом деле не работают с точки зрения крупномасштабного принятия. Они недостаточно контекстуальны. Они препятствуют эмпирическому контролю процесса (ключевой принцип скрама), уникальному обучению и исследованию, которые обязательно должны происходить. Группы разработчиков (и работа по разработке) слишком разнообразны для чего-то вроде детализированной четко определенной структуры или процесса или во многом стандартного рецепта. Теперь РУП попытался противостоять этой проблеме, предложив «адаптировать» или удалить элементы, чтобы якобы упростить это. В теории звучит хорошо, но в реальном мире я видел, что это просто не работает. В итоге, группы «переняли» слишком много ролей, структур, процессов и методов, став излишне «определенными» и сложными. Хотя им и посоветовали «брать из этого буфета с опциями только то, что вам действительно нужно». В этих группах сотрудники исходили из предположения, что они могли бы делегировать полномочия или избежать изучения, обнаружения и устранения своих системных слабостей, поскольку «эти проблемы решаются путем принятия фреймворка, который мы купили».Но вот, что мы узнали: более определенный процесс ведет к меньшему обучению, и, наоборот - менее определенный процесс ведет к большему обучению.

… Но LeSS - это не минимализм: Зона Златовласки для групп Шу

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


Но… проведите такой эксперимент. Отправляйтесь в продуктовую группу телекоммуникационной инфраструктуры, состоящую из 500 человек, размещенных на 5 объектах, которая десятилетиями следует очень традиционной организационной структуре и культуре, так что старая система действительно встроена в мозги сотрудников. Или так же в банк. И скажите им там: «Привет, ребята, займитесь-ка теперь системным мышлением, самообладанием, ментальными моделями, общим видением и командным обучением!»


Ничего на деле не меняется.


И это вторая вещь, которую мы узнали за десятилетия участия в инициативах по внедрению изменений: для группы, находящейся на начальной стадии принятия крупного изменения, нужна определенная критическая масса конкретных советов по структуре, политикам, процессам, ролям и т. д., чтобы действительно что-то сделать для такого изменения. В противном случае, если это группа «стадии Шу» ( стадия обучения новичков основам боевого искусства-прим.) с сильными традиционными элементами, то либо они действительно ничего не меняют, либо из-за мощных сил противодействия со стороны статуса-кво, это изменение становится «подделкой», чтобы внешне как-то соответствовать идее. Но если копнуть глубже, это окажется все той же, старой системой. Между прочим, такая подделка осуществляется путем переопределения или перезагрузки новой терминологии, чтобы она в основном означала то же, что и этот статус-кво.


Итак, существует зона Златовласки (околозвездная зона обитаемости-прим.) для современного фреймворка разработки в организации на стадии Шу: между «всего лишь несколькими простыми принципами» и «множеством ролей, структур, техник и процессов».


Мы наблюдаем (и многие другие заметили это), что обычный однокомандный скрам преимущественно и находится в такой зоне, для небольшой продуктовой группы. Его простые конкретные элементы дают достаточное определение, чтобы реализовать более глубокие принципы: эмпирический контроль процесса с прозрачностью, самоорганизацией и т.д.


Точно так же LeSS (крупномасштабный скрам) использует ту же тему: просто достаточно конкретных элементов для организации на стадии Шу, чтобы осуществить реальные изменения и знать, что делать для начала работы; чтобы задействовать более глубокие принципы эмпирического контроля процесса с прозрачностью, и самоорганизацией. Но этого едва ли достаточно. В LeSS есть огромное пространство для уникального ситуационного обучения и адаптации, которое требуется для бесчисленного множества уникальных организаций.


LeSS фокусируется на первопричинах в структуре организации.


Кроме того, коротко описывая LeSS, я бы сказал: «LeSS фокусируется на коренных причинах организационных слабостей при масштабировании». Многие эксперты по организационной структуре знают, что основными первопричинами проблем являются (1) существующее статус-кво организационных структур и ролей и (2) командно-административные политики, которые отрицают реальность неотъемлемой изменчивости и человеческой мотивации в работе по разработке. Но точно так же, многие эксперты или консультанты ходят на цыпочках вокруг этих вопросов и избегают их поднимать, поскольку это может подвергнуть сомнению существующие структуры власти и убеждений. Это еще одна причина, по которой такие «фальшивые изменения» имеют место. Другими словами, они допустимы только до той степени, пока не бросают вызов или не нарушают ролей статуса-кво, структуры власти и политики…. «Вы, программисты, принимайте, конечно, всю эту штуку со скрамом. Делайте все, что хотите, для большей продуктивности. Но убедитесь, чтобы все это было сделано к установленной вами дате доставки!… А менеджеры проектов будут измерять ваши показатели, чтобы убедиться, что вы идете правильным путем».


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


РАНЬШЕ, ТРАДИЦИОННО: UX-аналитики пишут окончательную версию Experience, чтобы передать ее другим. Команда бизнес-аналитиков описывают пользовательские случаи и передает их программистам, архитекторы определяют UML PowerPoints и проталкивают свои проекты программистам, программисты пишут код для тестирования группой тестирования, после его интеграции с помощью менеджера интеграции и т. д.


ПОСЛЕ, 'АДЖАЙЛ': Аджайл-UXы пишут Истории Опыта, чтобы другие могли их прочитать, Аджайл-БА-команды пишут пользовательские истории для передачи программистам, аджайл-архитекторы определяют Эпики Архитектуры и передают свои проекты программистам, программисты пишут код для Команды Систем для интеграции и тестирования и т. д.


Действительно, что изменилось?


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


Успех с LeSS


Конечно, понимание LeSS и его принятие - это нечто большее, чем то, чего удалось коснуться в этой краткой статье. Прекрасный способ начать работу – это курс Certified LeSS for Executives или Certified LeSS Practitioner (см. списки курсов course listings), чтения и просмотр видео на веб-сайте less.works, работа с коучем, имеющим практический опыт работы с LeSS и чтение трех книг по LeSS. LeSS прост, но эффективен, и мы хотим помочь вам добиться успеха с его принятием.

2 перегляди0 коментарів

Останні пости

Дивитися всі

Comments


bottom of page