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

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Улучшение языка и региональных параметров организации

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

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

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

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

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

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

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

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

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

    • Встроенные вики-сайты

    • Внутренние списки рассылки

    • Хакатон недели или 10% время взлома

    • Внутренняя группа поддержки Agile для поддержки команд, которые принимают гибкие методики

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

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

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

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

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

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

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

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

Практики, которые не масштабировать

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