«Если вы хотите легкую в использовании, дружелюбную по отношению к пользователю программу для редактирования видео, это точно не она. Были вещи, которые я от нее ждал, а она их не делает. Или я не смог их запустить»[9].
«…это программное обеспечение – заведомо плохой код с большим количеством утечек памяти. Если вы попробуете перекодировать большой видеофайл в mpeg2, Premiere, скорее всего, выдаст ошибку из-за плохого управления памятью. Единственное решение – просто перезапустить систему и молиться, чтобы это опять не случилось»[10].
Следующий релиз, Premiere Pro CS4, должен был устранить дефекты CS3. CS4 должен был улучшить стабильность, скорость и легкость в использовании, а также остановить утечки памяти. Питер Грин услышал об этом и решил, что короткие циклы разработки позволят Adobe создать законченные инкременты общего продукта после каждого спринта. Затем инкременты будут складываться в нечто работающее, и это должно понравиться пользователям. Питер также хотел знать реальное положение дел в каждом спринте, поэтому поручил нескольким командам, работающим над CS4, попробовать Scrum.
У Adobe было более 100 девелоперов в 18 Scrum-командах, работающих над выпуском этого релиза. Все решили, что интегрирование всех инкрементов от всех 18 команд после каждого спринта будет слишком большой работой. Они решили подождать до даты, близкой к релизу, чтобы интегрировать все инкременты. Прямо перед выходом CS4 команды пытались соединить фрагменты своей индивидуальной работы в один объединенный продукт. Все противоречия и неразрешенные зависимости, которые препятствовали интеграции, выявились в виде ошибок, и фрагменты CS4 не работали вместе. Рисунок 7.8 показывает медленное увеличение в течение разработки до попытки интеграции и затем резкий скачок в количестве дефектов. Разработчики героически исправляли максимум возможного, но все-таки им пришлось выпустить продукт с заметными дефектами. Имена разработчиков, которые были госпитализированы по причине стресса и переработки в Adobe, стали легендой.
Рис. 7.8. Дефекты в Adobe CS4 и CS5
CS4 был выпущен в сентябре 2008 года и вызвал критические обзоры и негативные отзывы пользователей. Adobe использовал Scrum, чтобы стать более продуктивным, однако более продуктивной стала только каждая отдельная команда. Работа всех команд не была интегрирована и не стала прозрачной. Потенциальные проблемы интеграции были отложены для краткосрочной продуктивности. Качество продукта, отзывы критиков индустрии, своевременный выпуск новых возможностей, удовлетворенность клиентов, моральный дух и здоровье сотрудников в результате пострадали. Что-то надо было менять.
Стив и Питер решили в работе над CS5 использовать Scrum как можно шире, а также обучить методу всех разработчиков и программных менеджеров. Новой задачей Питера было обучать и инструктировать команды, чтобы они могли создать качественное программное обеспечение после каждого спринта. Все инкременты всех команд интегрировались и тестировались после каждого спринта. Каждый спринт естественным образом производил продукт уровня релиза CS5. Рисунок 7.8 показывает, что дефекты никогда не выходили из-под контроля в течение всего процесса. Более того, ко всеобщему удивлению, разработчики закончили работу быстрее, чем было запланировано. Неожиданные дефекты и ошибки от интеграции инкрементов больше не замедляли их прогресс. В дополнительное время перед выпуском разработчики исправили часть проблем, оставшихся от релиза CS4. CS5 был выпущен в апреле 2010-го, обзоры и отзывы пользователей были на этот раз одобрительными.
Питера попросили разработать показатели, которые могли быть использованы для управления Scrum-разработкой в Adobe. Он отметил три таких показателя. На первом месте было удовлетворение сотрудников Scrum процессом во время работы над CS5 и их вера в то, что Scrum улучшил их методы разработки программного обеспечения. Adobe предложил 200 разработчикам из 25 команд ответить на 50 вопросов[11]. Результаты были проанализированы командами, и выявлены области, в которых требовались улучшения. Впечатляет, что 80 % разработчиков отметили, что продолжат использовать Scrum даже без распоряжения руководства. Среди наиболее производительных команд так ответили 100 % разработчиков. Уровень дефектов уменьшился значительно, и практически ни один продукт не был выпущен с «отложенными» дефектами. Удовлетворение пользователей заметно возросло.
