Таблица 7.3
Третья колонка, названная «Сделано», содержит единицы работы, которые им требуется выполнить, чтобы создать полностью законченные, прозрачные инкременты функционала по каждому пункту из первой колонки. Общая сумма работы для создания прозрачных инкрементов составляет 171 единицу. Большинство разработчиков привыкли заканчивать только 71 из этих единиц работы, когда они переходят на эмпирические Scrum-проекты, как это показано в колонке «Обычно». Они привыкли оставлять на потом 100 единиц работы в каждом фрагменте функционала, который они создают. спринт за спринтом, эта незаконченная работа накапливается по экспоненте до самого конца проекта.
Перед тем как вы начнете ваш первый спринт, попросите Scrum-мастера и команду разработки оценить табл. 7.3. Пусть они сделают новую таблицу в соответствии с тем типом программного обеспечения, которое вы создаете. Затем попросите их, до того как вы начнете первый спринт, обдумать, как они планируют закончить все работы. Чтобы увидеть, все ли они сделали, как надо, попросите у них один или несколько инкрементов для начала использования по назначению в конце любого спринта. Если они скажут, что это невозможно, или вы попробуете сами, но инкремент не работает как надо, значит, команде разработки требуется больше обучения или практики.
Компания Adobe и технический долг
Продукт Adobe Premiere Pro – ведущий в отрасли набор программного обеспечения для нелинейного видеомонтажа. Программы канала BBC и The Tonight Show («Сегодня вечером») создаются с его помощью. Вице-президент подразделения Стив Уорнер управлял Premiere Pro. Питер Грин был программным менеджером пакета Creative Suite в его составе. Развивающиеся стандарты и запросы на новые возможности требовали от них очень быстрого выпуска новых релизов.
Premiere Pro CS3 (Creative Suite, версия 3.0) был выпущен в июле 2007-го. Для его создания были использованы традиционные методы, и программное обеспечение поставлялось одним большим фрагментом после 18 месяцев разработки. Когда дата выпуска стала приближаться, разработчики начали собирать CS3 к релизу. Было очень много «стучащих труб» (то есть дефектов или ошибок). Разработчики не располагали достаточным количеством времени, чтобы их все исправить, поэтому собрали релиз так, как смогли в эти временные рамки, и выпустили его. Вот какие комментарии оставляли пользователи о CS3:
«Если вы хотите легкую в использовании, дружелюбную по отношению к пользователю программу для редактирования видео, это точно не она. Были вещи, которые я от нее ждал, а она их не делает. Или я не смог их запустить»
[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 % разработчиков. Уровень дефектов уменьшился значительно, и практически ни один продукт не был выпущен с «отложенными» дефектами. Удовлетворение пользователей заметно возросло.
