Март 21

Фиксированный скоуп и сроки в эпоху Agile: как действовать PM’у

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

Эта статья содержит ряд практических советов о том, как подходить к планированию и выполнению проекта/релиза с фиксированным скоупом и сроками. Она написана на основании моего личного опыта, так как приходилось неоднократно иметь дело с подобными запросами.

Планирование

Для правильного планирования фиксированного релиза необходимо выполнить шаги, описанные ниже.

Зафиксировать скоуп на уровне, который позволит команде дать точную (в пределах допустимой погрешности) оценку. На практике это означает, что требования должны быть задокументированы на уровне детального описания user story (то есть заголовок + acceptance criteria), а пользовательский интерфейс должен быть согласован на уровне UX-прототипа и дизайн-гайдлайнов.

В случае если ваш код будет зависеть от API, выполняемых другими командами или подрядчиками, требования к этому API должны быть также задокументированы. Если хотя бы один из этих пунктов не выполнен, вам как проектному менеджеру не стоит брать на себя обязательство выполнить релиз. Вместо этого нужно очертить проблемы и предложить пути решения. В крайнем случае обозначить указанные проблемы в качестве рисков, которые могут повлиять на сроки.

Оценить скоуп вместе с командой. Сейчас достаточно самых разнообразных методов оценки; использовать можно любой, который зарекомендовал себя хорошо при работе с конкретной командой. Если вам удобны часы, используйте их (но учтите коэффициент между реальными и идеальными часами), если стори-поинты — пожалуйста, но при этом вы должны знать велосити команды на достаточно точном уровне.

Составить план релиза. На этом этапе у вас уже есть оценка скоупа, но самой по себе ее еще недостаточно, чтобы спланировать релиз. Теперь вам нужно составить план, который учтет зависимости между задачами, отразить время, необходимое на регрессионное тестирование и стабилизационную фазу, а также на UAT, подготовку продакшен-среды и собственно заливку вашего решения на продакшен. Даже если у вас идеальное покрытие автоматическими тестами и полностью автоматизированный деплоймент пайплайн, позволяющий выливаться в продакшен 20 раз в день, такой план вам необходим — иначе вы просто не учтете время, необходимое на выполнение всех шагов.

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

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

Создать деплоймент-план, то есть план развертывания вашего решения на продакшен-среде, а также на других средах, необходимых для выполнения проекта (UAT и т. д.). На этапе планирования проекта/релиза это может быть очень высокоуровневый документ, но он должен хотя бы примерно очертить, какие ресурсы (серверы, сетевой доступ и т. д) будут вам нужны, а также, кто будет принимать участие и отвечать за деплоймент. Это особенно актуально в случае, если сам деплоймент выполняете не вы, а специализированная команда (такое часто бывает, особенно с энтерпрайз-клиентами).

Согласовать алгоритм проведения UAT (user acceptance testing), а именно: сроки, порядок сбора пользовательского фидбэка, приоритеты дефектов, которые нужно будет устранять в ходе UAT, а также те, которые можно будет оставить на потом. Также нужно будет согласовать, что именно стоит за каждым из приоритетов, чтобы ваша команда и клиент понимали их одинаково. Иначе вам гарантированы постоянные споры о том, включать данный дефект в must-have-список или нет. Также важно будет договориться о том, с каким количеством (и приоритетами) дефектов фаза UAT в принципе может быть начата и какое их количество является критерием ее успешности.

Все указанные артефакты нужно оформить в виде документа, который затем согласовать с заказчиком (очень важный и обязательный пункт).

Без выполнения этих шагов брать на себя обязательства вписаться в конкретные сроки нельзя: таким образом вы сформируете у клиента ложные ожидания, подставите команду и себя, получите стресс и выгорание.

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

В общем виде план релиза выглядит так:

Выполнение и репортинг

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

Пока же поговорим о том, каковы основные задачи проектного менеджера на этом этапе. К ним прежде всего относятся:

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

О двух последних пунктах немного подробнее.

Мониторинг выполнения плана

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

На больших объемах такое предположение довольно близко к истине. В таком случае планируемый на конкретный день процент выполнения будет пропорционален времени, прошедшему после старта проекта, а фактический процент вы получите, поделив оценки выполненных задач на общую оценку скоупа. В результате вы имеете два числа: планируемый и фактический прогресс (в процентах). Сравнив их, можно точно определить, есть отставание от плана или нет.

Важно понимать, что такой подход к измерению возможен только на фазе разработки, когда команда разрабатывает и тестирует отдельные фичи. К этапам регрессии, стабилизации и UAT такой подход в чистом виде неприменим. Более того, если предположение о линейности процесса разработки неверно (например, у вас меняется размер команды), то нужно использовать более общий подход к измерению — метод освоенного объема (earned value method); он подробно описан в литературе, в том же PMBoK.

Здесь же вы выполняете корректировку плана; причинами могут быть изменения в скоупе, сработавшие риски и т. д. Здесь же прогнозируете дату завершения релиза с учетом откорректированного плана.

Отчетность и коммуникация со стейкхолдерами

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

Типичный отчет должен включать в себя:

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

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

Управление изменениями

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

Подход, проверенный на многих проектах, состоит в следующем. Любой запрос на изменения вносится в реестр и анализируется командой (прежде всего бизнес-аналитиком) на соответствие изначально согласованному скоупу. Если он ему соответствует, ваша задача — выполнить его, оставшись в рамках согласованных сроков, если это возможно. Если не соответствует — оценить эффект этого изменения на дату релиза, внести в реестр и сообщить клиенту. Он решит, двигать дату или отказаться от изменения. Или удалит из скоупа какой-то другой равноценный по времени элемент.

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

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

Организация UAT

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

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

Таким образом, UAT проводится для:

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

То есть в первую очередь клиент тестирует не систему (тестирование — ваша работа), а требования, которые он к ней предъявлял, ведь теперь они превратились в готовый продукт и их можно «пощупать».

На практике хорошо зарекомендовал себя следующий способ.

Команда совместно с клиентом готовит сценарий приемки, то есть последовательность шагов, которые клиент проходит при проверке системы. Здесь учитываются как самые типичные кейсы, так и те, которые встречаются редко. Часть кейсов может быть обозначена как «обязательные к приемке», то есть без них система приемку не пройдет, а часть — как опциональные.
Клиент проходит по сценариям в тестовом экземпляре системы и отмечает каждый как «принятый» или «непринятый». В последнем случае пишет свои замечания либо сразу заводит дефекты в системы учета дефектов (Jira, Redmine и т. д.) — как договоритесь.
Команда анализирует дефекты, чтобы определить, являются ли они запросами на изменение и входят ли по своему приоритету в список обязательных к устранению (в соответствии с правилами, которые вы согласовали с клиентом в начале проекта). Далее идет обсуждение с клиентом, на котором принимается решение, устранять дефекты сейчас или отложить на пострелизный период.

Для анализа фидбэка, пришедшего на фазе UAT, подходят такие же регулярные митинги, которые применялись для управления изменениями на этапе разработки.

Ваша совместная с клиентом цель — успешно завершить процесс UAT, выйдя из него с решением «релизить». В качестве альтернативы клиент может решить, что систему нужно отправить на доработку и отложить релиз. Такой вариант тоже имеет право на существование, ничего страшного в нем нет.

Решение «релизить» принимается в ситуации, когда:

все обязательные кейсы проверены и приняты клиентом;
все обязательные дефекты устранены либо признаны клиентом необязательными и отложены на пострелизный этап.

Релиз и пострелизная поддержка

Деплоймент-план (план развертывания системы), согласованный в общих чертах в начале проекта, должен быть детализирован и пересогласован вновь. В него обычно включают:

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

Деплоймент-план согласовывается с клиентом (как с представителями бизнеса, так и с техническим персоналом). Для того чтобы учесть все детали, проводится тестовая прогонка плана (dry run) — со всеми теми же участниками и шагами, как и в реальном прогоне, только на тестовом окружении.

После релиза вам важно не расслабляться и быть готовыми к тому, что в системе обязательно обнаружатся проблемы — те, которые не были видны при тестировании и UAT, те, которые даже клиент не смог учесть. Как бы близко ни было тестовое окружение к продакшену, надеяться на то, что проблем вообще не будет, нельзя.

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

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

Заключение

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