Методологии agile-разработки программного обеспечения существуют уже достаточно давно, но устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.
«Традиционный подход к заключению соглашений предполагает, что команда разработки может с помощью подробного технического проекта определять, с каким уровнем конкретизации будет конечный продукт, – говорит Дерек Шаффнер, адвокат юридической конторы Mayer Brown. – Согласовываются и указываются основные вехи, условия приемки клиентом и сроки получения выплат. Все это легко отразить в соглашении о разработке, поскольку процесс разработки традиционно носит линейный характер и начинается с детального планирования, после которого идут проектирование, написание кода, тестирование и ввод в эксплуатацию».
В agile-проектах от традиционных процессов разработки отказываются в пользу более гибких. «Подробных технических проектов и ключевых вех больше нет, поскольку клиент и разработчик непрерывно переопределяют приоритеты деятельности в рамках кратких итераций – спринтов, – напоминает Шаффнер. – Agile-подход требует доверия со стороны клиентов, тогда как те, возможно, привыкли к формализации и контролю, присущим традиционной разработке».
Однако существуют контрактные механизмы, и заказчики могут ими воспользоваться, чтобы уменьшить неопределенность, сохранив преимущества agile-разработки с ее кооперативным характером. О том, какие меры предосторожности понадобятся, Шаффер рассказал в интервью CIO Magazine.
- В чем главные сложности при составлении контрактов на agile-разработки?
Для agile-разработки ПО характерно неструктурированное, непрерывное взаимодействие между клиентом и разработчиком, основанное на доверии и взаимопонимании, а это трудно формализовать в контракте. Наибольшие сложности связаны с созданием системы норм, которая позволит получить преимущества agile-разработки с ее творческим подходом и одновременно выполнить требования клиента о своевременном создании продукта по справедливой цене.
- Для agile-разработки сделку с фиксированной ценой заключить не удастся. Как рассчитать расценки при подготовке agile-контракта?
Для agile-разработки ПО больше подойдет контракт, предусматривающий оплату затраченного рабочего времени и материалов (time and materials, T&M), но такой вариант может не устроить финансовый отдел и ИТ-директора. Ведь agile-разработка требует доверия, поскольку нет четких требований, а модель T&M может спровоцировать разработчика брать деньги за максимально большее количество часов.
Но существуют варианты этой модели, в которых предусмотрены инструменты контроля затрат, – например, контракт с лимитами для каждой итерации или проекта в целом, условие невыплаты заработанного до окончания всего проекта и оплата фиксированного количества часов, которые клиент может потратить, как пожелает.
Модель T&M более привлекательна, поскольку в ней предусмотрены условия прекращения проекта, более дружественные для клиента. Но есть и большой риск: когда проект идет уже достаточно давно, желание клиента закончить его перевешивает легкую возможность выхода из соглашения. Из-за этого может возникнуть ситуация, когда разработчик начнет выманивать деньги из заказчика к концу проекта, если, конечно, нет лимита на выплаты.
- Как именно право на расторжение контракта работает в описанных ситуациях?
Учитывая, что цель каждой итерации – создать работоспособный код, за который оплата осуществляется по принципам T&M, как правило, договор позволяет клиенту прекратить проект в конце любой итерации, обычно без платы за аннулирование заказа. Если клиента не устраивает продукт, созданный за очередную итерацию, он просто может выйти из контракта. Вероятность того, что проект сильно отойдет от спецификаций за одну итерацию, минимальна, поскольку требования определяются в начале каждой итерации так, чтобы продвинуться к цели создания продукта в соответствии с общим замыслом.
Но при agile-подходе ПО документируется лишь минимально, поэтому возрождение прекращенного проекта может оказаться очень затратным, поскольку новым разработчикам придется потратить больше времени на то, чтобы разобраться с кодом.
- Agile-разработка по сути своей является изменчивой. Как заказчику предусмотреть в контракте какие-то вехи еще до начала работы?
Agile-разработка начинается с формулировки общего замысла продукта. Пользуясь им как руководством, разработчики затем составляют список требований (product backlog), представляющий собой отсортированный по приоритетности перечень работ, которые нужно выполнить в рамках проекта. В соглашении о разработке стоит указать, как будет вестись этот список на протяжении проекта, в том числе четко сформулировать обязанности разработчика по предоставлению сметы на разработку каждой позиции из списка. Пользуясь списком, стороны могут также определять порядок работы над позициями.
Если стороны решат не использовать первоначальный список в качестве контрактного документа, следует указать в соглашении, как список будет создаваться и сортироваться. У клиента также должно быть исключительное право вносить поправки в список и менять расстановку приоритетов в нем.
В соглашении об agile-разработке стоит еще описать процедуру прохождения итерации, в том числе продолжительность каждой итерации (обычно не подлежащую продлению; неоконченная работа вносится в список задач как приоритетная), частоту собраний и процесс, с помощью которого стороны будут определять, что работа в рамках итерации окончена. Следует отметить, что перенос неоконченной работы в следующую итерацию может увеличить денежные затраты.
- Как заказчику снизить риск текучки сотрудников на проектах, требующих непрерывной работы?
С одной стороны, итерационный подход дает клиенту возможность легко прекратить проект, с другой, меньше вероятность того, что поставщики услуг будут готовы предоставлять разработчиков на долговременной основе, если клиент не даст финансовых обязательств по использованию этих кадровых ресурсов. Чтобы снизить риск текучки и потери знаний о проекте, клиенту следует выбрать ключевых разработчиков, указать в соглашении их обязательства и дать гарантии того, что поставщик услуг не переведет их с проекта без согласия клиента.
В соглашении также должны быть гарантии того, что разработчик предоставит все ресурсы, необходимые для завершения задач в рамках отдельной итерации. Тем самым исключается возможность оправдать незавершенность итерации нехваткой ресурсов. Кроме того, в контракте стоит указать, что передача знаний между разработчиками не оплачивается.
- При традиционном аутсорсинге разработки приложений поставщик услуг на определенное время дает гарантию того, что продукт будет работать согласно требованиям и любое несоответствие им будет устранено. Можно ли получить такие гарантии при agile-разработке?
Подобные гарантии были бы проблематичны, но разработчик мог бы гарантировать, что рабочий код, созданный в рамках каждой итерации, отвечает требованиям этой итерации. Учитывая, что объем рабочего кода от итерации к итерации растет, клиенту стоит потребовать гарантий того, что интегрированные компоненты будут работать друг с другом и финальный продукт будет функционировать согласно совокупности требований ко всем итерациям. Если для продукта характерны сезонные колебания нагрузки, надо позаботиться о том, чтобы такая гарантия охватывала периоды высокой нагрузки.
- Как обговорить права на интеллектуальную собственность с учетом того, что agile-разработка подразумевает активное взаимодействие клиента и поставщика услуг?
В соглашении об agile-разработке нужно уточнить, какая сторона владеет правами на интеллектуальную собственность в готовом продукте и имеет ли другая сторона право на его использование и создание производных работ. Если поставщик услуг непременно хочет обладать правами на интеллектуальную собственность, у клиента должна быть неограниченная лицензия на готовый продукт, и, возможно, стоит требовать ограничений на его использование разработчиком в той же отрасли, в которой специализируется клиент. Ситуация дополнительно усложняется, если какая-то из сторон предоставляет для проекта уже готовый код, – тогда может потребоваться отдельное согласование для каждого случая.
- Если клиент тратит слишком много усилий на составление соглашения об agile-разработке, может ему не стоит передавать такую разработку вовне?
Соглашение на agile-разработку требует от клиента отказаться от определенной доли контроля и некоторых контрактных инструментов, которые можно было бы применить, если проект собьется с плана. Среди сложностей – необходимость полагаться на доверие, чему скорее всего будут противиться юристы организации-заказчика. Если клиента не устраивают отсутствие контроля и вариативность денежных затрат, то ему для разработки критически важных приложений больше подойдет традиционный подход.
– Stephanie Overby. How to contract for outsourcing agile development. CIO. July 1, 2016