Использовать Scrum можно, когда это необходимо, например когда у вас есть безотлагательная возможность или очень важный проект. Эта глава поможет понять, как начать это делать немедленно, без суеты и затрат. Вы научитесь получать ценность каждые 30 дней.

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

В течение предыдущих 20 лет многие Scrum-проекты проходили внизу организации, скрытые от взгляда. Команда, работающая над проектом, пробовала применить Scrum и создавала впечатляющие результаты. Затем другая команда пробовала его, и скоро команды внутри организации начинали разрабатывать программное обеспечение быстрее и чаще. Довольно скоро Scrum-проекты стали проявляться повсюду в организации. Мы называем такой Scrum PRN.

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

Затраты на 30-дневный спринт могут варьироваться от 50 до 150 тысяч долларов в зависимости от размера Scrum-команды, заработной платы ее членов и других факторов. Каковы же преимущества метода?

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

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

Перепланирование. Инвестиции могут быть переоценены и изменены для каждого спринта. Это называется планирование «точно в срок». Так как изменения предполагаются, перепланирование делается, чтобы приспособить их. Время, потраченное на планирование того, что может никогда не быть реализовано, полностью исключается.

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

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

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

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

Когда требования трансформируются в инкременты функционала. проявляется тенденция. Например, в начале первого спринта команда разработки оценила размер требований в 140 единиц работы. Она представила 20 единиц работы в спринте № 1, 40 единиц – в спринте № 2 и 40 единиц – в спринте № 3. Это может быть прослежено при помощи диаграмм сгорания задач, измеряющих требования в единицах работы, которую еще предстоит сделать. Оставшаяся работа вычисляется в конце каждого спринта. Она равна единицам работы, прогнозируемой в начале спринта, за вычетом единиц законченной работы, которая была переведена в инкремент к концу спринта. Как выглядит диаграмма сгорания задач для примерного проекта, показано на рис. 6.1.

Рис. 6.1. Пример диаграммы сгорания задач

Это дает представление о прогрессе, достигнутом в направлении, когда вся работа будет закончена.

Чтобы прогнозировать будущее, можно использовать средние значения прошедших спринтов. В первых трех средняя единица законченных требований была 33,3 со стандартным отклонением 11,5. Прогнозная линия строится, как показано на рис. 6.2.

Рис. 6.2. Пример прогноза

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

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

Рис. 6.3. Реальная и предполагаемая диграммы сгорания задач

Так получилось, потому что было найдено и добавлено в бэклог столько же новой работы, сколько команда разработки закончила.

Чтобы сохранить тренд снижения диаграммы сгорания, вычисляется новая конечная базовая линия: [(начальная базовая линия + дополнительные единицы работы над новыми требованиями) – (законченные единицы работы над требованиями) = новая конечная базовая линия]. Эта новая конечная базовая линия показана на рис. 6.4. Она помогает нам спрогнозировать, что проект, скорее всего, будет закончен гораздо позднее, чем ранее предположенный конец четвертого спринта.

Рис. 6.4. Конечная базовая линия отражает бэклог продукта

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

The Standish Group оценила, что 50 % всех функций программного обеспечения очень редко или никогда не используются пользователями. К примеру, 80 % пользователей применяют только 14 % функционала массивного сайта .

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

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

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

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

Организации, которые применяют Scrum, имеют тенденцию к использованию 30-дневных спринтов, но Scrum также позволяет более короткие спринты наравне со спринтом в один месяц. Более длинные спринты хороши для более стабильных ситуаций, а более короткие – для более сложных и требовательных.

Рис. 6.5. Переменные, влияющие на длину спринта

Лучшая длина спринта для вашего проекта определяется после оценки следующего (рис. 6.5):

• перерасходы на короткие спринты;

• увеличение гибкости и контроля;

• длина спринта.

Спринт никогда не должен превышать один месяц.

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

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

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

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

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

5. Предоставление обучающего опыта. Люди любят быть успешными. Когда они учатся ездить на велосипеде, кататься на коньках или лыжах, то для начала делают короткие попытки. Неудача может быть оценена и внесены изменения. Затем они пробуют снова. Короткие спринты способствуют обучению.

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

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

Два двухнедельных спринта стоят больше, чем один 30-дневный. Будет в два раза больше мероприятий по планированию спринта, обзору спринта и ретроспективе спринта. Scrum-команда должна будет формулировать новый дизайн в два раза чаще. Естественные процессы разгона и спада скорости во время спринта будут и происходить в два раза чаще.

Цена, которую приходится платить за более короткие спринты, – увеличение времени, необходимого для планирования и разбора. Вы можете сами выбирать, хотите ли вы платить за дополнительную страховку. Таблица 6.1 показывает, какое примерно время необходимо на спринты разной длины. В примере время на проведение мероприятий спринтов разной длины приведено к эквиваленту 30-дневного спринта. Стоимость мероприятий спринта, таких как планирование спринта, обзор спринта и ретроспектива спринта, принята одинаковой. Стоимость Scrum-команды, о которой идет речь в примере, составляет 200 тысяч долларов за тридцатидневный спринт.

Таблица 6.1. Стоимость коротких спринтов

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

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

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

1. Заинтересованные лица теряют внимание и забывают о проекте.

2. Так как количество требований увеличивается, общая сложность возрастает, и процесс разработки перестает быть линейным. Чтобы управлять увеличившейся сложностью и помнить предыдущие решения, команде разработки требуется вести больше документации и средств проектирования.

3. Объем информации для обзора и изучения, а затем для принятия решений разрушает эффективность коротких Scrum-мероприятий.

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

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

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

В Fidelity Investments применили Scrum в 1997 году, чтобы предоставлять интернет-услуги для своих пользователей. Чарльз Шваб и клиенты E-Trade уже управляли своим капиталом онлайн, а пользователи Fidelity – еще нет. В то время Fidelity представляла собой жесткую каскадную организацию. Многочисленные попытки по предоставлению интернет-услуг заканчивались неудачей. В отчаянии компания обратилась к Scrum. За несколько месяцев первый вариант сайта был разработан и запущен, и в течение 18 месяцев инвесторы были счастливы работать с , который стал не хуже решений конкурентов. Успех был достигнут, и Scrum выведен из оборота компании. Следующие семь раз, когда Fidelity критически нуждалась в разработке программного обеспечения, она создавала Scrum-проекты. Однако компания не воспользовалась всеми преимуществами, которые могла бы получить, приняв во внимание предыдущий опыт. Каждый Scrum-проект мог быть более эффективным, чем предыдущий. Тем не менее Fidelity сделала выбор – использовать Scrum только в чрезвычайных ситуациях, PRN.