все же общие обзоры спринтов имеют много смысла.

Соблюдаются все правила, определенные скрамом. Ядро системы – узнаваемый скрам. Чтобы выпускать инкременты продукта, которые обеспечивают от начала до конца ценность для конечного пользователя, все целиком есть «система функциональной возможности». Независимо от их комбинации, команды совместно выпускают интегрированные инкременты продукта не позднее конца каждого спринта.

3.7.3. Мультипродуктовый скрам

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

У каждого продукта есть свой владелец. Для каждого продукта существует бэклог продукта и несколько команд, которые его выпускают и поддерживают. Каждая продуктовая экосистема – это однокомандный или мультикомандный скрам.

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

Технические зависимости и зависимости в разработке разрешаются внутри спринта командами разработки различных продуктовых центров в духе неиерархического взаимодействия.

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

Глава 4

Будущее скрама

4.1. ДА, МЫ РАБОТАЕМ ПО СКРАМУ. И…

Скрам развился в 1990-е годы на основе работ Кена Швабера и Джефа Сазерленда. Они критически проанализировали практики, которые в то время были распространены в разработке софта, свой собственный профессиональный опыт, успешные техники продуктовой разработки и теорию управления процессами. Итогом их изысканий стал скрам[30], и формально он был представлен публике в 1995[31] году. За годы, которые прошли со времени публикации «Аджайл-манифеста» в 2001 году, скрам стал наиболее широко используемым фреймворком в мире аджайла.

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

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

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

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

Самый главный фактор, который влияет на скрам, – это возможность выйти за стены одного отдела разработки и распространиться на все предприятие. Помните, что в основе аджайла – бизнес-гибкость. И поэтому теперь надо сосредоточиться не на том, как разрабатывать продукты, а на том, что нужно разработать. Это смещение фокуса поможет организациям увидеть сильные стороны возможного продукта, уменьшить объем разрабатываемого продукта вместо того, чтобы просто оптимизировать то, как разрабатывается продукт[32].

Существуют мириады техник и практик игры в скрам. Но движение от старой индустриальной парадигмы к новой аджайловой не просто затрагивает процессы и практики – это настоящее обновление организации. Совместного энтузиазма команд, которые используют скрам, не хватит для глубоких организационных преобразований. Для долговременного эффекта этот энтузиазм, идущий снизу, должен быть поддержан и принят наверху[33].

4.2. МОЩЬ ПОТЕНЦИАЛЬНОГО ПРОДУКТА

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

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

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

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