Якщо команда розробників працює за agile-методологією, краще не укладати стандартний договір на розробку ПЗ. Стандартний договір не захищає розробника від дівчачого комплексу замовника під назвою «я передумала», а замовника ¬- від ефекту «зіпсованого телефону». Тому ІТ-юрист, який розуміє відмінність між agile-договором та non-agile-friendly договором (які умови варто фіксувати, як у розробці бере участь замовник, що таке гнучкість етапів та чому відповідальність – це зло), - скарб.

1. Agile contracts. OR is agile dead?

2. “Values have been totally lost
behind implementation”
Dave Thomas

3. ПРОЕКТ ІНСТРУМЕНТ
+ +
+ -
- -
- +

4. AGILE?

6. What arriving late on
the market means for
business?

7. Waterfall project
management

9. Agile project
management

10. Fixed all
Time spent
approach
Agile contract
is here

15.  Чітка послідовність етапів розробки;
 Гарантована успішність кожного етапу (неуспішність = недотримання
строку);
 Всі недоліки і баги треба усунути до поставки продукту, інакше -
порушення договору;
 Однобічне спілкування (замовник цікавиться процесом, але не
уточнює завдання);
 Єдина поставка повністю готового продукту;
 Гарантія виконання договору – штрафні санкції (недовіра)
Not agile-friendly

18. • «Орієнтовний графік робіт погоджується Сторонами у Додатку
№1 до цього Договору. Обсяг робіт та їх вартість на кожному
етапі погоджується Сторонами перед початком кожного етапу
на основі зробленої Виконавцем оцінки часових витрат.
• Погоджений перед початком кожного
етапу обсяг робіт та їх вартість може
відрізнятися від орієнтовного обсягу,
визначеного в Додатку №1 до цього Договору.»
Agile-friendly

19. • “The Customer may from time to time request
changes in the agreed software development project, scope,
schedule, software design… or any other aspect of its initially
ordered Services (“Change Request”).”
• “Considering the resources required to process a Change Request
the Customer agrees that during the review of a Change Request
the Contractor may without any liability temporarily
cease or slow down software development
and other Services in the part affected by the Change Request.”
Agile-friendly

21. “Customer agrees that its timely participation in the
following processes is essential for the Contractor’s development
process and timely performance of Deliverables:
• Participate in sprint planning. A sprint cycle can be from
one to four/or three weeks.
• Provide feedback on priorities. Once a new sprint
starts, priorities cannot be changed by the Customer.
• Cooperate, respond to questions and provide clarifications as
needed for the Consultants to complete their Deliverables.
Agile-friendly

22. + Відсутність чіткої послідовності розробки;
+ Відсутність штрафних санкцій - заміна схемою бонусного
заохочення / підстави для розірвання договору;
+ Прийняття результатів життєздатними частинами, а не тільки
вкінці.
Agile-friendly
Fixed Agile
Scope Working product, continuous
delivery
Time Sprints/Iterations/ongoing
collaboration
Cost Time&Material, Cost+

23. Що треба прописати?
• definitions
100% agile contract
Team
(PO, PM,
Developer,
QA
Engineer)
Services
Stages Backlog
Sprint
(5-10
days)
Task
Project
Completion
(!!!)
Deliverables

24. 100% agile contract
Як
узгоджуються
бюджет і
строки
Як
підписується
ТЗ
Обмеження
часу надання
послуг (40
год/тиждень)
Процес
розробки за
аджайл-
методологією
Періодичність
виставлення
інвойсів
Ставки
– у ТЗ

25. “The Supplier
shall not be responsible for any
deficiency or delay in the rendering of the Services caused
by the Customer’s failure to provide full cooperation and perform its
obligations under the Master Agreement and relevant SOWs. If the
Idle Time exceeds 3 (three) business days, the Supplier reserves the
right to
assign the Team to another project.”
А як же… відповідальність?