В феврале 2001 года семнадцать представителей нетрадиционных направлений программной инженерии сформулировали основные принципы так называемой «скорой» (agile) разработки в документе под названием Agile Manifesto. Среди авторов манифеста был Джеф Сазерленд, создатель самой первой agile-методологии Scrum. В настоящее время доктор Сазерленд, директор по технологиям компании PatientKeeper, активно продвигает свой метод, внедряя его в практику создания программных продуктов и обучая специалистов по управлению проектами Scrum.
В начале марта Сазерленд впервые приехал в Россию, чтобы провести в Санкт-Петебурге тренинг Certified ScrumMaster. Курс был организован компанией Exigen Services StarSoft, которая специализируется на услугах офшорной разработки программного обеспечения в России и Восточной Европе и применяет методику Scrum в своей практике. Сазерленд ответил на вопросы журнала «Открытые системы.СУБД».
Можно ли вкратце обрисовать, что такое Scrum?
Одна из проблем управления программными проектами состоит в том, что значительное число требований изменяется в процессе разработки. В традиционных подходах к разработке план создается в самом начале процесса, и команда старается реализовать этот план в заданное время и с заданным бюджетом. Однако недавнее исследование показало, что около 65% требований к программному продукту изменяется в ходе работы над ним. Это означает, что 65% созданных функций никогда не используется, они не востребованы заказчиками, а на разработку продукта уходит почти в два раза больше времени, чем нужно, и обходится она вдвое дороже.
В больших проектах с традиционными методами управления формируется специальный совет для контроля за изменениями, который, фактически, предназначен для того, чтобы помешать заказчикам получить то, что им действительно нужно. В центре внимания методики Scrum — обеспечение максимальной ценности для бизнеса заказчика. Заказчики активно вовлекаются в процесс инспектирования хода разработки, регулярно проверяют работающий код и имеют возможность менять требования по мере необходимости, так чтобы программный продукт реализовывал действительно нужные им функции. И когда заказчик понимает, что уже не осталось ничего, что надо сделать непременно, проект может завершиться.
Приведу пример. Одна компания выполняла проект по методу Scrum для строительной фирмы. По истечении трех месяцев с начала проекта выяснилось, что реализовано 15% запланированных задач, однако это была работа, обладавшая самым высоким приоритетом для бизнеса заказчика. Было реализовано не менее 80% наиболее ценных функций, и заказчик счел возможным завершить проект и пустить продукт в эксплуатацию. Контракт был составлен таким образом, чтобы заказчик мог остановить проект в любой момент, когда сочтет это нужным, заплатив 20% оставшейся стоимости. Общая сумма контракта составляла 10 млн. долл., заказчик заплатил 1,5 млн. плюс 20% оставшейся суммы, то есть чуть больше 3 млн. долл. вместо 10 млн., и получил готовую программную систему на год раньше. Вот что привлекает в Scrum.
Современные рыночные условия меняются быстро, заказчики становятся более требовательными, и для них особое значение приобретает возможность быстро получать качественный программный продукт. Практически все крупные мировые компании — Microsoft, Siemens, Oracle, SAP, Google, Yahoo и многие другие — сегодня в той или иной степени используют Scrum.
Scrum — простой процесс. Вначале так называемый «владелец продукта» — представитель заказчика или человек, который работает с заказчиком, — расставляет приоритеты в списке требований к программному продукту и передает этот список команде Scrum. Команда определяет, как много верхних элементов списка она в состоянии реализовать за 30 дней или меньше. Истоки Scrum лежат в принципах так называемого «экономного производства» (lean manufacturing), именно оттуда взят доказавший на практике свою эффективность принцип «вытягивания» требований. Для каждой очередной итерации команда «вытягивает» верхние элементы из списка приоритетов, разбивает полученный в результате список функций на список конкретных задач и начинает работать.
Scrum подразумевает ежедневные встречи команды, в которую входит семь плюс-минус два человека. На таких встречах каждый участник разработки отчитывается, что он сделал вчера, что должен сделать сегодня, какие проблемы у него возникли. В ходе общего сбора ищутся способы разрешения этих проблем. Как показывает опыт, такие ежедневные встречи способствуют продуктивности разработки.
Команда в Scrum работает на принципах самоорганизации: сама оценивает, какие функции из общего списка она в состоянии реализовать в тридцатидневный срок, и формирует соответствующий список работ, тем самым всегда стараясь выбрать наиболее быстрый способ построения приложения. Задача лидера команды — мастера Scrum — состоит в том, чтобы предоставить команде все возможности для реализации выбранных задач, но не диктовать, что должен делать каждый участник разработки. Директивный стиль управления, при котором менеджер определяет задачи членов команды, часто замедляет процесс, мешает людям самим выбирать, как выполнить работу наилучшим образом.
С помощью специальных диаграмм мастер Scrum анализирует ход итерации, оценивает объем оставшихся задач и определяет текущий статус работ. Минимальная отчетность позволяет руководителю команды постоянно отслеживать, что происходит в проекте, обеспечивает полную прозрачность процесса. В прошлом году в CIO Magazine были опубликованы результаты опроса американских ИТ-директоров, у которых поинтересовались, насколько они осведомлены о состоянии проектов в ходе их выполнения. Как правило, ИТ-руководитель знает, что проект начался и что он с опозданием, но завершился. Оказалось, что 96% ИТ-директоров ничего не знают о промежуточном состоянии проекта, то есть фактически движутся вслепую. В Scrum руководитель постоянно наблюдает за состоянием проекта.
И наконец, цель Scrum, как и других «скорых» процессов, — получить по завершении итерации работающую программу, которую владелец продукта может попробовать своими руками.
Scrum — первый подобный метод; он был разработан в 1993 году в компании Easel. С 2001 года мы реализуем сертификационную программу Certified ScrumMaster, количество участников которой удваивается ежегодно. Сейчас в мире насчитывается около 11 тыс. сертифицированных мастеров Scrum, а через год их будет уже 22 тыс. или даже больше.
Итак, Scrum существует с 1993 года. В 1996 году был представлен другой метод, eXtreme Programming (XP). В середине 90-х сложились условия для новых подходов к разработке?
Когда Кент Бек начал работу над XP в 1995 году, он написал мне письмо, попросив дать все материалы по Scrum, что я и сделал. В 1993 году было уже совершенно ясно, что большие проекты, содержащие миллионы строк кода, порождают огромное количество ошибок. Мы поняли, что необходима радикальная альтернатива существующему процессу разработки, в особенности для проектов, использующих объектные технологии. Моя команда в то время работала с языком Smalltalk, уже начал появляться интерес к Java. Мы видели, что стандартные методы управления программными проектами дают сбой, и начали вырабатывать свой стиль управления ими, который дал бы возможность воспользоваться преимуществами быстрой реализации программных систем. Время пришло для этого. И не случайно, что в создание принципов «скорых» методологий оказались вовлечены очень многие из сообщества разработчиков на SmallTalk.
Я был директором по технологиям в девяти компаниях, в четырех из них я пытался вывести принципы Scrum, в пятой Scrum был изобретен, а в остальных он уже применялся. Традиционные методы разработки сопровождались высокой частотой ошибок и постоянным запаздыванием проектов. При этом руководители до определенного момента вообще не видели, что разработка не выполняется в срок, а обнаружив это, впадали в панику, заставляя своих сотрудников работать во внеурочное время. В результате люди находились в постоянном стрессе и в конце концов были вынуждены бросать такую работу.
Моя цель была полностью изменить эту ситуацию, создать среду, в которой продуктивность разработчиков повысится не менее чем на порядок, и они смогут быстрее выдавать результат более высокого качества, получая при этом гораздо больше удовольствия от работы. И эта цель, без сомнения, была достигнута; не случайно сейчас мы наблюдаем очень быстрый рост популярности Scrum.
Вы сказали, что Scrum очень прост. Я читала, что ваш соавтор, Кен Швабер также отмечал это, но одновременно заметил, что реализовать Scrum очень сложно. Как вы это объясните?
В основе Scrum лежит механизм постоянного улучшения качества разрабатываемого продукта. Одна из основных обязанностей мастера Scrum — в работе с командой определять препятствия к успешному продвижению проекта вперед и удалять эти препятствия. В одной телекоммуникационной компании, с которой я работал, мастер Scrum показал мне список из 18 таких препятствий. Три из них были связаны с работой команды, остальные 15 были проблемами на уровне компании в целом, и чтобы справиться с ними, необходимо было работать с руководством, то есть фактически менять компанию. А это всегда тяжело. Как показывает практика, правильно реализованная методика Scrum позволяет добиться «эффекта Toyota» — четырехкратного повышения продуктивности работы и 12-кратного улучшения качества результата. Но чтобы достичь этого, необходимо ежедневно становиться лучше чем вчера, то есть меняться каждый день. Это для компаний всегда очень сложно. Scrum позволяет выявить все проблемы компании и расставить им приоритеты. Мастер Scrum работает с этим списком проблем, прикладывая усилия к тому, чтобы менеджмент исправлял ошибки в компании, а команда — ошибки в разработке. Это очень непростая работа.
Насколько методика Scrum универсальна? Есть ли условия, когда Scrum трудно или невозможно применить, например, в руководстве географически распределенными командами?
StarSoft — хороший пример большой, географически распределенной команды, успешно применяющей Scrum. Скажем, проект по созданию библиотечной системы, выполненный StarSoft совместно с американской компанией SirsiDynix, содержит более 1 млн. строк кода и полностью реализован в рамках Scrum. И уже есть примеры использования Scrum вне разработки программного обеспечения, скажем, для организации свадеб, для реализации каких-либо личных целей, в издательском деле — для управления оперативной деятельностью компаний, бизнес которых никак не связан с разработкой программных продуктов. Почему? Scrum вводит принципы «экономного производства», направленные на снижение издержек и повышение качества производственных процессов, то есть обеспечивает результативность ваших действий быстрее, лучше и дешевле.
Приведу пример одной датской компании, сертифицированной на соответствие уровню 5 модели CMMI. Они потратили семь лет на эту сертификацию. А потом реализовали Scrum. В ходе подготовки к оценке по CMMI число переделок программного обеспечения было сокращено на 80%, что действительно характеризует очень низкую частоту ошибок в проектах. А когда была введена методика Scrum, частота ошибок снизилась еще на 40%. Таким образом, один из лучших коллективов разработчиков в мире в течение нескольких месяцев, внедрив Scrum, добилась радикального улучшения качества своих программных продуктов. При этом их затраты на планирование снизились на 80%, а общие затраты на реализацию проекта — на 50%.
Многие компании считают модель CMMI эффективным способом совершенствования своих процессов и улучшения качества выпускаемого программного обеспечения. Могут ли организации комбинировать CMMI и Scrum? Какие преимущества это им даст?
Если компания ведет разработку по методу «водопада», то получение сертификации CMMI потребует от нее больших инвестиций. Датская компания, о которой я говорил, потратила семь лет и более сотни тысяч часов консалтинга на выстраивание процесса по CMMI. Чтобы продемонстрировать преимущества Scrum, нужен двухдневный курс и менее шести месяцев на организацию процесса. Я бы рекомендовал начинать с реализации Scrum и затем переходить к оценке процессов по модели CMMI. Думаю, затраты на сертификацию по CMMI при условии, что уже реализован Scrum, сократятся минимум вполовину. Если вам удалось реализовать полноценную среду Scrum, вы уже получите многое из модели CMMI. Эта модель вводит процесс, в котором каждый должен делать одно и то же одним и тем же способом. Реализовав Scrum, вы получите практически все, что нужно, для того чтобы соответствовать третьему уровню CMMI. Для перехода на уровень 4 или 5 вам понадобится дополнительные возможности по сбору данных, отчетности и т.д. В Scrum вы их реализуете с меньшими затратами, чем с применением традиционных методов управления проектами.
Оценка на соответствие модели CMMI верхних уровней, это, как правило, бизнес-решение, исходящее из желания получать заказы на проекты у определенных ведомств, в частности, оборонных. Если такое решение принимается, то реализовать модель CMMI, уже имея в наличии Scrum, будет дешевле, чем при отсутствии этой методики.
Насколько «скорые» методы влияют на современное сообщество разработки программного обеспечения?
В мире разработки происходит очень важная трансформация — разработчики все активнее принимают подобные методики. Если сертификация мастеров Scrum продолжится с той же скоростью до 2017 года, то через десять лет каждый разработчик в мире будет сертифицированным мастером Scrum. Так что нам надо просто продолжать делать то, что мы делаем.
Вы можете сравнить Scrum и XP?
В XP Кент Бек фокусируется на инженерных практиках, показывая, что необходимо делать в процессе разработки, чтобы создать высококачественный программный продукт. В центре внимания Scrum — организация процесса командной разработки: как мотивировать членов команды на решение конкретных задач, как добиваться их выполнения. Scrum — это руководство командой, XP — инженерные практики. Эти методики взаимодополняют друг друга. Более того, Scrum не может обеспечить достаточно высокую продуктивность команды без надлежащих принципов программной инженерии, и поэтому мы рекомендуем обращаться к XP. С другой стороны, трудно применять XP в масштабных проектах, если нет эффективного метода управления командой, такого, как в Scrum. Поэтому оба эти метода нуждаются друг в друге: XP делает Scrum высокопроизводительным, а Scrum позволяет расширять масштабы XP-проектов.
А какими качествами должны обладать люди, чтобы успешно вписаться в среду Scrum?
Scrum определяет три роли участников процесса — владелец продукта, мастер Scrum и команда. Команда Scrum помогает своим членам стать хорошими командными игроками. Традиционно у нас есть прекрасные разработчики, которые не в состоянии общаться с другими людьми. Но разработка стала настолько масштабной и сложной, что подобный изоляционизм уже не допустим. Нужны люди, умеющие работать в команде.
Scrum связан и с формированием иного типа лидера для руководства командой. Мастер Scrum — это не начальник, выдающий указания, а человек, который использует все свои возможности для содействия успешной разработке, который может руководить на своем примере, вдохновлять людей на работу, выступать в роли тренера, наставника. Scrum подразумевает, что команда сама в значительной степени определяет, как выполнить работу. Поэтому ей нужен именно такой лидер. Я бы сравнил разработку в Scrum с игрой хорошей спортивной команды. Ее капитан не говорит команде, что надо делать, а показывает на примере. А игроки должны уметь передавать мяч партнерам.
Не так давно у меня была возможность побеседовать с Кентом Беком. Он с сожалением отметил падение престижа профессии разработчика. Как вы можете прокомментировать эту точку зрения?
Пожалуй, я не соглашусь с Кентом. Конечно, мир разработки программного обеспечения изменился. Программные продукты сегодня ориентированы прежде всего на пользователя и в значительно большей степени определяются рынком. Пожалуй, так было всегда, однако только сейчас пришло осознание, что если не найти эффективные пути маркетинга программного обеспечения, успеха не добиться. В 80-е или в начале 90-х было много неудачных софтверных компаний, которые фокусировались на программной инженерии, но не умели продавать свои продукты. Сейчас разработчики стали гораздо чувствительней к требованиям рынка, знают, как строить маркетинговые планы, как продвигать программы на рынок, как продавать консалтинговые услуги по всему миру. И понимают, что это не менее важно, чем инженерные квалификации.
Меняется и роль разработчика. Если раньше герой-одиночка мог быть создателем великолепного продукта, то сегодня это слишком сложно для одного человека. Поэтому сейчас мы говорим не о выдающихся личностях разработчиков, а о выдающихся командах, подразумевая разные роли — программисты, тестировщики, разработчики технической документации, специалисты по маркетингу программных продуктов и т.д. Если раньше команда могла рассчитывать на гуру, который укажет ей правильный путь, то теперь подход к созданию программного обеспечения стал гораздо более сбалансированным.
Какие еще тенденции в разработке программного обеспечения вы видите?
В 90-х годах, когда я имел смелость заявить, что компания Toyota превзойдет в бизнесе General Motors, в США меня назвали непатриотичным. Я утверждал, что Toyota, благодаря эффективной организации своего производства, более продуктивна и обеспечивает более высокое качество продукции. А GM не способна меняться, чтобы как-то отреагировать на сложившуюся ситуацию. Что же мы наблюдаем сегодня? В GM всерьез рассматривают варианты слияния или продажи своего бизнеса, чтобы выжить. А Toyota не просто вырвалась в безусловные лидеры, но и настолько ускорилась, что ее невозможно остановить, ситуация для конкурентов все ухудшается и ухудшается. В среде разработки программного обеспечения происходит то же самое. Методы Scrum позволяют увеличить скорость разработки, обеспечить более высокое качество и выпускать продукты за половину стоимости. Это означает, что эпоха «водопадного» метода закончилась, он бесповоротно уходит в историю. Компании, которые базируют свои процессы на этом методе, в недалеком будущем будут выглядеть просто смешными. Это лишь дело времени возможно, понадобится пять, десять или двадцать лет. Но через двадцать лет каждая компания-разработчик должна будет применять тот или иной «скорый»метод, иначе ее просто не будет в бизнесе.
По моему мнению, главная трансформация, происходящая в разработке — это возможность видеть изменения. Сегодня лидером этого движения является Scrum. Вместе с XP на долю Scrum в мире приходится, по-видимому, не менее 80% проектов, ведущихся по «скорым» методикам. Думаю, мы являемся движущей силой революции в программной индустрии.
Какой инструментарий разработки оптимален для команд Scrum?
Есть инструментальные средства, которые прекрасно поддерживают задачи управления конфигурациями, автоматизированное тестирование, рефакторинг и другие аспекты инженерии. Есть немало инструментов для управления проектами, которые может использовать Scrum. Все они предоставляют те или иные полезные функции, но ни один не обеспечивает простой адекватной поддержки всех ролей в разработке, не предоставляет единый пользовательский интерфейс. Такой, например, как мы реализуем в компании PatientKeeper, где разрабатывается программное обеспечение для врачей с простым пользовательским интерфейсом для различных персональных устройств, смартфонов, КПК, посредством которого можно обратиться к любой нужной системе. А у разработчика сегодня для создания программного обеспечения есть несколько десятков систем, с которыми приходится работать, чтобы получить результат. Надеюсь, ситуация в конце концов изменится. Все производители инструментария задают мне вопрос, что нам нужно, и я стараюсь дать достаточно ясную картину, как должен эволюционировать инструментарий разработки.
Не так давно была завершена работа над Руководством к своду знаний по программной инженерии (e Guide to the Software Engineering Body of Knowledge, SWEBOK). Что Вы думаете об этом документе, его значении для сообщества разработчиков?
Создатели SWEBOK пытались собрать максимум полезной информации, но в ней оказалось слишком много представлений о традиционном управлении программными проектами. В «скорых» методах исповедуются совершенно иные подходы, и, по моему мнению, серьезных перспектив у этого труда нет.
Объединяют ли усилия приверженцы различных «скорых» методов, чтобы продвигать свои идеи?
Agile Alliance, образованный авторами Agile Manifesto, организует конференции и обучение. Есть также Scrum Alliance, который фокусируется на обучении принципам Scrum. Мы не только проводим тренинги, но и предоставляем консалтинговые услуги. Уникальность Scrum состоит в том, что этот метод создает сообщество практиков, упрощает совместную работу, преодолевая границы компаний. Вы можете обратиться за помощью к участнику команды Scrum в Google, Yahoo или даже Microsoft, и вы ее получите, потому что в основе Scrum лежит открытость, прозрачность, помощь друг другу. Это главные ценности метода. В XP тоже есть правило, что если кто-либо в команде разработки просит помощи, он ее незамедлительно получит. «Скорые» методы agile формируют совершенно иной стиль совместного существования в сравнении с традиционными средами разработки.
Может быть, вам нужен свой agile SWEBOK, чтобы распространять эту методику, например, в университеты? Как обстоят дела с академическим образованием в области «скорых» методов?
У меня большой опыт преподавания в различных вузах, я часто выступаю на конференциях и стараюсь поддерживать хорошие связи с академическим сообществом. Проблема университетов состоит в том, что они постоянно отстают на несколько лет от реалий индустрии. Например, когда практически все разработчики перешли на SmallTalk и Java, в большинстве университетов продолжали учить программированию на языке Cи. Как мне кажется, университеты, к сожалению, — самые неповоротливые организации с точки зрения восприятия нового.
Под руководством мастера Scrum команда разработки, состоящая из пяти-девяти человек, определяет в начале очередной итерации список задач Sprint Backlog, которые необходимо выполнить для того, чтобы реализовать приоритетные возможности в списке требований к программному продукту. Командная разработка в Scrum построена на принципе самоорганизации: команда сама решает, кто и как будет выполнять те или иные действия для достижения поставленных целей. Задача мастера Scrum — обеспечить надлежащие условия для продуктивной работы команды, в частности, ликвидировать все препятствия, которые могут возникнуть в ходе решения поставленных задач, от установки новой компьютерной мыши до организационных изменений в компании. Для своевременного выявления этих препятствий и постоянного инспектирования хода проекта предназначены ежедневные общие сборы команды — Daily Scrum.
