Что представляет собой скорая разработка?
Официального определения не существует, да и не должно быть. Но есть определенный набор ключевых характеристик, присущих различным методикам скорой разработки. Среди них – постепенная, эволюционная природа разработки, особое внимание к качеству. Работа ведется совместно – в скорой разработке важно очень тесное взаимодействие разработчиков друг с другом и со всеми заинтересованными лицами, так называемыми «стейкхолдерами» проекта. Еще одна характерная черта скорых мето-дов – стремление на каждом очередном этапе получить работающий продукт, который демонстрируется заказчику и потенциально может быть ему поставлен. Такой подход способствует сокращению рисков разработки. Большое внимание уделяется поддержке изменений в требованиях заказчика. Так уж сложилось на протяжении десятилетий, что заказчики программных решений никогда не знали абсолютно точно, чего они хотят. Поэтому, вместо того чтобы добиваться невозможного, методы скорой разработки обеспечивают более тесные взаимосвязи с заинтересованными сторонами, помогая понимать изменения в их потребностях.
В целом методы скорой разработки предлагают не усложнять, а повышать эффективность разработки, делать то, что продемонстрировало свою полезность на практике, а не то, что навязывает теория. Для многих организаций это означает изменение корпоративной культуры.
Принципы скорой разработки ПО сформулированы в Agile Manifesto восемь лет назад. Претерпели ли они за это время какую-либо эволюцию?
Безусловно, эволюция происходит. В марте текущего года был опубликован «Манифест программного мастерства» (Manifesto for Software Craftsmanship), провозглашающий набор новых ценностей, важных для разработчика. Авторы манифеста потверждают значимость принципов скорой разработки, но говорят о том, что они должны быть расширены и дополнены. Не просто получать работающие программные системы, но качественные, мастерски разработанные программные системы. Не просто реагировать на изменения, но, поступая таким образом, извлекать возможности для повышения ценности конечного продукта для заказчика. Не просто ставить во главу угла индивидуальное мастерство отдельных членов команды и эффективность взаимодействия между ними, но стремиться создавать сообщество профессионалов. Не просто постоянно сотрудничать с заказчиками, но строить отношения продуктивного партнерства с ними. Таким образом, этот манифест призывает по-новому взглянуть на принципы скорой разработки с целью максимально раскрыть их потенциал.
Что касается IBM, то для нас развитие принципов скорой разработки – это прежде всего проблема их масштабирования. Дело в том, что большинство приверженцев наиболее известных скорых методик говорят об их использовании в применении к небольшим командам, которые работают вместе в одном помещении. Есть определенные программные решения, разработка которых может вестись в таких условиях. Но что произойдет, если у вас большая, географически распределенная команда, если работа ведется под постоянным давлением различных нормативных требований? А ведь это более характерно для современной индустрии разработки.
Поэтому мы в IBM сосредоточили свое внимание на том, как методы скорой разработки будут работать в среде, для которой характерны подобные усложняющие факторы. Недавно под моим руководством была предложена модель зрелости процессов скорой разработки (Agile Process Maturity Model, АРММ). Цель создания этой модели состояла в формировании контекста применения различных методов и практик скорой разработки, которые сегодня можно найти в изобилии. С помощью APMM мы надеемся повысить уровень наших консультаций по поводу использования принципов скорой разработки. APMM не стоит сравнивать с известной пятиуровневой моделью зрелости процессов CMMI. Последняя используется для совершенствования процессов разработки, в то время как с помощью APMM мы надеемся решить более простую задачу описания условий, в которых применяются принципы скорой разработки.
APMM имеет три уровня. Первый уровень описывает базовые процессы, такие как экстремальное программирование (Extreme Programing, ХР), Scrum, Agile Modeling. Все это прекрасные идеи, но не вполне законченные методологии с точки зрения жизненного цикла разработки систем. Так, Scrum рассматривает в основном вопросы лидерства в проекте и управления требованиями. Процесс разработки в соответствии с ХР ближе к описанию полной картины, но сфокусирован преимущественно на построении ПО, включая в себя такие практики, как рефакторинг, программирование в парах, непрерывная интеграция и т.д., но оставляя без внимания вопросы моделирования продукта, его запуска в продуктивную эксплуатацию. Agile Modeling описывает только простейшие способы моделирования программного обеспечения и составления документации.
На втором уровне мы рассматриваем возможность построения процесса, охватывающего весь жизненный цикл разработки. Что необходимо сделать, чтобы выполнить всю работу от начала до конца? Возможно, достаточно собрать воедино различные компоненты базовых методик – ХР, Scrum, Agile Modeling. Или реализовать специальные процессы, такие, например, как Rational Unified Process (RUP), его открытая и упрощенная версия Open Unified Process (OpenUP), Dynamic System Development Method (DSDM) и др. Все эти варианты включает в себя второй уровень модели.
Третий уровень APMM рассматривает возможности масштабирования скорой разработки в условиях работы в больших распределенных командах, в условиях существования различных нормативных и регулирующих факторов. Мы стремимся дать ответы на вопросы, как должна измениться организация команды, какой инструментарий необходимо использовать и т.д., чтобы реализовать эффективный процесс скорой разработки в такой сложной среде.
В качестве примера могу привести тему моей недавней статьи в журнале Dr.Dobb’s Journal, где я рассматривал применение модели APMM к практике product backlog в методологии Scrum. Речь идет о списке необходимых функций программного продукта, в котором перед каждой очередной итерацией разработки заказчик выделяет наболее приоритетные для реализации. Как масштабировать этот процесс в среду третьего уровня, когда, например, различные нормативы требуют отслеживания большого количества деталей реализации проекта? Модель APMM помогает трансформировать подход к определению product backlog в зависимости от ситуации, в которой ведется разработка.
Казалось бы, такие строгие методологии, как RUP или разработка на базе моделей, и скорая разработка – «вещи несовместные»?
Как автор книги о скором моделировании я могу смело утверждать, что в процессы скорой разработки прекрасно вписываются различные подходы к моделированию, от простейших инструментов в соответствии с методикой Agile Modeling до значительно более сложных.
RUP действительно часто рассматривают как очень тяжелую методику. Но это совсем не обязательно должно быть так. Вполне успешен оказался ее agile-вариант – Agile Unified Process (AUP), разработкой которого я занимался. Это предельно облегченная, открытая версия RUP, в которой очень четко и ясно демонстрируются понятия и принципы RUP в применении
к процессам скорой разработки.
Есть ли, по вашему мнению, задачи, где данные принципы неприменимы?
Скорыми методами пользуются разработчики всех программных направлений IBM, включая разработку ПО управления информации, WebSphere, Lotus, Rational, Tivoli. Есть проекты, которые полностью ведутся по принципам скорой разработки, в других эти принципы используются для отдельных частей работы.
Думаю, данные принципы неприменимы только в тех организациях, которые не готовы к использованию скорой разработки с точки зрения корпоративной культуры. Если организация недостаточно гибкая, не способна меняться, например, если люди не хотят работать вместе, не доверяют друг другу, они не смогут использовать скорые методы, в которых совместная, командная работа является одним из ключевых аспектов.
Определенных областей, где данные методы использовать нельзя, не существует. Никакие технологические особенности, использование того или иного инструментария, приверженность определенному языку программирования не могут служить препятствиями к применению методов скорой разработки. На нынешней конференции Rational Software Conference был даже представлен опыт использования принципов скорой разработки при создании встроенных программных систем в самолетостроении, недоработки в которых могут иметь самые серьезные последствия. Так что единственным препятствием к использованию скорой разработки могут быть только недостатки корпоративной культуры.
Не вытеснит ли в конце концов скорая разработка традиционные подходы?
Наши исследования показывают, что очень много организаций так или иначе пробуют применять agile-методы, большинство зрелых организаций ставят целью использование скорой разработки и имеют вполне реалистичные планы по переходу к применению соответствующих принципов.
На самом деле проблема сегодня состоит не в том, использовать скорые методы или нет. Проблема в совершенствовании профессиональной разработки программного обеспечения. Но все чаще способом ее решения становится обращение к методам скорой разработки, которые на практике демонстрируют свою эффективность.
Что вы думаете о роли методик разработки для достижения качества ПО?
Повышенное внимание к качеству – одна из характеристик процессов скорой разработки. Я знаю примеры организаций, которые, серьезно занимаясь проблемой отслеживания дефектов, обнаруживают, что в agile-проектах дефектов возникает значительно меньше. Это, я думаю, наглядный пример влияния методологии на качество. В сообществе agile-разработчиков принято делать больше тестов, проводить тестирование раньше в жизненном цикле разработки, делать рефакторинг кода – все это открывает больше возможностей для создания качественного продукта, чем в традиционных методологиях разработки.
Я знаю примеры организаций, которые препятствуют командам, занимающимся скорой разработкой, в их стремлении улучшать качество продукта, поскольку, например, рефакторинг или большой объем тестирования занимают слишком много времени. Эти довольно странные менеджерские решения объясняются тем, что дополнительное время на проверку кода, на тестирование повышают, по мнению руководства, вероятность не реализовать разработку в срок в рамках заданного бюджета. Однако это не так. Чем больше усилий вы тратите на качество, тем больше шансов, наоборот, ускорить разработку продукта, при этом снизив ее стоимость, поскольку качественный код проще для понимания и развития. Инвестиции в качество способствуют снижению стоимости программного продукта.
