Зачастую во время реализации проекта стоит задача автоматизации процессов взаимодействия между членами команды, которые работают над ним. Кроме прочего, ключевым вопросом является также и организация алгоритма работы над проектом. Решить эти задачи может использование методологии Agile.

Изначально Agile — это методология гибкого управления вашим будущим проектом. Одной из методик гибкого управления является Scrum. Считается, что данная методология, является развитием аутосрсинга, и его приемником. У методики Scrum существует определенный алгоритм реализации:

  • формирование команды от 2-10 человек;
  • назначение скрам-мастера;
  • составление требования к продукту и цели;
  • оценка данных вместе со всей командой, фиксирование количества времени, которое потребуется на выполнение;
  • определение с периодом итераций (разделение на сроки).

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

составление тендерной документации

Производительность

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

Приоритезация фич

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

Внесение изменений

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

Метрики (оценка итераций)

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

Тестирование

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

Качество кода

Акцентировать внимание следует на качестве кода. Метрики (оценка за определенный этап), оценивающие аккуратность кода, его надежность и легкость поддержки, также должны быть встроены в договор.

Оценка заказной разработки

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

В agile методах хорошо то, что они поощряют постоянную оценку и улучшения.

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

Кроме этого, следует уделить внимание дополнительному соглашению, которое заключается вместе с agile договором.

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

В качестве примера приведем возможный вариант оформления дополнительного соглашения:

«1.1.  Во время выполнения работ заказчик устанавливает 4 итерации, по результатам которых могут быть проведены корректировки.

1.2. Последняя итерация всегда предназначена для стабилизации и поставки текущей версии продукта, при этом никакие пользовательские истории в этой итерации не реализуются».

В дополнительном соглашении к agile договору следует выделить также и особые условия:

«2.1. По завершению очередной итерации заказчик может принять решение о досрочном успешном завершении выполнения работ подрядчиком, письменно уведомив подрядчика об этом решении. При этом заказчик обязуется:

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

Полностью произвести с подрядчиком взаимный расчет по количеству фактически выполненных итераций.

Дополнительно выплатить подрядчику сумму в размере 30% от неизрасходованного остатка общей стоимости выполнения Работ по настоящему Дополнительному соглашению».

Заказать консультацию по вопросам подготовки Agile договора.

*Информация не передается третьим лицам