Самое необходимое в Agile контракте
| October 1, 2012 | Posted by admin under Практики, Статьи |
Автор: Alex Adamopoulos
http://alexadamopoulos.wordpress.com/2012/08/20/must-haves-for-agile-contracts/
Agile контракты – горячая тема. В статье «Sourcing for Agile» мы коснулись проблем, связанных с заказной разработкой ПО на основе agile, и обсудили разные методологии управления и разработки, которые были опробованы для облегчения и улучшение отношений между заказчиком и исполнителем. Слишком часто возникали неудачи при их использовании, из-за жесткого следования шаблонам, процессам и процедурам, что мешало заказчикам и исполнителям адаптироваться к быстрым изменениям, которые происходят в постоянно соперничающей коммерческой среде.
Суть хорошо схвачена в agile манифесте: Сотрудничество с заказчиком важнее согласования условий контракта. Поэтому, хотя переговоры по контракту важны для всех сторон, прежде всего, нужно быть уверенным, что не разрушена возможность взаимодействовать.
В 2010 году компания Emergn, вместе с одной из ведущих юридических фирм, разработала первый шаблон для agile контрактов. Результатом стал набор принципов, которые могли бы быть применены для определения контрактного соглашения между клиентом и исполнителем, с целью улучшения отношений, в терминах ожиданий и результатов. И хотя нет такого документа, который мог бы решить все проблемы взаимоотношений, соглашение, построенное на ценности, может повлиять на поведение, убрать некоторые барьеры, и сделать отношения более подвижными и значимыми, что очень важно для клиентов.
Ниже я выделил некоторые важнейшие элементы agile контракта и вставил несколько отрывков из шаблона контракта, чтобы показать, как это может выглядеть.
- Обязательства
- Контрактные обязательства – это количество результата (в виде полностью работающего ПО, которое можно установить), а не детали, связанные с результатом (т.е. реальные спецификации). Здесь мы видим реальный отход от традиционных контрактов «fixed price» и « time and materials», и возможность появления целого ряда новых ценовых моделей.
“8.1 Планирование:
(a) Стороны должны провести Планирование релиза (i) на старте Начальной (Start–Up) фазы, (ii) в начале Калибровочной (Calibration) фазы, (iii) и следить за выполнением SOW для каждого релиза в Операционной (Operational) фазе.
(b) Каждая из сторон должна удостовериться, что следующие лица лично присутствуют на планировании релиза: (i) от имени Исполнителя: все члены команды или ключевые лица, которые полностью уполномочены действовать от имени членов, которых они представляют; и (ii) от имени Заказчика: Product Owner.
(c) Исполнитель должен сделать переоценку количества Story Point-ов для каждой Истории, изложенной в Баклоге продукта, и должен подтвердить реальное количество Story Point-ов для каждой Истории, применительно к релизу, в полном соответствии с Методологией.
(d) Заказчик должен сделать переоценку Ценности истории для каждой Истории, изложенной в Баклоге продукта, и должен подтвердить реальную Ценность истории для каждой истории, применительно к релизу, в полном соответствии с Методологией.“
- Спецификация
- Нет необходимости делать предварительную спецификацию, потому что контрактные обязательства определяют количество результата, а не детали результата. Это значительно уменьшает время, требуемое на переговоры и составление контракта. Общая работа над спецификацией по ходу проекта встроена в подход. Создание высокоуровневых сценариев, основанных на ценности, дает основу для взаимных уступок по ходу проекта.
“(c) Баклог продукта: Содержит начальный список Историй вместе с (i) начальным значением Ценности истории в соответствии с Методологией для каждой высокоприоритетной Истории; и (ii) начальным значением Story Point-ов в соответствии с методологией для каждой из этих Историй с высокой Ценностью, как это предоставлено Исполнителем.”
- Производительность
- Производительность измеряется в терминах полностью работающего ПО, которое готово к поставке, которое включает фичи, указанные заказчиком. Только после поставки заказчик получает реальную ценность. Отчеты, изменения и поставляемые компоненты не являются заменой полностью работающему и протестированному ПО.
“(c) Исполнитель должен сделать переоценку количества Story Point-ов для каждой Истории из Баклога продукта и должен подтвердить реальное количество Story Point-ов для каждой Истории, применительно к релизу, в полном соответствии с Методологией. “
- Приоритезация фич
- Вводятся механизмы приоритезации фич. Одна из пустых трат – создание фич, которые никогда или редко используются – исключается.
“(e)Заказчик должен приоритезировать Истории, которые формируют План релиза, принимая во внимание Пункты 8.1(c )и 8.1(d) и отзывы от Демонстрации предыдущего Релиза (если применимо). “
- Внесение изменений
- Внесение изменений в фичу по ходу проекта может быть согласовано, поскольку набор фич, которые нужно построить, определяется только в начале каждой итерации. Поэтому нет необходимости в сложном механизме контроля за изменениями.
“7.6 Заказчик может вносить поправки в истории, которые входят в минимальный набор фич релиза (Minimum Marketable Features of a Release) в любой момент во время релиза, без дополнительной оплаты, при следующих условиях:
(a) Заказчик не должен вносить изменения в Истории текущей Итерации, следуя взаимному соглашению сторон по плану Итерации; и
(b) Новая История (Новые Истории) и/или вариации существующей Истории (Историй) могут быть введены, если (i) существующая История (Истории) с эквивалентным числом Story Point-ов удаляется или (ii) существующие Истории уменьшаются на эквивалентное число Story Point-ов, так что общее число Story Point-ов Релиза остается постоянным в течение Релиза. “
- Метрики
- Акцент делается на быструю поставку фич. Метрики включаются в контракт, чтобы показать уровень продуктивности сторон и дать сторонам необходимую информацию для улучшений в циклах создания фич, т.е. от момента возникновения идеи и до поставки фичи.
- ПО готово (Done)
- Тестирование – это часть процесса разработки, оно используется для получения ценного отклика и достижения качества, а не просто для того, чтобы вооружить заказчика контрактными правами и средствами правовой защиты.
“9.6 История должна считаться “Завершенной” и должна называться “Завершенной Историей”, когда каждый из следующих пунктов применим к Истории:
(a) Решение удовлетворяет Критериям приемки для этой Истории;
(b) Для Решения готовы процессы тестирования и Решение прошло через эти процессы тестирования;
(c) ПО, включающее Историю, готово к поставке в пред-промышленное или промышленное окружение, и ПО можно повторяемо установить на любое количество целевых настроек в пред-промышленное или промышленное окружение, так что функционирование ПО не изменится на каждой целевой настройке, не зависимо от природы такой настройки;
(d) Поставляемые компоненты, как описано в Методологии, утверждены Заказчиком, в том, что касается данной Истории;
(e) Product Owner и Представитель заказчика подтвердили, что История удовлетворительно завершена.“
- Качество кода
- Сильный акцент делается на качество кода. Метрики, оценивающие аккуратность кода, его надежность и легкость поддержки, встроены в контракт.
- Риск/Вознаграждение
- Риски и вознаграждения по проекту распределены в соответствии с навыками, компетенцией и экспертизой обеих сторон.
- Модель совместной поставки
- Совместный подход к модели поставки позволяет обеим сторонам привносить свой опыт и идеи в проект, который постоянно улучшается за счет прозрачности и обратной связи, прописанных в контракте.
“7.4 В каждом Релизе Исполнитель должен поставить Решение, заключающееся в Завершении Историй с количеством Story Point-ов равным или большим, чем количество Story Point-ов, прописанных в SOW к Дате завершения релиза, при условии что Заказчик выполняет свои обязательства по Соглашению.
7.5 Заказчик признает, что если он не выполняет свои обязательства по Соглашению, относительно Релиза, это будет иметь отрицательное влияние на количество Story Point-ов, которые Исполнитель может Завершить в течение Релиза. Соответственно, если, для какого-либо Релиза, (i) Исполнитель не поставляет Решение, заключающееся в Завершении Историй с количеством Story Point-ов, равным или большим, чем количество Story Point-ов, прописанное в SOW к Дате завершения релиза, и (ii) Исполнитель может показать, что причина срыва напрямую связана с тем, что Заказчик не выполнил одно или более обязательств, определенных Соглашением:
(a) Исполнитель должен перестать придерживаться обязательств, прописанных в Пункте 7.4 для этого Релиза; и
(b) Пункт 12.3 не должен применяться к этому Релизу. “
- Оценка заказной разработки
- Определяется необходимость оценивать существующие отношения и процессы заказной разработки, чтобы оптимизировать реализацию agile контракта в организации. Управление отношениями встроено в совместный стиль работы, так что проблемы с поставкой работающего ПО регулярно обсуждаются, а планы по улучшению совместно обговариваются и постоянно реализовываются. Что разрабатывается, как это разрабатывается, роли и ответственности сторон тесно связаны.
- В agile методах хорошо то, что они поощряют постоянную оценку и улучшения. Наиболее часто встречающаяся форма – ретроспектива, она может использоваться более часто для оценки отношений в целом, и помогает удостовериться, что ценность работы выше стоимости управления командой и отношениями.
“9.7 Ретроспектива:
(a) Стороны должны проводить Ретроспективу the Retrospective для каждой Итерации, вслед за завершением Демонстрации для этой Итерации.
(b) Каждая из сторон должна удостовериться, что следующие лица присутствуют на Ретроспективе лично: (i) от имени Исполнителя: все члены команды или ключевые лица, которые полностью уполномочены действовать от имени членов, которых они представляют; и (ii) от имени Заказчика: Product Owner и Представитель заказчика.
(c) Исполнитель должен поставить Заказчику отчеты, определенные в Пункте 11. Заказчик должен провести ревью Метрик производительности Активностей Итерации, как описано в отчетах.
(d) Стороны должны обсудить, как и почему не были достигнуты (если применимо) любые из целевых и / или Контрактных метрик, какие аспекты Активностей шли хорошо, какие аспекты Активностей шли не очень хорошо, принимая во внимание людей, процесс и инструменты, используемые в Итерации; стороны должны рассмотреть области улучшения и разработать список действий для исправления этих областей в следующей Итерации и/или Релизе (в соответствующих случаях).”
С традиционными контрактами многие организации не получают результаты или поведение, нужное для того, чтобы справиться с быстрыми изменениями и проблемами, связанными с ограничениями по цене и тратящимся бюджетом. Agile контракты – это соглашения, базирующиеся на ценности, они принимают во внимание принципы, которые компании хотят видеть в действии при работе с внешними исполнителями.
Они помогают создавать историю и найти правильный уровень гибкости, чтобы справиться с изменениями, справиться с вопросами качества и стоимости, и в конечном итоге могут лечь в основу“agile трансформации”, к которой многие стремятся.
