Реализация гибких методик, масштабируемых
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Корпоративные организации принимают гибкие методики по многим причинам. Основными из этих причин являются следующие:
- Сокращение времени выхода на рынок, ускорение выпуска продукции
- Повышение эффективности организации для управления изменяющимися приоритетами
- Повышение качества программного обеспечения и прогнозируемости доставки
- Улучшение видимости проекта и уменьшение риска проекта
По мере роста организации вы хотите масштабировать свои методики, чтобы оставаться гибкими и соответствовать изменяющимся целям. Для этого рассмотрим следующие два руководящих принципа:
- Что такое успех для вас, ваших команд и вашей организации? Что вызывает наибольший интерес: своевременная доставка? Качество продукта? Предсказуемость? Удовлетворенность клиентов?
-
Вернитесь к первым принципам, вернитесь к принципам и общим значениям, перечисленным в манифестеAgile, как отмечает Кен Швабер, один из основателей Scrum:
- "Ценности и принципы масштабируются, а практики чувствительны к контексту."
- "Держите ценности, держите принципы, думайте для себя. Основная предпосылка Agile заключается в том, что люди, выполняющие работу, являются людьми, которые могут лучше всего выяснить, как это сделать".
Создание ритма и потока
Принимая общий курс и набор периодических коммуникаций, вы создаете постоянный поток действий по всей организации. Ниже приведены методики, помогающие создавать ритм и поток в крупных организациях:
- Общий ритм:Регулярные спринты и релизы устанавливают ритм бизнеса. Работа всех команд в едином ритме помогает координации и сотрудничеству.
- Письма спринта: Чтобы держать организацию и все команды в курсе хода выполнения и планов команд по разработке функций, каждая команда может отправить сводку предыдущих результатов спринта и текущих планов спринта.
- Демонстрации спринта: быстрое, 2-3 минутное видео, демонстрирующее новую функцию, подготовленную командой. Ссылки на такие видео можно включить в письма спринта.
- Демонстрационные встречи: чтобы информировать другие команды и просить обратную связь о программном обеспечении в процессе разработки, команды демонстрируют выполненную работу. Проводите эти собрания через регулярные интервалы в течение жизненного цикла проекта и откройте их всем заинтересованным сторонам.
- Сводки об ошибках по электронной почте: чтобы поддерживать анализ качества продукта и поощрять сохранение дисциплины в работе с ошибками, периодически делитесь с организацией показателями качества. Эти метрики могут включать активные ошибки по каждой команде, тенденции ошибок и ошибки по каждому инженеру.
- Собрания по координации: проводите собрания, которые координируют команды на регулярной основе или по мере необходимости для решения пересекающихся целей, зависимостей и рисков.
Взаимодействие с клиентами
Привлечение клиентов на протяжении всего жизненного цикла продукта является основным принципом гибкой работы. Предоставьте каждой команде возможность напрямую взаимодействовать с клиентами в наборах функций, которыми они владеет.
-
Непрерывная обратная связь: создание циклов отзывов клиентов. Эти циклы могут принимать множество форм:
- Голосовая связь клиента: облегчите клиентам предоставление отзывов, добавление идей и голосование по функциям следующего поколения. Предоставление отзывов часто выполняется через выделенный веб-сайт.
- Отзывы о продукте. Кнопки обратной связи в продукте являются еще одним способом для получения отзывов об опыте продукта или конкретных функциях.
- Демонстрации клиентов: регулярно запланированные демонстрации, которые запрашивают отзыв от клиентов, могут помочь сформировать продукты следующего поколения и следить за созданием приложений, которые клиенты хотят использовать.
- Ранние программы внедрения: такие программы должны быть разработаны с учетом того, что все команды могут захотеть принять участие в какой-то момент. Ранние пользователи получают доступ к ранним версиям рабочего программного обеспечения и затем могут предоставлять свои отзывы. Часто эти программы работают, включив флаги компонентов для списка ранних пользователей.
- Решения на основе данных: поиск способов инструментирования продукта для получения полезных данных и которые могут протестировать различные гипотезы. Помогите способствовать созданию культуры, благоприятной для экспериментов, которая празднует обучение.
Улучшение видимости проекта
Чем больше понимания у вас и ваших команд в цель, видение и прогресс выполнения работы, тем лучше вы сможете управлять зависимостями и снижать риски.
- Структура команды: Независимо от того, насколько велика ваша организация, структурируя вашу организацию вокруг небольших команд размером от 6 до 9 человек, вы обеспечиваете масштабируемость. Создайте вертикальные, автономные группы функций, сгруппированные в области управления портфелями.
- Структура разбивки рабочих работ: разбиение больших целей, функций или требований в небольшие остается стабильным для управления проектами. Разбивая работу на аналогичные задачи, команды могут повысить оценку и определить риски и зависимости.
- Объединенные представления: используйте инструменты отслеживания в Интернете для агрегирования данных о работе для получения информации о различных командах. Создание панелей мониторинга для отображения хода выполнения и тенденций.
- Обсуждение опыта: эти собрания, проводимые до начала разработки характеристики, используются для информирования руководства о сценариях и приоритетах, сбора отзывов, установки ожиданий и выявления любых межкомандных проблем, связанных с характеристикой.
Расширение возможностей продуктивной рабочей силы
Некоторые конкретные методики Гибкой работы, которые хорошо масштабируем и приводят к более счастливым, заинтересованным и продуктивным сотрудникам, включают:
- Внедренное руководство: расширение возможностей команд и лидеров в организации для самостоятельной организации и самостоятельного управления как можно больше. Автономия команды увеличивает эффективность команды и гибкость организации. Убедитесь, что рабочие группы имеют корпоративное спонсорство, необходимое для успеха.
- Ежедневные стендапы: Или Scrum собрания; помогают командам сосредоточиться на том, что им необходимо делать ежедневно, чтобы максимально увеличить их возможность соответствовать своим обязательствам по спринту. По мере роста организаций следует рассмотреть возможность чередования времени проведения этих собраний, чтобы обеспечить участие между командами по мере необходимости.
- Scrum of scrums: Ежедневные встречи членов из разных Agile команд ежедневно встречаются, чтобы отчитываться о выполненной работе, дальнейших шагах и проблемах или блоках, возникающих в представляемых командах.
- Обмен данными между группами. Предоставление и поощрение команд поделиться своими практиками и рекомендациями, к которым они и другие команды могут обращаться через корпоративную сеть. Общие средства, используемые для этой цели, включают вики-сайты группы, OneNotes или Markdown.
- Совместная работа: поощряйте неформальную связь между командами и совместную работу в команде. Институционализация таких методов, как обзоры кода, обзоры проектов, проверки спецификаций не только повышают совместную работу команды, но и помогают разрабатывать индивидуальную и общую корпоративную компетенцию.
Улучшение организационной культуры
Вы повышаете эффективность организации, уделяя внимание культуре, которую вы хотите создать. Изменения культуры происходят, когда отдельные лица, команды и организации принимают одну или несколько методик непрерывного улучшения. К некоторым масштабируемым методикам гибкой разработки относятся следующие:
Ретроспективы: Задавая такие вопросы, как "Что пошло хорошо?", "Что мы должны делать по-другому?", и "Что мы должны прекратить делать?", помочь командам отразиться на том, как они могут улучшить свои процессы и практики. Ретроспективы помогают командам выявлять, что работает хорошо и что требует улучшения. Ретроспективы можно проводить в любое время и в любом месте. Однако институционализация некоторых ретроспектив на регулярной основе помогает инициализировать непрерывное улучшение практики. Например:
Ретроспективы спринта могут помочь командам выявить области, требующие улучшения, с регулярной периодичностью.
Ретроспективы выпуска могут помочь организациям определить области для улучшения коммуникаций и внутренних процессов, стимулировать улучшения, направленные на следующий выпуск.
Операционные проверки: обычно проводятся ежемесячно и включают представителей из всего потока ценности. Охватывая портфель проектов и других инициатив и используя целевые, количественные данные, спроектируйте эти ретроспективы, чтобы спровоцировать обсуждение динамики, влияющей на производительность между командами.
См. вики-ресурс по гибким ретроспективам для идей, советов и инструментов по планированию и проведению ретроспектив. Смотрите также расширение Marketplace Retrospectives.
Доска отслеживания улучшений: хорошие идеи для улучшения процессов могут поступать от любого человека в любое время. Захват этих идей для обсуждения и принятия решения о том, как быстро действовать над ними, является ключом для поддержки усилий по улучшению процессов.
Белая доска предоставляет любые простые и визуальные средства, с помощью которых можно захватить идеи. Кроме того, вы можете создать команду отслеживания улучшений и записать идеи, которые вы отслеживаете на электронной доске.
Институционализировать совместное использование: Обмен лучшими практиками и передача идей помогает всем командам в организации расти и улучшаться. Разработка культуры обучения является ключом к поддержке этой и другой непрерывной деятельности по улучшению. Некоторые идеи для рассмотрения:
Встроенные вики-сайты
Внутренние списки рассылки
Недели хакатона или 10% времени на хакатон
Внутренняя группа поддержки Agile для поддержки команд, которые принимают гибкие методики
The Culture Game предоставляет хороший ресурс для менеджеров Agile, чтобы помочь командам внедрять Agile и делиться лучшими практиками.
Сообщества практики: поддержка внутренних общих дисциплин (например, СУБД, архитекторов SW, проектирования пользовательского интерфейса)
Работающее программное обеспечение
"Часто поставляйте рабочее программное обеспечение, от нескольких недель до нескольких месяцев, с предпочтением более короткого интервала времени."
"Рабочее программное обеспечение является основной мерой прогресса".
- Гибкий манифест
По мере увеличения объема программного обеспечения, функций и сложности вам потребуется применить методики, которые помогут вам создавать потребляемые решения.
- Флаги компонентов: используйте флаги компонентов для включения или отключения доступа к различным функциям. Предоставьте поддержку включения функций для ранних пользователей, чтобы получить рабочие отзывы.
- Релизные поезда: обеспечивают иной ритм для реализации одной или нескольких функций. Команды разработки понимают заранее запланированное расписание выпуска новых функций и корректно планируют свою работу. Поезда выпуска могут соответствовать одному и тому же спринту, устанавливаемому для организации, или выполняться с другой частотой. Сведения о настройке спринтов и выпуске поездов см. в статье "Масштабируемая гибкая платформа ".
- Непрерывная интеграция. Внедрение процессов, которые устраняют ручную работу и автоматизируют поток программного обеспечения с помощью тестов, сборки и развертывания циклов.
- Внутренний открытый исходный код: доведите значение и этиты, разработанные в сообществе Программного обеспечения с открытым исходным кодом, в ваши внутренние команды разработки.
Связанные статьи
Наряду с приведенными выше рекомендациями вы найдете дополнительные рекомендации по масштабированию средств Agile в следующих статьях:
- Культура Agile
- Добавление команд
- Управление портфелем
- Видимость между командами
- Масштабирование Agile для крупных команд
Отраслевые ресурсы
Практики, которые не масштабируются
- Оценка крупных инициатив: часть методов каскадной модели проектов включала в себя оценку ресурсов и расписаний. Чем больше инициатив, тем меньше вероятность того, что эти оценки имеют любое значение. По мере роста проектов могут возникнуть риски и непредвиденные проблемы, которые могут поставить под сомнение многие оценки.
- Скорость. Хотя скорость команды может предоставить полезную метрику для получения сведений о том, сколько работы каждая команда может завершить во время цикла спринта, вы не можете добавить скорости команды, чтобы получить значимые или полезные метрики. Кроме того, использование скорости выполнения работы многих команд, чтобы надёжно выполнять долгосрочные прогнозы, вызывает проблемы. Команды различаются способом оценки своей работы, и эти различия увеличиваются с течением времени.
- Предварительные решения верхнего уровня: один размер не соответствует всем, и одно решение обычно не соответствует всем командам. Поддержка автономности команд означает, что команды могут найти свои собственные решения.