В Чем Секрет Популярности и Эффективности Методологии Agile
Сегодня в мире управления проектами существует множество инструментов и методологий, которые помогают улучшить качество производимого продукта.
Также участники опроса рассказали, в каких департаментах их организаций используют Agile методологии. Среди них:
В этой статье мы подробнее расскажем, что же такое Agile методология, на чем она основана и почему так популярна.
Что такое методология Agile?
Agile — это набор практик, целью которых является оперативная реакция на изменения в ходе рабочего процесса.
Такие подходы помогают командам быстро реагировать на обратную связь от клиентов и заказчиков, тем самым постоянно улучшая производимый продукт.
Стоит отметить, что Аджайл (от англ. agile — гибкий) — это не набор конкретных методов и не свод инструкций. Будет правильнее сказать, что Agile — это группа методологий, которые стремятся к улучшению производимого продукта с помощью повторяющихся рабочих циклов и постоянного фидбека от клиентов.
Философию Agile характеризуют гибкость и скорость команды, а также максимальная прозрачность рабочих процессов.
Проще говоря, Agile — это не про отчетность, документооборот и четкий план, а про постоянное общение с клиентом и готовность оперативно реагировать на изменения в ходе проекта.
Чаще Agile используется для разработки программного обеспечения. В этой сфере Аджайл базируется на итерациях фаз программирования и тестирования на протяжении полного жизненного цикла продукта. В Agile и разработка, и тестирование выполняются одновременно, в отличие от методологии Waterfall, в которой проект выполняется поэтапно.
В программировании методология Agile начинается с описания клиентом результата, которого он стремится достичь. Команде важно четко понимать, какие проблемы с помощью разработанного продукта хочет решить заказчик.
С началом работы команда циклично проходит процессы планирования, проектирования, реализации и оценки. В ходе выполнения этих процессов конечный результат может измениться, если выяснится, что он будет еще больше соответствовать целям и стремлениям клиента.
Постоянное взаимодействие команды с заказчиком и остальными заинтересованными лицами способствует оперативному обсуждению грядущих изменений. Это позволяет принимать полностью обоснованные и согласованные со всеми участниками команды решения.
Непрерывное стремление компаний улучшить производимый продукт помогает им оставаться конкурентоспособными на протяжении долгого времени.
Преимущества Agile:
Agile манифест
Публикация Agile манифеста в 2001 году знаменовала рождение Agile как методологии.
Началась эта история в американском штате Юта, где в начале 21 века 17 независимых программистов собрались для обсуждения будущего разработки программного обеспечения.
Группа сошлась во мнении, что главная проблема среди команд разработчиков заключалась в том, что они были чрезмерно сосредоточены на планировании и документировании циклов разработки ПО. И упускали из виду то, что действительно имело значение, а именно удовлетворенность заказчиков.
Манифест группы разработчиков стал новаторским и в корне изменил подход к сотрудничеству с клиентами и достижению целей команды. Agile Manifesto не являет собой свод правил, он выделяет ключевые ценности, которые ставят взаимодействие с людьми на первое место.
За последние 20 лет с момента создания манифест приняли многие команды и организации из разных профессиональных сфер. Сегодня документ доступен более чем на 50 языках, включает в себя 4 ценности и 12 принципов.
4 ценности Agile манифеста:
Авторы манифеста отметили, что не отрицают необходимость пунктов, находящихся в правом столбце. Но все же в приоритет выносят ценности, расположенные слева.
12 принципов Agile манифеста о разработке программного обеспечения:
Популярные Agile методологии
Существует множество различных методологий (или фреймворков) гибкой разработки, которые держат за основу ценности и принципы Agile манифеста. Канбан (Kanban), Скрам (Scrum), Бережливое производство (Lean) и Экстремальное программирование (XP) — часто используемые из них.
Kanban
Это визуализированный подход к управлению проектами. Используя Канбан, команды визуализируют задачи при помощи доски и стикеров либо специальных онлайн-инструментов.
Задачи перемещаются между столбцами, обозначающими их статус. Такой подход позволяет эффективно расставлять приоритеты, контролировать прогресс выполнения проекта, а также ограничивать объем незавершенной работы.
Scrum
Скрам — это методология управления проектами, в которой командой руководит Скрам-мастер. Его главная задача состоит в устранении преград на пути к завершению проекта.
Работа в команде делится на короткие повторяющиеся циклы, которые называются спринтами и обычно длятся 1-4 недели. При этом команда собирается на ежедневные митинги (стендапы), чтобы обсудить текущие задачи и препятствия, которые предстоит преодолеть.
Экстремальное программирование (XP)
Название методологии произошло от идеи использовать полезные классические методы разработки ПО, подняв их на «экстремальный» уровень.
Доступно проиллюстрирует идею XP способ «парного программирования». В этом случае один разработчик занимается написанием кода, а его коллега непрерывно просматривает и проверяет написанное, не дожидаясь окончания работы первого программиста.
Бережливое производство (Lean)
Ключевой задумкой бережливого производства является максимально экономный и разумный подход к ресурсам проекта. Методология Lean — это набор инструментов и принципов, направленных на выявление и устранение возможных потерь для ускорения процесса разработки.
В понятие потерь входят не только затраты времени, финансов и труда. Сюда же относится и нереализованный творческий потенциал команды и каждого ее участника.
Другие гибкие методологии разработки ПО
В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:
Каждая методология воплощает в себе принципы частых итераций, непрерывного обучения и высокого качества производимого продукта.
Что это будет, классический Скрам из учебников или смесь Канбан и XP, зависит целиком и полностью от вас. Главное, чтобы выбранный способ удовлетворял потребностям проекта. Гибкость приветствуется даже в выборе методологии этой самой гибкости.
Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).
Кому подойдет методология Agile?
Несмотря на популярность и высокие результаты при использовании методологии Agile, применять ее в работе над каждым проектом нет никакой необходимости. Все же Agile не панацея.
К примеру, простой баннер или веб-сайт можно сделать поэтапно, используя техническое задание от заказчика.
Существует несколько условий, при которых проекту наверняка потребуется гибкая методология управления:
В этом случае разумнее реализовывать проект постепенно и постоянно его тестировать. Это поможет сэкономить непредвиденные расходы.
Чем дольше будет длиться работа над проектом, тем сложнее прогнозировать и планировать его развитие в отдаленном будущем.
Так бывает, когда команда разрабатывает инновационный продукт. В этом случае невозможно заранее проработать весь его функционал. Поэтому логичнее идти к созданию продукта небольшими шагами и опять же постоянно его тестировать.
Когда идей много, внедрять их одновременно — решение рискованное и экономически нецелесообразное. Ведь заранее сложно сказать, какие из них окажутся удачными.
Идеальное условие для внедрения Agile методологий — это заинтересованность заказчика в плотном сотрудничестве с командой.
Инструменты для работы с Agile-проектами
Вовлеченность в проект нескольких команд делает рабочий процесс менее прозрачным. Кроме того, менеджеру, руководителю и заказчику становится все сложнее следить за прогрессом проекта, контролировать его реализацию и вносить изменения.
Облегчить работу с комплексными проектами и настроить взаимодействие между участниками команды помогут инструменты управления Agile-проектами. С ними вы всегда можете видеть общую картину проекта, контролировать загрузку работников, общаться с командой и держать заказчика в курсе изменений и корректировок.
Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам.
Онлайн диаграмма Ганта GanttPRO
Ведите проекты, управляйте временем, ресурсами и финансами.
Какую гибкую методологию управления проектами предпочитаете вы?
Agile — незаменимый подход к управлению проектами, который держит команду в тонусе и постоянно помогает добиваться лучших результатов. Благодаря тесному сотрудничеству команды и заказчика, а также вовлеченности и обратной связи потребителей продукта, результат приносит еще большее удовлетворение каждому участнику проекта.
А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в комментариях ниже.
Лучшие приемы и практики Agile для технических и нетехнических команд
Работая продолжительное время по Agile, можно легко выделить основные ценности, принципы и практики, благодаря которым выбор в пользу методологии сегодня делают огромное количество компаний. Некоторые практики в методологии удостаиваются высокой оценки почти у всех, какие-то являются спорными. Однако Agile не стал бы Agile, если бы лучшие ценности и приемы методологии не завоевывали расположения миллионов менеджеров и разработчиков по всему миру.
Знаменитая методология была создана для разработки ПО. Поэтому практически все практики Agile применяются именно там. Однако это не мешает применять Agile и многим нетехническим командам.
Компании, которые не связаны с IT быстро обнаружили преимущества использования гибкого мышления и некоторых Agile-практик, которые могут помочь бизнесу достичь большего, принести клиентам максимум пользы и удовольствия, а также сплотить команду внутри.
С 2001 года Agile-принципы оформили в знаменитый манифест Agile, а сама методология стала стандартным процессом разработки ПО.
Каковы ключевые практики Agile сделали методологию столь известной и востребованной?
Приведенный ниже список не является полным, поскольку практики Agile можно рассматривать с разных точек зрения и применяя различные классификации. В нашем списке — самые основные из них, которые могут применяться в разработке ПО, а некоторые — в применении к нетехническим продуктам и проектам.
Список лучших практик Agile
Очередь задач
Часто крупные задачи в проекте необходимо разделять на части. Многие из них скапливаются, образуя очередность. В этом случае менеджеру продукта необходимо тщательно поработать со всеми задачами бэклога, определив верные приоритеты для каждой.
Обычно в бэклог продукта входят следующие элементы: продуктовые фичи, возможные баги, приоритетные знания по продукту, некоторые технические работы, и др.
Все элементы в бэклоге упорядочены согласно их ценности. Чем весомее элемент, тем скорее он пойдет в работу. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.
В управлении бэклогом определяющую роль играет собрание backlog grooming, во время которого представители Agile команды обсуждают детали бэклога продукта и готовят очередное планирование спринта.
Итерации
Agile-команды выбирают количество работ, которые необходимо выполнить в определенное время. Итеративная разработка означает, что сама команда может решить, что она может сделать, исходя из своих возможностей и опыта предыдущей итерации.
Клиентоориентированность
Сотрудничество с клиентами является ключевым моментом в методологии Agile. Согласно гибкому подходу, команда должна предоставить всю информацию, необходимую клиентам, и сообщать им о прогрессе. Постоянная связь также должна быть частью внутренней командной работы.
User stories
User stories включают описание, критерии приемки и оценку времени. Когда они слишком сложны, менеджеры продуктов разделяют их на более мелкие.
Agile-роли
Методология включает разные роли и, соответственно, разные их названия. Если обобщать, роли в Agile можно разделить по группам, включающим:
Value stream analysis
Анализ потока ценностей — это метод управления для анализа текущего состояния и разработки будущего состояния продукта. Цель анализа в том, чтобы идентифицировать и удалять «отходы» в потоках создания ценности, тем самым повышая эффективность потока данных.
Здесь методология знакомит с двумя принципами. Первый — это определение продукта на основе пользовательских историй, основанных на анализе бизнеса. Второй — определение зависимостей между бизнес-и технической функциональностью.
Timeboxing
Timeboxing используется в качестве метода планирования проекта. Расписание делится на несколько отдельных периодов времени (таймбоксы), каждый из которых имеет свои конечные результаты, срок и бюджет.
Спринты продолжаются в соответствии с указанными таймфреймами. Обычно от двух недель до одного месяца. Scrum-митинги обычно продолжаются около 15 минут.
Ежедневные собрания
Например, Scrum meeting — это ежедневное мероприятие, короткая утренняя или дневная встреча, обычно организованная менеджером продукта или владельцем продукта. Длится 10-15 минут и требует присутствия Скрам-мастера и всей команды. Такая встреча организуется, чтобы:
Sprint demo meeting
Такая встреча организуется, когда определена функциональность и пришло время объяснить клиенту, как это работает. Это важно, потому что клиенты могут подтвердить, что они принимают конкретный функционал или определить моменты, с которыми не согласны.
Retrospective meeting
Речь идет о ретроспективе по окончательному итеративному развитию. Retrospective meeting рекомендуется посещать всем членам команды. Клиенты также могут участвовать.
Здесь обсуждаются возможности улучшения процессов, качества работы, используемых инструментов и т. д.
Тестирование
Очень важно своевременно получить информацию о фичах, которые не работают так, как планировалось. Тесты запускаются автоматически перед началом работы. Это гарантирует, что все изменения кода приемлемы.
Burndown chart
Этот график демонстрирует, действительно ли все идет в соответствии с календарем программирования и общим планом. Он отражает сроки и расписания. В диаграммах Burndown также отображается количество пользовательских историй за единицу времени.
Приоритизация требований
Приоритезация требований используется в Agile для определения того, какие конкретные требования к продукту должны быть включены в определенный релиз.
Менеджеры продуктов также приоритезирует требования для минимизации рисков во время разработки — сначала выполняются наиболее важные. В этом случае опытные менеджеры по продуктам и проектам используют хорошо известные методы и техники приоритизации.
Планирование релиза
Релиз продукта представляет собой набор новых функций или финальный запуск продукта. Грамотное планирование релиза помогает командам выпускать качественные продукты.
В чем секрет успешного релиз-менеджмента? Определенно, это не только о предоставлении клиентам доступа к новым функциям. Это окончательная дата, когда ваша команда может поделиться новым опытом своей работы и поддержать взаимодействие с клиентами.
Все заинтересованные стороны должны знать, когда они могут ожидать новых функциональных возможностей. Календарь релизов всегда должен быть четко распланирован.
Этот список можно продолжать и дополнять другими интересными практиками. Однако какие же практики могут быть использованы нетехникеской командой?
Яркий пример — использование бэклога и приоритизация задач командой авиатранспортной компании Air Methods, которая специализируется на оказании скорой помощи.
В компании из более чем 6000 сотрудников активно работает команда по созданию и управлению стратегией обучения и развития. В самом начале деятельности эта команда столкнулась с тем, что заинтересованные стороны не понимали, сколько времени и сил понадобится для создания тренингов и обучающих проектов.
Так команда пришла к Agile-практике использования и управления бэклогом и определению приоритетов. За визуализацию стали отвечать инструменты Trello.
На доске собираются запросы заинтересованных сторон, команда присваивают каждому зеленый или красный лейбл. “Зеленые” проекты можно выполнять сейчас, “красные” попадают в очередь.
Ежемесячно команда и заинтересованные собираются для определения новых приоритетов, голосуют и дискуссируют.
По словам представителей компании, такая практика помогает работать с ожиданиями бизнеса, создает синергию внутри команды, увеличивает ее эффективность. В результате, нетехническая команда начала продуктивно сотрудничать с заинтересованными сторонами.
Как уже упоминалось выше, этот список может включать множество других практик, связанных с требованиями, проектированием, развитием продукта, тестированием, а также организационными вопросами.
Сегодня успешно применять главные ценности Agile помогают доступные сервисы и инструменты для управления проектами, истории мировых компаний, распространненных в сети, множество современных курсов и актуальной литературы по методологии. Благодаря этому, приемы и практики Agile ежедневно обеспечивают успех многим компаниям и привлекают все больше технических и нетехнических команд.
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.
Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.
Пропускная способность
Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.
Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.
Для того чтобы поддерживать этот ритм и чтобы не завязнуть в ручном регрессивном тестировании, команда усиленно работает над автоматическим тестированиеми постоянной интеграцией. Поэтому на каждую фичу приходится писать автотесты, и большая часть кода имеет встроенные автотесты.
Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.
Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.
Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.
Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.
Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”
Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.
Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.
Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.
Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.
Есть только один способ держать список задач под контролем — это слово “нет”
Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.
Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.
Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.
Принятие решений
Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.
Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.
Как владелец продукта определяет ценность и объем истории? Никак. Это игра в угадайку. И лучше в ней участвовать всем. Пэт постоянно общается с заинтересованными лицами, чтобы знать ценность каждой истории, общается с командой разработчиков, чтобы знать объем работ, но все это приблизительные догадки, никаких точных цифр. Вначале всегда будут промахи и это нормально. Гораздо большую ценность представляет общение, чем сверхточные цифры.
Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.
Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.
Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.
Владелец ИТ-продукта должен постоянно со всеми общаться
Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.
Баланс между сложностью разработки и ценностью пользовательской истории
На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.
Риски
Бизнес риск: «Правильную ли вещь мы делаем?»
Социальный риск: «Сможем ли мы сделать то что нужно?»
Технический риск: «Будет ли проект работать на данной платформе?»
Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»
Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,
Компромисс между ценностями знания и ценностями для клиента
С точки зрения заказчика кривая выглядит вот так:
С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.
Компромисс между краткосрочным и долгосрочным мышлением
Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.
Делать правильные вещи, делать вещи правильно или делать быстро?
В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.
Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.
Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.
Между ролями в Scrum существует здоровое противостояние
Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.
Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.
Компромисс между разработкой нового продукта и улучшением старого
Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.