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

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

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

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

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

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