Šī prezentācija ir par to, kādas būtiskas lietas ir jāzina, slēdzot jebkuru līgumu, kādas ir tipiskas programmatūras izstrādes līguma daļas, kas ir mainījies līdz ar agile programmatūras izstrādes pieejas parādīšanos un kā sagatavot programmatūras izstrādes līgumu, kas atbalsta agile izstrādes pieeju.

1. AGILE LĪGUMI
Prezentācija balstīta uz patiesiem notikumiem
un personīgo pieredzi

2. Piegādātāja piegādes sfēra Projekta plāns
Cena un apmaksas kārtība
Pasūtītāja piegādes sfēra
Kvalitātes prasības
Izmaiņu pieprasījumu apstrādes
procedūra
Nodevumu piegādes un
akceptēšanas kārtība
Projekta pārraudzība
LĪGUMS

3. LĪGUMS = VIENOŠANĀS

4. LĪGUMS = REALITĀTE

5. LĪGUMS = MOTIVĀCIJA

6. KAS IR MAINĪJIES?

7. SFĒRA

8. Sfērai ir jābūt aprakstītai lietotājstāstos vai
citā spējās izstrādes metodoloģijai
draudzīgā veidā
ar skaidri aprakstītu sagaidāmo rezultātu.

9. Lietotājstāsta piemērs
Kā [lietotāja loma] es vēlos [darbība], lai es varētu
[iemesls/mērķis].
Kā ceļotājs es vēlos atrast savu rezervēto vietu
lidmašīnā, lai varētu to nomainīt.

10. Līgumam sākotnēji jāsatur
mazāko iespējamo sfēru, kas sniedz
klientam pievienoto vērtību.

11. Katram lietotājstāstam nepieciešams
novērtējums sarežģītības punktos vai
cilvēkdienās.

12. CENA UN APMAKSAS KĀRTĪBA

13. Apmaksas kārtībai ir jābūt viegli
saprotamai un pieņemamai visām
iesaistītajām pusēm.
agile ≠ time/material

14. PASŪTĪTĀJA PIEGĀDES SFĒRA

15. Līgumā jāiekļauj detalizēts izklāsts par
to, kāda iesaiste tiek sagaidīta no
klienta.

16. PROJEKTA PLĀNS

17. Projekta sākumā nepieciešama vismaz
viena iterācija (sprints), kuras laikā tiek
veikti sagatavošanās darbi.

18. Projekta laikā nepieciešama vismaz viena
iterācija (sprints), kuras laikā tiek veikta
visas sistēmas testēšana
(akcepttestēšana).

19. PROJEKTA PĀRRAUDZĪBA

20. Projekta pārraudzības process tiek
aprakstīts pasūtītāja piegādes sfēras
un izmaiņu apstrādes procedūras
ietvaros.

21. NODEVUMU PIEGĀDES UN
AKCEPTĒŠANAS KĀRTĪBA

22. Programmatūrai ir jābūt potenciāli
piegādājamai (potentially shippable)
katras iterācijas (sprinta) beigās.

23. Sistēmas tests iterācijā (sprintā)
iekļautajai funkcionalitātei ir jāparedz
katrā iterācijā (sprintā).

24. Akcepttestēšanai jāparedz atsevišķa
iterācija (sprints).

25. IZMAIŅU APSTRĀDES
PROCEDŪRA

26. Līgumā jāiekļauj īss un skaidrs
apraksts par lietotājstāstu
aizvietošanas principiem.

27. KAS NAV MAINĪJIES?

28. Juridiskais ietvars
Kvalitātes prasības
Piegādātāja sfērā iekļautās:
a) nefunkcionālās prasības
(piemēram, tehnoloģiju izvēle, integrācijas prasības)
b) produkcijā esošā risinājuma uzturēšana

29. KĀ TIKT PIE AGILE IZSTRĀDES
LĪGUMA?

30. Darba grupā kopā
ar klientu
apkopojiet
lietotājstāstus
minimālajai
nepieciešamajai
sfērai
Apkopojiet
nefunkcionālās,
kvalitātes un
uzturēšanas
prasības
Vienojieties ar
klientu par
izstrādes pieeju,
īpaši izskaidrojot
sagaidāmo
klienta iesaisti
1. 2. 3.

31. Vienojieties ar
klientu par
nodevumiem, to
piegādes un
akceptēšanas
kārtību
Vienojieties ar
klientu par cenu un
apmaksas kārtību
Sagatavojiet
juridisko ietvaru
5.4. 6.

32. Iedvesmas avoti
Agile Contracts by Alistair
Cockburnhttp://alistair.cockburn.us/Agile+contracts
Agile Contracts by Tom Arbogast, Craig Larman, and
Bas
Voddehttp://www.agilecontracts.org/agile_contracts_prim
er.pdf
Scrum ceļvedis (latviešu
valodā)http://www.autentica.lv/lv/article/scrum-celvedis-
latviesu-valoda/
oriģināls (angļu valodā)
http://www.scrumguides.org/scrum-guide.html

33. Elīna Jakubaņeca
@ejakubaneca
https://www.linkedin.com/in/ejakubaneca