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

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) и другие.

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