Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Артефакты — это инструменты схватки, которые позволяют командам управлять процессом схватки. Они помогают членам команды общаться о работе, которую они делают, и предоставляют отчет о том, что команда согласилась сделать и что они достигли. Любой может указать на артефакты команды разработчиков, чтобы показать людям, над чем они работают, чего они достигли и чего они ожидают достичь.
Существует ряд артефактов, которые помогают командам подготовиться и управлять в рамках процесса работы в Scrum. Знакомство с языком Scrum означает понимание того, для чего предназначен каждый из артефактов и как он используется. В этой главе мы рассмотрим несколько наиболее распространенных артефактов схватки, таких как:
-
история
-
резерв продукта
-
отставание в спринте
-
доска
-
определение «сделано»
-
графики скорости
-
график выгрузки
-
приращение продукта
У разных команд разные подходы к созданию и поддержке артефактов, которые они используют, но для веб-разработки и разработки мобильных приложений стоит помнить о некоторых.
Обзор артефактов
Хотя формальная схватка не зависит от того, как именно используются артефакты процесса, мы рассмотрим несколько способов создания и поддержки артефактов, которые окажутся полезными для работы, в которую обычно попадают веб-и мобильные команды.
Одним из основных артефактов схватки для веб-сайтов и мобильных устройств является история, описывающая функцию, над которой нужно работать. Истории разрабатываются и управляются в заделах. Отдельные резервные копии сохраняются для владельца продукта, чтобы отслеживать общее видение продукта, и для команды, чтобы участвовать в спринте, который в настоящее время выполняется. Оба журнала содержат описания того, что должно произойти, чтобы продвинуть продукт вперед, но элементы в списке продуктов не будут выглядеть как истории в списке задач спринта. Скрам-команды используют скрам-доску для отслеживания хода историй в спринте, и мы обсудим, как они работают вместе.
Scum также предлагает ряд инструментов для сбора статистики, которые полезны для отслеживания эффективности работы команды и информирования о том, как разработка продукта идет людям как внутри, так и вне группы разработчиков. Среди них мы собираемся охватить диаграмму скорости, которая охватывает несколько спринтов, и диаграмму выкатов, которая отслеживает прогресс в пределах одного спринта.
Другие артефакты, которые команда подонков найдет полезными, включают в себя определение выполненного, которое согласовывается владельцем продукта и командой под руководством мастера, а также фактический прирост продукта или текущее состояние продукта. как это существует в конце спринта.
Истории
Истории — это то, как владелец продукта сообщает команде разработчиков, что нужно разрабатывать. Истории инкубируются в журнале ожидания продукта, а затем выражаются в стандартном формате, чтобы их можно было представить команде в рамках совещания по планированию спринта для оценки, оценки, а затем включить в журнал ожидания спринта.
Примечание: происхождение использования историй
Концепция использования истории для инкапсуляции отдельных частей работы взята из Extreme Programming (XP) , которая представляет собой специализированную вариацию гибкой разработки, которая поддерживает целый ряд отличных практик разработки, таких как парное программирование и написание тематических историй. Истории очень полезны при разработке веб-приложений и мобильных приложений с использованием Scrum, когда работа над полным набором функций обычно включает в себя множество одинаковых компонентов от внутреннего до внешнего интерфейса. Команда часто будет видеть истории, которые имеют одни и те же компоненты, и сравнение одной истории с другими, над которыми она работала прежде, облегчает разбивку и оценку новых историй. По этой причине мы будем считать истории основным артефактом схватки для той работы, о которой мы говорим.
История должна охватить полный кусок функциональности. Каждая история должна быть независимой, чтобы разработчикам не приходилось завершать одну историю перед работой над другой. История должна быть небольшой частью функциональности, над которой можно работать и завершать в течение одного спринта.
Истории помогают уловить суть функции и дают команде возможность обсудить параметры и критерии приемлемости значимым и относительным образом. Оценка работы путем подбора тематических рассказов о том, чего команда может достичь в спринте, является полезным упражнением.
Каждая история должна повысить ценность продукта и приблизить его к видению владельца продукта. Каждая история должна прояснить, как владелец продукта будет тестировать конечный продукт, чтобы убедиться, что история была завершена.
Примечание: истории не являются техническими характеристиками
Хотя владельцы новых продуктов с опытом работы в области проектирования или управления продуктами иногда чувствуют склонность решать все технические проблемы и предлагать статические решения с полностью проработанными спецификациями для каждой функции, важно помнить, что разборки не являются техническими характеристиками. Это возможность открыть дискуссию между владельцами продукта и инженерами о том, как реализовать функцию и сколько усилий потребуется. Это одна из причин, почему истории следуют короткому и последовательному формату. Это подрывает искушение включить более подробные спецификации.
Ответственность за написание историй лежит на владельце продукта. Написание историй, отражающих полное намерение и ожидания клиента, — это навык, развитие которого может занять некоторое время, но оно крайне важно для эффективного процесса схватки. Хороший мастер схватки должен уметь помогать владельцу продукта в том, как писать истории нужного размера, выражать соответствующие критерии приемлемости и открывать диалог, а не закрывать его.
Есть простая формула, которая хорошо подходит для написания историй. Люди перепробовали много вариантов за эти годы. Посредством итераций и размышлений разные команды могут в конечном итоге разработать разные подходы, которые работают для них, но это хорошее место для начала:
Название: краткое понятное название функции
-
Как тип пользователя
-
Я хочу к поведению
-
так что оправдание за поведение
Критерии приемки:
-
Учитывая определенное состояние
-
когда набор условий или событий
-
тогда последовательный и проверяемый результат
Примечание: что делает для хорошей истории?
Хорошая история коротка и прямолинейна. Многие команды разработчиков придерживаются соглашения, согласно которому история должна быть написана на одной стороне карточки-указателя, три дюйма на пять дюймов, с критериями приемлемости, написанными на обратной стороне той же карты. Если для записи истории требуется больше, чем столько информации, спецификации могут быть слишком подробными или история может быть слишком сложной, и может потребоваться разбить ее на несколько историй.
Например, рассмотрим команду, которая разрабатывает приложение галереи. Посетители галереи, возможно, захотят оценить отображаемые изображения, чтобы они могли отслеживать свои избранные. Галерея может функционировать как с функцией оценки, так и без нее, поэтому работа может быть выделена как полный набор функций. И, по словам инженеров, работа по добавлению виджета рейтинга может быть выполнена за один спринт.
Вот как можно написать историю, чтобы команда могла оценить ее, оценить и зафиксировать в спринте:
Название: Рейтинг Галерея изображений
-
Как зритель галереи
-
Я хочу оценить изображения
-
чтобы я мог отслеживать и оценивать изображения, которые я оценил
Критерии приемки:
-
Пользователь вошел в систему, просматривая галерею.
-
когда пользователь нажимает на звездочку в виджете рейтинга для изображения
-
тогда значение этой звезды должно быть записано как рейтинг этого пользователя для этого изображения
и
-
Пользователь вошел в систему, просматривая галерею.
-
когда отображается изображение, которое оценил пользователь
-
тогда виджет рейтинга должен отражать ранее введенный пользователем рейтинг
и
-
Пользователь вошел в систему, просматривая галерею.
-
когда переключатель «Избранное» включен
-
тогда должны отображаться только изображения, оцененные пользователем, в порядке убывания рейтинга
Для истории, подобной этой, у команды может быть стандарт для того, как каркасы или проекты прикрепляются к историям и сообщаются. Например, если это новый виджет, дизайнер может подготовить макет и набор ресурсов, которые понадобятся инженерам для реализации этой функции. Также может быть руководство по стилю или другая документация для продукта, которую необходимо обновить соответствующей информацией.
Эта история не связана с инженерными решениями, такими как дизайн API или соглашения об именах, которые используются в коде. Хотя определение «сделано для группы» может включать необходимость создания документации о таких технических аспектах, как эта, история, которую представляет владелец продукта, обычно не должна иметь мнения по этим вопросам.
Когда история представляется при планировании спринта, инженеры должны проверить, что все необходимые ресурсы и информация, в которой они нуждаются, были собраны и доступны. Фактическая работа, которую предстоит выполнить в предстоящем спринте, определяется описанием в карточке истории и диалогом, который она вдохновляет между владельцем продукта и командой.