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

Планирование релиза на уровне системы и отслеживание. Рисунок А3.2ошибочно дает понять, что вопрос по разделению организации на команды по работе над отдельными функциями продукта, сервисами и подсистемами довольно простой: команды сделают свою работу, и интегрированная система получится естественным образом. Опыт показывает, что это крайне маловероятно. Даже когда индивидуальным командам ставится задача достичь целей спринта и скоординировать интеграцию между командами и подсистемами, присутствует целый ряд больших трудностей. Это необходимость в создании целостной системы, когда мы встраиваем и тестируем наши интеграции со всеми подсистемами и где подсистемы работают вместе для обеспечения более широких требований пользователей, а вся система должна соответствовать требуемому уровню качества, производительности и надежности. Теперь нам требуется, чтобы любая работа отдельной команды считалась законченной и интегрированной и работа всех команд по интеграции тестированию должна быть закончена. Это показано на рис. А3.3.

Рис. А3.3. Система из трех подсистем

Для решения этих проблем многие команды добавили роль технического лидера, выполняемую на уровне системы. Архитекторы, лидеры команд, менеджеры продуктов и персонал контроля качества часто объединяются в дополнительную Scrum-команду, думающую и действующую на системном уровне. Кроме того, члены этой команды могут также применять Scrum-метод на уровне системы, устанавливать набор целей спринта и создавать пункты бэклога, включающие системные интеграции, демонстрации на системном уровне, контрольные точки проверки качества, создание пробных выпусков и других мероприятий, гарантирующих, что разработка системы идет по выбранному пути. Из всей этой работы возникает общая картина, показанная на рис. А3.3.

Даже при таком уровне структуры и координации в больших проектах и при распределенных командах могут ощущаться недостаток координации между командами и недостаточная проектная прозрачность, необходимые для надежного выпуска программного обеспечения с помощью быстрых, полностью протестированных итераций. Хотя Scrum предоставляет проверенную основу для управления проектами, касающимися разработки программного обеспечения, он не предписывает специфические методы разработки и не рекомендует конкретный набор инструментов для поддержки Scrum-процесса. Философия Scrum в этом отношении состоит в том, чтобы «сохранить его простым и позволить команде решать». Поскольку организации испытывали трудности с применением современных инженерных практик, Scrum.org представил курсы и программы для Scrum-разработчиков, ориентированных на современные инструменты управления жизненным циклом приложений.

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

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

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