Рис. 2.1. Одна итерация производит один прозрачный инкремент
В конце каждой итерации мы можем указать команде разработки другое направление, отличное от того, что задумывалось ранее. На самом деле, вероятность этого высока. Изначально у нас есть всего лишь видение или преимущество, которым мы хотим воспользоваться. Команда разработки создает для нас приложение, содержащее только важнейшие аспекты будущего продукта. Мы смотрим на приложение, а затем начинаем думать, как его использовать, что надо добавить к инкременту, чтобы сделать его более удобным. В некоторых областях это требует внесения корректировок в середине разработки, так случается с каждой итерацией.
Каждый разработанный нами инкремент побуждает нас обдумывать более творческие либо более конкретные пути реализации идей и видения. Это заставляет нас начать диалог с командой разработки: мы можем совместно искать пути и изменения, позволяющие добиться наилучшего результата от следующей итерации.
Мы можем обнаружить, что наша идея нереалистична: отсутствует необходимая технология, или нам не нравятся результаты, или мы обнаруживаем, что цена будет слишком высокой. В зависимости от наших выводов мы можем остановиться на этом этапе и больше не тратить деньги, пока не найдем более реалистичное решение. Успешные проекты – те, на которые деньги не тратятся напрасно.
Иногда одной итерации достаточно, чтобы разработать то, чем уже можно пользоваться, пока мы направляем команду разработчиков развивать более широкий функционал. Мы можем встраивать больше производительности и функционала итерация за итерацией, так как у нас есть преимущество более полного использования. Каждый инкремент накладывается на предыдущие. Когда результат работы команды разработки признается правильным, мы выпускаем релиз программного обеспечения, и им начинают пользоваться. Рисунок 2.2 иллюстрирует несколько итераций.
Рис. 2.2. Несколько итераций создают инкремент дополнительной функциональности
Мы придумали эмпирический процесс разработки программного обеспечения и выбираем, что делать дальше в конце каждой итерации, держа в уме нашу цель и рассматривая, что уже было разработано. Мы можем экстраполировать вероятную стоимость и срок поставки продукта, чтобы решить, хотим ли мы продолжать. Мы называем это итеративно-инкрементальным процессом, и это основа Scrum. Мы описали, как это работает и почему это может называться «программное обеспечение за 30 дней». Теперь давайте посмотрим, решает ли данный процесс проблемы, которые мы нашли в каскадном, или предиктивном, процессе.
Решает ли наше эмпирическое решение проблемы каскадного метода? Давайте оценим новый процесс в болевых точках, обнаруженных в каскадном методе.
Проблема 1 каскадного процесса: выпуск продукта занимает все больше и больше времени. Наши релизы будут состоять из множества объединенных инкрементов, разработанных последовательно, итерация за итерацией. Мы можем остановить итерации, когда захотим. Например, когда ценность продукта окажется максимальной, особенно если учесть, что более половины функционала программного обеспечения используется редко или никогда. Мы также можем остановиться и выпустить продукт, когда достигнута дата релиза или исчерпан бюджет. Мы накопили самые ценные инкременты в конечном результате.
Проблема 2 каскадного процесса: срыв графиков релизов. Наш график разработки не может сдвинуться более чем на 30 дней, так как это максимальная длительность одной итерации. Мы выпускаем накопленные инкременты, когда достигаем даты релиза. Мы не выделяем итераций для построения малозначительного функционала, что позволяет выпускать законченную систему гораздо раньше, чем обычно. При использовании традиционного метода разработки программного обеспечения только менее 50 % функционала используется часто. Мы не разрабатываем этот функционал.
Проблема 3 каскадного процесса: создание стабильной версии перед релизом занимает все больше и больше времени. Каждая итерация производит законченный, готовый к работе прирост функционала. Каждый последующий инкремент интегрируется с инкрементами всех предыдущих итераций, он также полностью завершен и готов к использованию. Перед релизом не требуется дополнительной работы по стабилизации, так как эта работа уже была выполнена.