Эта статья была первоначально опубликована на scrum.org
https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-04/Pentacomp2021%20%282%29%20%281%29.pdf

Задача

Pentacomp сотрудничает с Министерством здравоохранения Польши над разработкой нескольких программных продуктов, включая платформу электронных рецептов, которую они называют e-health. Министерство здравоохранения работало над этими продуктами на протяжении десяти лет и им нужно было новое решение для доставки их сложных систем.
Министерство здравоохранения тестировало различные подходы к разработке e-health и решило, что Scrum лучше всего подходит для них, изначально работая с 5 отдельными Scrum-командами. По мере поступления последующих заказов от клиента были добавлены еще 2 команды, одна из которых была от второго поставщика, в общей сложности 7 Scrum-команд, а затем они добавили еще 2 команды, всего почти 100 разработчиков в 9 Scrum-командах для поддержки растущей системы e-health.

По мере роста системы e-health увеличивалось количество возможностей, компонентов и сборок, создавая увеличенную сложность и зависимости. Интеграция становилась очень сложной с их постоянно растущим объемом работ. Команды столкнулись с проблемами коммуникации и прозрачности среди разработчиков.

Решение

Для решения этих проблем Pentacomp решила внедрить фреймворк Nexus для инициативы e-health. Они тестировали несколько других подходов перед выбором Nexus, но в конечном итоге обнаружили, что Nexus лучше всего подходит. Министерство здравоохранения было очень вовлечено в решение использовать Nexus для масштабирования Scrum и нашло его наиболее подходящим для своих команд, поскольку они уже использовали Scrum.
Масштабирование за пределами Nexus до Nexus+

Основной проблемой, с которой они столкнулись через несколько месяцев использования Nexus, было то, что они обнаружили, что команды не согласованы, что создавало проблемы при упорядочивании их продуктового бэклога, показывая, что команды в Nexus работали над отдельными потоками работ. Они решили разделиться на 2 отдельных потока работ. Каждый поток стал Nexus, и вместе это стало известно как Nexus+, несколько Nexus, работающих вместе, представляющих семейство продуктов для Министерства здравоохранения. Первый поток был сосредоточен на их основной домене: Онлайн-счет пациента и электронные услуги по рецептам. Эти продукты включали электронные направления, трансграничные рецепты, мобильный e-patient и возможности записи на вакцинацию от Covid-19. Второй поток реализовывал обмен медицинской информацией, включая электронную медицинскую документацию и медицинские встречи. Тем не менее, требовалась некоторая интеграция между двумя Nexus, чтобы обеспечить последовательный опыт для пациентов. По мере развития команд они работали над согласованностью в использовании Scrum, принципов, ценностей и культуры, совместного продуктового мышления и гибкости, увеличивая эффективность. Каждый Nexus рассматривался как отдельный продукт, поэтому был введен еще один владелец продукта, всего по одному на каждый Nexus. Таким образом, в Nexus+ было 2 Nexus (по одному для каждого потока работ или продукта). У каждого потока работ был свой продуктовый бэклог и владелец продукта.

Изначально, как Nexus+, каждый Nexus проводил отдельные сессии планирования спринта Nexus, ретроспективы спринта Nexus, ежедневные с Scrum и сессии уточнения между командами. У них были общие определения «сделано» и сохранялись одни и те же принципы дизайна через Nexus. У них также был один общий обзор спринта Nexus+.

После нескольких спринтов они поняли, что проведение индивидуальных событий спринта Nexus маскирует взаимозависимости между двумя Nexus. Следовательно, они адаптировались к проведению одной общей сессии планирования спринта Nexus+, определяя общее направление работы в обеих областях, отношения, зависимости и долгосрочные планы. Они также начали проводить одну ретроспективу Nexus+ и один ежедневный Scrum Nexus+ для обоих Nexus вместе. Они сохранили двух отдельных владельцев продукта, рассматривая каждый Nexus как свой собственный продукт, и проводили сессию уточнения между командами Nexus+ в дополнение к сессиям уточнения между командами в индивидуальных Nexus. Был строгий акцент на последовательной коммуникации для интеграции, устранении отходов, разрешении несоответствий, целях продукта и ценности для клиента.

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

• Обеспечение четкого определения «сделано» для всех элементов продуктового бэклога
• Разработка правил и стандартов (gitflow, создание анализа, тестовая пирамида, правила создания документации и т. д.)
• Регулярная синхронизация между владельцем продукта и клиентом
• Использование ежедневного Scrum Nexus+ для выявления зависимостей между Nexus
• Поддержание 15% порога каждого спринта, посвященного управлению техническим долгом по мере необходимости
• Проведение «Большой ретроспективы»: один раз каждые несколько месяцев после крупных выпусков продукции с участием Scrum-команд и клиента на встрече, длительностью несколько часов. Клиенты участвовали в этих ретроспективах и взаимодействовали непосредственно с Scrum-командами, что было очень полезно и мотивирующе.

Результаты

Как только Nexus начали работать, наступила пандемия Covid-19. Они не были уверены, как Nexus будут работать удаленно, но это сработало хорошо и, что более важно, их продукты стали важнее, чем когда-либо. Пациенты легко могли получить свои рецепты, не посещая врача, благодаря их продукту e-health. Система, которую они построили, помогла спасти польскую систему здравоохранения от коллапса. Они получили множество похвал от Министерства здравоохранения из-за этого. (https://pacjent.gov.pl/e-recepta/porady-lekarskie-i-e-recepty)
До Nexus Министерство здравоохранения выпускало продукцию реже:

“В 2018 году у нас было 5 выпусков, в 2019 году было 3, в 2020 году было 6. В январе 2021 года (когда писалось это исследование) у нас уже было 4 выпуска», сказала Ханна Охманска, Scrum-мастер.

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

Компания

Pentacomp разрабатывает инновационные ИТ-решения, обслуживает и поддерживает ИТ-системы и предоставляет консультационные услуги компаниям различных отраслей. Реализуя стратегические проекты, команда Pentacomp уже 25 лет поддерживает крупнейшие организации и фирмы в достижении успеха и получении рыночных преимуществ. Это исследование дела говорит о ее работе с Министерством здравоохранения Польши.

О Scrum.org

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