Hvad er juridiske og kontraktmæssige problemer forbundet med Agile-udvikling?

Der er forskellige metoder til at drive systemudvikling. Den mest klassiske og almindelige er vandfaldsmodellen, og mange juridiske bøger, der behandler systemudvikling, diskuterer dette på baggrund af denne model. I denne artikel vil vi forklare de juridiske problemer, der kan opstå i forbindelse med systemudvikling baseret på den agile udviklingsmodel, som det kan være svært at finde information om i bøger og lignende.

Agil udviklingsmodel og jura

Hvad er en model i systemudvikling?

I systemudviklingsprojekter findes der udviklingsmodeller, som fungerer som rammer for at få et overblik over projektets fremskridt. Den mest kendte af disse er den såkaldte “vandfaldsmodel”. Det vil sige, ligesom vand falder fra “opstrøms” til “nedstrøms”, gennemføres alle processer som kravspecifikation, design, implementering, test osv. i en enkelt gennemgang. Denne metode sigter mod at minimere tilbageskridt og dobbeltarbejde så meget som muligt og er velegnet til planlagt arbejdsfremgang.

På den anden side gentager den agile udviklingsmodel processen med at implementere små programmer og teste dem. Ved at gentage denne iterative proces med at implementere og teste små programmer, bygges et større system gradvist op. For en mere detaljeret forklaring på disse systemudviklingsmodeller og en sammenligning af fordele og ulemper ved begge udviklingsmodeller, se artiklen nedenfor.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Karakteristika ved den agile udviklingsmodel

En stor fordel ved udvikling med den agile model er, at man kan komme hurtigt i gang med det faktiske arbejde. Da “opstrøms” opgaver som kravspecifikation og design ikke er adskilt fra programmeringsarbejdet, er det velegnet til at styre fleksibelt, herunder at håndtere tilføjelser og ændringer af funktioner og specifikationsændringer. Juridisk set er det særligt vigtigt at håndtere dokumentstyring og ændringsstyring effektivt for at gøre den agile udviklingsmodel til en succes. I den agile udviklingsmodel er roller og ansvar ikke så klart defineret som i vandfaldsmodellen. Desuden, da denne metode prioriterer “hastighed” til udførelse og igangsættelse frem for “styring”, kan det let føre til mangelfuld dokumentation, såsom design- og specifikationsdokumenter og mødereferater.

Desuden, i forhold til ændringsstyring, da den agile udviklingsmodel er smidig i håndteringen af ændringer, er der en risiko for, at projektet kan gå op i flammer, hvis godkendelsesprocessen for beslutningstagere overses, og specifikationsændringsanmodninger håndteres på arbejdspladsniveau. Hvis dette sker, kan fordelene ved en udviklingsmodel, der er “smidig i håndteringen af efterfølgende ændringer”, i sig selv blive en risiko for, at projektet går op i flammer.

Håndtering af dokumentstyring og ændringsstyring i agil udvikling

Vigtigheden af dokumentstyring

I udviklingsprojekter baseret på den agile udviklingsmodel er en juridisk bekymring, at mundtlige interaktioner akkumuleres, hvilket fører til mangel på dokumentation. Vi har detaljeret forklaret, hvorfor dokumentstyring er vigtig i systemudviklingsprojekter, i følgende artikel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

I denne artikel forklarer vi vigtigheden af dokumentstyring i systemudviklingsprojekter fra to perspektiver: forebyggelse af konflikter (dvs. “forebyggende juridisk arbejde”) og bevisbevarelse i tilfælde af konflikter (dvs. “krisehåndtering”).

Implementering af et kommunikationsråd er effektivt for dokumentstyring

Når den agile udviklingsmodel anvendes, er der ikke en klar plan på forhånd, som det er tilfældet med vandfaldsmodellen. Derfor er det ikke nok bare at styre afvigelser mellem plan og faktiske resultater, og der er bekymring for, at omkostningerne kan stige både økonomisk og tidsmæssigt, hvis det overlades til arbejdspladsen.

Derfor er det effektivt at have en leder, der regelmæssigt afholder et kommunikationsråd for at sikre en gnidningsfri fremdrift af projektet. I tilfælde af mindre udviklingsprojekter er det ofte mere ønskeligt at samles, når ledere kan mødes efter behov, i stedet for at afholde regelmæssige kommunikationsmøder. Men i tilfælde af den agile udviklingsmodel er risikoen for at overse rettidige problemer i møder ofte større. Derfor er det sikkert at sige, at det er sikkert at inkludere regelmæssige kommunikationsmøder i kontrakter og lignende. Reglerne er som følger i den modelkontrakt, der er angivet af det japanske ministerium for økonomi, handel og industri.

(Etablering af kommunikationsråd)

Artikel 12 Part A og B skal afholde et kommunikationsråd for at drøfte nødvendige spørgsmål for at sikre, at dette arbejde kan udføres gnidningsfrit, herunder fremskridt, risikostyring og rapportering, fælles arbejde og implementering af individuelle opgaver af begge parter, bekræftelse af indhold, der skal inkluderes i systemspecifikationerne, drøftelse og løsning af problemer, indtil dette arbejde er afsluttet. Dog, (udeladt).

2. Kommunikationsrådet skal afholdes regelmæssigt med den frekvens, der er fastsat i den individuelle kontrakt, og derudover skal det afholdes efter behov, når enten part A eller B finder det nødvendigt.

3. Ledere, hovedansvarlige og dem, som lederne finder passende, skal deltage i kommunikationsrådet. Desuden kan både part A og B anmode den anden part om at deltage i de personer, der er nødvendige for drøftelserne i kommunikationsrådet, og den anden part skal overholde dette, medmindre der er en rimelig grund.

4. Part B skal udarbejde en fremskridtsrapport i det format, der er aftalt separat mellem part A og B, og indsende den i kommunikationsrådet, bekræfte fremskridt baseret på denne fremskridtsrapport, tilstedeværelsen af forsinkede emner, årsager og modforanstaltninger, når der er forsinkede emner, behovet for at ændre fremdriftssystemet fastsat i dette kapitel (personaleændringer, stigninger og fald, ændringer i underleverandører osv.), status for implementering af sikkerhedsforanstaltninger, tilstedeværelsen af årsager, der kræver ændringer i den individuelle kontrakt, indholdet, når der er årsager, der kræver ændringer i den individuelle kontrakt, og bekræfte emner, der er besluttet, emner, der skal fortsættes med at blive overvejet, og tidsplanen for overvejelse og parterne, der skal overveje, når der er emner, der skal fortsættes med at blive overvejet.  

(De følgende afsnit 5, 6 og 7 er udeladt.)

Det vigtigste punkt er, at eksistensen af kommunikationsrådet giver en vis legitimitet i kontraktbestemmelserne og giver det en anden betydning end andre ad hoc-møder.

Udnyttelse af kommunikationsrådet til ændringsstyring

Desuden, i agil udvikling, er det en forudsætning, at emner, som begge parter oprindeligt var enige om, ændres efterfølgende. Derfor er det også meget vigtigt, hvordan man håndterer situationen med efterfølgende specifikationsændringer.

I denne forbindelse, hvis kommunikationsrådet afholdes regelmæssigt, bliver ændringsstyringen og dens metode meget glat. For eksempel kan du gøre ændringsdiskussioner i kommunikationsrådet og inkludere en forpligtelse i kontrakten for den anden part til at overholde disse diskussioner, når der er en anmodning om ændringsdiskussion fra den ene part. (Nedenfor er en uddrag af bestemmelsen i modelkontrakten fra det japanske ministerium for økonomi, handel og industri.)

(Ændringsstyringsprocedure)

Artikel 37 Part A eller B skal, når de har modtaget et ændringsforslag fra den anden part (udeladt), overdrage et dokument (herefter kaldet “ændringsstyringsdokumentet”) til den anden part inden for ○ dage efter modtagelsen, hvori følgende emner er angivet, og part A og B skal drøfte, om den pågældende ændring er mulig i kommunikationsrådet som fastsat i artikel 12. (Udeladelse af emner, der skal angives)

De vigtigste punkter i ovenstående bestemmelse kan opsummeres som følger:

• Metoden til at acceptere ændringsanmodninger er standardiseret til et format kaldet “ændringsforslag”.
  
• Der er en tidsfrist for datoen fra modtagelsen af forslaget til diskussionen om det → Selvom det ikke er angivet som “inden for ◯ dage”, kan det overvejes at erstatte det med ord som “hurtigst muligt”.
  
• Stedet for at diskutere, om ændringen er mulig, er standardiseret til “kommunikationsrådet”.
  

Med andre ord, for at undgå misforståelser som “Jeg har anmodet om en ændring, jeg har ikke” og “Jeg har svaret på, om ændringen er mulig, jeg har ikke”, er metoden til proceduren klar.

Forståelse af pligten til ærlighed og god tro er afgørende

Indtil videre har vi introduceret modelkontraktbestemmelser om ‘Kontaktudvalg’ og ‘Ændringsforhandlinger’. Men det, der er vigtigt for at forstå essensen af disse, er emner som ‘pligten til ærlighed’ og ‘god tro’. Agile udviklingsmodeller er ofte vanskelige at gennemføre uden et tillidsforhold mellem ordregiver og leverandør. Dette skyldes, at de prioriterer hastigheden af at komme i gang med det faktiske arbejde, og procedurerne, der fører op til starten, er normalt minimeret. Derfor er det også almindeligt i praksis at inkludere bestemmelser, der pålægger den anden part en ‘pligt til ærlighed’.

Paragraf 4, stk. 3: I ændringsforhandlinger skal begge parter ærligt drøfte emnet for ændringen, om ændringen er mulig, og virkningen af ændringen på prisen og leveringstiden.

Dette er for at forhindre en tilgang, hvor man pludselig forråder den anden part med en formel juridisk argumentation, såsom ‘om man vil acceptere en kontraktændring er udelukkende op til den part, der modtager anmodningen, og der er ingen pligt til at overholde tvang’, i forhandlinger, der oprindeligt blev gennemført på grundlag af et tillidsforhold. Dette afspejler også principperne i loven, der gælder for private transaktioner, ikke kun systemudvikling.

Civilretten paragraf 1, stk. 2

Udøvelsen af rettigheder og opfyldelsen af pligter skal ske i god tro og med ærlighed.

Loven værdsætter ikke nødvendigvis kun ‘indholdet af kontrakten’ eller ‘ordlyden af bestemmelserne’. Især i transaktioner med en anden part bør den bruges fleksibelt, mens man tager hensyn til den faktiske ‘god tro’ og ‘ærlighed’. Desuden er der en detaljeret forklaring i følgende artikel om, at det, der er ‘pålagt ved lov’, ikke nødvendigvis er baseret på ‘kontrakt’ proceduren.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Opsummering

Det er selvfølgelig vigtigt at forstå risikoen for, at administrative procedurer og ledelsesstrukturer bliver tilfældigt sløset i systemudviklingsprojekter baseret på den agile udviklingsmodel. Men det er ikke kun det, det er også vigtigt at forstå de fleksible egenskaber, som loven oprindeligt har, baseret på principper som “god tro”, og at have en holdning til at anvende det i praksis.