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

скачать книгу бесплатно

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

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

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

Для кого

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

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

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

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

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

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

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

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

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

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

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

© Gunther Verheyen & Van Haren Publishing, 2019

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

* * *

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

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

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

Скрам: Гибкое управление продуктом и бизнесом (http://litres.ru/pages/biblio_book/?art=45001832)

Кен Швабер

Agile: Оценка и планирование проектов (http://litres.ru/pages/biblio_book/?art=30810025)

Майк Кон

Канбан Метод: Улучшение системы управления (http://litres.ru/pages/biblio_book/?art=56904516)

Майк Барроуз

Agile-менеджмент: Лидерство и управление командами (http://litres.ru/pages/biblio_book/?art=35478823)

Юрген Аппело

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

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

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

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

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

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 1

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

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

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

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

Серьезные недостатки этой парадигмы уже известны и тщательно описаны. В частности, Отчет о состоянии ИТ-проектов от Standish Group[2 - Standish, 2011; Standish, 2013.] раз за разом выявляет низкий уровень успешности традиционной разработки ПО. Количество проблем и ошибок в ПО, которое разрабатывали традиционным способом, превышало все возможные пределы. Столь обескураживающие результаты повлияли на ожидания от разработки в целом. Считалось нормальным, что только 10–20 % проектов успешны. Успех в индустриальной парадигме определяется выполнением трех требований: в заданное время, в рамках бюджета и в запланированном объеме. Хотя можно спорить с этими критериями успеха, это то, что нам обещает индустриальная парадигма. Стало общепринятым, что качество остается низким и более половины функциональности софта[3 - Эти цифры являются предметом дискуссии, см., например https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used (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/ (https://scrumcrazy.wordpress.com/2015/08/06/a-response-%E2%80%8Bto-mike-cohns-comments-on-64-of-software-features-rarely-or-never-used/). В моей личной практике бывали примеры создания вовсе не нужного софта. – Прим. пер.] никогда не используется[4 - Standish, 2002; Standish, 2013.].

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

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

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

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

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

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

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

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

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

Существует огромное количество доказательств того, что старая парадигма не работает. Но раньше доказательства преимуществ аджайла были единичными историями. Отчет о состоянии ИТ-проектов[5 - Chaos Manifesto (The Laws of Chaos and the Chaos 100 Best PM Practices). The Standish Group International, 2011.] в 2011 году, подготовленный Standish Group, – это поворотная точка. Он впервые продемонстрировал однозначные результаты исследований, которые были подтверждены во всех последующих отчетах. Было проведено масштабное исследование/сравнение традиционных проектов с проектами, которые использовали гибкие методы. Отчет показал, что гибкий подход к разработке софта дает значительно более высокие результаты даже в рамках традиционных ожиданий, когда софт должен быть поставлен в заявленные сроки, в рамках бюджета и во всем обещанном объеме функциональности. Отчет показал, что аджайловые проекты были в три раза более успешными, а провальных аджайловых проектов было в три раза меньше, чем традиционных. Для больших проектов, однако, разница в степени успешности была не такой явной, что может быть связано с неправильными ожиданиями, т. е. с комбинацией время + бюджет + объем. Ясно, что при правильно сформированных ожиданиях с фокусом на активном сотрудничестве с заказчиком и частой поставке ценности новая парадигма будет работать еще лучше, преодолевая проблему объема за счет частой поставки срезов ценности.

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

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

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

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

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

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

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

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