Что такое пи ай: PI-планирование в SAFe / Хабр

Содержание

PI-планирование в SAFe / Хабр

Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «PI Planning — Scaled Agile Framework».

Сессия PI-планирования на 190 участников

Содержание

  • Обзор

  • Подготовка
    • Организация

    • Содержание

    • Инфраструктура

  • Повестка
    • День 1

    • День 2

  • Результаты

  • Практика

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

— Michael Kennedy, «Product Development for the Lean Enterprise»

В SAFe нет никакого волшебства… разве что только PI-планирование.

— Авторы SAFe


Один из принципов Agile-манифеста говорит, что «непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Это несложно осуществить, если у вас одна небольшая команда. А как быть в масштабах огромной компании, когда команд много и необходима их синхронная работа? Для этого в Scaled Agile Framework (SAFe) используется инструмент PI-планирование (PI Planning) — это практика прямого общения всех команд, представителей бизнеса и других заинтересованных лиц, которые как бы объединяются в одну большую команду — Agile Release Train (ART).

Общение проходит на регулярных встречах со стандартной повесткой: в начале презентация представителей бизнеса с рассказом о текущей ситуации, стратегии и задачах, затем сессия планирования, когда команды создают план реализации инкремента продукта, создаваемого в рамках программы — Program Increment (PI). Сразу оговоримся: в терминологии SAFe для обозначения большого количества взаимосвязанных между собой команд используется термин «программа», в дальнейшем мы будем его придерживаться. В этой сессии принимают участие все члены ART, насколько это возможно. Для фасилитации таких встреч выделена специальная роль — Release Train Engineer (RTE). Он же отвечает за эскалацию блокеров, помогает в управлении рисками, поставке ценности и непрерывном совершенствовании.

Для подобных мероприятий по планированию, исследованиям и обучению предусмотрена специальная IP-итерация (Innovation and Planning iteration), чтобы не занимать время команд на других итерациях внутри PI. Сессия длится от 1,5 до 2 дней. Результатом является согласованный набор целей программы на следующий PI.

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

Обзор


PI-планирование важно проводить регулярно, ведь оно задает ритм работы всего ART. Это неотъемлемая часть SAFe: если вы не проводите PI-планирование, вы не применяете SAFe.

Сессия PI-планирования на 250 участников

PI-планирование предоставляет бизнесу множество преимуществ:

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

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

  • Бизнес-заказчики и разработчики наконец-то слышат друг друга и начинают действовать слаженно в соответствии с целями бизнеса.

  • Команды начинают видеть «картинку в целом», выявляются зависимости, что подталкивает команды к координации между собой и другими ART.

  • Команды выбирают только необходимый минимум требований к архитектуре и пользовательскому интерфейсу. Это позволит уложиться в запланированные сроки и «не наворачивать» избыточный функционал.

  • Объем работ планируется с учетом емкости команд, за счет чего устраняется избыток незавершенной работы.

  • Форсируется принятие решений.


К сессии готовятся следующие материалы: дорожная карта, концепция, топ-10 приоритетных фич из бэклога программы и другие артефакты для передачи бизнес-контекста.

Основными результатами PI-планирования являются:

  1. Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. Каждая цель оценена с точки зрения значимости для бизнеса. Цели всех команд объединены в набор целей всей программы на PI.

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

  3. Общее согласие с реалистичностью и готовность взять на себя ответственность за достижения этих целей.

Подготовка


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

Успешное мероприятие готовится по следующим направлениям:

  • Организация: согласованность бизнеса и разработки по стратегии, готовность команд и всего ART.

  • Содержание: подготовленность менеджмента и разработчиков.

  • Инфраструктура: место проведения и логистика мероприятия.


Ниже приводится описание подготовки по каждому направлению.

Организация


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

Ниже примеры вопросов, которые помогают определить эту готовность.

  • Объем работы и контекст планирования: «Понятны ли рамки планирования: продукта, системы, технологической области? Знаем ли мы, какие команды нужны для совместного планирования?»

  • Согласованность бизнеса: «Согласованы ли приоритеты между представителями от бизнеса?»

  • Agile-команды: «Есть ли у нас Agile-команды? Все ли команды укомплектованы разработчиками и тестировщиками? Везде ли определены Скрам-мастер и владелец продукта?»

Содержание


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

  • Обзор текущего бизнес-контекста от топ-менеджмента.

  • Обзор продуктовой концепции, который готовят продуктовые менеджеры на основе топ-10 приоритетных фич из бэклога программы.

  • Обзор архитектурной концепции обычно представляет технический директор или архитектор, чтобы рассказать о технологических новинках для поддержки реализации фич, а также о нефункциональных требованиях.

Инфраструктура


Подготовить место проведения и техническую инфраструктуру мероприятия с большим количеством участников не так просто, особенно если есть удаленные участники.

Ниже приведены моменты, которые следует учесть.

  • Пространство: в помещении должно быть достаточно просторно для всех участников, включая места для перерывов при необходимости.

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

  • Каналы связи: распределенные сессии планирования требуют наличия основных и резервных каналов трансляции аудио, видео и презентаций.

Повестка


В целом мероприятие соответствует стандартной повестке, которая показана ниже. Далее мы рассмотрим каждый блок мероприятия подробнее.

Стандартная повестка 2-дневной сессии PI-планирования

День 1

Бизнес-контекст


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

Концепция продукта


Продуктовые менеджеры презентуют текущую концепцию программы, обычно рассказывая про важнейшие 10 предстоящих к реализации фич, про изменения с предыдущего PI-планирования, а также про любые грядущие вехи.

Архитектура и практики разработки


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

Контекст планирования


Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.

Ведущий объясняет цели и план сессии PI-планирования на 100 человек

Работа команд — 1


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

Команды выявляют взаимозависимости на сессии PI-планирования на 100 человек

Рецензирование черновиков планов


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

Владелец продукта презентует собранный ее командой план на сессии PI-планирования на 100 человек

Рецензирование руководством и решение проблем


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

День 2

Изменение планов


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

Работа команд — 2


Команды продолжают планирование на основе результатов предыдущего дня, внося необходимые изменения. Они финализирует свои цели на PI, а представители от бизнеса оценивают бизнес-ценность этих целей.

Результаты планирования одной из команд на сессии PI-планирования на 100 человек

Презентация итоговых планов


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

Риски программы


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

  • Resolved — команда согласилась, что проблема больше не актуальна;

  • Owned — вопрос не может быть решен на мероприятии, но кто-то согласился продвигать разрешение этого вопроса далее;

  • Accepted — некоторые риски являются фактами или потенциальными событиями, которые просто должны быть всеми поняты и учтены в дальнейшей работе;

  • Mitigated — команда может определить план по устранению последствий данного риска или блокера.

Риски программы на сессии PI-планирования на 100 человек

Голосование


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

Правила голосования на сессии PI-планирования на 100 человек

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

Голосование на репетиции с участием Скрам-мастеров и владельцев продуктов команд перед сессией PI-планирования на 100 человек

Переделка планов, если нужно


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

Ретроспектива


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

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

Результаты


Успешное PI-планирование позволяет получить три основных артефакта.

  1. Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. По каждой цели представителями от бизнеса определена оценка ее бизнес-ценности.

  2. Доска программы, на которой видны сроки поставки новых фич, зависимости между командами и зависимости от других ART, а также важные вехи.

    Доска программы одного ART

  3. Согласие всех команд ART с реалистичностью целей PI и их готовность взять на себя ответственность за достижение этих целей.

Практика


В этом видео наша практика PI-планирования:

PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.

PI Planning — планирование для больших команд: как его провести и что получается на практике

На этапе организации процесса разработки проектов, программ мы сегодня часто обращаемся к гибким (Agile) методологиям, например Scrum. В том числе и для планирования объема работ и условий разработки и поставки. Но Scrum-практики и артефакты эффективно работают для одной-двух команд общей численностью до 20 человек. А что делать, если нужно организовать планирование программы, где вовлечены сотни человек?

Полтора года назад мы к пришли к такой ситуации на одном из наших эккаунтов — Ahold Delhaize. Команда за этот период выросла от 40 до 130 человек. Мы столкнулись с необходимостью внедрения инструментов масштабирования в процесс планирования программы. Я расскажу о PI Planning. Не только о теории, но и о живом опыте из нескольких планировочных сессий с нашим клиентом. Так как опыт реальный, в нем есть и плюсы, и минусы. Попробую объяснить, как использовать этот инструмент по максимуму.

Вплоть до 1000 человек

Program Increment (PI) Planning Meeting — это практика планирования, которая пришла из Scaled Agile Framework (SAFe). SAFe — специально разработанный гибкий фреймворк для больших организаций. Набор предоставляемых инструментов SAFe помогает построить Agile-процессы и эффективную коммуникацию между бизнесом и командами разработки программного обеспечения в масштабе 100-1000 человек.

Здесь нужно отдельно сказать о нашем клиенте. Ahold Delhaize — один из крупнейших представителей grocery retail в мире. Проект по развитию онлайн-ветви их бизнеса у нас начался в 2015 году. Почти год на проекте в нашем харьковском офисе было задействовано до 20 человек. А затем клиент решил интенсифицировать выход нового функционала. Мы начали масштабироваться: 2 команды, 4, затем 6. А когда поняли, что команд будет 9, как сейчас, понадобились инструменты для поддержания этого масштаба.

Мы пришли к тому, что будем внедрять отдельные практики SAFe, в частности ежеквартальное PI планирование. SAFe — конечно, не единственный способ. Кроме него масштабирование для Agile организаций предоставляют: Scrum Of Scrums, Nexus, LeSS. Но наш заказчик, зная свою диджитал-организацию, решил, что именно SAFe подойдет лучше всего. Так что мы пришли к PI Planning эволюционно.

Если вкратце, сам PI Planning Meeting происходит в течение двух дней, которые полностью расписаны. В начале озвучиваются общие цели от бизнеса. Затем люди расходятся по командам, изучают, что нужно сделать конкретно каждой команде. Через время снова собираются вместе, делятся тем, что смогли запланировать, какие зависимости и риски выявили. Снова расходятся по командам и обсуждают: возможно, что-то нужно подвинуть по зависимостям от других команд.

На нашем проекте Program Increment включает в себя 6 двухнедельных спринтов. Поэтому, например, одна команда говорит: «Вам нужен вот этот функционал? Но мы сможем сделать его только в пятом спринте этого Program Increment». Другая говорит: «Чтобы нам доделать нашу фичу, нужна ваша. А нашу тоже нужно отдать в пятом спринте. Давайте вы запланируете закончить вашу в третьем, и тогда мы сможем отдать нашу в пятом».

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

Главная цель PI Planning

Вообще для Program Increment Planning необходимо собрать офлайн всех людей, которые участвуют в разработке проекта. Команда просматривает планы и цели на квартал от бизнеса, предоставляет решения. И планирует, когда эти решения будут отданы клиенту.

Главное преимущество, ради которого все затевается, это то, что участвует вся команда. То есть каждый разработчик, начиная от Junior, заканчивая Technical Leads, Solution Architects, Program Managers. Соответственно, все проблемы и зависимости можно достаточно качественно выявить и сразу их запланировать. Или озвучить как риски и начать работать над их управлением и уменьшением их влияния.

Так растет прозрачность процесса. Это уже не менеджеры, которые сказали, что нужно сделать то-то к такой-то дате, и давят на команды разработки сверху. Команда сама, изнутри, говорит: «Этот кусок можем сделать к этой дате». Сама анализирует проблемы, возможные риски и механизмы работы с ними. Думает, как сделать, чтобы зависимостей от других команд было меньше. После всех этих процессов команда чувствует себя более ответственной за конечный результат и доставку этого результата вовремя.

Также в случае больших команд (в нашем кейсе вместе с бизнесом и другими отделами на стороне клиента ± 200 человек) всегда есть несколько ключевых архитекторов, которые очень перегружены. Чтобы с ними пообщаться, встречи ради одного-двух вопросов порой приходится ждать неделями. E-mail коммуникация тоже не всегда эффективна, потому что количество e-mail у этих людей зашкаливает. Пока они смогут ответить, проходит еще пара недель. Сессии PI Planning решают и эту задачу.

Без сложностей никуда

Первая и самая главная трудность — для PI Planning нужна очень хорошая подготовка со стороны бизнеса. Бизнес-представители заранее должны определиться, что они хотят и в каком приоритете. «Я хочу новую страницу с супер UX для покупателей» — не подходит. Нужна конкретика — как и зачем будет использоваться эта новинка? Желательно заранее иметь анализ и дизайн.

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

Другой недостаток — обратная сторона преимущества. В упражнении много людей. Если участвует больше 6-7 команд, обычно это больше 100 человек — уже тяжело. Нужны оптимизации. PI Planning точно хорошо работает до 100 человек. Больше 100 — уже искусство. Мы сталкивались с ситуациями, когда нам нужно было организовать PI для 160 человек.

Как это происходит на месте

Все начинается с подготовки. Как я говорила выше, вначале она обязательно идет на стороне бизнеса: там прорабатывается, какие требования у них есть и в каком приоритете. Затем составляется график самого мероприятия. Есть лидер всего Program Increment — обычно это Agile-коуч. В зависимости от масштаба, их может быть один или два. В нашем случае сначала был один, а в последний раз — двое.

Пример стандартного расписания, которое рекомендует сам SAFe. Мы во встречах с Ahold Delhaize идем по похожей, адаптируя ее под задачи мероприятия.

В начале есть интро, где бизнес привносит цели на следующий инкремент (квартал). Желательно в формате «Хотим внедрить вот эту фичу, чтобы получить новый сегмент рынка или заработать плюс $2-3 млн к доходам».

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

Дальше команды расходятся. В каждой из них есть Scrum Master как фасилитатор внутрикомандных обсуждений вместе с Product Owner, который приносит пожелания бизнеса. Scrum Master фасилитирует и вместе со всей командой (5-6 разработчиков, тестировщики, а также, в зависимости от задач, дизайнеры и архитекторы) обсуждает, что у них за объем работ, какие пожелания у самой команды. Обсуждение идет около 2 часов. Они выделяют основные риски, зависимости с другими командами и/или вендорами.

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

Пример рабочего бумажного борда

Так проходит 2-3 итерации: команды вместе, команды отдельно, ключевые люди работают с бордом. В конце все команды снова расходятся и завершают планирование. После чего ключевые люди завершают зависимости и вопросы.

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

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

Завершается все, как правило, голосованием от команд — confidence vote. Насколько они уверены, что действительно как команда предоставят обещанный скоуп к концу следующего квартала. И желательно, чтобы confidence vote был достаточно высок. У нас он от одного до пяти — просто голосуем пальцами одной руки.

Пример подсчета «пальцев» во время голосования

Желательно, чтобы от всей команды confidence vote был около четырех. Тогда мы уверены, что все в порядке. Если же он меньше, значит, этой команде нужна еще одна итерация — на раздумья, обсуждение рисков и проблем. Скорее всего, мы что-то где-то недопонимаем. Поэтому на этом планировании важно личное присутствие архитекторов. Они помогут прояснить вопросы на месте. Это важная точка PI Planning как мероприятия: все ключевые люди, которые могут ответить на вопросы, как со стороны бизнеса, так и со стороны архитекторов, находятся в одной комнате и могут мгновенно отвечать на различные вопросы, непонимания, проблемы и т. д.

После confidence vote делается ретроспектива. Она может быть двух типов.

Первый вариант — предыдущий квартал. Все ли мы по нему выполнили, что обещали? Если нет, то в формате ретроспективы же разбираемся, почему.

Второй вариант — ретроспектива самого Program Increment. Как прошли эти 2 дня? Насколько они эффективны? Что бы мы улучшили к следующему разу? Что бы мы ни в коем случае не делали в следующий раз? Кстати, последний вопрос мы включили в недавнем очередном PI Planning с Delhaize. И фидбэк был очень ценным.

Приблизительно так проходят эти 2 дня.

Нужные люди

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

  • представители бизнеса, которые могут принимать решение на месте;
  • архитекторы;
  • технические лиды;
  • Scrum-мастера;
  • аналитики;
  • ключевые девелоперы;
  • Subject Matter Experts;
  • Program или Project Managers (если идут разработки различных уровней программ).

В целом Agile-коуч или Release Train Engineer фокусируется на том, чтобы вся программа была доставлена. А если какие-то части программы важно сделать к определенной дате, это отслеживают Program Managers. Это особенно важно, когда есть интеграция с другими системами или зависимости от внешней системы за пределами основной. Тогда необходимо согласовывать сроки с нескольких сторон. И чем больше сторон, тем сложнее это все происходит.

Критерии успеха и ошибки

Полностью ценность мероприятия можно измерить только на следующем PI Planning. Скажу просто: если мы разъезжаемся, и объем работ, и приоритеты не меняются, и мы доставляем основную часть работ согласно договоренностям во время PI — это успех. Если разъезжаемся, и приоритеты вдруг меняются или по каким-то другим причинам мы не можем доставить обсужденный объем работ — надо думать над улучшением планирования и его форматом. Тогда собираемся ретроспективой и думаем, как это изменить в будущем.

У нас был опыт провальных сессий. Все собирались, делали очень дорогое и тяжелое упражнение, планировали. Затем все разъезжались, мы садились на рабочие места, стартовали — и через неделю по тем или иным причинам приоритеты менялись. Выходит, упражнение было практически бесполезным или использовалось максимум на 30-50% того, что мы обсуждали. По сути, надо заново делать планирование. Конечно, спустя две недели повторного собрания не делали. Поэтому мы проводили перепланирование уже более кустарным способом и сталкивались с теми же вопросами, ждали письменных ответов от ответственных менеджеров и только тогда двигались дальше. Но с каждой следующей сессией эта сложность уходила.

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

Результаты сессии модерируются и контролируются со стороны менеджмента клиента и нашей.

И несколько пунктов, чтобы все прошло эффективно:

  1. Подготовка — самое главное. План расписания должен прорабатываться опытными людьми. Желательно драйверами с сертификацией SAFe, с пониманием бизнес-целей, с осознанием, что и зачем мы делаем.
  2. Agile-коучи во главе проведения сессий.
  3. Правильные инструменты фасилитации митингов — чтобы люди вовремя останавливались. Не должно быть такого, что одна задача обсуждалась час, а остальные 20 — по 1 минуте. Для этого желательно внедрять определенные ограничения по времени на каждый вопрос/задачу, чтобы люди были максимально сконцентрированы. Обычные инструменты фасилитации митинга очень важны, поэтому роль Scrum-мастера — вовремя их предлагать и применять. На уровне общих сессий это задача Agile-коучей.

Квартальный тимбилдинг

Точка проведения PI Planning в случае распределенных команд выбирается по нескольким факторам: удобство рабочей площадки, размещение гостей и, разумеется, стоимость. Например, в нашем случае с Ahold Delhaize несколько PI сессий мы проводили в Харькове. Здесь у нас большая часть команды, еще есть люди в Киеве и Гродно. Представители клиента — в Брюсселе и Афинах. Оказалось, что наш город отлично подходит для таких мероприятий по логистике и отелям. Плюс мы смогли провести PI Planning прямо в офисе.

Большой кусок закулисной работы по организации ложится на guest relations и event-менеджера. Проектом подготовки к двухдневной сессии занимается Project Administrator, который отвечает за весь процесс. Первый раз был вызовом, подготовка к нему заняла у нас почти 2 месяца. Каждый последующий раз требовалось меньше усилий — можно сказать, мы откатали процесс. Сегодня никто и не удивляется, когда мы говорим об организации визита клиентов в 40 человек и мероприятий на 180 человек.

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

И да, по нашему убеждению, серьезная работа должна оканчиваться фаном. Это полезно и для внутренней коммуникации, и для эмоционального вхождения команды в новый период. Как говорится, «work hard play hard».

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми:
менеджмент, планирование

Ваша мочевыделительная система (для детей)

en español: Tu sistema urinario

Медицинское заключение: KidsHealth Medical Experts

Первичная педиатрическая помощь в Nemours Children’s Health

Что такое мочевая система (мочевыводящие пути)?

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

Какие части мочевыделительной системы (мочевыводящих путей)?

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

Мочевыводящие пути — это пути, которые включают:

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

Что делают почки?

Почки играют ключевую роль в работе мочевыводящих путей. Они выполняют две важные функции:

  • фильтруют отходы из крови и
  • производить мочу (мочу)   чтобы избавиться от нее

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

Почки находятся под грудной клеткой сзади, по одной с каждой стороны. Каждая взрослая почка размером с кулак.

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

Что такое мочеточники?

Моча выходит из почек через мочеточников  (произносится: ЮР-ух-терс) и собирается в мочевом пузыре (мышечный мешок в нижней части живота).

Что делает мочевой пузырь?

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

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

Что такое уретра?

Когда человек мочится, моча выходит из мочевого пузыря и выходит из тела через мочеиспускательный канал  (произносится: yoo-REE-thruh), еще одну трубчатую структуру. Мужская уретра заканчивается на кончике полового члена; женский мочеиспускательный канал заканчивается чуть выше входа во влагалище.

Что такое моча (моча)?

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

Моча содержит:

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

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

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

 

Как я могу сохранить свою мочевыделительную систему (мочевыводящие пути) здоровой?

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

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

Медицинское обследование: KidsHealth Medical Experts

Дата рассмотрения: январь 2023 г.

/content/kidshealth/misc/medicalcodes/kids/articles/pee

Моча Определение и значение — Merriam-Webster

1 из 3

ˈpē

1

: буква p

2

множественное число моча, британский

: пенни

моча

2 из 3

непереходный глагол

неформальный

: помочиться

моча

3 из 3

1

неофициальный

: моча

2

неофициальный

: акт мочеиспускания

Примеры предложений

Последние примеры в Интернете

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

—Майкл Клинтон, Men’s Health , 14 июня 2023 г.

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

— Лоуренс Спекер | [email protected], al , 2 июня 2023 г.

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

— Кэтлин Фелтон, Health , 26 мая 2023 г.

Разрез посередине для порций мочи спасает жизнь!

— Лаура Ладжинесс Каупке, 9 лет.0146 harpersbazaar.com , 28 апреля 2023 г.

Это приводит к неприятному запаху мочи , который также может выглядеть мутным.

— Женское здоровье , 28 апреля 2023 г.

pee ломается среди деревьев на окраине Хопкинтона.

— BostonGlobe.com , 12 апреля 2023 г.

Сначала Яс смущает личность человека, чьи вопли раздаются эхом от прилавков, прерывая ее пи поток.

— Миган Джордан, Rolling Stone , 4 апреля 2023 г.

Говорит, что Маркус выглядел грустным, взял пописать на стоянке.

— Хэзлитт , 29 марта 2023 г.

Джордан Ривера мочился возле бара Banditos в Порт-Шарлотте вечером в воскресенье, 21 мая, когда произошел инцидент.

— Филип Эллис, Men’s Health , 25 мая 2023 г.

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

— Уилл Салливан, 9 лет.0146 Smithsonian Magazine , 14 марта 2023 г.

Есть люди, которые полностью отключаются и идут 90 146 пописать 90 147 и перекусить, что также абсолютно справедливо.

— Скотт Файнберг, The Hollywood Reporter , 2 июня 2023 г.

Через три часа после входа в свою космическую капсулу задержки с запуском подтолкнули астронавта Алана Б. Шепарда-младшего к моменту, который, несомненно, когда-то знал каждый человек, — необходимости pee без уборной в поле зрения.

— Элис Джордж, Smithsonian Magazine , 4 мая 2022 г.

Этот сезон подарил нам Кэти , писающую на руку Джона, появление страшного Пурпурного камня и самого интересного игрока в истории Survivor, сыгравшего всего один раз за Шона Ректора.

— Далтон Росс, EW.com , 18 мая 2023 г.

Пока его глаза бегают туда-сюда, молодой человек подходит к пописал на гигантский куст.

— Стервятник , 8 мая 2023 г.

В отместку Сэм помочился перед клеткой Мэтью, пытаясь обвинить его в преступлении.

— Washington Post , 25 февраля 2021 г.

Жидкости вводят постоянно, чтобы, среди прочего, избежать несахарного диабета; здоровый BHC должен выделять от 100 до 250 миллилитров мочи в час.

— Дик Терези, 9 лет.0146 Журнал Discover , 19 февраля 2012 г.

Узнать больше

Эти примеры программно скомпилированы из различных онлайн-источников, чтобы проиллюстрировать текущее использование слова «моча». Любые мнения, выраженные в примерах, не отражают точку зрения Merriam-Webster или ее редакторов. Отправьте нам отзыв об этих примерах.

История слов

Этимология

Глагол

эвфемизм от начальной буквы piss

Первое известное употребление

Существительное (1)

1602, в значении, определенном в смысле 1

Глагол

около 1825 г., в значении, определенном выше

Существительное (2)

1880, в значении, определенном в пункте 1

Путешественник во времени

Первое известное использование моча был
в 1602 г.