Возможно, вы подумали, что идея приветствовать изменения требований интересна и может помочь проектам или, наоборот, что она ужасна. Это довольно распространенная реакция. Многие из тех, кто работает в команде разработчиков программного обеспечения (особенно традиционные руководители проектов), чувствуют себя неуютно, впервые узнав об этом.
Эти менеджеры ежедневно сталкиваются с изменениями, но гибкие методологии предполагают совершенно иное решение. В agile-практиках традиционное отношение к изменениям проекта считается командно-административным подходом.
Термин «командно-административный» заимствован из военной терминологии. В уже упоминавшейся книге «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга», выпущенной в 2010 году, есть интервью Нила Сигела, главного инженера компании Northrop Grumman, который дал определение этому термину:
Эндрю. Я не знаком с военными системами – что такое командно-административная система?
Нил. Это информационная система военных командиров. Она позволяет им общаться друг с другом и поддерживать ситуационную осведомленность: знать расположение войск и их статус. Благодаря этому командир понимает, что происходит. Раньше сражения проходили на небольших площадях и командир мог стоять на холме с биноклем и наблюдать за происходящим. Но примерно к 1900 году поля сражений стали настолько большими, что вы уже не можете стоять на холме, как это делал Наполеон. Вы должны начать использовать технологию, чтобы «видеть» все поле боя. И системы, которые делают это, называются командно-административными.
Командно-административное управление проектом похоже на военную систему.
• Слово «командное» имеет отношение к тому, как руководитель проекта распределяет работу в команде. Команда может не отчитываться перед руководителем, но он контролирует выполнение всех своих распоряжений. Он делит работу на части, создает график выполнения задач, распределяет их и ресурсы внутри команды.
• Слово «административное» описывает способ, при помощи которого руководитель управляет изменениями. Каждый проект сталкивается с изменениями: работа занимает больше времени, чем ожидалось, люди болеют или покидают проект, оборудование выходит из строя и т. д. Руководители проектов постоянно следят за этими изменениями и управляют проектом, оценивая каждое изменение, обновляя планы, включая изменения в графики работ, производя назначения в команде, а также управляя ожиданиями всех заинтересованных сторон, чтобы исключить неожиданности.
Причина, по которой традиционный менеджер проекта испытывает неудобства, впервые столкнувшись с изменениями, в том, что те же самые проблемы будут происходить и в agile-проектах, и команда должна быть в состоянии отвечать на них. Простое принятие изменений выглядит как гарантированный способ хаотизировать проект. Если agile-команды не используют командно-административный подход, то как они умудряются справляться со всеми этими изменениями, одновременно решая и все те проблемы, с которыми проектные команды сталкиваются ежедневно?
Рис. 3.1. Команда использует итерации для частой доставки работающего программного обеспечения, добавления новых функций с каждым релизом
Ключ к одобрению изменений без внесения хаоса заключается в частой поставке рабочей программы. Команда использует итерации, чтобы разбить проект на части с регулярными сроками сдачи. Во время итераций команда поставляет рабочее ПО. По окончании каждой итерации команда проводит демонстрацию, показывая клиенту созданный продукт, а также предыдущие варианты, чтобы посмотреть, какие уроки можно извлечь из данной ситуации. Затем начинают сеанс планирования, чтобы выяснить, что они будут создавать в следующей итерации. Предсказуемый график и постоянные точки контроля помогают команде отследить эти изменения на ранних стадиях и создают атмосферу, в которой не принято искать виноватого, когда каждый может обсудить изменения и придумать стратегию, чтобы включить ее в проект.
В этот момент Agile становится привлекательной для традиционного командно-административного менеджера проекта. Такой менеджер хочет контролировать срок. Установка ограничений на продолжительность итераций дает ему эту возможность. Кроме того, решается также одна из главных задач менеджера – работа с изменениями, которые возникают в самом конце проекта. Один из наиболее сложных моментов в работе традиционного менеджера – мониторинг изменений. Ежедневные отчеты и ретроспективы итераций позволяют руководителю проекта заручиться поддержкой всех членов команды, ведь они теперь глаза и уши руководителя, помогающие обнаружить необходимость изменений, прежде чем они станут причиной более серьезных проблем в проекте.