Будучи в конце концов разработчиками программного обеспечения, команды, естественно, захотят лучше организовать свои артефакты и автоматизировать те аспекты Scrum-процесса, которые поддаются программной поддержке. В частности, они выразят желание добавить инфраструктурную поддержку для ряда видов деятельности и типов артефактов в жизненном цикле программного обеспечения.
Управление бэклогом. Так как сложность системы растет, команда захочет больше поддержки по фиксации и техническому обслуживанию списка признаков, функциональных и нефункциональных требований, сценариев использования, пользовательских историй, а также их приоритетов, стоимости и владельцев этих пунктов. Когда Scrum применяется для более крупных проектов, эти артефакты могут вырасти до многих тысяч позиций, и методы по их организации, поддержке и просмотру с помощью системы или подсистемы станут критическими.
Проектная отчетность. Scrum сторонится традиционного, каскадного планирования проектов, но тактическая ежедневная природа Scrum-системы управления проектом интенсивна и неослабна. Команда нуждается в простом методе, при котором каждый член команды может вводить свои оценки выполнения задач, статус и оставшиеся усилия таким образом, чтобы диаграммы выгорания задач были автоматизированы и постоянно доступны. В дополнение инфраструктура должна поддерживать естественную передачу сигналов, которую команды используют по мере движения пунктов бэклога продукта в течение их жизненного цикла. Старший персонал должен иметь инструменты наблюдения за командами и понимать их индивидуальные итерации и планы выпуска для оценки состояния программы в целом.
Разработка требований по принципу PRN. Многие небольшие Scrum-проекты добились успеха с помощью неформальных механизмов формирования требований, таких как прямое обсуждение между владельцем продукта и командой разработки. Но, по мере того как сложность и критичность проекта растут, требуется более глубокое и полное описание требований и их версий. К примеру, становится важной документация интерфейсов, которая влияет на несколько команд. Изменения в интерфейсах или новые функции, которые выходят за пределы одной команды, могут иметь значительное влияние на весь проект.
Эти требования должны быть разработаны на основе принципа PRN, то есть непосредственно перед спринтом, который реализует новые функциональные возможности. Для решения этой проблемы командам может понадобиться централизованная поддержка по созданию более полных форм выражения требований и их обобщения, для их оценки и автоматическом уведомлении об изменениях.
Раннее тестирование. Каждый спринт предоставляет потенциально готовые к выпуску элементы базового продукта. Проведение раннего тестирования и автоматизация тестирования позволяют командам поддерживать требования Scrum к частым итерациям. Инструменты, которые генерируют тестовые случаи непосредственно из требований или карты историй, ускоряют процесс разработки и предоставляют постоянное отслеживание, необходимое для удостоверения пригодности этой функции. Знайте, что текущее управление сотнями и тысячами регрессионных тестов, которые накапливаются, вероятно, станет решающим фактором в определении скорости и успешности ваших спринтов.
Планирование релиза. Философия Scrum фокусируется на «магии воспользоваться возможностями в ближайшей перспективе», в отличие от «черной магии по точному предсказанию именно того, что будет доставлено через 612 спринтов». Эта философия прорыв в мышлении на уровне команды, потому что это позволяет Scrum-командам фокусироваться на текущей работе в ближайшие 30 дней и таким образом производить работающее программное обеспечение более надежно. Но, по мере того как количество команд растет, применение дополнительного анализа и точности к спринтам за пределами непосредственного горизонта помогает избежать архитектур, которые требуют в дельнейшем существенного рефакторинга, который хотя и весьма поощряется в гибком методе разработки, но становится менее практичным по мере увеличения масштаба приложений и количества существующих внедрений. Дополнительное планирование релиза, который предоставляет нам архитектурный путь, часто бывает оправданным. Таким образом, искусство планирования спринта может включать функции планирования «что будет через несколько спринтов» и «что если планирование», которые помогают командам идти на компромиссы в бэклогах и обсуждать разумное видение и дорожную карту продукта со спонсорами.
Планирование релиза. Философия Scrum фокусируется на «магии воспользоваться возможностями в ближайшей перспективе», в отличие от «черной магии по точному предсказанию именно того, что будет доставлено через 612 спринтов». Эта философия прорыв в мышлении на уровне команды, потому что это позволяет Scrum-командам фокусироваться на текущей работе в ближайшие 30 дней и таким образом производить работающее программное обеспечение более надежно. Но, по мере того как количество команд растет, применение дополнительного анализа и точности к спринтам за пределами непосредственного горизонта помогает избежать архитектур, которые требуют в дельнейшем существенного рефакторинга, который хотя и весьма поощряется в гибком методе разработки, но становится менее практичным по мере увеличения масштаба приложений и количества существующих внедрений. Дополнительное планирование релиза, который предоставляет нам архитектурный путь, часто бывает оправданным. Таким образом, искусство планирования спринта может включать функции планирования «что будет через несколько спринтов» и «что если планирование», которые помогают командам идти на компромиссы в бэклогах и обсуждать разумное видение и дорожную карту продукта со спонсорами.
Кроме того, эти команды обычно хотят организовать все эти инструменты в центральном хранилище, где они доступны каждому участнику 24 часа в сутки семь дней в неделю из любой точки мира, и должны предоставлять мгновенный просмотр проектного и программного статуса, с автоматическим уведомлением об изменениях для критических изменений в проекте.
Развитие инфраструктуры в спринтах. В Scrum внедрение этого уровня инфраструктуры не разовое событие, подготовленное «заранее» командой внедрения.
Сами Scrum-команды берут на себя задачу определять, что они будут приобретать и строить для решения своих проблем, основываясь на уроках, полученных в предыдущих спринтах. Кроме того, эти инвестиции делаются в контексте текущих спринтов, поэтому команда принимает решение о построении инфраструктуры путем добавления элементов к бэклогу продукта, в том числе и архитектурных элементов, как показано на рис. А3.4.
Рис. А3.4. Добавление инфраструктурных элементов в спринт
Конечно, функциональность, ориентированная на клиентов, по-прежнему занимает более приоритетное положение, но опытная команда придет к осознанию, что необходимо постоянно планировать инфраструктурную работу, чтобы сохранить скорость и производительность по мере того, как будет расти сфера применения и количество команд.
1.7. Выводы
Scrum проверенный и эффективный способ разработки программного обеспечения, который может быстро повысить производительность, скорость работы и качество команд разработки программного обеспечения.
Обычно организации, специализирующиеся на разработке программного обеспечения, после внедрения Scrum получают следующие преимущества:
уменьшение времени цикла разработки;
больше ценности для конечных пользователей;
более высокое качество;
меньше производственных рисков;
большая удовлетворенность пользователей;
улучшение морального духа компании.
Внедрение Scrum, хотя и кажется простым на первый взгляд, часто требует существенных организационных изменений, чтобы устранить препятствия на пути эффективной разработки и поставки. Как ведущий агент изменений высший руководитель несет главную ответственность за устранение этих препятствий.
Постоянная заинтересованность руководителя может быть решающим фактором успешной реализацией и провалом. Хотя путь реализации Scrum непростой, руководитель, который решил улучшить разработку программного обеспечения с помощью Scrum, делает первый шаг для того, чтобы предприятие встало на путь достижения коммерческих преимуществ от быстрой поставки более качественного программного обеспечения.
Кроме того, Scrum весьма эффективен при разработке крупномасштабных проектов и может поддерживать потребности многих сотен сотрудников, участвующих в совместном создании приложений. Масштабирование Scrum представляет собой дополнительный набор вызовов к архитектуре и инструментам, которые команды должны решать, но преодоление этих вызовов с большой вероятностью предоставит этим крупным компаниям существенное преимущество в конкурентной борьбе.
Благодарности
Эта книга не стала бы такой, какая она есть, без превосходного редактирования Арлетт Бэлью, общих указаний Ричарда Наррамора и лазерного фокуса Кэри Армстронг.
Об авторах
Джефф Сазерленд и Кен Швабер создатели Scrum, метода разработки программного обеспечения, который обеспечивает приращение функционала разрабатываемого программного обеспечения каждые 30 дней. Scrum появился на свет, когда в августе 1995 года Джефф и Кен представили доклад на конференции OOPSLA в Остине. Этот документ, Scrum Development Process, был результатом их совместной деятельности. Работы Х. Такеучи и И. Нонаки по созданию бережливых знаний, интеллектуальному развитию и работе в команде оказали сильное влияние на Джеффа.
На Кена столь же глубокое влияние оказал Бабатунде Огунайке своей работой о промышленном управлении технологическими процессами и применимости теории сложности и эмпиризма к разработке программного обеспечения.
Джефф и Кен не только создали Scrum, но и стали его попечителями и обеспечили его развитие.
Позднее они разработали способы ускорения систематической эволюции Scrum, основываясь на опыте Scrum-сообщества и входных данных. В «Исчерпывающем руководстве по Scrum» (Приложение 2 «Scrum-гайд») Джефф и Кен предлагают полное определение Scrum.
Доктор Джефф Сазерленд CEO компании Scrum в Кембридже, предлагающей обучение, руководство и инструктаж для компаний по всему миру. Джефф выдающийся выпускник Военной академии США и лучший стрелок в своем RF-4C командном классе Военно-воздушных сил США. Он также имеет ученую степень Стэнфордского университета и доктора философии медицинской школы Университета Колорадо.
В качестве старшего советника OpenView Venture Partners он помогает внедрять Scrum и гибкие методы разработки для всех портфельных компаний. Джефф расширял и улучшал Scrum во многих компаниях по разработке программного обеспечения и информационных технологий на протяжении многих лет.
Кен Швабер профессионал в области разработки программного обеспечения, имеющий 40-летний опыт работы программистом, аналитиком, продукт-менеджером и владельцем бизнеса. В начале своей карьеры он безрезультатно пытался сделать успешным каскадный процесс разработки программного обеспечения, а позже создал ему альтернативу. Кен провел последние 20 лет, развивая Scrum и взаимодействуя с организациями по всему миру, чтобы помочь им воспользоваться этим методом. Кен один из тех, кто участвовал в написании Agile Manifesto («Манифест гибкой разработки программного обеспечения»). Кроме того, он основатель Agile Alliance и Scrum Alliance. В настоящее время Кен работает над улучшением профессионализма людей, связанных с созданием программного обеспечения, через сайт Scrum.org. Кен и его жена Кристина живут в районе Бостона. Кен окончил Морскую торговую академию Соединенных Штатов Америки, а также курс дополнительного обучения в области компьютерных наук в Чикагском университете, прошел бизнес-обучение в Школе управления имени Джона Андерсона при Калифорнийском университете в Лос-Анджелесе.