Продукт 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 % разработчиков. Уровень дефектов уменьшился значительно, и практически ни один продукт не был выпущен с «отложенными» дефектами. Удовлетворение пользователей заметно возросло.
Adobe опробовал Scrum, потому что испытывал проблемы, которые только усугублялись. Благодаря настойчивости, обучению и согласованности усилий многие проблемы были решены, и релизы программного обеспечения стали занимать меньше времени, а качество улучшилось.
Происхождение грехаДавайте рассмотрим типичный проект. Перед запуском проекта команда разработки сделала оценку, что бэклог продукта содержит 80 единиц работы над требованиями. Вы надеетесь выпустить это программное обеспечение после десяти спринтов длиной в один месяц. По привычке команда разработки делит 80 на 10 и сообщает, что будет выполнять по восемь единиц работы над требованиями за один спринт, причем станет выбирать восемь единиц работы для каждого месячного спринта, независимо от того, какое качество ожидается и сколько работы придется пропустить, чтобы все сделать вовремя.
В предиктивных проектах по разработке программного обеспечения организация оценивает требования и намечает дату выпуска и стоимость, затем следует обеспечить соответствие реальности планам. В Scrum-проектах команда разработки поставляет столько инкрементов функционала, сколько сможет, с учетом продуктовых приоритетов. И вы можете управлять этим процессом путем приоритезации потребностей, и каждый инкремент продукта будет работоспособен и будет соответствовать необходимому уровню качества.
Качество традиционно было переменной в сфере разработки программного обеспечения. Системы заканчивались с минимальной просрочкой срока выпуска, если качество понижалось. Однако ухудшение качества на самом деле снижает продуктивность, увеличивает стоимость и становится причиной еще больших просрочек. Команды отягощаются дополнительной работой по исправлению обнаруженных дефектов и ошибок, с той только разницей, что причина задержки и увеличение стоимости становятся невидимыми для вас. Сегодня качество перестает быть переменной.
Продолжаем наш пример. Вы ожидаете, что к концу десятого месяца сможете использовать весь функционал программного обеспечения. Однако в конце концов узнаете, что накопилось 48 единиц недоделанной работы, и вас это, конечно, не радует. Что делать? Просить разработчиков закончить недоделанные задачи, чтобы увеличить процент законченного для каждой строчки бэклога продукта как можно быстрее? Но мы ошибаемся, если требуем закончить работу как можно быстрее. Обычно на это уходит еще шесть месячных спринтов (48 единиц, деленные на предполагаемую скорость восемь единиц). Оставшаяся несделанная работа отражена на рис. 7.9 как пробел между работой, которая была заявлена как законченная, и аккумулированной незавершенной работой.
Качество традиционно было переменной в сфере разработки программного обеспечения. Системы заканчивались с минимальной просрочкой срока выпуска, если качество понижалось. Однако ухудшение качества на самом деле снижает продуктивность, увеличивает стоимость и становится причиной еще больших просрочек. Команды отягощаются дополнительной работой по исправлению обнаруженных дефектов и ошибок, с той только разницей, что причина задержки и увеличение стоимости становятся невидимыми для вас. Сегодня качество перестает быть переменной.
Продолжаем наш пример. Вы ожидаете, что к концу десятого месяца сможете использовать весь функционал программного обеспечения. Однако в конце концов узнаете, что накопилось 48 единиц недоделанной работы, и вас это, конечно, не радует. Что делать? Просить разработчиков закончить недоделанные задачи, чтобы увеличить процент законченного для каждой строчки бэклога продукта как можно быстрее? Но мы ошибаемся, если требуем закончить работу как можно быстрее. Обычно на это уходит еще шесть месячных спринтов (48 единиц, деленные на предполагаемую скорость восемь единиц). Оставшаяся несделанная работа отражена на рис. 7.9 как пробел между работой, которая была заявлена как законченная, и аккумулированной незавершенной работой.
Рис. 7.9. Накопление технического долга по мере выполнения работы
В конечном счете команда разработки завершает часть недоделанных задач, и менеджмент признает, что продукт начинает работать. Однако вскоре пользователи принимаются жаловаться, что продукт не соответствует их ожиданиям. С этого момента незаконченная работа замораживается. Это технический долг, который ограничивает людей в эффективном использовании продукта. Начинаются звонков клиентов в службу поддержки и исправление ошибок, которое съедает наше внимание и прибыль. Хуже всего, что это может заставить пользователей искать лучшие альтернативы. Мы не получаем выгоды, которых ожидали. Технический долг прогрессивно уменьшает долговечность продукта, его предполагаемый жизненный цикл.
Предположим, команда разработки состоит из трех программистов и двух инженеров по качеству. Они применяют традиционные, предиктивные, методы. У них имеется контроль качества, чтобы посмотреть, все ли работает. Любые ошибки или дефекты обнаруживаются и возвращаются программистам на исправление. Пока это происходит, другие программисты могут написать много нового программного обеспечения поверх дефектного. Усилия по устранению изначальной проблемы теперь занимают больше времени, а усилия по исправлению сборок программного обеспечения еще больше увеличивают эти временные затраты. Очень важно обнаруживать и исправлять проблемы, как только они появляются. Затем разработчики могут продолжить без усложнения проблемы и отложенных проблем при сборке.