Техническое совершенство и качество в LeSS

В этой статье мы расскажем, почему в LeSS так много внимания уделяется техническим практикам, и как обеспечить высокое качество продукта в каждом инкременте. Мы рассмотрим все ключевые аспекты – от Definition of Done и непрерывной интеграции до устранения технического долга.

Техническое совершенство – основа масштабирования Scrum

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

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

Основатели LeSS Бас Водде и Крэг Ларман прямо указывают, что фундаментом для единого инкремента служат такие практики технического совершенства, как непрерывная интеграция и автоматизированное тестирование (ATDD, TDD и др.). Без них несколько команд просто не смогли бы синхронно выдавать результат каждый спринт. Таким образом, масштабирование Scrum в LeSS строится на фундаменте – сначала наведите технический порядок, и лишь затем добавляйте команды.

Как добиться качества в масштабируемой среде

В LeSS качество продукта — ответственность всех команд. Для успешной совместной работы необходимы единые стандарты. Рассмотрим ключевые из них.

Единый Definition of Done

Definition of Done – это перечень критериев, по которым определяется, что элемент Product Backlog завершён и продукт готов к потенциальному релизу. В масштабной Scrum-среде каждый знает, что означает «готово» для инкремента. 

Примеры DoD для User Story:

• Юнит тесты пройдены
• Код просмотрен
• Acceptance Criteria выполнены
• Функциональные тесты пройдены
• Выполнены нефункциональные требования
• Владелец Продукта принял User Story

Единые критерии позволяют командам легко объединять свои результаты, при этом DoD должен охватывать все необходимые виды работ. Например, функциональное готовое ПО, проверенное на безопасность и производительность, с учетом нефункциональных требований. Если Definition of Done слабый, появляется так называемая невыполненная работа (Undone Work) – моменты, которые остались за рамками спринта. В LeSS можно этого избежать за счет расширения Definition of Done и повышения планки качества на всех этапах. 

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

Непрерывная интеграция (CI)

Continuous Integration означает, что разработчики загружают изменения в общую кодовую базу как минимум ежедневно, и каждое интегрирование проверяется автоматической сборкой и тестами. 

В LeSS культивируется именно такой подход – все команды работают в одном репозитории и не создают ответвлений. Изменения интегрируются сразу в основную ветку. Получается, что провал сборки — это срочная проблема, требующая немедленного решения.

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

Автоматизация тестирования

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

В LeSS это особенно актуально. Код постоянно меняется, а значит всё, что автоматически проверяет продукт, должно постоянно прогоняться и быть доступно командам – юнит-тесты, интеграционные тесты, авто-тесты UI и API. Это создает предохранительную сеть – если кто-то из команды внесет правку, то тут же запустятся сотни тестов. 

В масштабной разработке, где код общий и любая команда может менять любую часть системы (feature-команды), автоматизированные тесты особенно важны для уверенности в продукте. Конечно, не всё можно автоматизировать – например, UX-исследования или сложные сценарии с физическим оборудованием – но такие вещи выносятся отдельно, а 80-90% тестовой рутины автоматизируется. 

Как заметила специалист по Agile-тестированию Элизабет Хендриксон, инвестиции в автотесты окупаются очень быстро:

— Если тест достаточно важен, чтобы его прописать и выполнить вручную, значит он достаточно важен, чтобы его автоматизировать. 

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

DevOps и непрерывная поставка (CD)

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

С практической точки зрения, LeSS-команды внедряют инфраструктуру непрерывной доставки (Continuous Delivery) с целью минимизировать разрыв между написанием кода и его попаданием в руки пользователей – автоматизированные пайплайны для сборки, тестирования и деплоя, среды, максимально приближенные к боевым, мониторинг и другие инструменты.

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

Управление техническим долгом

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

Примеры технического долга:

• Временные обходные решения
• Дублирование кода
• Быстрые хаки в ущерб качественному дизайну
• Устаревшие модули, которые давно пора переработать

Технический долг уже вреден на небольшом проекте с одной Scrum-командой, но его влияние ограничено масштабом команды. А теперь представьте продукт, где работают 5-10 команд. Любой технический долг там ощутим с процентами – он замедляет сразу десятки инженеров, осложняя совместную работу.

Исследования подтверждают, что накопленный технический долг вызывает трения и значительно замедляет поставку. В итоге команда не может поставлять в том масштабе, который нужен бизнесу. Другими словами, невозможно эффективно масштабироваться, игнорируя технический долг – все упрется в потолок сложности и дефектов. LeSS строго относится к техническому долгу и рекомендует управлять им с самого начала. Это проявляется в нескольких аспектах.

Встроенное улучшение кода

В LeSS нет отдельной фазы проекта для “рефакторинга” или “стабилизации” – улучшение качества кода встроено в каждодневную работу команд. Если команда замечает неудобный модуль или дублирование, они пытаются исправить это на месте, в ходе выполнения функциональной задачи. Рефакторинг становится частью Definition of Done – фича не считается полностью готовой, если команда, реализуя её, создала себе проблемы на будущее. 

Таким образом любой новый код сразу приводится к общим стандартам чистоты и дизайна. Это соответствует практике экстремального программирования (XP) – «покинь место в лучшем состоянии, чем оно было». Каждый коммит должен улучшать кодовую базу или хотя бы не ухудшать её.

Прозрачность и приоритизация долга

Конечно, бывает, что у продукта исторически есть долг. В таких случаях важно о нём не забыть. Команды в LeSS выносят долговые элементы в бэклог – например, записывают как технические User Story или задачи на техдолг. Product Owner в LeSS понимает значение таких задач, потому что скорость выпуска фич напрямую зависит от качества кодовой базы. Поэтому некоторые технические улучшения могут быть приоритезированы почти наравне с бизнес-фичами, особенно если долг несёт риски, такие как ненадежность, трудности масштабирования, уязвимости и так далее. 

На каждой командной ретроспективе все оценивают, не мешает ли им качество кода. А на общей ретроспективе (Overall Retrospective) вопрос тех долга может подниматься как системная проблема, требующая внимания менеджмента. Такая прозрачность не даёт долгу прятаться – о нём знают, его влияние обсуждается, и его гашение планируется.

Непрерывное обучение и профилактика

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

Принцип «остановите линию» 

В Lean-подходе на производстве, если обнаружен дефект на конвейере, производство останавливается до устранения причины. В разработке ПО подобный принцип означает, что критические проблемы (например, упавшие авто-тесты или сломанная сборка) устраняются немедленно, приостанавливая новые изменения. Это позволяет не накапливать процент по долгу. В LeSS такой подход означает, что, пока сборка не исправлена, новые изменения не вносятся — вся команда чинит проблему. Стоит отметить, что LeSS сознательно исключает фазы стабилизации, полагаясь на непрерывное поддержание качества. 

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

За архитектурные решения отвечают команды, а не отдельные роли

Традиционно во многих организациях стратегические решения по архитектуре отдавались архитектору или архитектурному комитету. Казалось бы, в большом продукте нужен специальный человек, который будет следить за целостностью системы. Однако Agile-подход, в особенности LeSS, подвергает сомнению такое распределение ответственности. В LeSS архитектура рассматривается не как должность, а как коллективное действие и навык команд. Нет отдельной роли Software Architect, вместо этого архитектурное мышление включено в обязанности самих команд. Есть несколько причин, почему LeSS отказывается от отдельной роли архитектора.

Избежание разрывов и узких мест

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

В противоположность этому, LeSS стремится вернуть архитектуру в руки разработчиков, то есть отдать решения тем, кто будет воплощать их в коде. Это повышает ответственность команд и устраняет бюрократию согласований. Практика показывает, что если архитектурные решения принимают сами команды, то они лучше понимают систему и чаще находят реально работающие решения.

Архитектура – это непрерывный процесс

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

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

Отсутствие отдельных архитектурных команд и групп в LeSS

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

Может возникнуть вопрос, как координировать архитектуру между командам на ранних этапах, когда нужно выбрать технологии и определить базовую структуру? Через механизмы сотрудничества, но не через постоянную роль. Например, на старте большого продукта команды могут провести общие архитектурные ворк-шопы – собрать ведущих разработчиков от каждой команды, обсудить и наметить основные компоненты и их взаимодействие. 

Дальнейшее обсуждение продолжается на совместных встречах:

• На уточнении бэклога продукта обсуждаются архитектурные последствия новых фич.
• На общей ретроспективе поднимаются системные технические проблемы.
• В сообществах практик разработчики разных команд регулярно обмениваются знаниями и согласовывают подходы — например, выбирают общие библиотеки, определяют стиль кода и конвенции.

Технические лидеры – наставники, а не командиры

Часто в больших продуктах есть сильные инженеры, технические лидеры, которые обладают глубоким знанием системы. Вместо того чтобы закреплять за ними формальные роли архитекторов, LeSS поощряет модель roaming experts или «переходящие эксперты». Это означает, что опытный инженер может временно присоединяться к разным командам, помогая с их дизайном, он может участвовать в парном программировании, устраивать дизайн-ревью и делится знаниями. 

Такой лидер не командует, а именно обучает на практике, показывает пример и улучшает части системы вместе с командой. В литературе LeSS есть понятие «component mentor» или наставник по компоненту. То есть человек, который хорошо знает определенный компонент системы, и который помогает любому, кто в нём работает. Важно, что наставник не блокирует коммиты других, не требует формального одобрения каждого изменения, его задача – подтянуть уровень всех разработчиков до понимания архитектуры, вместо того чтобы единолично решать всё. В результате архитектура становится живым знанием в головах всей группы.

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

Не жертвуйте надежностью, избегая бюрократии

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

LeSS позволяет сохранять баланс между скоростью и качеством, избегая лишней бюрократии

Во-первых, LeSS – это фреймворк, упрощающий масштабирование. В нём намеренно меньше ролей и артефактов по сравнению с другими подходами. Нет надстройки в виде программных менеджеров, координаторов, отдельного релиз-менеджмента – все эти промежуточные звенья убраны. Так требования идут напрямую к командам, работающих над функциональностью, а тестирование и развертывание выполняются самими командами, без ожидания очереди в другом отделе. Меньше слоев – меньше задержек. Таким образом, скорость повышается за счет устранения бюрократии и холостых циклов. 

LeSS сохраняет ритм Scrum – те же спринты, те же обзоры, та же ретроспектива и прочее. Но не добавляет сложных церемоний – весь фокус на том, чтобы команды тратили максимум времени на реальную поставку ценности.

Во-вторых, парадоксально, но именно высокий уровень качества позволяет двигаться быстрее в долгосрочной перспективе. Если попытаться экономить время, пропуская тестирование или не проводя рефакторинг, скорость упадет из-за багов и интеграционных проблем. LeSS придерживается принципа: «делай правильно, чтобы делать быстро». Каждая команда должна следить за качеством своей работы, чтобы интеграция с другими не была проблемой. В реальности это означает, что команды не упрощают Definition of Done даже ради срочного релиза. Если пользовательская история не успевает выполниться с соблюдением DoD, её переносят, а не пытаются выдать наполовину сырой результат. 

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

В-третьих, качество – зона ответственности команд, а не контролирующего органа. В традиционных организациях, чтобы обеспечить надежность, вводят процедуры контроля качества, чеклисты, комитеты – словом, бюрократию. В LeSS команды сами соблюдают DoD, сами проводят код-ревью, сами запускают тесты и видят результаты CI. 

Нет надсмотрщика, но есть внутренняя мотивация разработчиков делать хорошо. Эту культуру поддерживают Scrum-мастера и менеджеры в LeSS-организациях. Например, если одна из команд начинает торопится в ущерб качеству, это всплывет на общей ретроспективе как проблема. Ведь если интеграция затормозится, то другие команды это почувствуют. За этим последует совместный поиск решения, как восстановить баланс – может, добавить автотестов, может обучить команду практикам Test-Driven Development или помочь с ресурсами. 

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

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

Качество – это не то, на что тратится время, а то, что экономит время и деньги в масштабе

В LeSS нет лишних ролей и этапов, но взамен усиливаются технические практики. Более пяти команд могут работать как одна, потому что у них единые стандарты кода, общий Definition of Done и непрерывный процесс интеграции. Да, достичь этого непросто – это требует инвестиций в обучение, инструменты и изменения культуры. Зато в награду вы получите организацию, которая может быстро реагировать на рыночные изменения, и не тонуть в дефектах.

• Устраняя технический долг, мы устраняем преграды для развития.
• Вовлекая команды в архитектурные решения, ускоряем их работу и улучшаем дизайн системы.
• Автоматизируя рутинные процессы, сокращаем ручной труд и снижаем риски.

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

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