Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

Однако масштабирование практик Scrum на распределенные команды и Scrum-команды, состоящие из отдельных команд, представляет собой специфические коммуникационные проблемы. Координация между командами действий по внедрению общих требований, отслеживанию статуса определенного признака и выявлению проблемных вопросов становится первоочередной задачей. В таких случаях механизм для частой синхронизации их работы должен быть изобретен и внедрен. Также должна быть создана более детализированная техническая архитектура продукта, чтобы работа могла быть поделена между командами (Швабер, 2004).

Традиционные инструменты управления проектами могут показать идеализированные задачи с четкими датами начала и окончания, а также временем выполнения, возможно, безрезультатного. Это очень важный путь анализа для долгих каскадных проектов. При этом основанная на планировании деятельность теряет важность для коротких итераций, когда вся команда фокусируется на получении нескольких функциональных признаков с самым высоким приоритетом. Вместо одного человека, ведущего базу отдельных задач, которые команда планирует и выполняет день за днем (например, пользовательские истории и тесты), более крупные программы нуждаются в окружающей среде, поддерживающей взаимодействие в режиме реального времени и обеспечивающей естественную передачу сигналов среди членов команды, когда они берут функциональный признак из бэклога продукта для разработки, тестирования и интеграции. Для эмуляции, расположенной в одном рабочем пространстве команды, эта окружающая среда управления гибкой разработкой проектов должна позволять всем быстро увидеть и обновить информацию, где функциональный признак находится в жизненном цикле в пределах спринта, а также определить, сколько усилий требуется для его завершения и какие конкретные вопросы блокируют его прогресс.

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

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

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

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

Разработка требований по принципу PRN.Многие небольшие Scrum-проекты добились успеха с помощью неформальных механизмов формирования требований, таких как прямое обсуждение между владельцем продукта и командой разработки. Но, по мере того как сложность и критичность проекта растут, требуется более глубокое и полное описание требований и их версий. К примеру, становится важной документация интерфейсов, которая влияет на несколько команд. Изменения в интерфейсах или новые функции, которые выходят за пределы одной команды, могут иметь значительное влияние на весь проект.

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

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