Книга: Скрам: Правила игры. Карманное руководство
Назад: Глава 1. Аджайловая парадигма
Дальше: Глава 3. Тактики достижения цели
Глава 2

Скрам

2.1. Дом Скрама

Дом скрама — это добрый дом. Это дом, где люди ЖЕЛАННЫ.

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

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

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

2.2. Скрам, что в имени твоем?

Термин «скрам» был впервые использован Хиротакой Такеути и Икудзиро Нонакой, двумя признанными экспертами в области менеджмента, в их новаторской статье 1986 года «Разработка нового продукта. Новые правила игры».

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

Джеф Сазерленд и Кен Швабер задумали скрам-процесс для аджайловой разработки софта в начале 90-х. Они впервые представили скрам в 1995 г. на конференции Oopsla в Остине (Техас, США).

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

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

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

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

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

Джеф Сазерленд, 2011 год

2.3. Что я там вижу — гориллу?

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

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

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

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

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

Примерно в 2007 году аджайл пересек пропасть. До этого времени были только слухи об использовании аджайла, и, как правило, они основывались на единичных внедрениях в отдельных компаниях и на личных рассказах. Это типично для данных фаз жизненного цикла принятия технологии. Типично также, что аджайл интересовал по большей части лишь энтузиастов и визионеров. Но, как только пропасть была пересечена, аджайл привлек внимание более широкой аудитории — ранних последователей. Обычно они смотрят на преимущества новой парадигмы и оценивают, насколько она поможет решить проблемы существующей. Yahoo! — яркий пример большой компании, совершившей переход к аджайлу и описавшей свой опыт в 2008 году. В третьем квартале 2009 года Forrester Research и команда доктора Добба проводили опрос ИТ-профессионалов по всему миру. Возможно, вас удивит, что на вопрос «Какой подход ближе всего тому, что вы используете в настоящее время для разработки?» 36% опрошенных ответили «аджайл», тогда как только 13% сказали, что используют водопадную модель. Это стало важным официальным подтверждением общего ощущения, что аджайл постепенно вытесняет водопадную модель и что он пересек пропасть. В апреле 2012 года Forrester Research опубликовала результаты исследования применения аджайла для разработки приложений по всему миру, отмечая, что «ИТ-индустрия широко внедряет аджайл» и что его применение не ограничивается малыми предприятиями. Среди компаний, переходящих на аджайл, много и крупных организаций. В исследовании также отмечено, что «короткие итерации и скрам — самый распространенный аджайловый подход» и подтверждается мнение о том, что скрам является одним из наиболее популярных подходов к разработке. Это исследование, таким образом, подтвердило результаты ежегодного опроса «Состояние аджайловой разработки», проведенного VersionOne.

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

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

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

Скрам де-факто стал стандартом, с которым сравнивают другие подходы. Скрам — это горилла в семействе гибких методов.

2.4. Фреймворк, а не методология

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

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

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

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

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

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

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

2.5. Как играть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.2. Время

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6. Основные принципы скрама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7. Ценности скрама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7.4. Уважение

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

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

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

2.7.5. Смелость

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

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

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

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

Назад: Глава 1. Аджайловая парадигма
Дальше: Глава 3. Тактики достижения цели