Знание – это результат опыта. В традиционных подходах к управлению проектами все решения принимаются в самом начале. Я всегда недоумевала: ведь мы начинаем всерьез разбираться в проекте только под конец! Скрам подталкивает команды выдавать результаты как можно быстрее, поэтому быстрее расширяются и знания исполнителей относительно требований по проекту и технологий, а в работе команды появляется (и усиливается) динамика. Чем раньше команда начнет работу, тем лучше. Когда команда накапливает достаточно знаний, исполнители могут принимать более правильные и взвешенные решения. Обычно скрам-команды откладывают решения по вопросам меньшей важности на более позднее время – требования в их технологическом окружении все равно постоянно меняются.

Скрам, как табурет, стоит на четырех «ножках»: приоритезированный бэклог; выделенная кросс-функциональная команда, тайм-боксы и, наконец, инспекция и адаптация. Эти четыре «ножки» и создают структуру, позволяющую нам называть скрам эмпирическим процессом. Когда «табурет» теряет одну из опор, он лишается равновесия (попробуйте-ка усидеть на табурете с тремя ножками). Даже если одна из «ножек» всего лишь короче других, табурет становится неустойчивым и неудобным. То же относится и к скраму: как только какой-то элемент структуры ослабевает, ослабевает и команда, проект идет наперекосяк, эксперимент становится неубедительным, поскольку утрачиваются точки контроля. Скажем, если скрам-мастер по какой-то причине допускает прерывание спринта, команда может и не довести дело до логического завершения. Все вынуждены остановиться и начать все сначала – это мы и называем хаосом. То же самое происходит, если владелец продукта неаккуратно ведет бэклог, где идеи не ранжированы по приоритетности: в этом случае команда может передать потребителю необходимую функциональность, а может и не передать. Даже небольшое нарушение этих основополагающих принципов может вызвать эффект схода лавины. Если же команда твердо придерживается вышеизложенных принципов скрама, то с наибольшей вероятностью достигнет цели.

Кен Швабер и Джефф Сазерленд создали эти четыре «ножки стула», или принципа скрама, для того, чтобы посредством эмпирического процесса контролировать проекты по разработке программного обеспечения. Впрочем, этот метод годится, пожалуй, для проектов любого характера. Скрам представляет собой особый (имеющий доказательную базу) способ продвижения проекта или инициативы. Без определенных временных рамок для получения обратной связи по фрагментам функциональности (как при «водопадном» управлении проектом) команда, менеджмент и потребители не имеют никакого представления, что за продукт вообще создается. Вспомните обычное совещание по ходу работы над проектом при традиционной модели. Нравились они вам? Лично меня пугали. Как правило, я представляла доклад о статусе исполнения проекта с многочисленными красными, зелеными и желтыми точками на нем, зачитывала какие-то цифры, какие-то проценты («завершенность фазы») и иногда приводила список ближайших рисков. Честно говоря, я, выполняя обязанности традиционного менеджера проекта, действовала так: если я не знала точно степень готовности проекта, то изображала на доске желтую точку, рассчитывая уточнить информацию позднее. Или, хуже того, перед совещанием я допоздна проводила несколько вечеров в офисе, стараясь придать диаграммам Ганта правдоподобность.

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