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

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

■ движимый людьми;

■ итеративно-инкрементальный процесс;

■ мера успеха – ценность.

1.3.1. Движимый людьми

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

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

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

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

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

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

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

1.3.2. Итеративно-инкрементальный процесс

Аджайловые процессы – это не игра без правил. Эти процессы определенны и требуют высокой дисциплины.

Продукты создаются слой за слоем, в этом заключается «инкрементальность» процесса: каждый новый слой создается из расширений, улучшений, удалений и модификаций. Уже созданные слои и продукт целиком часто пересматриваются, чтобы удостовериться в целостности продукта, – это «итеративность».

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

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

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

1.3.3. Мера успеха – ценность

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

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

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

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

Не существует одного определенного, полномасштабного, годного на все случаи жизни, унифицированного бережливого процесса ни для продуктовой разработки, ни для производства, с предопределенными и предписанными фазами, ролями, определениями, артефактами, результатами и т. д. Бережливый процесс должен быть построен на базе бережливых принципов и образа мыслей и постоянно настраиваться на текущую ситуацию. Это и есть адаптивность. Онлайновый «учебник по бережливому производству для начинающих» Баса Водде и Крэйга Лармана является блестящим введением не только в суть бережливого производства, но и в его принципы и образ мыслей[8].

1.6.1. Основные аспекты бережливого производства

Люди

Краеугольным камнем любой системы, которая претендует на то, чтобы называться бережливым производством, являются люди. И это понятие – «люди» – относится к каждому возможному действующему лицу целостной бережливой экосистемы разработки/построения продукта: это и клиенты, и рабочие, и команды, и поставщики, и менеджеры, внутренние и внешние.

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

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

Брак

Предпочтительный способ работы с браком – избегание брака за счет постоянного совершенствования и оптимизации. Запомните, что «брак» относится к этапам процесса, а не к людям. Брак – это не повод избавляться от людей.

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

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

Складские запасы, лимиты и поток

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

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

1.6.2. Внедрение бережливого производства

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

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

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

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

! Аджайл помогает.

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

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

1.6.3. Смесь философий бережливого производства и аджайла

Я опубликовал более подробную статью на эту тему с таким же названием «Смесь философий бережливого производства и аджайла»[10]. Здесь отмечу несколько стратегий аджайла, которые ставят его в один ряд с бережливым производством:

■ Складские запасы могут быть не использованы. Детализированные требования, жесткие планы, дизайн и т. д. формируют уязвимость в разработке софта и других видах комплексной продуктовой разработки – это не актив, потому что они представляют собой работу, которая может быть не использована. Аджайл избегает прорабатывания наперед каждой возможной мелочи. Если результаты определенной работы пригодятся где-то в будущем, то высоки шансы, что они вообще не будут использованы. Ожидания могут быть уточнены с течением времени, опыт промежуточных реализаций и релизов может выявить лучшие способы выполнения будущей работы. Только непосредственно предстоящая, высокоприоритетная работа детализируется более полно, потому что это то, над чем будут трудиться прямо сейчас. И даже тогда команда будет вытягивать только тот объем деятельности, который считает возможным выполнить за итерацию. Прогноз основывается на постоянном обучении и непрерывном улучшении на ежедневной основе.

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

■ Новая функциональность должна быть ценной. Исследование показывает, что едва ли 20 % функциональности софтверного продукта, построенного традиционным образом, регулярно используется[11]. Неиспользуемые или редко используемые функции создают колоссальные потери трудозатрат и бюджета, как в процессе разработки, так и при поддержке. Активное сотрудничество с людьми, которые знают и представляют пользователей и клиента, предотвращает работу над нежелательными или малоценными требованиями и помогает команде сфокусироваться на минимальном количестве функций, которые действительно могут быть ценными. Фокус на желаемых требованиях не только экономит бюджет разработки, но и гарантирует, что будущая стоимость сопровождения и поддержки останется на более низком уровне. А итеративно-инкрементальный процесс позволяет командам регулярно адаптировать продукт, основываясь на эффективной оценке его качества, а также использовать новые возможности поставки ценности.

В аджайле есть четко выраженные стратегии постоянного совершенствования за счет использования духа кайдзен:

■ рабочий план аджайл-команды проверяется и корректируется каждый день;

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

■ процесс, по которому команда работает, сотрудничает, общается, подходит к разработке, верифицируется в последней точке итерации – ретроспективе.

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

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

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

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

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

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

На игровом поле скрама находятся игроки, артефакты, события и основные принципы игры. Правила скрама связывают эти элементы воедино.

2.5.1. Игроки и их ответственность

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

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

■ владелец продукта,

■ член команды разработки,

■ скрам-мастер.

Владелец продукта – роль одного из игроков, он привносит бизнес-взгляд на продукт.

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

Владелец продукта вместе с командой разработки отвечает за бэклог продукта. Владелец продукта управляет бэклогом продукта на основании долговременного ви́дения продукта. Ви́дение продукта – это то, зачем создается продукт.

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

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

Команда разработки самоорганизуется, чтобы выполнить от начала и до конца все работы, необходимые, чтобы превратить элементы бэклога продукта, разъясненные и упорядоченные[22] владельцем продукта, в версии продукта. Термин «разработка» относится ко всей работе, которую команда разработки делает на протяжении спринта. Она может включать создание прототипов, тестирование, написание кода, подготовку документов, интеграционную работу, активности по выпуску, и т. д. В нее входит вся работа, необходимая для того, чтобы гарантировать, что не позднее конца каждого спринта инкремент продукта окажется пригодным для использования и что технически он может быть выпущен для пользователей или потребителей продукта либо сервиса. Такое состояние инкремента называется «готово». Качества и критерии, которые нужно удовлетворить для этого и которые также влияют на работу команды разработки, фиксируются в определении готовой работы.

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

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

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

2.5.2. Время

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

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

Спринт включает в себя все остальные мероприятия скрама. Каждое мероприятие ограничено по времени и является возможностью изменить курс или адаптироваться к изменяющимся условиям:

■ планирование спринта,

■ ежедневный скрам,

■ обзор спринта,

■ ретроспектива спринта.

Каждый спринт начинается с планирования спринта, когда команда разработки вытягивает работу в спринт из существующего на данный момент бэклога продукта. Команда берет тот объем работы, который представляется ей реалистичным для спринта, чтобы результат оказался готовым к выпуску. Выбранная работа – это прогноз[23], представляющий собой понимание команды на момент выбора. Команда разработки может посмотреть на объем работы, который был сделан в среднем в предыдущие спринты, и сравнить этот объем с планом на предстоящий спринт, чтобы слегка повысить точность прогноза.

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

Прогноз создается, анализируется и детализируется в план работ для ограниченного по времени спринта – это бэклог спринта. После окончания фиксированного по времени планирования спринта (или даже раньше) команда разработки начинает действовать по совместно разработанному плану. Планирование спринта никогда не занимает более восьми часов.

Чтобы управлять и отслеживать работу, команда разработки проводит ежедневные 15-минутные встречи, которые называются ежедневный скрам. Эта встреча – своего рода оперативная планерка. Команда оптимизирует план предстоящей работы на основании реального продвижения к цели спринта. Адаптация фиксируется как обновление бэклога спринта. Реальный прогресс в выполнении бэклога спринта визуализируется, показывается объем оставшейся работы. Если реальный прогресс не совпадает с намеченным, команда разработки консультируется с владельцем продукта.

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

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

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

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

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

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

Объем работы, который команда делает за спринт, иногда называют скоростью. Скорость – показатель того объема работы, который команда смогла выполнить в предыдущих спринтах. Это типичные для определенной команды (или состава команды) трудозатраты в одном спринте. Длина спринта такова, чтобы использовать возникающие и прежде непредвиденные бизнес-возможности. Совместный обзор спринта – лучший источник информации для владельца продукта, помогающий принять во внимание баланс рисков, трудозатрат, бюджета и сплоченности команды и решить, как дополнительные спринты могут улучшить ценность продукта.

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

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

2.5.3. Отслеживание продвижения в работе

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

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

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

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

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

Тем не менее команда самостоятельно принимает решение о наилучшем способе отображения прогресса в работе. Это может быть диаграмма сгорания, физическая скрам-доска, диаграмма роста (например, бизнес-ценности) или накопительная диаграмма потока:

2.5.4. Ценность бэклога продукта

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

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

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

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

Бэклог продукта постепенно уточняется, создавая инкрементальное управление требованиями к продукту.

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

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

Уровень детальности описаний элемента бэклога продукта находится где-то между мечтой и требованием. Мечта слишком туманна, чтобы над ней работать, требование слишком точно и излишне детализировано. Чрезмерная детальность в разработке препятствует оптимальному использованию технологий, блокирует способность использовать синергию различных функций и влечет денежные потери даже при минимальной турбулентности и изменениях. Поэтому хорошо подходит термин «пожелание».

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

Базовыми атрибутами для бэклога продукта являются стоимость и ценность.

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

■ Важным принципом аджайла является «удовлетворение клиента с помощью ранней и непрерывной поставки ценного для потребителя софта»[24]. Без соотнесения элементов бэклога продукта с бизнес-ценностью владелец продукта, который представляет интересы заказчика в скрам-команде, не может знать, насколько ценной может быть какая-либо функциональная возможность, идея или совокупность функциональных возможностей. Ценность будет зависеть от типа компании, типа продукта и его рынка. Ценность элемента бэклога продукта может быть непрямой. Непрямая ценность проявляется в том, что если не включить данный элемент в бэклог, то это может снизить ценность всей системы или даже целой организации. Отсутствие высокого приоритета у этого элемента может привести к образованию негативной ценности или подорвать будущую возможность создавать ценность.

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

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

2.5.5. Важность готовности

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

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

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

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

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

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

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

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

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

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

Игровое поле скрама на рис. 2.5 не только показывает обязательные элементы скрама, но также демонстрирует три главных принципа, лежащих в основе скрама:

■ общее визуальное пространство,

■ самоорганизация,

■ эмпирический контроль над процессом.

2.6.1. Общее визуальное пространство

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

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

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

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

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

Общее визуальное пространство оптимизирует прозрачность и радикально сокращает затраты на обмен информацией.

2.6.2. Самоорганизация

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

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

Самоорганизация – это не анархия и не безграничная свобода. Настоящая самоорганизация имеет границы и требует их соблюдения. Правила скрама – одни из самых главных границ, внутри которых команда организует свою работу.

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

■ Чтобы определить работу, имеющую наибольшую ценность, владелец продукта взаимодействует с пользователями, заинтересованными лицами и продуктовым менеджментом. Он полагается на кросс-функциональную команду или команды разработки, которые осуществляют поставку инкрементов продукта. Заинтересованные лица помогают сформировать будущий облик продукта на каждом обзоре спринта.

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

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

Дэниел Пинк в книге «Драйв»[26] рассматривает исследования о том, что мотивирует людей. Он пишет, что автономия, возможность управлять собственной работой является одним из трех решающих мотивационных факторов в креативной работе. «Мастерство» и «целеустремленность» дополняют его. Вместе они составляют то, что Пинк называет мотивацией 3.0, моделью мотивации человека, которая следует за первой моделью – выживанием, и второй моделью – методом кнута и пряника. То есть самоорганизация в скраме – решающий фактор мотивации для тех, кто занят креативной работой, требующей умственных усилий.

Однако автономность и самоорганизация не решают всех проблем. Некоторые проблемы выходят за рамки самоорганизации команды разработки. Скрам называет их «препятствия».

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

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

Давайте проиллюстрируем это на примере конфликта между членами команды.

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

Однако командная работа неизбежно включает узнавание друг друга, нахождение путей совместного построения версий продукта, исследование различных путей сотрудничества, нахождение консенсуса. В своей книге «Коучинг agile-команд» Лисса Адкинс[27] говорит о необходимости конструктивного несогласия. Этот наименьший уровень конфликта напоминает «встроенную нестабильность», которую наблюдали и описывали Такеути и Нонака как плодородную почву для успешной разработки комплексных продуктов. Это естественная часть свободы, которая дается группе людей, чтобы они вместе нашли наилучшие пути движения вперед при отсутствии внешнего авторитета, предписывающего решение.

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

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

2.6.3. Эмпирическое управление процессом

Разработка новых продуктов – сама по себе комплексная деятельность, она создает сложные продукты в комплексных обстоятельствах.

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

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

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

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

Для разных типов деятельности требуются разные типы контроля:

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

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

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

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

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

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

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

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

События скрама задают частоту инспекции и адаптации, а артефакты содержат информацию, которая подлежит инспекции и адаптации.

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

Инспекция без адаптации не имеет смысла в скраме. Все мероприятия скрама – это возможность сформировать будущее.

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

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

Скрам – это фреймворк правил, принципов и… ценностей.

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

2.7.1. Преданность

Преданность – это состояние приверженности делу, деятельности и т. д. Оно может быть проиллюстрировано утверждением тренера команды: «Я не могу винить своих игроков за преданность» (даже если они только что проиграли).

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

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

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

Чтобы лучше выразить первоначальное намерение и более эффективно соотнести его с эмпиризмом, «обязательство» в контексте объема работ спринта было заменено на «предсказание».

В то же время преданность, приверженность все ещё остается базовой ценностью скрама.

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

2.7.2. Сфокусированность

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

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

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

2.7.3. Открытость

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

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

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

2.7.4. Уважение

Экосистема скрама базируется на уважении к людям, их опыту, образованию и квалификации. Игроки уважают разнообразие. Они уважают разные мнения. Они уважают умения, опыт и новые идеи друг друга.

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

Все игроки уважают фреймворк скрам. Они уважают ответственности ролей скрам.

2.7.5. Смелость

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

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

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

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

Были описаны обязательные элементы скрама, правила игры и правила, которые тесно связывают эти элементы вместе. Они остаются неизменными и не зависят от масштаба.

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

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

Есть несколько тактик, которые позволяют играть в скрам в большем масштабе в зависимости от контекста.

3.7.1. Скрам одной команды

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

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

Одна команда – это скрам-команда, в которой есть владелец продукта, одна команда разработки и один скрам-мастер. Чтобы делать поставки функций продукта, которые от начала до конца предоставляют ценность конечному пользователю, команда разработки должна быть тем, что обычно называют фиче-команда.

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

3.7.2. Многокомандный скрам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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