Собираем базу компаний, которые сокращают штат или зарплаты из-за кризиса. Заполните анкету
×Закрыть

Фиксированный скоуп и сроки в эпоху 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 проводится для:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

LinkedIn

15 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Как я не люблю много букв. по-моему, все элементарно. Основа ПМ — трипл констрейнс. Если ты не можешь быть флексибл по скопу, остаётся играть ресурсами и временем. Чудес не бывает.

Если проект нужно делать «по эджайлу», но при этом он фиксед прайс, по факту, это означает, что он не будет по эджайлу. Переговоры провалены на этапе заключения сделки, ПМ может сказать горячее «спасибо» сейлзам. Пункт о взаимодействии с заказчиком уже не работает. Проект будет «agile sweatshop», где клиент будет выжимать все, инженерные практики будут настолько убогими, насколько это будет возможно для продвижения проекта, качество будет стабильно низким, а успех проекта будет определяться эффективностью политических игр сторон.

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

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

Ну почему, variable scope вполне работает на практике, если заказчику-таки нужен реальный результат по завершению проекта.

Да, говорят, где-то лет 5-7 назад был заказчик, который был готов мириться с урезанием скоупа на фиксед-прайс проекте и адекватно это воспринял. Эту легенду ПМы друг другу на каждой пьянке рассказывают :-)

на фиксед-прайс проекте

1. Отучаемся подменять понятия. Речь шла о variable scope.
2. Что там рассказывают ПМы на пьянках, мне неизвестно, а вот в моей лично практике variable scope проекты были, и не единожды.

Проблема этой статьи — это слово Agile в заголовке.

Я имею ввиду, что статья — отличное практическое руководство по планированию релизов. Точка. Слово Agile в заглавии, такое впечатление, служит как кликбейт. Или это типа «заказчик думает, что мы в Agile, не будем его разочаровывать»? =)

Саша, привет. Годная статья, при этом brace yourself, comments are coming =)) Бьюсь об заклад, что сейчас повалят комменты типа «это не аджайл, это ватерфол» или «это порочная практика, аджайл это когда есть гибкость» итд, итп. При этом, увы, 80% коллег не сталкивались с разработкой софта в контролируемом энвайрменте для большого энтерпрайза, когда заинтересованные стороны клиента хотят нереальное количество всего в абсолютно нереалистичные сроки, доменная область обязывает быть compliant с процессами основанными, например, на IEC 62304 а у аджайла есть только один путь — стать ОЧЕНЬ дисциплинированным =)))). Остальные же 20% уверен, статью оценят и улыбнуться про себя, вспомнив свои проекты и набитые шишки.

сейчас повалят комменты типа «это не аджайл, это ватерфол» или «это порочная практика, аджайл это когда есть гибкость»

Ну это только фанбои могут такие комментарии писать. На самом деле, в Agile сообществе давно уже поняли, что далеко не всегда нужен максимально адаптивный процесс. В том же Disciplined Agile на максималках процесс напоминает, скорее слегка облегчённый RUP, чем Scrum.

В том же Disciplined Agile на максималках процесс напоминает, скорее слегка облегчённый RUP

да, RUP неплох.

а диаграмка «ватерфол» была утрирована Ройсом чтобы показать почему вот такой дибильный ватерфол не работает :)
но самого автора за нее самого записали в дибилы, объявив отцом ватерфол

см в его работу
MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS Dr. Winston W. Royce

всем известная картинка там
Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

а реалии в
Figure 4 Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps

C Agile же все просто

Начнем с манифеста
Он содержит всего 4ре пункта, причем указано что эти утверждения в левой части не отрицают, утверждений в правой, а указывают на приоритетность внимания, усилий

Малое количество пунктов указывает на то что они все обязательны.
Потому что манифесты создаются компактными именно с такой целью — указать критически важный обязательный минимум, и все части опираются, увязаны друг с друг
«Какой угол квадрата лишний, чтобы можно было его убрать, и квадрат остался квадратом?»

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

Без прочтения других работ авторов, а я и сам не всех читал, будет сложно понять что

Люди и взаимодействие
говорят о проблеме «программисты по продуктивности, ценности для проекта отличаются в разы» (см Факты и заблуждения профессионального программирования)
и поэтому примененение процессов и инструментов дает меньший вклад в проект, чем вклад в людей и их взаимодействие

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

Сотрудничество с заказчиком
обязательность возникает из-за отстуствия забюрократизированных процессов и исчерпывающей документации, от которой отказались в предыдущих пунктах
а так же из желания эффективности разработки, ради соблюдения KISS, YAGNI, Lean
без непосредственного участия заказчика и тонн документации невозможно опеределить что можно упростить, а что выбросить

Готовность к изменениям
можно считать результатом соблюдения предыдущих пунктов:
когда требуемого качества люди, сработавшиеся в одну команду
способны согласованно создавать продукт
и отлично понимают потребности заказчика
то они они сопособны применять KISS, YAGNI, Lean так что при этом не придется переписать все, потому что «изменение ТЗ» почему-то радикально меняет задачу.

Слабость же Agile, потому он и не прижился нигде (хоп, шмяк и в продакшн — это не аджайл)

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

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

а Scrum такой же Agile как и JavaScript — Java

разработкой софта в контролируемом энвайрменте для большого энтерпрайза, когда заинтересованные стороны клиента хотят нереальное количество всего в абсолютно нереалистичные сроки, доменная область обязывает быть compliant с процессами основанными, например, на IEC 62304 а у аджайла есть только один путь — стать ОЧЕНЬ дисциплинированным

Именно людьми из такого «энвайрмента» и был придуман Agile Software Development. Самоорганизовующиеся команды дисциплинированных профессионалов лежат в основе этих практик. Там же и XP рукой из-за угла машет.

Там же и XP рукой из-за угла машет.

Вот только XP — это намного больше про разработку, чем про управление проектом в смысле объёма работ, бюджета и сроков. Да и придумали XP, насколько я помню, как последнее средство для спасения какого-то зашедшего в тупик и считавшегося безнадёжным проекта.

А ещё хочу добавить вот что. Чтобы работал труЪ agile «по книжке», должны соблюдаться как минимум два условия:

1. Зрелая самоорганизованная команда (привет украинскому аутсорсу, так любящему паттерн «ледоколы и катерки»)

2. Заказчик, который сам организационно и с точки зрения бизнеса готов работать по гибкому адаптивному процессу. Потому как статьи, подобные обсуждаемой, появляются именно тогда, когда agile пытаются применять в условиях организации, чьи бизнес-процессы и подход к планированию сами по себе недостаточно гибкие и требуют более предсказуемых прогнозов и обязательств.

Причём, пункт 2 — это не критика автора статьи ни в коем случае. Скорее, это результат стараний «религиозных фанатиков» от Agile, которые везде носятся с лозунгом «нет итеративно-инкрементальных процессов, кроме Agile, и SCRUM — пророк его». А, на самом деле-то, итеративно-инкрементальная разработка была известна ещё до волны хайпа по поводу Scrum и XP. В тот же RUP она была заложена задолго до этого хайпа.

труЪ agile «по книжке»

Да нету такого. Их 100500 видов, и самые гибкие — просто конструктор — делаешь что хочешь (см. Organizational Patterns of Agile Software Development).

Да нету такого.

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

Все так, все так...
заголовок только назвать бы
Как действовать PM’у без Agile

И фразу

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

Заменить на что-то вроде
Утвердив функционал релиза и дату сдачи, можно сгруппировать функционал в промежуточные релизы, также утвердив сроки их сдачи.

А так все так, аджайл не работает, без непосредственного включения в команду разработчиков представителя заказчика, поэтому
«Как действовать PM’у без Agile »

Несмотря на большую популярность Agile-подхода

да, загадка с этой «популярностью»
его почти никто не применяет, даже одинокий фрилансер делая сайт для пиццерии редко применяет,
но говорят, говорят, что кругом аджайл, и срам. тьху, Scrum

Если серьезно: спасибо, честная статья из практики.
Если несерьезно: учимся натягивать Waterfall на Scrum.

Подписаться на комментарии