Проблемы законодательства и контрактов, связанные с Agile-разработкой

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

Аджайл-модель разработки и юридические вопросы

Что такое модель в системной разработке?

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

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

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Особенности аджайл-модели разработки

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

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

Способы управления документами и изменениями в Agile-разработке

Важность управления документацией

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

В этой статье объясняется важность управления документацией в проектах разработки систем с двух точек зрения: предотвращение конфликтов (то есть “предупредительное юридическое обслуживание”) и сохранение доказательств в случае конфликта (то есть “управление кризисом”).

Установление контактного совета эффективно для управления документами

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

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

(Установление контактного совета)

Статья 12. Стороны А и Б до завершения данной работы проводят контактные совещания для обсуждения прогресса работы, управления и отчетности по рискам, совместной работы сторон А и Б и выполнения их отдельных задач, подтверждения содержания, которое должно быть включено в техническое задание, обсуждения и решения проблем и других вопросов, необходимых для гладкого выполнения данной работы. Однако, (пропуск).

2. Контактные совещания, как правило, проводятся регулярно с частотой, определенной в индивидуальном договоре, и кроме того, проводятся по мере необходимости, определенной сторонами А или Б.

3. На контактных совещаниях присутствуют руководители и главные исполнители обеих сторон, а также те, кого руководители считают подходящими. Кроме того, стороны А и Б могут требовать от другой стороны присутствия тех, кто необходим для обсуждения на контактном совещании, и другая сторона должна согласиться на это, за исключением случаев, когда есть разумные причины.

4. Сторона Б на контактном совещании создает и представляет отчет о управлении прогрессом в формате, согласованном между сторонами А и Б, и на основе этого отчета проверяет прогресс работы, наличие задержек, причины и меры по устранению задержек, если они есть, необходимость изменения структуры продвижения, определенной в этой главе (замена персонала, увеличение или уменьшение числа сотрудников, изменение подрядчика и т.д.), состояние выполнения мер безопасности, наличие причин для изменения индивидуального договора, содержание причин для изменения индивидуального договора, если они есть, и обсуждает и подтверждает вопросы, требующие дальнейшего рассмотрения, и график рассмотрения и участников рассмотрения, если есть вопросы, требующие дальнейшего рассмотрения. 

(Пункты 5, 6 и 7 опущены.)

Главная особенность в том, что наличие контактного совета придает определенную законность условиям договора и придает ему значение, отличное от других встреч, проводимых по мере необходимости.

Путь к использованию Совета по связям для управления изменениями

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

Если Совет по связям регулярно проводит заседания, управление изменениями и его методы становятся очень гладкими. Например, обсуждение изменений проводится на Совете по связям, и в контракт включается обязательство отвечать на запросы об изменениях от одной из сторон. (Ниже приведены положения модельного контракта Министерства экономики, торговли и промышленности.)

(Процедура управления изменениями)

Статья 37. Если сторона А или сторона Б получает предложение об изменении от другой стороны (…), она должна в течение ○ дней с даты получения представить другой стороне документ, содержащий следующую информацию (далее – “документ управления изменениями”), и стороны А и Б должны обсудить одобрение или отклонение этого изменения на Совете по связям, указанном в статье 12. (Дальнейшие подробности опущены)

Основные моменты этого положения можно суммировать следующим образом:

• Метод приема предложений об изменениях стандартизирован в формате “предложение об изменении”.
• Установлен срок между получением предложения и обсуждением его – “в течение ○ дней”. Это не обязательно должно быть указано как “в течение ○ дней”, можно рассмотреть замену на “немедленно” или подобные выражения.
• Место для обсуждения одобрения или отклонения изменений стандартизировано в “Совет по связям”.

То есть, чтобы избежать разногласий в понимании вопросов типа “было ли предложено изменение”, “был ли дан ответ на предложение об изменении”, процедура уточняется.

Требуется понимание обязанности честности и принципа добросовестности

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

Пункт 3 статьи 4. В обсуждении изменений следует рассмотреть объект изменения, возможность изменения, влияние изменения на стоимость и сроки поставки, и обе стороны должны обсудить изменения в добросовестной манере.

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

Пункт 2 статьи 1 Гражданского кодекса

Упражнение прав и исполнение обязанностей должны производиться в соответствии с добросовестностью и честностью.

Закон не всегда уважает только “содержание контракта” или “слова статьи”. Особенно в сделках с другой стороной, он должен быть гибко использован, включая существенную “добросовестность” и “честность”. Кроме того, мы подробно объяснили в следующей статье, что “обязанность”, которая налагается по закону, не всегда основывается на процедуре “контракта”.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Вывод

В проектах по разработке систем, основанных на модели Agile, конечно, важно понимать риск того, что процедуры и система управления могут стать неструктурированными и небрежными. Однако, это не все. Мы считаем, что также важно понимать гибкие особенности закона, основанные на принципах, таких как “принцип добросовестности”, и применять их на практике.