Проектирование архитектуры информационных систем

4.1.2 Соотношение Agile и Lean

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

4.1.3 Каркас Scrum

Scrum, в русскоязычном тексте часто называемый Скрамом, представляет собой легковесный каркас организации работы над сложными продуктами. Он основан на эмпирическом управлении, при котором решения принимаются на основе наблюдаемого результата и полученного опыта. Scrum не является подробной технологической инструкцией. Он не определяет язык программирования, структуру архитектуры, метод оценки задач, правила тестирования или инструмент управления проектом. Эти практики выбираются командой с учетом контекста. Актуальная официальная версия руководства Scrum была опубликована в ноябре 2020 года и по состоянию на 2026 год остается текущей официальной редакцией. Руководство определяет Scrum через команду, события, артефакты, обязательства и связывающие их правила. Теоретической основой Scrum является эмпиризм, то есть получение знаний из опыта и принятие решений на основе наблюдений. Эмпиризм поддерживается тремя опорами: прозрачностью, инспекцией и адаптацией. Прозрачность означает, что состояние работы и продукта должно быть понятно участникам. Если требования, качество, прогресс или проблемы скрыты, решения принимаются на основе неправильной информации. Инспекция представляет собой регулярную проверку продукта и способа работы. Она не должна превращаться в тотальный контроль сотрудников. Инспекция направлена на своевременное обнаружение отклонений. Адаптация означает изменение продукта или процесса, если проверка выявила проблему или новую информацию. Инспекция без последующей адаптации не создает пользы. Scrum поддерживается пятью ценностями: обязательностью, сосредоточенностью, открытостью, уважением и смелостью. Эти ценности определяют ожидаемый характер взаимодействия команды. Основной организационной единицей является Scrum-команда. Она включает владельца продукта, Scrum-мастера и разработчиков. Внутри Scrum-команды отсутствуют отдельные подкоманды и внутренняя иерархия. Команда является межфункциональной и самоуправляемой: она располагает навыками, необходимыми для создания ценного результата, и самостоятельно определяет внутреннюю организацию работы. Официальное руководство указывает, что Scrum-команда обычно состоит из десяти или меньшего числа участников. Термин «разработчики» в Scrum имеет расширенное значение. Он относится ко всем участникам, непосредственно создающим пригодное приращение продукта. В зависимости от предметной области к ним могут относиться программисты, аналитики, тестировщики, проектировщики, специалисты по данным и другие исполнители. Владелец продукта отвечает за максимизацию ценности продукта и результативное управление бэклогом продукта. Он определяет цель продукта, обеспечивает понятность элементов бэклога и упорядочивает их. Владелец продукта не является простым секретарем, записывающим пожелания пользователей. Он должен принимать решения о приоритетах, согласовывать интересы заинтересованных сторон и обеспечивать ориентацию команды на ценность. Ответственность владельца продукта должна быть закреплена за одним человеком, а не комитетом. При этом он может консультироваться с экспертами и представителями пользователей. Scrum-мастер отвечает за правильное понимание и применение Scrum. Он помогает команде развивать самоуправление и межфункциональность, устранять препятствия, улучшать практики и взаимодействовать с организацией. Scrum-мастер не является традиционным начальником команды и не распределяет задачи между разработчиками. Он создает условия, в которых команда может эффективно управлять собственной работой. Scrum организует работу в рамках спринтов. Спринт представляет собой фиксированный период продолжительностью не более одного месяца, в течение которого создается полезное и пригодное приращение продукта. Новый спринт начинается сразу после завершения предыдущего. Внутри спринта проводятся планирование спринта, ежедневный Scrum, обзор спринта и ретроспектива. Короткая продолжительность спринта ограничивает риск. Если решение оказалось ошибочным, команда получает обратную связь раньше. Слишком длинный спринт увеличивает объем работы, выполненной без проверки. Во время спринта не должны вноситься изменения, ставящие под угрозу его цель. Однако содержание работы может уточняться по мере получения новых знаний. Это отличает Scrum от полностью жесткого плана. Планирование спринта определяет, почему предстоящий спринт имеет ценность, что может быть выполнено и каким образом будет создан результат. В ходе планирования формируется цель спринта, выбираются элементы бэклога продукта и составляется план работы. Цель спринта должна объединять работу команды. Если участники выполняют несвязанные задачи без общей цели, спринт превращается в календарный контейнер для набора поручений. Ежедневный Scrum представляет собой короткое ежедневное событие для разработчиков. Его назначение состоит в проверке продвижения к цели спринта и адаптации плана. Ежедневный Scrum не должен превращаться в отчет каждого сотрудника руководителю. Команда координирует собственную работу, выявляет препятствия и принимает решения о следующем шаге. Обзор спринта проводится для анализа результата вместе с заинтересованными сторонами и определения дальнейших изменений. Команда демонстрирует созданное приращение, рассматривает состояние продукта и уточняет будущие приоритеты. Обзор не является только праздничной демонстрацией. Он должен обеспечивать содержательную обратную связь. Если заинтересованные стороны не участвуют или решение уже невозможно изменить, ценность обзора уменьшается. Ретроспектива спринта направлена на повышение качества и эффективности. Команда анализирует людей, взаимодействия, процессы, инструменты и определение готовности, а затем выбирает полезные улучшения. Scrum определяет три основных артефакта: бэклог продукта, бэклог спринта и приращение. Каждому артефакту соответствует обязательство, усиливающее прозрачность. Бэклог продукта является возникающим и упорядоченным перечнем всего, что необходимо для улучшения продукта. Его обязательством является цель продукта, описывающая будущее состояние, к которому стремится команда. Бэклог называется возникающим, потому что он изменяется по мере получения новых знаний. Он не является раз и навсегда утвержденным списком. Бэклог спринта включает цель спринта, выбранные элементы бэклога продукта и план их реализации. Он создается разработчиками и обновляется в течение спринта. Приращение представляет собой конкретный шаг к цели продукта. Оно должно быть совместимо с предыдущими приращениями, проверено и пригодно для использования. Обязательством приращения является определение готовности. Оно устанавливает формальное описание состояния, при котором работа соответствует требованиям качества и может считаться частью приращения. Официальное руководство связывает бэклог продукта с целью продукта, бэклог спринта — с целью спринта, а приращение — с определением готовности. Определение готовности может включать прохождение автоматических тестов, проверку кода, обновление документации, соответствие требованиям безопасности, развертывание в тестовой среде и отсутствие критических дефектов. Не следует смешивать определение готовности с критериями приемки отдельной функции. Критерии приемки относятся к конкретному требованию, а определение готовности устанавливает общий уровень качества для всех элементов. В Scrum часто используются дополнительные инструменты, не входящие в обязательное ядро каркаса. К ним относятся пользовательские истории, оценка в условных единицах, диаграмма сгорания работы, планирование с карточками, карта историй и методы приоритизации. Например, диаграмма сгорания показывает изменение оставшегося объема работы во времени. Она помогает увидеть, успевает ли команда завершить запланированное. Однако сама диаграмма не гарантирует создание ценности и не должна использоваться как единственный показатель эффективности. Scrum эффективен в условиях сложной работы, когда невозможно заранее определить все решения и требуется регулярная проверка результата. Он обеспечивает ритм, прозрачность и взаимодействие. Ограничением Scrum является риск формального применения. Организация может проводить все события, но сохранять командно-административное управление, передавать задачи крупными партиями и не выпускать продукт месяцами. Другой проблемой является использование спринта как жесткого обязательства выполнить заранее назначенный объем. Цель спринта является обязательством, но отдельные элементы могут уточняться. Попытка любой ценой выполнить первоначальный перечень приводит к снижению качества и скрытию проблем. Scrum не решает автоматически архитектурные и инженерные задачи. Без автоматического тестирования, управления конфигурацией, качественной архитектуры и технического совершенствования команда может быстро накапливать технический долг.

4.1.4 Метод Kanban

Kanban, или Канбан, представляет собой метод управления потоком знаний и услуг, основанный на визуализации работы, ограничении незавершенной работы, управлении потоком и эволюционном совершенствовании существующего процесса. Канбан необходимо отличать от простой доски с карточками. Доска является одним из инструментов визуализации, но полноценный метод включает принципы, правила, показатели, ограничения и циклы обратной связи. Официальное руководство Kanban University выделяет принципы управления изменениями: начинать с существующего способа работы, стремиться к улучшению через эволюционные изменения и поддерживать лидерские действия на всех уровнях. Метод не требует одномоментной полной перестройки организации, а развивается на основе наблюдения за текущим процессом. Первой общей практикой Kanban является визуализация работы. Для этого создается доска, отражающая стадии процесса. Простейшая доска может включать состояния «Запланировано», «Анализ», «Разработка», «Проверка», «Готово». Карточка представляет единицу работы: пользовательскую функцию, дефект, аналитическую задачу, запрос на изменение или техническую работу. Ее движение по доске показывает состояние. Визуализация должна отражать реальный процесс, а не желаемую упрощенную картину. Если задача ожидает архитектурного согласования или развертывания, соответствующая стадия должна быть видна. Иначе время ожидания остается скрытым. На карточке могут указываться тип работы, ответственный, дата начала, срок, приоритет, класс обслуживания, блокировка и связанные зависимости. Второй практикой является ограничение незавершенной работы. Для отдельных стадий устанавливается максимальное количество одновременно находящихся в них элементов. Например, если для стадии разработки установлен предел пять задач, шестая задача не должна начинаться до завершения одной из текущих. Команда сосредотачивается на завершении начатого, а не на постоянном открытии новых задач. Ограничения делают узкие места видимыми. Если очередь перед тестированием постоянно достигает предела, проблема может заключаться в недостаточной автоматизации тестов, неравномерном распределении компетенций или низком качестве разработки. Без ограничения работы доска только отображает перегрузку, но не управляет ею. Третьей практикой является управление потоком. Команда стремится обеспечить предсказуемое и равномерное движение задач. Анализируются задержки, блокировки, возвраты и колебания нагрузки. Поток не означает максимальную загрузку каждого сотрудника. Система, в которой все участники загружены на сто процентов, может работать медленно, поскольку отсутствует резерв для обработки проблем и взаимной помощи. Четвертой практикой является явное определение правил. Участники должны понимать условия перехода карточки между стадиями, правила приоритета, критерии готовности, ограничения и порядок обработки срочных работ. Например, задача может переходить в состояние «Готова к тестированию» только после прохождения модульных тестов, проверки кода и обновления описания программного интерфейса. Неявные правила приводят к конфликтам. Один разработчик считает задачу готовой после написания кода, другой — после развертывания, тестировщик — после устранения всех дефектов. Явная политика устраняет неоднозначность. Пятой практикой является использование циклов обратной связи. В Kanban могут проводиться ежедневные совещания, обзоры поставки, анализ рисков, пополнение очереди, обзоры операций и стратегические обзоры. Разные циклы решают различные задачи. Ежедневная встреча координирует текущий поток, пополнение определяет, какие задачи допускаются к выполнению, а обзор поставки анализирует предсказуемость и качество обслуживания. Шестой практикой является совместное улучшение и экспериментальное развитие. Изменения процесса формулируются как гипотезы и проверяются по показателям. Например, команда предполагает, что автоматизация подготовки тестовой среды уменьшит среднее время прохождения задачи. После внедрения сравниваются показатели до и после изменения. К основным показателям Kanban относятся время выполнения запроса, время цикла, пропускная способность и объем незавершенной работы. Время выполнения запроса измеряет период от появления потребности до предоставления результата. Время цикла обычно измеряет период от начала активной работы до завершения. Границы показателей должны быть явно определены. Пропускная способность показывает количество элементов, завершенных за определенный период. Объем незавершенной работы показывает количество элементов, находящихся в процессе. Важным средством анализа является накопительная диаграмма потока. Она отображает количество элементов в каждом состоянии во времени. Расширение области определенной стадии указывает на накопление очереди. Другим инструментом является диаграмма времени цикла, показывающая длительность выполнения отдельных задач. Она позволяет оценивать вариативность и формировать прогнозы. Kanban стремится к прогнозированию на основе исторических данных. Вместо обещания завершить каждую задачу к точной дате может использоваться вероятностное ожидание, например определенная доля задач данного типа завершается за установленный срок. Для разных типов работ могут применяться классы обслуживания. Срочная работа получает особые правила, но число срочных задач должно быть ограничено. Если каждая задача объявляется срочной, система теряет управляемость. Kanban хорошо подходит для сопровождения информационных систем, обработки заявок, эксплуатации, поддержки пользователей и других процессов с непрерывным поступлением работы. Он также может использоваться в проектной разработке. В отличие от Scrum, Kanban не требует фиксированных спринтов и определенных ролей. Работа может поставляться по мере готовности. При этом метод не запрещает использование итераций. Scrum и Kanban могут сочетаться. Scrum задает ритм планирования и обзора, а Kanban помогает управлять потоком внутри спринта. Такое сочетание иногда называется Scrumban, или Скрамбаном, однако конкретные правила должны быть определены организацией. Основным риском Kanban является ограничение применения только визуальной доской. Если отсутствуют ограничения незавершенной работы, показатели, явные правила и улучшение процесса, организация не получает основных преимуществ метода.

4.1.5 Сравнение Scrum и Kanban

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

4.1.6 Типичные ошибки гибкой разработки

Первой ошибкой является представление Agile как отсутствия планирования. Гибкий подход предполагает постоянное планирование на разных уровнях: цели продукта, выпусков, итераций и ежедневной работы. Отличие заключается в возможности корректировать план на основе новой информации. Второй ошибкой является отказ от документации. Гибкость требует создавать документацию в объеме, необходимом для понимания, эксплуатации, безопасности и сопровождения. Особенно важны архитектурные решения, требования к интерфейсам, модели данных и инструкции эксплуатации. Третьей ошибкой является подмена результата количеством выполненных задач. Закрытие карточки не гарантирует получения ценности. Необходимо оценивать использование функции, качество и влияние на цели. Четвертой ошибкой является разделение команды на последовательные мини-подразделения. Аналитик завершает требования, передает разработчику, разработчик — тестировщику. В результате внутри короткого спринта воспроизводится каскадная модель. Пятой ошибкой является отсутствие технического совершенствования. Если команда постоянно добавляет функции, но не улучшает архитектуру, тесты и средства развертывания, скорость разработки постепенно снижается. Шестой ошибкой является использование оценки как средства давления. Условные единицы и скорость предназначены для прогнозирования команды, а не для индивидуального контроля. Седьмой ошибкой является формальная ретроспектива. Если одни и те же проблемы обсуждаются, но не устраняются, доверие к процессу снижается.

4.2 Методология DevOps

DevOps представляет собой культурный, организационный и инженерный подход, объединяющий разработку программного обеспечения и его эксплуатацию в единый поток создания и предоставления ценности. Название образовано от английских слов development и operations, однако в русскоязычной лекции целесообразно понимать DevOps как совместную организацию разработки и эксплуатации. Традиционно разработчики могли отвечать за создание функций, а эксплуатационное подразделение — за стабильность работающей системы. Интересы подразделений вступали в противоречие. Разработчики стремились чаще выпускать изменения, эксплуатация стремилась уменьшить число изменений как источник риска.DevOps исходит из того, что скорость развития и надежность не должны достигаться разными изолированными группами. Команда должна учитывать эксплуатационные характеристики с начала проектирования, а эксплуатационная информация должна использоваться для улучшения продукта. DevOps не является отдельной должностью, конкретным инструментом или обязательной архитектурой. Наличие инженера с названием должности «DevOps» не гарантирует внедрения подхода. Основное значение имеют совместная ответственность, автоматизация, быстрые обратные связи, управляемые изменения и обучение. В DevOps особое значение имеет управление всем потоком поставки. Он начинается с изменения программного кода или конфигурации и завершается безопасным предоставлением результата пользователю и наблюдением за работой. Основой является управление версиями. В системе контроля версий должны храниться программный код, сценарии сборки, конфигурации, тесты, описание инфраструктуры и, по возможности, архитектурная документация. Это обеспечивает историю, проверку изменений и возможность воспроизведения. DORA указывает, что комплексное использование управления версиями является важной способностью непрерывной поставки. Следующей практикой является непрерывная интеграция. Разработчики часто объединяют небольшие изменения в общей основной ветви. Каждое изменение автоматически собирается и проверяется. Назначение непрерывной интеграции заключается не только в запуске автоматических тестов. Она сокращает длительность изоляции изменений и позволяет раньше выявлять конфликты. DORA связывает непрерывную интеграцию с небольшими партиями работы и быстрыми циклами обратной связи. Автоматизированный процесс может включать получение исходного кода, установку зависимостей, компиляцию, модульные тесты, статический анализ, проверку безопасности, сборку пакета и публикацию артефакта. Если сборка или обязательная проверка завершается ошибкой, исправление должно иметь высокий приоритет. Длительное существование неработающей основной ветви лишает команду надежной интеграционной основы. Непрерывная поставка означает способность быстро, безопасно и устойчиво выпускать изменения по требованию. Программный продукт поддерживается в состоянии, пригодном для развертывания. DORA отличает непрерывную поставку от непрерывного развертывания: при поставке выпуск возможен в любой момент, а при непрерывном развертывании каждое успешно прошедшее изменение автоматически передается в промышленную среду. Непрерывное развертывание подходит не для каждой системы. Мобильное приложение требует публикации через внешнюю площадку, а критическая система может требовать официального разрешения. Однако даже при ручном решении о выпуске сборка, тестирование и подготовка должны быть автоматизированы. Последовательность автоматизированных действий называется конвейером поставки. Он может включать стадии сборки, тестирования, проверки безопасности, упаковки, развертывания и контроля после выпуска. Описание конвейера целесообразно хранить в виде кода. Jenkins, например, поддерживает определение конвейера в файле Jenkinsfile, который хранится вместе с проектом и проходит управление версиями. Официальная документация определяет такой конвейер как автоматизированное представление процесса движения программного обеспечения от системы контроля версий до пользователей. Системы GitHub Actions также позволяют автоматизировать сборку, тестирование и развертывание на основе событий в репозитории. Ключевой практикой DevOps является инфраструктура как код. Серверы, сети, хранилища, политики и другие ресурсы описываются декларативными конфигурациями, которые можно хранить в системе контроля версий, проверять и повторно применять. Terraform позволяет описывать облачные и локальные ресурсы в конфигурационных файлах и управлять их жизненным циклом через последовательность записи, предварительного плана и применения изменений. Инфраструктура как код снижает зависимость от ручной настройки. Если тестовая среда создается вручную, она может незаметно отличаться от промышленной. Автоматизированное описание обеспечивает повторяемость. Управление конфигурацией автоматизирует настройку операционных систем, программ, пользователей и сервисов. Ansible использует человекочитаемые сценарии, называемые плейбуками, и стремится приводить управляемую систему к описанному состоянию. Повторное выполнение не должно изменять уже правильно настроенную систему. Контейнеризация позволяет упаковать приложение вместе с необходимыми зависимостями в переносимый образ. Контейнеры запускаются как изолированные процессы и помогают обеспечить единообразие среды. Контейнер не решает автоматически проблемы архитектуры. Если приложение плохо разделено, не имеет мониторинга или хранит состояние неправильно, упаковка в контейнер не устранит недостатки. Для управления большим числом контейнеров применяется оркестрация. Kubernetes является открытой платформой управления контейнеризированными рабочими нагрузками и поддерживает декларативную конфигурацию, автоматизированное развертывание, масштабирование и управление. Оркестрация оправданна при соответствующем масштабе и сложности. Для небольшой системы Kubernetes может создать больше эксплуатационной нагрузки, чем пользы. DevOps требует автоматизированного тестирования. Проверки должны выполняться на разных уровнях: модульном, интеграционном, системном, пользовательском, нагрузочном и безопасностном. Автоматизация не отменяет исследовательское тестирование. Она берет на себя повторяющиеся проверки и освобождает специалистов для анализа сложных сценариев. Важной практикой является статический анализ программного кода. Он позволяет обнаруживать потенциальные дефекты, нарушения правил, уязвимости и проблемы сопровождаемости без выполнения программы. SonarQube, например, применяет профили правил и пороги качества, определяющие возможность принятия изменения. Официальная документация связывает анализ с защищенностью, надежностью и сопровождаемостью программного обеспечения. DevOps охватывает наблюдаемость системы. Она включает журналы событий, показатели, распределенную трассировку и профилирование. Мониторинг показывает известные показатели и состояния, например загрузку процессора, количество ошибок или время отклика. Наблюдаемость позволяет исследовать внутреннее состояние системы по внешним данным и отвечать на заранее не предусмотренные вопросы. Логи должны содержать достаточный контекст, но не раскрывать пароли, персональные данные и другие секреты. Метрики используются для анализа тенденций и уведомлений. Трассировка показывает прохождение запроса через распределенные компоненты. DevOps использует управление инцидентами. При отказе команда должна обнаружить проблему, ограничить влияние, восстановить сервис, установить причины и реализовать улучшения. Анализ инцидента должен быть направлен не на поиск виновного, а на понимание системных причин. Ошибка человека часто становится катастрофической только при отсутствии защитных механизмов, проверок и возможности безопасного отката. Для уменьшения риска применяются стратегии постепенного выпуска. Сине-зеленое развертывание использует две среды, между которыми переключается трафик. Канареечный выпуск сначала предоставляет новую версию небольшой части пользователей. Функциональные переключатели позволяют включать и выключать функции независимо от развертывания кода. Автоматизация выпуска должна сопровождаться возможностью отката или быстрого исправления. При изменении структуры базы данных откат может быть сложным, поэтому миграции проектируются с учетом совместимости версий.