Мы продолжаем делиться переводами полезных статей. На очереди материал про agile-методологию — устойчивый тренд в разработке программного обеспечения.
В это сложно поверить, но agile-методологии официально исполнилось уже 20 лет в прошлом году. То, что
Все больше компаний выбирают такие agile-методологии как scrum и kanban, для модернизации приложений, улучшения клиентского опыта и проведения цифровых изменений.
Эта статья представляет собой гайд по методологии agile и лучшим практикам, которые помогают организациям культивировать agile-культуру и создавать качественное программное обеспечение.
Процесс agile-разработки программного обеспечения всегда начинается с выявления пользователей конкретного продукта и документирования всех проблем, возможностей и ценностей, которые необходимо решить. Product owner (владелец продукта) фиксирует это видение и работает с многопрофильной командой (или командами) над его реализацией. Процесс разработки включает следующие роли:
Пользователи. Agile-процесс всегда начинается с пользователя или клиента. Специалисты часто определяют портрет пользователей, чтобы проиллюстрировать различные роли рабочего процесса, потребности клиентов и модели их поведения.
Владельцы продукта. Задача владельца продукта — быть голосом клиента. Этот специалист собирает мнения, идеи и отзывы для формирования видения продукта. Видение продукта — это короткое и простое описание портрета клиента или пользователя. Оно включает базовые ценности продукта и стратегию их реализации. Например, можно представить, что первоначальное видение Google выглядело следующим образом: «Давайте сделаем так, чтобы любой человек, имеющий доступ в интернет, мог легко находить нужные сайты и веб-страницы с помощью простого, управляемого ключевыми словами интерфейса и алгоритма, который ставит авторитетные источники выше в результатах поиска».
Каким бы ни было видение, product owner отвечает за его определение, а затем работает с командой разработчиков, чтобы воплотить его в жизнь.
Для работы с командой разработчиков владелец продукта разбивает видение продукта на серию пользовательских историй. Каждая пользовательская история выявляет целевых пользователей, их проблемы и решения. Product owner определяет приоритеты этих пользовательских историй и обсуждает их с командой, чтобы убедиться, что все члены команды имеют общее понимание своих функций.
Команды должны быть многопрофильными и включать разнообразные группы, обладающие навыками и опытом, необходимыми для выполнения работы. В дополнение к разработчикам, agile-команды должны включать QA-инженеров, Data-инженеров, UX-дизайнеров и других специалистов в зависимости от типа проекта.
Agile нацеливает команды на запуск работающего программного обеспечения, а не только на создание технических компонентов. Члены команды должны согласовать, что они создают, кто что делает и как будет разрабатываться программное обеспечение.
В agile-командах часто присутствуют другие роли:
Решение о том, как укомплектовать agile-команды и насколько масштабными их сделать, принимают руководители организаций. Многие следуют передовой практике Джеффа Безоса, который создал две agile-команды размером с пиццу, чтобы максимизировать сотрудничество между членами команды.
Как только команда принимает принципы agile, начиная с тех, которые определены в манифесте agile, она должна выбрать методологию.
Некоторые организации начинают с kanban, потому что его относительно легко объяснить и внедрить. Команда берет истории пользователей с kanban-доски и работает над ними, пока они не будут отмечены как выполненные.
Другие компании внедряют scrum, который организует работу через спринты, обычно продолжительностью в одну или две недели. Владелец продукта записывает требования в виде пользовательских историй, затем расставляет приоритеты в бэклоге на основе их бизнес-ценности. Команда анализирует бэклог и принимает решение о том, какие из историй пользователей нужно завершить.
Scrum включает несколько стандартных встреч (иногда называемых scrum-церемониями или scrum-ритуалами), которые помогают командам определить приоритеты спринта и успешно завершить каждый спринт. Эти встречи обычно включают несколько общих элементов:
Сегодня многие лучшие технические практики включают определение жизненного цикла разработки программного обеспечения (SDLC) и внедрение devops-процессов. SDLC обеспечивает руководство по написанию кода, управлению программными активами и разработке технических стандартов. Devops-автоматизация, такая как CI/CD, инфраструктура как код (IaC) и непрерывное тестирование, обеспечивает более надежный путь к созданию качественного продукта.
Расширение возможностей самоорганизующихся команд, agile-методологии, devops-автоматизация и модернизация до облачных архитектур — все эти компоненты помогают технологическим организациям развивать свою культуру. Длительные циклы разработки заменяются моделями непрерывной доставки, которые позволяют быстрее выпускать функции и улучшения. Сочетание этих практик помогает agile-командам принимать более разумные архитектурные решения, стимулировать эксперименты, больше ориентироваться на данные и быстро исправлять ошибки.
Другие практики, такие как интеграция дизайн-мышления в scrum, управление продуктом и внедрение непрерывного планирования, помогают agile-командам сотрудничать с клиентами, конечными пользователями и заинтересованными сторонами бизнеса.
Agile-команды обычно используют такие инструменты, как Jira, Azure DevOps и Digital.ai для совместной работы над agile-бэклогами и канбан-досками. Эти инструменты помогают agile-командам определять приоритеты работы, фиксировать требования, дополнять пользовательские истории, просматривать отчеты и автоматизировать рабочие процессы с помощью контроля версий, CI/CD и других инструментов.
Большинство специалистов рекомендуют начинать agile-практику с четко определенных бизнес-целей, нескольких команд и ограниченного, оптимально подобранного инструментария. Задача руководителей организаций состоит в том, чтобы найти правильный баланс разнообразных команд, принципов самоорганизации, стандартов, инструментов и интеграций, которые позволят их организациям создавать, расширять, масштабировать и поддерживать технологические возможности.
