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

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

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

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

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

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

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

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1. Меняться или не меняться

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

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

Серьезные недостатки этой парадигмы уже известны и тщательно описаны. В частности, Отчет о состоянии ИТ-проектов от Standish Group2раз за разом выявляет низкий уровень успешности традиционной разработки ПО. Количество проблем и ошибок в ПО, которое разрабатывали традиционным способом, превышало все возможные пределы. Столь обескураживающие результаты повлияли на ожидания от разработки в целом. Считалось нормальным, что только 10–20% проектов успешны. Успех в индустриальной парадигме о…