Разобщенность, одна культура
Участники команды находятся в разных местах – возможно, даже разных странах. Но все говорят на одном языке и регулярно встречаются.
✓ Попробовать паттерны: лотки (6), работа (9).
✓ Избегать антипаттерны: смещенная стадия тестирования (2), цикл по V-модели (2), недоступный эксперт (3), Scrum-мастер – микро-шеф (5).
Разобщенность, разные культуры
Команда разделена, участники находятся в разных странах с разными культурами, между ними возможно недопонимание.
Лучше избегать таких случаев и объединять людей в Scrum-команды иначе.
Данные характеристики относятся к состоянию ПО, с которым работает команда.
• Архитектура
Команда должна понять, можно ли добавлять пользовательские истории в существующее программное обеспечение без пересмотра архитектуры.
Если архитектура программного обеспечения нестабильна, это означает, что присутствуют технические риски. Лучше уменьшить их как можно скорее. При этом довольно сложно определить, что именно нужно для этого сделать.
Нестабильная архитектура
✓ Следовать практике, несмотря на все трудности: обзор спринта с проведением демо.
✓ Попробовать паттерны: бесконечный спринт (2), сториотип (6) с целью определения технических работ, разделение (7) – с целью декомпозиции историй.
✓ Избегать антипаттерны: архитектор в башне из слоновой кости (19).
• Возраст системы
Возраст определяется размером и качеством уже существующего кода в разрабатываемом ПО.
Scrum проще внедрить на новом программном обеспечении. Если продукт включает части существующего (устаревшего) кода, команда будет вынуждена продолжать работу с этим кодом более или менее хорошего качества и, возможно, с техническим долгом.
Устаревший код
✓ Попробовать паттерн: бэклог тикетов (6), сториотип (6) – с целью определения работы, необходимой для погашения технического долга.
✓ Дополнительные практики: практики из Экстремального Программирования (глава 19).
Характеристики относятся к компании или компаниям, в которых работает Scrum-команда.
• Экономическая модель
Иными словами, способ получения бюджета для разработки. Возможны разные контексты.
✓ Контракт клиент-поставщик: разработка основана на контракте с фиксированной ценой между заказчиком и компанией-разработчиком. Это, скорее всего, усложняет реализацию ряда практик. В еще большей степени это касается согласования ценностей и принципов.
✓ Open Source: те, кто работает над проектами с открытым исходным кодом, часто находятся в разных странах и вовлечены в разработку на условиях частичной занятости.
✓ Разработка внутренней командой требует наименьших усилий по адаптации. Это вариант издательств.
Контракт клиент-поставщик
В данном случае обязательно проведение прелюдии, чтобы люди из разных организаций нашли общий язык и были на одной волне.
✓ Попробовать паттерны: бэклог поставки/рабочий бэклог (6), так как необходимо установить связь между функциональностями и спецификациями, относящимися к тендеру; сезонный ритм (2) – для уточнения начала и конца действия контракта.
✓ Избегать антипаттерны: proxy РО (4), так как роль Владельца продукта должна быть на стороне заказчика и включена в команду, что часто оказывается довольно сложно реализовать и увеличивает риски успешной адаптации; приверженность под давлением (9), спринт под управлением цифр (9), участники прелюдии не участвуют в спринте 1 (13), измерение потраченного времени (18).
Open source
Поскольку команда работает неполный рабочий день, следует уточнить концепцию спринта; см. как применить Kanban в Scrum (глава 20).
Инженерные практики (19) позволяют команде работать удаленно.
• Управление
Речь о важности ограничений, наложенных организацией на жизненный цикл и отчетность проектов.
Легкое управление не требует особой адаптации.
Сильное и иерархичное управление
Некоторые крупные французские компании отличаются способом управления проектами, который наследуется от методов, разработанных в 1980-х годах в промышленной среде. Конечно, каждая из них по-своему адаптировала эти методы, но результат, с точки зрения управления, как правило, не отличается легкостью.
✓ Попробовать паттерны: сезонный ритм (2) и все, что представлено в главах о бэклоге (7 и 8).
✓ Избегать антипаттерны: цикл по V-модели (2) для сосуществования Scrum со стадиями и контрольными точками организации, чрезмерная трата времени на оценку (16), газовый завод (17).
Прелюдия имеет важное значение для детального определения уровня участия заинтересованных сторон, которые должны быть информированы о Scrum и пройти необходимую подготовку. Их участие в обзоре необходимо для уравновешивания полномочий руководства.
Scrum-мастер вовлечен в обсуждение выбранных индикаторов.
14.4 Адаптация с учетом ситуации
Изучение характеристик проекта позволяет определить практики, которые нужно адаптировать.
Идеальный для перехода к Scrum проект должен обладать следующими характеристиками.
✓ Команда из семи человек, при этом все находятся в одном офисе.
✓ Новое ПО с известной архитектурой.
✓ Продукт с невысокой критичностью, который легко развертывается.
✓ Разработка происходит внутри команды, ее участники обладают необходимыми техническими компетенциями.
✓ Понимающее руководство.
Чем дальше характеристики проекта от вышеперечисленных, тем больше усилий необходимо приложить команде во время прелюдии.
Все относительно! Любые изменения культуры, в том числе переход к Scrum, всегда требуют усилий.
Изображение ниже дает наиболее общее представление об усилиях, необходимых для адаптации.
Рисунок 14.3 – Контекст проекта
Проект В (более удаленный от центра) требует больше усилий для перехода к Scrum, чем проект A (центральный). Но это не означает, что проект В вовсе не должен переходить к Scrum: преимущества от использования Scrum могут оказаться более значимыми, нежели цена этого перехода.
Подробный анализ контекста позволяет узнать ограничения, налагаемые на внедрение Scrum. Для каждой значимой характеристики необходимо определить, как адаптировать те или иные практики.
Scrum-мастер модерирует коллективную работу по контекстуализации и гарантирует применение и адаптацию Scrum.
Результаты контекстуализации не отражаются в документах. Обмен знаниями между участниками команды продолжается непрерывно – при помощи событий, перечисленных в предыдущих главах. Команда уже не нуждается в бесполезной документации.
В свою очередь, коммуникация с людьми вне команды, на уровне организации, включающей несколько команд, может потребовать больше формализма.
Большинство Agile-практик эффективны для большинства проектов, но применяются по-разному в зависимости от ситуации и времени.
Характеристики, определяющие контекст, меняются со временем. Некоторые (например, управление) могут за несколько месяцев приблизиться к центру графика, в то время как другие удаляются от него – как, например, размер команды (в том случае, если проект расширяется).
Вот почему необходимо регулярно проводить анализ контекста. Сравнение контекста двух последовательных сезонов позволяет понять, что за это время изменилось.
В этот момент можно определиться с новыми паттернами.
Результаты, полученные благодаря применению Scrum, зависят от усилий, предпринятых в ходе контекстуализации, и полученного опыта.
Это наглядно показывает модель Agile Fluency, которая использует бизнес-ценность (business value), производимую командой, чтобы определить, насколько она освоила Agility. На пути к Agile команда проходит через несколько зон.
Использование основных элементов Scrum соответствует первой зоне, практическое внедрение инжиниринга и критериев завершенности – второй зоне, практики по определению продукта вкупе с изменением культуры – третьей.
Мы вернемся к этому в главе 22.
14.5 Антипаттерны
Ситуация. Команда применяет Scrum, ограничиваясь только его фреймворком. Участники в конце спринта приходят к определенному результату и легко достигают критериев завершенности, поэтому не применяют инженерные практики.
Последствия. Команда быстро сталкивается с трудностями, связанными с накапливающимся техническим долгом.
Как сделать лучше? Scrum, и в частности, критерии завершенности, позволяют выявить проблемы – это одно из его главных преимуществ. Но усилия, необходимые для устранения технического долга, определяет сама команда.
Ситуация. Команда применяет практики в строгом соответствии с книжками и рассказами других.
Последствия. Участники рискуют быть отрезанными от реальности. То, что практика сработала для одного проекта, не значит, что она сработает в другом контексте.
Пример, рассказанный Хенриком Книбергом. В книге «Scrum и ХР: Заметки с передовой» он показал технику, которая называется фокус-фактор. Многие команды после прочтения книги решили применить эту технику, думая, что поступают правильно. Книберг был вынужден с сожалением отметить, что использование фокус-фактора подходит для определенного контекста, но совершенно неприменимо в других ситуациях.