Мое путешествие стартовало в 2003 году: мой путь к бизнес-гибкости начался c экстремального программирования и скрама. Этот путь был сложным, но по-другому быть и не могло. За время моего путешествия я использовал скрам со множеством команд, на разнообразных проектах, в разных организациях. Я работал в больших и маленьких организациях и тренировал как команды, так и высшее руководство. Я написал первое издание этой книги. Мне посчастливилось сотрудничать с Кеном Швабером, одним из создателей скрама в Scrum.org.
Кто бы мог предположить, что спустя пять лет после почти случайного создания первого издания в 2013 году возникнет потребность во втором издании моей книги?
Я помню, как описал ценности скрама в первом издании, а в июле 2016 года они были добавлены в «Руководство по скраму». Я охарактеризовал традиционные три вопроса как хорошую, но необязательную практику, которую можно использовать на ежедневном скраме, и это тоже было добавлено к руководству в ноябре 2017 года.
Однако с 2013 года возникло еще больше вызовов и они стали еще более сложными. Баланс форм труда в обществе продолжает быстро сдвигаться от индустриальных (часто физических) к цифровым (часто виртуальным). Во многих отраслях непредсказуемость в сфере труда продолжает увеличиваться. Индустриальная парадигма становится бесполезной. Сейчас, более чем когда-либо, необходимы гибкая парадигма и основательный фреймворк, который помогает людям и организациям увеличивать бизнес-гибкость для сложной работы в непредсказуемых обстоятельствах.
Скрам – это простой фреймворк, который помогает отвечать на комплексные вызовы, а не только способ создания сложных софтверных продуктов. Все больше людей хотят понять, как применять скрам в областях, которые находятся за пределами разработки софта. Организации перестраивают свои структуры и бизнес-процессы для применения скрама и пытаются четко понимать его правила. Это требует более общего рассказа о скраме, других слов, других углов зрения на его правила. Сейчас идет третья волна скрама, и, если вы хотите ее поймать, эта книга вам поможет. Это, второе, издание рассказывает об основах скрама, чтобы вы смогли научиться его использовать.
Я благодарю Кена Швабера за предисловие и рецензирование первого издания, так же как и других рецензентов: Дэвида Старра, Патрисию Конг и Ральфа Джохама – за обратную связь по первому изданию. Я очень признателен Блейк МакМиллан и Доминик Максимини за рецензирование второго издания. Я благодарю всех переводчиков за их труды по распространению моей книги на разных языках.
Я благодарю издательство Van Haren Publishing и в особенности Иво ван Харрена за то, что мне был дан шанс рассказать о своем ви́дении скрама в этой книге.
Наслаждайтесь чтением и… продолжайте скрамить.
Глава 1
Аджайловая парадигма
1.1. МЕНЯТЬСЯ ИЛИ НЕ МЕНЯТЬСЯ
В индустрии разработки ПО долгое время доминировала парадигма индустриальных взглядов (рис. 1.1). Фактически она была калькой со старых добрых промышленных практик и теорий. Важной частью фундамента этих практик было тейлористское убеждение[1] о том, что «рабочим» нельзя доверять осмысленную и креативную работу. От них можно ждать выполнения только механических задач. Вся их работа должна быть подготовлена, спроектирована и спланирована более старшими по иерархии сотрудниками. Более того, старшие должны неусыпно надзирать за исполнением этих тщательно подготовленных задач.
Качество работы в индустриальной парадигме удостоверяется приемкой хороших и отбраковыванием плохих партий изделий. Денежное вознаграждение используется, чтобы стимулировать желаемое поведение. Нежелательное поведение наказывается. Используются старые добрые стратегии кнута и пряника.
Серьезные недостатки этой парадигмы уже известны и тщательно описаны. В частности, Отчет о состоянии ИТ-проектов от Standish Group[2] раз за разом выявляет низкий уровень успешности традиционной разработки ПО. Количество проблем и ошибок в ПО, которое разрабатывали традиционным способом, превышало все возможные пределы. Столь обескураживающие результаты повлияли на ожидания от разработки в целом. Считалось нормальным, что только 10–20 % проектов успешны. Успех в индустриальной парадигме определяется выполнением трех требований: в заданное время, в рамках бюджета и в запланированном объеме. Хотя можно спорить с этими критериями успеха, это то, что нам обещает индустриальная парадигма. Стало общепринятым, что качество остается низким и более половины функциональности софта[3] никогда не используется[4].
1
Фредерик Тейлор (1856–1915) – американский инженер, который известен прежде всего исследованиями в области оптимизации производительности, эффективности и стоимости труда. Он пропагандировал внедрение стандартизации и применение системных методов и практик. Контроль выполнялся исключительно менеджментом, тогда как рабочие, по его мнению, могли выполнять только непосредственно свою работу. –
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/. В моей личной практике бывали примеры создания вовсе не нужного софта. –