Джефф Сазерленд - Софт за 30 дней. Как 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 как пробел между работой, которая была заявлена как законченная, и аккумулированной незавершенной работой.

Рис. 7.9. Накопление технического долга по мере выполнения работы

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

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

Технический долг затуманивает прозрачность и делает решения сомнительными. Мы измеряем наш прогресс путем сравнения законченных, готовых к использованию фрагментов функциональных возможностей программного обеспечения с оставшимися необходимыми фрагментами. Мы не берем в расчет незаконченную работу. Тем не менее очень много разработчиков программного обеспечения производят незаконченные инкременты. Обычно, когда членов команды спрашивают, почему они частично закончили некоторое количество требований бэклога продукта, вместо того чтобы выбрать меньшее количество и закончить полностью, они говорят: «У нас не было времени». Мы должны обратиться к нашему Scrum-мастеру, чтобы убедиться, что такого не произойдет.