Скрам: Правила игры. Карманное руководство

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

Глава 4 Будущее скрама

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

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

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

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

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

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

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

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

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

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