Гибкие контракты

— Фиксированная цена Agile это договорная модель, согласованная поставщиками и заказчиками ИТ-проектов, разрабатывающих программное обеспечение с использованием методов Agile . Модель представляет собой начальный этап тестирования, после которого согласовываются бюджет, срок выполнения и способ управления объемом в рамках структуры.

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

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

Дальнейшими аспектами Agile-контракта являются распределение риска (обе стороны делят между собой дополнительные расходы на непредвиденные изменения поровну) или возможность выхода любой из сторон из контракта на любом этапе (точки выхода).

Подходы к гибким контрактам

Контракты с ограниченным временем и материалами

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

Контракты с целевой стоимостью

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

Контракты на дополнительную поставку

Контракты на постепенную поставку позволяют клиентам просматривать контракты в определенные моменты жизненного цикла контракта. Эти пункты закрепляются в контрактах и ​​позволяют клиентам вносить изменения, продолжать или прекращать проект.

• Первый шаг охватывает содержание контракта на широком уровне. Сюда входят наиболее важные цели, темы и эпики проекта , а также правовая база.
• Выбирается один из эпиков, который лучше всего представляет весь проект, детализируется и превращается в несколько пользовательских историй . Хорошо выбранный эпик должен превратиться в большое количество пользовательских историй, каждая из которых различна и включает в себя ряд различных функций. Таким образом, их можно использовать в качестве справочных пользовательских историй.
• Затем поставщик и клиент собираются на семинаре, чтобы определить расходы на весь проект на основе этих справочных пользовательских историй и всех других эпических событий с помощью пунктов истории. Допущения также сделаны с точки зрения риска реализации и ценности бизнеса. Эта информация затем приводит к созданию ориентировочной структуры фиксированных цен, которая еще не имеет юридической силы и фиксируется только на более позднем этапе (в конце так называемой контрольной фазы).
• Затем определяется фаза контрольной точки. Это тестовый этап сотрудничества, во время которого начинается реализация и достигается первоначальное эмпирическое понимание. Рекомендуется, чтобы эта фаза длилась от двух до пяти спринтов (при продолжительности спринта две недели). В конце этапа контрольных точек заказчик и поставщик проверяют свои первоначальные предположения и решают, хотят ли они реализовать проект целиком или частично. Только после этого индикативная система фиксированных цен официально согласовывается и становится обязательной по контракту. На этапе контрольной точки также определяется доля риска, которая определяет, в какой степени с клиента будут взиматься дополнительные расходы, превышающие фиксированную цену.
• Кроме того, необходимо определить и заполнить роли, отвечающие за управление проектом. Заказчик предоставляет менеджера проекта, поставщик — владельца продукта. Рекомендуется привлечь независимого ИТ-консультанта, выбранного по взаимному согласию обеих сторон. Вместе эти роли образуют руководящий комитет (управление объемом работ). ) с мандатом официальной группы по принятию решений, которая собирается на регулярной основе и обеспечивает соблюдение непрерывного процесса спецификации, включая определение требований с наивысшим приоритетом в виде пользовательских историй.
• В отличие от традиционных проектов с фиксированной ценой, проекты с гибким контрактом могут закончиться раньше, если клиент считает, что получил ожидаемую выгоду благодаря уже предоставленным функциям. Это может произойти до того, как будут реализованы все согласованные функции. Для того чтобы такая договорная гибкость была выгодна как заказчику, так и поставщику, необходимо достичь конкретных соглашений, т.е. поставщику может быть выплачен определенный процент бюджета, оставшегося за непоставленные функциональные возможности, или поставщик может получить новое задание в объеме остаток бюджета.

Критика

Фиксированная цена Agile — это контрактная система, наиболее подходящая для сложных ИТ-проектов, масштабы, ход выполнения и затраты которых сложно определить заранее. Для стандартных проектов, которые уже выполнялись таким же или аналогичным образом в прошлом, этап тестирования и оценка хода проекта могут быть пропущены. Чтобы эта контрактная модель была успешной, поставщик и заказчик должны тесно сотрудничать на протяжении всего проекта. Кроме того, необходима определенная степень взаимного доверия, чтобы иметь возможность договориться о бюджете, расходах и наборе функций. Также желательно обеспечить, чтобы общие требования (эпики), перечисленные в начале проекта, как можно скорее превратились в более мелкие и подробные требования (пользовательские истории). В противном случае возрастает вероятность неопределенности и связанных с ней рисков.

Литература

• Андреас Опельт, Борис Глогер, Вольфганг Пфарль и Ральф Миттермайр: Гибкие контракты: создание и управление успешными проектами с помощью Scrum. 1-е издание, Серия Wiley по системной инженерии и менеджменту, 2013 г.
• Майкл Оверли, Джеймс Р. Каливас: Соглашения о программном обеспечении построчно. Как понять и изменить лицензии и контракты на программное обеспечение в соответствии с вашими потребностями . Книги Аспаторе, 2004, ISBN   978-1-58762-369-1 .
• Экхарт Хансер: Гибкие процессы. От XP к Scrum и MAP . Спрингер Верлаг, 2010 г., ISBN   978-3-642-12313-9 .
• Дебби Мэдден: «Я гибкая, но мой контракт — нет» http://blog.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile -команды-разработчиков программного обеспечения/