Гюнтер Верхеен

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

Переводчик Александр Лесневский

Редактор Люба Мамаева

Научный редактор Илья Павличенко, первый сертифицированный профессиональный скрам-тренер в России, основатель сообщества Scrum Russia

Главный редактор С. Турко

Руководитель проекта А. Василенко

Арт-директор Ю. Буга

Корректоры А. Кондратова, О. Улантикова

Компьютерная верстка К. Свищёв

© Gunther Verheyen & Van Haren Publishing, 2019

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2023

* * *

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

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

Рекомендуем книги по теме

Скрам: Гибкое управление продуктом и бизнесом

Кен Швабер

Agile: Оценка и планирование проектов

Майк Кон

Канбан Метод: Улучшение системы управления

Майк Барроуз

Agile-менеджмент: Лидерство и управление командами

Юрген Аппело

Предисловие Кена Швабера

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

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

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

Кен, август 2013 года

Предисловие

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

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

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

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

Мое путешествие стартовало в 2003 году: мой путь к бизнес-гибкости начался c экстремального программирования и скрама. Этот путь был сложным, но по-другому быть и не могло. За время моего путешествия я использовал скрам со множеством команд, на разнообразных проектах, в разных организациях. Я работал в больших и маленьких организациях и тренировал как команды, так и высшее руководство. Я написал первое издание этой книги. Мне посчастливилось сотрудничать с Кеном Швабером, одним из создателей скрама в Scrum.org.

Кто бы мог предположить, что спустя пять лет после почти случайного создания первого издания в 2013 году возникнет потребность во втором издании моей книги?

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

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

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

Я благодарю Кена Швабера за предисловие и рецензирование первого издания, так же как и других рецензентов: Дэвида Старра, Патрисию Конг и Ральфа Джохама – за обратную связь по первому изданию. Я очень признателен Блейк МакМиллан и Доминик Максимини за рецензирование второго издания. Я благодарю всех переводчиков за их труды по распространению моей книги на разных языках.

Я благодарю издательство Van Haren Publishing и в особенности Иво ван Харрена за то, что мне был дан шанс рассказать о своем ви́дении скрама в этой книге.

Наслаждайтесь чтением и… продолжайте скрамить.

Гюнтер, август 2018 г.

Глава 1

Аджайловая парадигма

1.1. МЕНЯТЬСЯ ИЛИ НЕ МЕНЯТЬСЯ

В индустрии разработки ПО долгое время доминировала парадигма индустриальных взглядов (рис. 1.1). Фактически она была калькой со старых добрых промышленных практик и теорий. Важной частью фундамента этих практик было тейлористское убеждение[1] о том, что «рабочим» нельзя доверять осмысленную и креативную работу. От них можно ждать выполнения только механических задач. Вся их работа должна быть подготовлена, спроектирована и спланирована более старшими по иерархии сотрудниками. Более того, старшие должны неусыпно надзирать за исполнением этих тщательно подготовленных задач.

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

Серьезные недостатки этой парадигмы уже известны и тщательно описаны. В частности, Отчет о состоянии ИТ-проектов от Standish Group[2] раз за разом выявляет низкий уровень успешности традиционной разработки ПО. Количество проблем и ошибок в ПО, которое разрабатывали традиционным способом, превышало все возможные пределы. Столь обескураживающие результаты повлияли на ожидания от разработки в целом. Считалось нормальным, что только 10–20 % проектов успешны. Успех в индустриальной парадигме определяется выполнением трех требований: в заданное время, в рамках бюджета и в запланированном объеме. Хотя можно спорить с этими критериями успеха, это то, что нам обещает индустриальная парадигма. Стало общепринятым, что качество остается низким и более половины функциональности софта[3] никогда не используется[4].

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

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

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

Семена нового мировоззрения были посеяны уже в 1990-е годы. Проросли они в 2001 году, когда появилось формальное наименование «аджайл» – это событие стало новой точкой отсчета в истории разработки софта. Новая парадигма родилась в софтверной индустрии, но почти сразу стала распространяться на другие сферы общества. В ее основе креативность, уважение творческой природы работы и интеллигентности «рабочих».

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

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

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

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

Постепенные изменения – это фактически сохранение статус-кво, то есть индустриальная парадигма остается в неизменном виде.

Существует огромное количество доказательств того, что старая парадигма не работает. Но раньше доказательства преимуществ аджайла были единичными историями. Отчет о состоянии ИТ-проектов[5] в 2011 году, подготовленный Standish Group, – это поворотная точка. Он впервые продемонстрировал однозначные результаты исследований, которые были подтверждены во всех последующих отчетах. Было проведено масштабное исследование/сравнение традиционных проектов с проектами, которые использовали гибкие методы. Отчет показал, что гибкий подход к разработке софта дает значительно более высокие результаты даже в рамках традиционных ожиданий, когда софт должен быть поставлен в заявленные сроки, в рамках бюджета и во всем обещанном объеме функциональности. Отчет показал, что аджайловые проекты были в три раза более успешными, а провальных аджайловых проектов было в три раза меньше, чем традиционных. Для больших проектов, однако, разница в степени успешности была не такой явной, что может быть связано с неправильными ожиданиями, т. е. с комбинацией время + бюджет + объем. Ясно, что при правильно сформированных ожиданиях с фокусом на активном сотрудничестве с заказчиком и частой поставке ценности новая парадигма будет работать еще лучше, преодолевая проблему объема за счет частой поставки срезов ценности.

Тем не менее аджайл – это выбор, а не требование. Это один из путей улучшения индустрии разработки софта. Исследование показывает, что этот путь более успешен.

! Скрам помогает.

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

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

1.2. ПРОИСХОЖДЕНИЕ АДЖАЙЛА

Несмотря на доминирование индустриальных взглядов, в которых главное – тщательное планирование, эволюционный подход к разработке ПО совсем не нов. Крэйг Ларман подробно описал предшественников аджайла в своей книге «Аджайл и итеративная разработка» (Agile & Iterative Development).

Но официальное название «аджайл» родилось в начале 2001 года, когда 17 лидеров по разработке программного обеспечения собрались на горнолыжном курорте Сноубёрд в штате Юта. Они обсуждали свои взгляды на разработку ПО в то время, когда неработающий водопадный подход был заменен тяжеловесной методологией RUP[6], но и она не привела к лучшим результатам по сравнению с традиционными процессами. Лидеры разработки шли различными путями и использовали разные методы, каждый из которых был воплощением новой парадигмы: скрам, экстремальное программирование, адаптивная разработка ПО, Crystal, разработка, управляемая функциональностью (Feature driven development), метод разработки динамических систем (DSDM) и другие.

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

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

Манифест помогает понять идеи, на которых основан аджайл. Если вы используете его как источник более глубокого понимания аджайла, я рекомендую посмотреть на 12 принципов[7], которые стоят за формулировками четырех ценностей.

1.3. ОПРЕДЕЛЕНИЕ АДЖАЙЛА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.4. ИТЕРАТИВНО-ИНКРЕМЕНТАЛЬНЫЙ КОНТИНУУМ

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

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

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

Мы привыкли к тому, что риск в ИТ-контексте определяется как нечто техническое (Будет ли система работать? Масштабируется ли она?) и покрывает аспект пригодности для использования продукта (Выдержит ли технически? Не сломается?). Но этот взгляд на риск часто игнорирует конечную цель гибкой разработки – обеспечить бо́льшую удовлетворенность конечных пользователей и клиентов, то есть продукты должны быть полезны. Продукт, пригодный для использования с технической точки зрения, – это только начало.

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

Гибкая разработка устроена так, чтобы максимально смягчить этот бизнес-риск. Требования, имеющие высокую ценность, удовлетворяются в первую очередь. Версии продукта и обновления выпускаются быстро и часто. Они удовлетворяют существующие потребности, а также предлагают неожиданные, инновационные функции. Благодаря этому пользователи платят за продукт, а инвестиции возвращаются. Версии продукта качественные, что позволяет минимизировать сопровождение и поддержку, оптимизировать общую стоимость владения (Total Cost of Ownership, TCO).

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

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

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

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

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

1.5. ГИБКОСТЬ НЕЛЬЗЯ СПЛАНИРОВАТЬ

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

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

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

■ Гибкость нельзя спланировать.

■ Гибкость нельзя продиктовать сверху.

■ Гибкость нельзя скопировать.

■ У гибкости нет конечного состояния.

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

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

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

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

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

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

1.6. СОЧЕТАНИЕ АДЖАЙЛА И БЕРЕЖЛИВОГО ПРОИЗВОДСТВА

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

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

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

Люди

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

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

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

Брак

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2

Скрам

2.1. ДОМ СКРАМА

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

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

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

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

2.2. СКРАМ, ЧТО В ИМЕНИ ТВОЕМ?

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

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

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

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

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

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

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

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

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

2.3. ЧТО Я ТАМ ВИЖУ – ГОРИЛЛУ?

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4. ФРЕЙМВОРК, А НЕ МЕТОДОЛОГИЯ

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

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

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

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

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

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

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

2.5. КАК ИГРАТЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.2. Время

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6. ОСНОВНЫЕ ПРИНЦИПЫ СКРАМА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7. ЦЕННОСТИ СКРАМА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7.4. Уважение

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

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

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

2.7.5. Смелость

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

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

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

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

Глава 3

Тактики достижения цели

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

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

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

В скраме можно использовать много тактик. Хорошие тактики служат цели скрама. Хорошие тактики усиливают ценности скрама, а не уменьшают их.

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

3.1. ВИЗУАЛИЗАЦИЯ ПРОДВИЖЕНИЯ В РАБОТЕ

Хорошей иллюстрацией того, как скрам движется в сторону большей легкости, стала отмена обязательности диаграмм сгорания.

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

Однако требование использовать для этого диаграммы сгорания было изъято из определения скрама. Теперь нет обязательного формата визуализации. Это требование заменено простым ожиданием визуализации продвижения в работе над обязательными артефактами скрама: бэклогом продукта и бэклогом спринта.

Посмотрите на пример диаграммы сгорания спринта (рис. 2.7) в разделе 2.5.3 «Отслеживание продвижения в работе».

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

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

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

3.2. ВОПРОСЫ ЕЖЕДНЕВНОГО СКРАМА

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

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

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

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

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

Вы знали, что ежедневный скрам – необязательно ежедневное короткое собрание команды?

Ежедневное короткое собрание команды – это практика, описанная в экстремальном программировании[28], которая служит той же цели, что и ежедневный скрам. Но экстремальное программирование советует последователям проводить это мероприятие стоя.

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

3.3. УТОЧНЕНИЕ БЭКЛОГА ПРОДУКТА

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

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

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

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

3.4. ПОЛЬЗОВАТЕЛЬСКИЕ ИСТОРИИ

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

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

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

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

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

3.5. ПОКЕР ПЛАНИРОВАНИЯ

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

На покере планирования команда устраивает обсуждение требования, после которого каждый член команды делает оценку требования, выбирая карту с определенным значением из колоды. Карты для покера обычно используют экспоненциальную шкалу наподобие последовательности Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34, …). Члены команды не раскрывают выбранного значения до тех пор, пока все не сделают выбор. Далее все раскрывают свои оценки одновременно, после чего обсуждают возможные различия. Этот цикл повторяется до тех пор, пока не будет достигнуто согласие и общее понимание оценки требования. Оценки относительны и выражаются в абстрактных единицах, например в стори пойнтах или даже мишках Гамми, как в ранних проектах экстремального программирования.

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

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

3.6. ДЛИНА СПРИНТА

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

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

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

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

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

Давайте посмотрим на команду с однодневными спринтами.

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

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

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

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

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

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

3.7. КАК МАСШТАБИРОВАТЬ СКРАМ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3. ПРИНЯТИЕ СКРАМА ТОП-МЕНЕДЖМЕНТОМ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будущее состояние скрама не будет больше называться «скрам». То, что мы сейчас называем скрамом, должно стать нормой, и так возродятся организации.

Словарь

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

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

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

Диаграмма сгорания – диаграмма, показывающая изменение остающейся работы во времени.

Длина спринта – продолжительность спринта во времени, которая составляет четыре недели или меньше.

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

Заинтересованное лицо, стейкхолдер – внешнее по отношению к скрам-команде лицо с определенным интересом к продукту и знанием продукта, которое необходимо в ходе эволюции продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цель спринта – короткая фраза, раскрывающая главное назначение спринта.

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

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

Об авторе

Гюнтер Верхеен, gunther.verheyen@mac.com – давний практик скрама. После впечатляющей карьеры консультанта он стал партнером Кена Швабера и директором линейки профессиональных тренингов по скраму в Scrum.org (2013–2016). Гюнтер сотрудничает с людьми и организациями как независимый хранитель скрама.

Гюнтер занялся ИТ и разработкой софта после окончания университета в 1992 году. Его путешествие в аджайл началось с экстремального программирования и скрама в 2003-м. Дальше были годы вовлеченности, годы использования скрама в различных обстоятельствах. С 2010 года Гюнтер был вдохновителем некоторых масштабных трансформаций компаний. В 2011-м он стал профессиональным тренером по скраму.

Гюнтер оставил консалтинг в 2013 году, чтобы основать Ullizee-Inc и заключить партнерские отношения с Кеном Швабером, одним из создателей скрама. Он представлял Кена и его организацию в Европе, занимался линейкой профессиональных тренингов по скраму и руководил глобальной сетью профессиональных скрам-тренеров Scrum.org. Гюнтер является сооснователем Agility Path, EBMgtTM[36] и фреймворка Нексус для масштабируемого профессионального скрама.

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

В 2013 году Гюнтер опубликовал первое издание этой книги, рекомендованное Кеном Швабером как «необычайно компетентное» и «лучшее на сегодняшний день описание скрама». В 2016-м был опубликован перевод на голландский. В 2017-м был выпущен немецкий перевод. Это второе издание также переводится на несколько языков.

Гюнтер живет и работает в Антверпене (Бельгия).

Гюнтера можно найти на LinkedIn: https://www.linkedin.com/in/ullizee, в Twitter: https://twitter.com/ullizee или почитать мысли о скраме в его блоге https://guntherverheyen.com/.

Сноски

1

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

2

Standish, 2011; Standish, 2013.

3

Эти цифры являются предметом дискуссии, см., например https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used и https://scrumcrazy.wordpress.com/2015/08/06/a-response-to-mike-cohns-comments-on-64-of-software-features-rarely-or-never-used/. В моей личной практике бывали примеры создания вовсе не нужного софта. – Прим. пер.

4

Standish, 2002; Standish, 2013.

5

Chaos Manifesto (The Laws of Chaos and the Chaos 100 Best PM Practices). The Standish Group International, 2011.

6

Методология разработки программного обеспечения, созданная компанией Rational Software.

7

См. http://agilemanifesto.org/principles.html.

8

Larman, C., Vodde, B. Lean Primer. http://www.leanprimer.com, 2009.

9

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

10

Verheyen, G. The Blending Philosophies of Lean and Agile. https://www.scrum.org/resources/blending-philosophies-lean-and-agile, 2011.

11

Keynote on Feature Usage in a Typical System at XP2002 Congress by Jim Johnson, Chairman of the Standish Group, 2002.

Chaos Manifesto 2013: Think big, act small. Standish Group, 2013.

12

Takeuchi, H., Nonaka, I. The New New Product Development Game. Harvard Business Review, 1986.

13

Oopsla – объектно-ориентированное программирование, системы, языки и приложения.

14

Moore, G. Crossing the Chasm, Marketing and Selling Technology Products to Mainstream Customers (second edition). Wiley, 1999.

Wiefels, P. The Chasm Companion. A Fieldbook to Crossing the Chasm and Inside the Tornado. Wiley, 2002.

15

Benefield, G. Rolling Out Agile at a Large Enterprise. HICSS’41 (Hawaii International Conference on Software Systems), 2008.

16

Hammond, J., West, D. Agile Application Lifecycle Management. Forrester Research, 2009.

17

31 % ответили, что они не следуют никакой методологии. 21 % ответили, что применяют итеративную разработку.

18

Giudice, D. L. Global Agile Software Application Development Online Survey. Forrester Research, 2011.

19

State of Agile Survey. 6th Annual. VersionOne Inc., 2011.

7th Annual State of Agile Development Survey. VersionOne Inc., 2013.

20

Verheyen, G., Arooni, A. ING, Capturing Agility via Scrum at a large Dutch bank. https://www.scrum.org/resources/ing-capturing-agility-scrum-large-dutch-bank, 2012.

21

Schwaber, K., Sutherland, J. The Scrum Guide. http://www.scrumguides.org, 2017.

22

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

23

Здесь и далее прогноз понимается как рациональное предсказание. – Прим. пер.

24

Цитата из «Аджайл-манифеста». http://agilemanifesto.org/.

25

Cockburn, A. Agile Software Development. Addison-Wesley, 2002.

26

Дэниел Пинк. Драйв. Что на самом деле нас мотивирует. – М.: Альпина Паблишер, 2013.

27

Лисса Адкинс. Коучинг agile-команд. – М.: МИФ, 2017.

28

Beck, K. Extreme Programming Explained – Embrace Change. Addison-Wesley, 2000.

29

См. подробнее на http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/.

30

Schwaber, K. SCRUM Software Development Process, 1995.

31

Sutherland, J. Business Object Design and Implementation Workshop, 1995. http://www.jeffsutherland.org/oopsla/schwaber.html.

32

См. раздел 4.2.

33

См. раздел 4.3.

34

Талеб Н. Черный лебедь: Под знаком непредсказуемости. – М.: Азбука-Аттикус, КоЛибри, 2018.

35

Kotter, J., Rathgeber, H. Our Iceberg Is Melting, Changing and Succeeding Under Any Conditions. MacMillan, 2006.

36

Сокращенно от Evidence-Based Managing of Software – научно обоснованное управление софтом.

Content

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

Рекомендуем книги по теме

Предисловие Кена Швабера

Предисловие

Глава 1 Аджайловая парадигма

1.1. МЕНЯТЬСЯ ИЛИ НЕ МЕНЯТЬСЯ

1.2. ПРОИСХОЖДЕНИЕ АДЖАЙЛА

1.3. ОПРЕДЕЛЕНИЕ АДЖАЙЛА

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

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

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

1.4. ИТЕРАТИВНО-ИНКРЕМЕНТАЛЬНЫЙ КОНТИНУУМ

1.5. ГИБКОСТЬ НЕЛЬЗЯ СПЛАНИРОВАТЬ

1.6. СОЧЕТАНИЕ АДЖАЙЛА И БЕРЕЖЛИВОГО ПРОИЗВОДСТВА

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

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

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

Глава 2 Скрам

2.1. ДОМ СКРАМА

2.2. СКРАМ, ЧТО В ИМЕНИ ТВОЕМ?

2.3. ЧТО Я ТАМ ВИЖУ – ГОРИЛЛУ?

2.4. ФРЕЙМВОРК, А НЕ МЕТОДОЛОГИЯ

2.5. КАК ИГРАТЬ

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

2.5.2. Время

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

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

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

2.6. ОСНОВНЫЕ ПРИНЦИПЫ СКРАМА

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

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

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

2.7. ЦЕННОСТИ СКРАМА

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

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

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

2.7.4. Уважение

2.7.5. Смелость

Глава 3 Тактики достижения цели

3.1. ВИЗУАЛИЗАЦИЯ ПРОДВИЖЕНИЯ В РАБОТЕ

3.2. ВОПРОСЫ ЕЖЕДНЕВНОГО СКРАМА

3.3. УТОЧНЕНИЕ БЭКЛОГА ПРОДУКТА

3.4. ПОЛЬЗОВАТЕЛЬСКИЕ ИСТОРИИ

3.5. ПОКЕР ПЛАНИРОВАНИЯ

3.6. ДЛИНА СПРИНТА

3.7. КАК МАСШТАБИРОВАТЬ СКРАМ

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

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

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

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

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

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

4.3. ПРИНЯТИЕ СКРАМА ТОП-МЕНЕДЖМЕНТОМ

Словарь

Об авторе

Сноски