Артефакты выпуска и источники артефактов
Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | Team Foundation Server 2018 — Team Foundation Server 2015
В Microsoft Team Foundation Server (TFS) 2018 и предыдущих версий конвейеры сборки и выпуска называются определениями, выполнения называются сборками, подключения к службам называются конечными точками служб, этапы называются средами, а задания называются этапами.
В этом разделе рассматриваются классические конвейеры выпуска. Сведения о артефактах в конвейерах YAML см. в разделе артефакты.
выпуск — это коллекция артефактов в процессах DevOps CI/CD. Артефакт — это развертываемый компонент приложения. Azure Pipelines может развертывать артефакты, созданные с помощью широкого спектра источников артефактов, и хранить их в разных типах репозиториев артефактов.
При создании конвейера выпуска вы связываете соответствующие источники артефактов с конвейером выпуска. например, вы можете связать конвейер сборки Azure Pipelines или проект Jenkins с конвейером выпуска.
При создании выпуска указывается точная версия этих источников артефактов. например, номер сборки, поступающий из Azure Pipelines, или версия сборки, поступающей из проекта Jenkins.
После создания выпуска изменить эти версии нельзя. Выпуск в основном определяется артефактами с версиями, которые составляют выпуск. При развертывании выпуска на различных стадиях вы будете развертывать и проверять одни и те же артефакты на всех этапах.
Один конвейер выпуска можно связать с несколькими источниками артефактов, один из которых является основным источником. В этом случае при создании выпуска необходимо указать отдельные версии для каждого из этих источников.
Artifacts являются центральными для ряда функций Azure Pipelines. Ниже перечислены некоторые функции, зависящие от связывания артефактов с конвейером выпуска.
Автоматические выпуски. Можно настроить автоматическое создание новых выпусков всякий раз, когда создается новая версия артефакта. Дополнительные сведения см. в разделе триггеры непрерывного развертывания. Обратите внимание, что возможность автоматического создания выпусков доступна только для некоторых источников артефактов.
Условия триггера. Можно настроить автоматическое создание выпуска или Развертывание выпуска на стадии, чтобы активировать его автоматически, когда выполняются только определенные условия для артефактов. Например, можно настроить автоматическое создание выпусков только в том случае, если новая сборка создается из определенной ветви.
Версии артефактов. Можно настроить выпуск для автоматического использования определенной версии артефактов сборки, чтобы всегда использовать последнюю версию или разрешить указание версии при создании выпуска.
Переменные артефактов. С каждым артефактом, который является частью выпуска, связаны метаданные, доступные для задач с помощью переменных. Эти метаданные включают номер версии артефакта, ветвь кода, из которой был создан артефакт (в случае артефактов построения или исходного кода), конвейер, который создал артефакт (в случае артефактов сборки) и многое другое. Эти сведения доступны в задачах развертывания. Дополнительные сведения см. в разделе переменные артефактов.
Рабочие элементы и фиксации. Рабочие элементы или фиксации, которые являются частью выпуска, вычисляются на основе версий артефактов. например, каждая сборка в Azure Pipelines связана с набором рабочих элементов и фиксациями. Рабочие элементы или фиксации в выпуске вычисляются как объединение всех рабочих элементов и фиксации всех сборок между текущим выпуском и предыдущим выпуском. обратите внимание, что в настоящее время Azure Pipelines может вычислять рабочие элементы и фиксировать фиксации только для определенных источников артефактов.
Источники артефактов
Существует несколько типов средств, которые можно использовать в процессе жизненного цикла приложения для создания или хранения артефактов. например, вы можете использовать системы непрерывной интеграции, такие как Azure Pipelines, Jenkins или TeamCity, для создания артефактов. Вы также можете использовать системы управления версиями, такие как Git или TFVC, для хранения артефактов. также можно использовать репозитории, например Azure Artifacts или репозиторий NuGet для хранения артефактов. Azure Pipelines можно настроить для развертывания артефактов из всех этих источников.
По умолчанию выпуск, созданный из конвейера выпуска, будет использовать последнюю версию артефактов. Во время связывания источника артефакта с конвейером выпуска можно изменить это поведение, выбрав один из параметров для использования последней сборки из конкретной ветви, указав теги, конкретную версию или разрешите пользователю указать версию при создании выпуска из конвейера.
При связывании нескольких наборов артефактов можно указать, какой из них является основным (по умолчанию).
Default version элементы раскрывающихся списков Artifacts зависят от repository type связанного определения сборки.
Latest from the build pipeline default branch with tags не поддерживается XAML определениями сборки.
В следующих разделах описывается работа с различными типами источников артефактов.
Источники артефактов — Azure Pipelines
конвейер выпуска можно связать с любыми конвейерами сборки в Azure Pipelines или коллекции проектов TFS.
Ниже приведены некоторые различия в возможностях разных версий TFS и Azure Pipelines.
TFS 2015. Вы можете связать конвейеры сборки только из того же проекта коллекции. Можно связать несколько определений, но нельзя указать версии по умолчанию. Вы можете настроить триггер непрерывного развертывания только для одного из определений. Если несколько конвейеров сборки связаны, используются последние сборки всех других определений, а также сборка, вызвавшая создание выпуска.
TFS 2017 и более поздние версии и Azure Pipelines. конвейеры сборки можно связать из любого проекта в Azure Pipelines или TFS. Можно связать несколько конвейеров сборки и указать значения по умолчанию для каждого из них. Триггеры непрерывного развертывания можно настроить в нескольких источниках сборки. После завершения любой из сборок вызывает создание выпуска.
при использовании Azure Pipelines источников доступны следующие функции:
По умолчанию выпуски выполняются в с областью авторизации задания уровня коллекции. Это означает, что выпуски могут обращаться к ресурсам во всех проектах Организации (или коллекции для Azure DevOps Server). Это полезно при связывании артефактов сборки из других проектов. Можно включить ограничение области авторизации заданий в текущий проект для конвейеров выпуска в параметрах проекта, чтобы ограничить доступ к артефактам для выпусков в проекте.
Чтобы задать область авторизации задания для Организации, выполните следующие действия.
Чтобы задать область авторизации задания для конкретного проекта, выполните следующие действия.
Если для области задано значение Project на уровне Организации, изменить область в каждом проекте нельзя.
Все задания в выпусках выполняются с областью авторизации задания, для которой задано значение коллекция. Иными словами, эти задания имеют доступ к ресурсам во всех проектах в коллекции проектов.
Источники артефактов — TFVC, Git и GitHub
Существуют сценарии, в которых может потребоваться использовать артефакты, хранящиеся в системе управления версиями напрямую, без передачи их через конвейер сборки. Пример:
Вы разрабатываете приложение PHP или JavaScript, не требующее явного конвейера сборки.
Вы управляете конфигурациями для различных стадий в разных репозиториях управления версиями и хотите использовать эти файлы конфигурации непосредственно из системы управления версиями в рамках конвейера развертывания.
Вы управляете инфраструктурой и конфигурацией в виде кода (например, шаблонов Azure Resource Manager) и хотите управлять этими файлами в репозитории системы управления версиями.
Так как в одном конвейере выпуска можно настроить несколько источников артефактов, можно связать конвейер сборки, создающий двоичные файлы приложения, а также репозиторий системы управления версиями, в котором файлы конфигурации хранятся в одном конвейере, и использовать два набора артефактов вместе при развертывании.
Azure Pipelines интегрируется с репозиториями система управления версиями Team Foundation (TFVC), репозиториями Git и GitHub репозиториями.
Конвейер выпуска можно связать с любыми репозиториями Git или TFVC в любом из проектов в коллекции (вам потребуется доступ для чтения к этим репозиториям). При развертывании артефактов системы управления версиями в одной коллекции дополнительные настройки не требуются.
при связывании репозитория Git или GitHub и выбора ветви можно изменить свойства по умолчанию для типов артефактов после сохранения артефакта. Это особенно полезно в сценариях, где изменяется ветвь для стабильной версии артефакта, и выпуски непрерывной поставки должны использовать эту ветвь для получения более новых версий артефакта. Можно также указать сведения о извлечении, например, будь то подмодули извлечения и файлы с отслеживанием LFS, а также неполная глубина выборки.
При связывании ветви TFVC можно указать набор изменений, который будет развернут при создании выпуска.
при использовании источников TFVC, Git и GitHub доступны следующие функции:
По умолчанию выпуски выполняются в с областью авторизации задания уровня коллекции. Это означает, что выпуски могут обращаться ко всем репозиториям в Организации (или коллекции для Azure DevOps Server). Можно включить ограничение области авторизации заданий в текущий проект для конвейеров выпуска в параметрах проекта, чтобы ограничить доступ к артефактам для выпусков в проекте.
Источники артефактов — Jenkins
Чтобы использовать артефакты Jenkins, необходимо создать подключение службы с учетными данными для подключения к серверу Jenkins. Дополнительные сведения см. в статье подключения к службам и Подключение службы Jenkins. Затем можно связать проект Jenkins с конвейером выпуска. Для публикации артефактов в проекте Jenkins необходимо настроить действие после сборки.
При использовании источников Jenkins доступны следующие функции.
Artifacts, созданные сборками Jenkins, обычно распространяются в репозитории хранилища для архивации и совместного использования. Хранилище BLOB-объектов Azure — это один из поддерживаемых репозиториев, позволяющий использовать проекты Jenkins, которые публикуют в службе хранилища Azure в качестве источников артефактов в конвейере выпуска. Развертывания автоматически загружают артефакты из Azure в агенты. В этой конфигурации подключение между агентом и сервером Jenkins не требуется. Агенты, размещенные в Майкрософт, можно использовать без предоставления доступа к серверу через Интернет.
возможно, Azure Pipelines не сможет связаться с сервером Jenkins, если, например, он находится в корпоративной сети. в этом случае можно интегрировать Azure Pipelines с Jenkins, настроив локальный агент, который может получить доступ к серверу Jenkins. Вы не сможете увидеть имя проектов Jenkins при связывании с построением, но можете ввести его в диалоговое окно ссылки.
Источники артефактов: реестр контейнеров Azure, Docker, Kubernetes
При развертывании контейнерных приложений образ контейнера сначала помещается в реестр контейнеров. После завершения отправки образ контейнера можно развернуть в службе Веб-приложение для контейнеров или в кластере DOCKER/Kubernetes. Необходимо создать подключение к службе с учетными данными для подключения к службе для развертывания образов, расположенных там или в Azure. Дополнительные сведения см. в статье подключения служб.
При использовании реестра контейнеров Azure, Docker, Kubernetes Sources доступны следующие функции:
В случае непрерывного развертывания из нескольких источников артефактов (несколько реестров или репозиториев) невозможно сопоставлять источники артефактов для активации определенных этапов. Выпуск будет создан всякий раз, когда в любой из источников артефактов отправляется отправка. Если вы хотите назначить источник артефакта для активации определенного этапа, рекомендуется разбить конвейер выпуска на несколько конвейеров выпуска.
Источники артефактов — Azure Artifacts
Ниже перечислены сценарии, в которых может потребоваться использовать следующие артефакты.
При связывании такого артефакта с конвейером выпуска необходимо выбрать веб-канал, пакет и версию по умолчанию для пакета. Вы можете выбрать последнюю версию пакета, использовать определенную версию или выбрать версию во время создания выпуска. Во время развертывания пакет загружается в папку агента, а содержимое извлекается в ходе выполнения задания.
при использовании Azure Artifacts источников доступны следующие функции:
Обработка моментальных снимков Maven
Для моментальных снимков Maven несколько версий можно загрузить одновременно (например, myApplication-2.1.0.BUILD-20190920.220048-3.jar myApplication-2.1.0.BUILD-20190820.221046-2.jar myApplication-2.1.0.BUILD-20190820.220331-1.jar ). Возможно, потребуется удалить старые копии и удерживать только последний артефакт перед развертыванием. Выполните следующую команду PowerShell в командной строке с повышенными привилегиями, чтобы удалить все копии, кроме одного с наибольшим значением лексикографическом:
В веб-канале можно хранить до 30 моментальных снимков Maven. после достижения максимального предела Azure Artifacts будет автоматически удалять моментальные снимки до 25. Этот процесс активируется автоматически при каждом публикации моментальных снимков в веб-канале в течение 30 лет.
Источники артефактов — внешний или локальный сервер TFS
Azure Pipelines можно использовать для развертывания артефактов, опубликованных локальным сервером TFS. Сервер TFS не должен быть виден в Интернете. Вы просто настроили локальный агент автоматизации. Сборки с локального сервера TFS загружаются непосредственно в локальный агент, а затем развертываются на указанных целевых серверах. Они не будут выходить за пределы корпоративной сети. Это позволяет использовать все инвестиции на локальный сервер TFS и использовать возможности выпуска в Azure Pipelines.
используя этот механизм, можно также развертывать артефакты, опубликованные в одной Azure Pipelines подписке, в другой Azure Pipelines или развертывать артефакты, опубликованные в одном Team Foundation Server из другого Team Foundation Server.
чтобы включить эти сценарии, необходимо установить артефакты TFS для расширения Azure Pipelines из Visual Studio Marketplace. Затем создайте подключение службы с учетными данными для подключения к серверу TFS (Дополнительные сведения см. в разделе подключения службы ).
При использовании внешних источников TFS доступны следующие функции.
возможно, Azure Pipelines не сможет связаться с локальным сервером TFS, если он находится в корпоративной сети. в этом случае можно интегрировать Azure Pipelines с TFS, настроив локальный агент, который может получить доступ к серверу TFS. Вы не сможете видеть имена проектов TFS или создавать конвейеры при связывании с построением, но эти переменные можно включить в диалоговые окна ссылки. кроме того, при создании выпуска Azure Pipelines может не иметь возможности запрашивать у сервера TFS номера сборок. Вместо этого введите идентификатор сборки (а не номер сборки) требуемой сборки в соответствующее поле или выберите последнюю сборку.
Источники артефактов — TeamCity
для интеграции с TeamCity необходимо сначала установить артефакты TeamCity для расширения Azure Pipelines из Marketplace.
Чтобы использовать артефакты TeamCity, начните с создания подключения службы с учетными данными для подключения к серверу TeamCity (Дополнительные сведения см. в разделе подключения к службам ).
Затем можно связать конфигурацию сборки TeamCity с конвейером выпуска. Конфигурация сборки TeamCity должна быть настроена с действием для публикации артефактов.
При использовании источников TeamCity доступны следующие функции.
возможно, Azure Pipelines не сможет связаться с сервером TeamCity, если, например, он находится в корпоративной сети. в этом случае можно интегрировать Azure Pipelines с TeamCity, настроив локальный агент, который может получить доступ к серверу TeamCity. Вы не сможете увидеть имя проектов TeamCity при связывании с построением, но можете ввести его в диалоговое окно ссылки.
Источники артефактов — пользовательские артефакты
помимо встроенных источников артефактов, Azure Artifacts поддерживает интеграцию любого источника настраиваемого артефакта с моделью расширяемости артефактов. вы можете подключить любой источник настраиваемого артефакта, и Azure DevOps предоставит интерфейс пользователя первого класса и простую интеграцию.
Источники артефактов — другие источники
артефакты могут создаваться и предоставляться другими типами источников, например репозиторием NuGet. хотя мы продолжаем расширять типы источников артефактов, поддерживаемых в Azure Pipelines, вы можете начать использовать их без ожидания поддержки определенного типа источника. Просто пропустите Связывание источников артефактов в конвейере выпуска и добавьте в этапы пользовательские задачи, которые загружают артефакты непосредственно из источника.
Псевдоним источника артефакта
такая уникальность также гарантирует, что при последующем переименовании связанного источника артефакта в его исходном расположении (например, при переименовании конвейера сборки в Azure Pipelines или в проекте в Jenkins) не нужно изменять свойства задачи, так как место загрузки, определенное в агенте, не меняется.
Исходный псевдоним — это, по умолчанию, имя источника, выбранного при связывании с источником артефакта, с префиксом подчеркивания. в зависимости от типа источника артефакта это будет имя конвейера сборки, задания, проекта или репозитория. Псевдоним источника можно изменить на вкладке артефакты конвейера выпуска. Например, при изменении имени конвейера сборки и необходимости использовать псевдоним источника, который отражает имя конвейера сборки.
Основной источник
При связывании нескольких источников артефактов с конвейером выпуска один из них назначается основным источником артефактов. Первичный источник артефактов используется для задания ряда предварительно определенных переменных. Его также можно использовать в выпусках именования.
Скачивание артефакта
При развертывании выпуска на этапе версии артефактов из каждого источника по умолчанию загружаются в агент автоматизации, чтобы задачи, выполняемые на этом этапе, могли развернуть эти артефакты. Артефакты, скачанные в агент, не удаляются после завершения выпуска. Однако при инициации следующего выпуска Скачанные артефакты удаляются и заменяются новым набором артефактов.
в настоящее время Azure Pipelines не выполняет оптимизацию, чтобы избежать загрузки неизмененных артефактов, если один и тот же выпуск развертывается снова. кроме того, поскольку ранее скачанное содержимое всегда удаляется при инициации нового выпуска, Azure Pipelines не может выполнять добавочные загрузки для агента.
однако можно указать Azure Pipelines пропустить автоматическую загрузку артефактов в агент для определенного задания и этапа развертывания при необходимости. Как правило, это делается, когда задачи в этом задании не нуждаются в каких-либо артефактах или если вы реализуете пользовательский код в задаче для загрузки требуемых артефактов.
Переменные артефактов
Azure Pipelines предоставляет набор предопределенных переменных, доступ к которым можно получить и использовать в задачах и скриптах. Например, при выполнении скриптов PowerShell в заданиях развертывания. При наличии нескольких источников артефактов, связанных с конвейером выпуска, можно получить доступ к сведениям о каждом из них. Список всех предварительно определенных переменных артефактов см. в разделе переменные.
Круговорот артефактов в Agile
Доброго времени суток.
В этой статье я хочу продолжить рассказ о «прагматическом» Agile процессе разработки ПО. На суд Читателя предлагается иная перспектива обзора этого процесса — с точки зрения создания и эволюции артефактов (Artifact Flow) в ходе развития проекта. А также мы рассмотрим практический подход для работы с артефактом «Коллекция Требований» с использованием Google Wave и Google Docs.
Артефакт — это рукотворный объект. В первом приближении артефактами можно назвать и код программы, и документы написанные программистами. При более тщательном подходе мы можем значительно расширить круг примеров и отнести к артефактам электронные письма, фрагменты чатов и даже наброски фламастером на доске.
На самом деле последовательность создания/модификации артефактов и их содержание имеет критическое значение для здоровья проекта. Особое значение, с моей точки зрения, имеют коллективно созданные артефакты.
Диаграммы потоков артефактов.
Дальше я предлагаю взглянуть на зарисовки жизненного цикла артефактов на трех разных этапах развития Agile проекта. При этом мы будем использовать такие обозначения:
Где Person и Group — создатели артефактов, Communication и Development — процессы, в которых рождаются артефакты, и, собственно сами артефакты. Обратите внимание, что в Communication процессах рождаются коллективные артефакты, а при Development — персональные.
Почему я акцентирую на важности коллективных артефактов? Потому что они являются каналами связи и синхронизаторами информации между заказчик(ом)(ами) и исполнител(ем)(ями) проекта. При отсутствии таких каналов связи проект будет протекать по «законам здравого смысла», которые весьма субъективны, и в результате заказчик «не узнает» в готовой системе ту «картинку» которая у него в голове. В итоге неизбежен конфликт.
Итак, посмотрим «слайды»…
Этап начала проекта (Project Initiation Artifact Flow).
Сценарий здесь такой: Sales сделали свою часть работы и у нас появился потенциальный клиент. На этом этапе в компании выделяется человек, который будет начинать общение с клиентом на технические темы. Роль этого человека можно назвать по-разному — аналитик, консультант, владелец проекта (Product Owner). Мы будем использовать последнее название.
Во время первой (реальной или виртуальной) беседы владельца проекта с заказчиком формируется самый первый из коллективных артефактов — Vision & User Story titles. Это текстовый документ где описывается основная идея проекта и его функциональность в виде коротких Историй Пользователя.
Затем следует внутренний митинг где встречаются владелец проекта и менеджер проекта. Задача этой встречи — принять решение о составе команды разработчиков и исходя из ее возможностей построить оценочный или предварительный план (Preliminary Plan). К примеру, в нашей команде мы «моделируем» выполнение Историй Пользователя с помощью Гантта с ресурсами.
Этап заканчивается согласованием оценочного плана с заказчиком на уровне Sales-, финансового- менеджера и прочего начальства (это и есть момент покупки сервиса) и официальным стартом разработки.
Architectural Iteration Artifact Flow
Первая итерация — архитектурная, во время которой строятся слои будущей системы, пишутся прототипы темных мест. Давайте посмотрим что творится с артефактами.
На входе у нас Vision & User Storiy titles. Этот артефакт выносится на первый большой митинг с командой. Задача митинга — выработать архитектуру ПО и план на архитектурную итерацию. Идет обсуждение, доска загромождается рисунками… Первый артефакт который рождается в споре — это драфт архитетктуры. Дальше оцениваются и распределяются задачи — инфраструктурные (что-то сконфигурировать и настроить), прототипы (проверить что архитектурная идея работает), архитектурные (подключить компонент архитектуры — например Веб-Сервисы). Оценки по времени поступают от самой команды. В результате появляется второй артефакт — план итерации.
План итерации и архитектурный драфт поступает в самый большой узел на нашей диаграмме — в разработку. Результатами разработки являются код, список багов и иженерные артефакты, такие как инструкции по инсталляции.
Интересно что на фоне артефакт-оборота разработки выполняется второй, не менее важный: сбор Требований. Это постоянный процесс в результате которого общий взгляд на систему скоординировано детализируется. Иногда в результате детализации меняется и сам изначальный общий взгляд. Сам процесс сбора требований может протекать по-разному, но его участниками всегда являются владелец проекта (наш аналитик) и заказчик (либо его технический консультант). Результатом этого процесса является постоянно развивающийся драфт Требований. Во второй части статьи я покажу как можно использовать сервисы Google Wave и Google Docs для работы над этим артефактом.
Также здесь важно отметить что у Владельца Проекта уже на этом этапе должен быть создан неформальный бэклог для накопления и приоритезации Историй Пользователя, которые попадают на следующую итерацию. Именно на них он должен сконцентрировать работу по сбору требований. Эта практика — сбор «наперед» — переходит от одной итерации к другой.
Functional Iteration Artifact Flow
Это самая важная составляющая проекта. Во время функциональных итераций продукт «растет». Как правило (у нас) разработка начинается с архитектурной итерации, а затем идут несколько функциональных итераций вплоть до релиза проекта.
Если в общих словах описывать потоки артефактов такой итерации, то кроме потока разработки и сбора требований добавляется поток спецификации: команда QA на основе коллекции Требований и списка наименований Историй Пользователя пишет короткие, но исчерпывающие Test Cases. Эти Test Cases вместе с итерационным планом являются главными движущими артефактами во время разработки.
Сбор сведений при помощи Google Wave и Google Docs
На артефакте коллекции требований хочу остановиться отдельно. Этот артефакт отвечает за синхронизацию картинки функционала системы между всеми участниками проекта. Наша группа набила тут много шишек и, если мне удастся убрать пару-тройку граблей с Вашей дороги, я буду счастлив).
Первый вопрос в Agile проекте возникает всегда: зачем писать Требования если можно просто поговорить по телефону или скайпу? Такой сценарий не исключается, но он ограничен случаем, когда домен хорошо понятен и программисту и заказчику, они говорят на одном языке примерно на одном уровне, они обладают одинаковым менталитетом (используют одинаковые принципы Здравого Смысла), части системы, которые обсуждаются легко укладываются в памяти (они компактны, а система как правило небольшая). На самом деле такой случай относится больше к исключениям, чем к правилам. Системы строятся большие и разветвленные, команды у нас сейчас распределенные, с разным менталитетом, с разной специализацией, мир многополярен, ИМХО, это хорошо.
На мой взгляд коллекцию требований нужно рассматривать как проект закона, а тест кейсы (в качестве спецификации) — как закон для данного проекта и его участников.
В данном подходе Google Волна используется для построения синхронного дерева обсуждений. Под синхронностью я понимаю то, что нету времени ожидания между отправкой данных и получения их Вашим собеседником. Вы можете видеть то, что он пишет и наоборот. Это свойство существенно активизирует скорость самого процесса накопления требований.
Волна состоит из текста и рисунков. Рисунки представляют макеты страниц пользовательского интерфейса системы. Текст — это описания к макетам и логическим потокам вокруг них. На первый взгляд все просто. Однако у Волны есть свои недостатки. Как ни странно самой серьезной проблемой является то, что волна имеет слишком много свободы для организации ветвления. Если начинать использовать Волну без продуманного набора правил она быстро превратится в бестолковое захламленное пространство. Эти правила мы обсудим через пару секунд.
Теперь о макетах. На данный момент наилучшим средством для их создания я считаю Google Document и его компонент Drawing. Он прост и надежен. В волну документ вставляется при помощи iFrame гаджета.
Теперь о правилах построения волн для сбора Требований:
1. Отдельные Истории пользователя являются отдельными волнами, собранными в «волновую» папку с названием проекта.
2. Макеты, относящиеся к определенной странице и ее состояниям собираются вместе в отдельной папке Google Docs с названием проекта. В названиях этих макетов присуствует название действия или эффекта, который они демонстрируют. Также следует отметить, что каждый Google документ имеет свою собственную систему версий — поэтому не следует дублировать версии макетов отдельными документами — это существенно упрощает всю схему.
3. Используйте один экземпляр точного макета на один шаг Истории Пользователя. Под точным макетом я подразумеваю Google документ. При этом набросков может быть много. Для набросков удобно использовать этот гаджет.
3. Внутри Волна имеет четкую структуру: в отдельных сообщениях находятся заголовок Волны, который описывает общий смысл данной Истории Пользователя, и далее в отдельных сообщениях следуют шаги этой истории.
Внутри шага истории идут в виде Replies три секции — макет (Google документ в iFrame), текст комментариев к макету и текст логических потоков на этом шаге истории. Эти части шага реализованы как Replies для того, чтобы их можно было быстро закрыть — это удобно для длинных и закрученных Волн.
Преимущества такого подхода к организации Волны следующие:
1. Сбор требований легко распараллеливается. Если проект объемный, в сбор требований легко включаются разработчики. Владелец проекта просто создает Волны с первым заголовочным сообщением и расшаривает их на разработчиков. Затем разработчики рисуют макеты и обсуждают их с заказчиком напрямую.
2. Упрощается и ускоряется общение по бизнес домену во время спринта. Если у программиста или QA-щика возникают вопросы — он их тут-же задает в Волну.
3. Заказчик может быстро инициировать разговор по любой точке Требований.
Пример сбора требований для простой Истории Пользователя
Рассмотри некий пример обсуждения и накопления требований по такой истории: посетитель веб-сайта знакомится с текстом домашней страницы и новостями.
Просмотрите экранный снимок волны, а дальше я добавлю пару комментариев.
Развитие этой волны происходило таким образом: владелец проекта создал волну под названием соответствующей истории пользователя. Затем он добавил сообщение — заголовок с общими словами по этой истории и адресами двух гаджетов (для удобства, чтобы они были всегда под рукой). Далее он пригласил в Волну заказчика. Создал сообщение для первого шага истории пользователя, создал Google документ с первым макетом страницы. Добавил несколько слов для описания макета и логического потока.
На этом этапе в работу включился заказчик и написал. что показ только трех последних новостей на домашней странице — плохая идея, нужен компонент для листания страниц (Pagination). Для наглядности заказчик вставил в реплику гаджет для рисования набросков и быстро изобразил вид такого компонента.
Владелец продукта согласился с предложением и дорисовал (не выходя из волны) нужный компонент на точном макете и обновил текстовку.