Методологии agile-разработки программного обеспечения существуют уже достаточно давно, но устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.

«Традиционный подход к заключению соглашений предполагает, что команда разработки может с помощью подробного технического проекта определять, с каким уровнем конкретизации будет конечный продукт, – говорит Дерек Шаффнер, адвокат юридической конторы Mayer Brown. – Согласовываются и указываются основные вехи, условия приемки клиентом и сроки получения выплат. Все это легко отразить в соглашении о разработке, поскольку процесс разработки традиционно носит линейный характер и начинается с детального планирования, после которого идут проектирование, написание кода, тестирование и ввод в эксплуатацию».

В agile-проектах от традиционных процессов разработки отказываются в пользу более гибких. «Подробных технических проектов и ключевых вех больше нет, поскольку клиент и разработчик непрерывно переопределяют приоритеты деятельности в рамках кратких итераций – спринтов, – напоминает Шаффнер. – Agile-подход требует доверия со стороны клиентов, тогда как те, возможно, привыкли к формализации и контролю, присущим традиционной разработке».

Однако существуют контрактные механизмы, и заказчики могут ими воспользоваться, чтобы уменьшить неопределенность, сохранив преимущества agile-разработки с ее кооперативным характером. Приведем семь советов о мерах предосторожности, которые могут понадобиться при составлении таких контрактов.

1. Главные сложности при составлении контрактов на agile-разработки

Для agile-разработки ПО характерно неструктурированное, непрерывное взаимодействие между клиентом и разработчиком, основанное на доверии и взаимопонимании, что трудно формализовать в контракте. Наибольшие сложности связаны с созданием системы норм, которая позволит получить преимущества agile-разработки с ее творческим подходом и одновременно выполнить требования клиента о своевременном создании продукта по справедливой цене.

2. Для agile-разработки сделку с фиксированной ценой заключить не удастся. Как рассчитать расценки при подготовке agile-контракта?

Здесь больше подойдет контракт, предусматривающий оплату затраченного рабочего времени и материалов (time and materials, T&M), но такой вариант может не устроить финансовый отдел и ИТ-директора. Ведь agile-разработка требует доверия, поскольку нет четких требований, а модель T&M может спровоцировать разработчика брать деньги за максимально большее количество часов.

Но существуют варианты, в которых предусмотрены инструменты контроля затрат – например, контракт с лимитами для каждой итерации или проекта в целом, условие невыплаты заработанного до окончания всего проекта и оплата фиксированного количества часов, которые клиент может потратить, как пожелает.

Модель T&M привлекательна, поскольку в ней предусмотрены условия прекращения проекта, более дружественные для клиента. Но есть и риск: когда проект идет уже достаточно давно, желание клиента закончить его перевешивает легкую возможность выхода из соглашения. Из-за этого может возникнуть ситуация, когда разработчик начнет выманивать деньги из заказчика к концу проекта, если, конечно, нет лимита на выплаты.

3. Как работает право на расторжение контракта на agile-разработку

С учетом того, что цель каждой итерации – создать работоспособный код, за который оплата осуществляется по принципам T&M, как правило, договор позволяет клиенту прекратить проект в конце любой итерации, обычно без платы за аннулирование заказа. Если клиента не устраивает продукт, созданный за очередную итерацию, он просто может выйти из контракта. Вероятность того, что проект сильно отойдет от спецификаций за одну итерацию, минимальна, поскольку требования определяются в начале каждой итерации так, чтобы продвинуться к цели создания продукта в соответствии с общим замыслом.

Но при agile-подходе ПО документируется лишь минимально, поэтому возрождение прекращенного проекта может оказаться очень затратным, поскольку новым разработчикам придется потратить больше времени на то, чтобы разобраться с кодом.

4. Agile-разработка по сути своей является изменчивой. Как предусмотреть в контракте какие-то вехи еще до начала работы?

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

Если стороны решат не использовать первоначальный список в качестве контрактного документа, следует указать в соглашении, как список будет создаваться и сортироваться. У клиента также должно быть исключительное право вносить поправки в список и менять расстановку приоритетов в нем.

В соглашении об agile-разработке стоит еще описать процедуру прохождения итерации, в том числе продолжительность каждой итерации (обычно не подлежащую продлению; неоконченная работа вносится в список задач как приоритетная), частоту собраний и процесс, с помощью которого стороны будут определять, что работа в рамках итерации окончена. Следует отметить, что перенос неоконченной работы в следующую итерацию может увеличить денежные затраты.

5. При agile-разработке, так же как и при традиционном аутсорсинге разработки приложений, необходимо получить от поставщика услуг гарантию того, что в течение определенного времени продукт будет работать согласно требованиям и любое несоответствие им будет устранено.

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

6. Поскольку agile-разработка подразумевает активное взаимодействие клиента и поставщика услуг, нужно обговорить права на интеллектуальную собственность.

В соглашении об agile-разработке нужно уточнить, какая сторона владеет правами на интеллектуальную собственность в готовом продукте и имеет ли другая сторона право на его использование и создание производных работ. Если поставщик услуг непременно хочет обладать правами на интеллектуальную собственность, у клиента должна быть неограниченная лицензия на готовый продукт, и, возможно, стоит требовать ограничений на его использование разработчиком в той же отрасли, в которой специализируется клиент. Ситуация дополнительно усложняется, если какая-то из сторон предоставляет для проекта уже готовый код, – тогда может потребоваться отдельное согласование для каждого случая.

7. Необходимо понять, стоит ли передавать agile-разработку вовне, если у вас уходит слишком много усилий на составление соглашения о такой разработке.

Соглашение на agile-разработку требует от клиента отказаться от определенной доли контроля и некоторых контрактных инструментов, которые можно было бы применить, если проект собьется с плана. Среди сложностей – необходимость полагаться на доверие, чему, скорее всего, будут противиться юристы организации-заказчика. Если клиента не устраивают отсутствие контроля и вариативность денежных затрат, то ему для разработки критически важных приложений больше подойдет традиционный подход.

– Stephanie Overby. How to contract for outsourcing agile