Реализация гибких методик, масштабируемых

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Корпоративные организации принимают гибкие методики по многим причинам. Основными из этих причин являются следующие:

  • Сокращение времени выхода на рынок и ускорение выпуска продуктов
  • Повышение эффективности организации для управления изменяющимися приоритетами
  • Повышение качества программного обеспечения и прогнозируемости доставки
  • Улучшение видимости проекта и уменьшение риска проекта

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

  • Что такое успех для вас, ваших команд и вашей организации? Что вас интересует больше всего: своевременная доставка? Качество продукта? Предсказуемость? Удовлетворенность клиентов?
  • Вернитесь к первым принципам и вернитесь к принципам и общим ценностям, перечисленным в манифесте Agile , как отмечает Кен Швабер, один из основателей Scrum:
    • "Ценности и принципы масштабируются, а практики чувствительны к контексту."
    • "Держите ценности, держите принципы и думайте для себя. Основная предпосылка Agile заключается в том, что люди, выполняющие работу, являются людьми, которые могут лучше всего выяснить, как это сделать".

Создание ритма и потока

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

  • Общий ритм:Регулярные спринты и релизы устанавливают ритм бизнеса. Работа всех команд в едином ритме помогает координации и сотрудничеству.
  • Спринт-коммуникации: чтобы информировать организацию и все команды о ходе выполнения и планах команд по функциям, каждая команда по функциям может поделиться сводкой о предыдущих результатах спринта и текущих планах через цифровые каналы, такие как Microsoft Teams, Slack или электронная почта.
  • Демонстрации и видео спринта: быстро создавайте 2-3-минутные видеоролики, которые иллюстрируют новые функции, разработанные командой. Делитесь ссылками на такие видеоролики в коммуникациях спринта или канале команды.
  • Показ собраний: чтобы информировать другие команды и получать обратную связь о программном обеспечении, разработка которого ведется, команды демонстрируют работу, которую они завершили. Проводите эти собрания через регулярные интервалы в течение жизненного цикла проекта и откройте их всем заинтересованным сторонам.
  • Панели мониторинга качественных метрик: для поддержки понимания качества продукта и поощрения поддержания культуры работы с ошибками, регулярно предоставляйте метрики качества организации. Эти метрики могут включать активные ошибки для каждой команды функций, тенденций ошибок, покрытия тестов и скорости побега дефектов.
  • Собрания и церемонии координации: проведение собраний, координирующих команды с регулярными интервалами или по мере необходимости для обсуждения перекрывающихся целей, зависимостей и рисков. Рассмотрите возможность проведения Scrum of Scrums или сеансов планирования программного инкремента (PI).

Взаимодействие с клиентами

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

  • Циклы непрерывной обратной связи: создание механизмов обратной связи клиентов. Эти циклы могут принимать множество форм:
    • Платформы голосовой связи клиентов. Это упрощает предоставление клиентам отзывов, добавление идей и голосование по функциям следующего поколения с помощью выделенных порталов, форумов сообщества или интегрированных систем обратной связи.
    • Отзывы о продукте: реализуйте кнопки обратной связи и телеметрию в продукте, чтобы получить аналитические сведения об опыте продукта и конкретных функциях.
    • Демонстрации клиентов и тестирование пользователей: запланируйте регулярные демонстрации, которые запрашивают отзывы от клиентов и проводят сеансы тестирования удобства использования, чтобы помочь сформировать продукты следующего поколения и следить за созданием приложений, которые клиенты хотят использовать.
  • Ранние программы внедрения и бета-версии: разработка программ с идеей, что все команды могут принять участие в какой-то момент. Ранние пользователи получают доступ к ранним версиям рабочего программного обеспечения и предоставляют ценные отзывы. Часто эти программы работают путём включения флагов функций для списка ранних пользователей.
  • Решения на основе данных: поиск способов инструментирования продукта для получения полезных данных и тестирования различных гипотез. Стремление к культуре, благоприятной для экспериментов, поощряющей обучение и принятие решений, основанных на доказательствах.

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

Чем больше понимания вы и ваши команды имеете о цели, видении и процессе выполнения работы, тем легче вам будет снизить риски и вести управление зависимостями.

  • Структура команды: Независимо от того, насколько большая ваша организация становится, эффективное структурирование вокруг небольших команд, состоящих из 6 до 9 человек, хорошо масштабируется. Создайте вертикальные, автономные группы функций, сгруппированные в области управления портфелями.
  • Структура разбивки рабочих работ: разделение больших целей, функций или требований на небольшие остается основным элементом управления проектами. Разбивая работу на аналогичные задачи, команды могут повысить оценку и определить риски и зависимости.
  • Объединенные представления и панели мониторинга: используйте средства отслеживания в Интернете для статистической работы и получения знаний в разных командах. Создание панелей мониторинга в режиме реального времени для отображения хода выполнения, тенденций и ключевых показателей производительности с помощью служб Azure DevOps Analytics.
  • Обзоры опыта и проектирования: Проводите эти собрания до начала разработки функции, чтобы информировать управление о сценариях и приоритетах, собирать отзывы, устанавливать ожидания и выявлять любые межкомандные проблемы, связанные с функцией.

Расширение возможностей продуктивной рабочей силы

К конкретным методикам гибкой работы, которые хорошо масштабируется и приводят к более счастливым, заинтересованным и продуктивным сотрудникам, относятся:

  • Внедренное руководство и психологическое обеспечение безопасности: расширение возможностей команд и лидеров в организации для самоорганизации и самостоятельного управления как можно больше. Автономия команды повышает гибкость организации и эффективность команды. Убедитесь, что команды имеют корпоративное спонсорство, необходимое для успеха и создания сред, где члены команды чувствуют себя в безопасности, чтобы выразить идеи и опасения.
  • Ежедневные митинги: Собрания Scrum помогают командам сосредоточиться на том, что им нужно делать ежедневно, чтобы максимально эффективно выполнять свои обязательства по спринту. По мере роста организаций следует рассмотреть возможность чередования времени проведения этих собраний, чтобы обеспечить участие между командами по мере необходимости.
  • Scrum of scrums: Представители разных команд Agile регулярно встречаются, чтобы сообщить о выполненных работах, дальнейших шагах и проблемах или блоках, возникающих в их командах.
  • Обмен данными и знаниями в команде. Предоставление и поощрение команд поделиться своими практиками и рекомендациями через корпоративные сети. К общим средствам относятся вики-сайты группы, Microsoft Teams, Confluence или вики-сайты Azure DevOps.
  • Качество совместной работы и кода: поощряйте неофициальные связи между командами и совместную работу. Утвердить такие методики, как проверки кода, проверки дизайна, парное программирование и моб программирование. Эти методики не только повышают совместную работу команды, но и помогают разрабатывать индивидуальные и общие корпоративные компетенции.

Улучшение организационной культуры

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

  • Ретроспективы: Задайте такие вопросы, как: "Что пошло хорошо?", "Что мы должны делать по-другому?", и "Что мы должны прекратить делать?", чтобы помочь командам подумать о том, как они могут улучшить свои процессы и практики. Ретроспективы помогают командам выявлять то, что работает хорошо, и то, что требует улучшения. Ретроспективы можно проводить в любое время и в любом месте. Однако институционализация некоторых ретроспектив на регулярном уровне помогает установить непрерывные методики улучшения. Например:

    • Ретроспективы спринта помогают командам выявлять области для улучшения на регулярной основе.

    • Ретроспективы выпуска помогают организациям определять области для улучшения общения и внутренних практик и способствуют развитию для следующего выпуска.

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

      См. вики-ресурс по гибким ретроспективам для идей, советов и инструментов по планированию и проведению ретроспектив. Смотрите также расширение Marketplace Retrospectives.

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

    Доска предоставляет простые и визуальные средства для захвата идей. Кроме того, вы можете создать команду отслеживания улучшений и записать идеи, которые вы отслеживаете на электронной доске.

  • Институцианализировать совместное использование и обучение: обмен передовым опытом и идеями способствует росту и улучшению всех команд в организации. Разработка культуры обучения поддерживает эту и другую непрерывную деятельность по улучшению. Рассмотрим следующие идеи:

    • Внутренние вики-сайты и базы знаний

    • Сообщества практики и гильдий

    • Недели хакатонов или время для инноваций

    • Внутренние команды DevOps и Agile коучинга для поддержки команд, внедряющих эти практики

    • Регулярные сеансы обеда и обучения

    • Внутренние конференции и технологические переговоры

      The Culture Game является полезным ресурсом для менеджеров Agile, чтобы помочь командам принять Agile-практики и поделиться лучшими практиками.

  • Сообщества практики: поддержка внутренних общих дисциплин (например, инженеров надежности сайта, архитекторов программного обеспечения, конструкторов пользовательского интерфейса, специалистов по обработке и анализу данных и безопасности)

Работающее программное обеспечение

"Часто поставляйте рабочее программное обеспечение, от нескольких недель до нескольких месяцев, с предпочтением более короткого интервала времени."
"Рабочее программное обеспечение является основной мерой прогресса".
- Гибкий манифест

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

  • Флаги функций и прогрессивная доставка: используйте флаги компонентов для безопасного включения или отключения доступа к различным функциям. Поддержка включения функций для первых пользователей, чтобы получить отзывы о работе. Внедряйте эволюционные паттерны доставки, такие как канареечные релизы и сине-зеленое развертывание.
  • Релизные циклы и непрерывная доставка: обеспечивают другой ритм для развертывания одной или нескольких функций. Команды разрабатывающие функции, понимают предварительно запланированное расписание выпуска новых функций и планируют свои действия соответственно. Релизные поезда могут соответствовать тому же ритму спринтов, который установлен для организации, или происходить с другой частотой. Сведения о настройке спринтов и выпуске поездов см. в статье "Масштабируемая гибкая платформа ".
  • Непрерывная интеграция и непрерывное развертывание (CI/CD) — внедрение автоматизированных процессов, которые устраняют ручную работу и автоматизируют поток программного обеспечения с помощью тестов, сборки и развертывания циклов. Реализуйте комплексные стратегии тестирования, включая модульные тесты, тесты интеграции и автоматизированные тесты принятия.
  • Внутренний исходный код и открытая разработка: принести ценность и этоос, разработанные в сообществе Open Source Software, в ваши внутренние команды разработки. Поощряйте совместное использование кода, документацию и методики совместной разработки в командах.
  • Облачные методики. Использование архитектур контейнеров, архитектур микрослужб и шаблонов развертывания на основе облака для повышения масштабируемости и удобства обслуживания.

Современные методики и рекомендации

По мере развития гибких методик рассмотрите следующие современные подходы:

  • Интеграция DevSecOps: интегрируйте методики безопасности на протяжении всего жизненного цикла разработки, а не рассматривать безопасность как отдельную проблему.
  • Проектирование надежности сайта (SRE) — внедрение методик SRE для повышения надежности системы и снижения эксплуатационных затрат.
  • Сопоставление потока значений: сопоставление и оптимизация потока ценности от идеи к доставке клиентов.
  • OKRs (цели и ключевые результаты): используйте OKR для выравнивания команд вокруг измеримых результатов, а не только выходных данных.
  • Проектирование мышления: внедрение подходов к проектированию с учетом человеческого центра для лучшего понимания потребностей клиентов.

Связанный контент

Наряду с приведенными выше рекомендациями можно найти дополнительные рекомендации по масштабированию средств Agile в следующих статьях:

Отраслевые ресурсы

Практики, которые не масштабируются

  • Оценка крупных инициатив: часть методов каскадной модели проектов включала в себя оценку ресурсов и расписаний. Чем больше инициатив, тем меньше вероятность того, что эти оценки имеют какую-либо ценность. По мере роста проектов могут возникнуть риски и непредвиденные проблемы, которые могут поставить под сомнение многие оценки.
  • Скорость как межгруппная метрика: хотя скорость команды может предоставить полезную метрику для получения сведений о том, сколько работы каждая команда может завершить во время цикла спринта, вы не можете добавить скорости команды, чтобы получить значимые или полезные метрики. Кроме того, использование темпа работы, полученного от многих команд, для уверенного выполнения долгосрочных планов проблематично. Команды могут различаться в том, как они оценивают свою работу, и эти вариации увеличиваются с течением времени.
  • Предварительные решения верхнего уровня: один размер не соответствует всем, и одно решение обычно не соответствует всем командам. Поддержка автономности команд означает, что команды могут находить собственные решения, предоставляя необходимые платформы и поддержку.
  • Карго культ Agile: простое принятие церемоний Agile без понимания их цели или адаптации их к вашему контексту это часто приводит к неэффективной реализации.
  • Last updated on