Presentasjon av SSA-S, avtale for smidig systemutvikling som Difi har på høring http://www.difi.no/artikkel/2012/02/horing-for-ny-statens-standardavtale-om-smidig-systemutvikling

1. SSA-S
Statens standardavtale for smidig
systemutvikling
XP-meetup 8.5.12

2. Mari Vestre
Cand real i Informatikk fra UiO 1985
Jobbet i statsforvaltningen fra 1992
Jobbet med SSA 2005-08
Laget første utkast til avtale for Smidig systemutviking i 2006
Prosjektleder for MinID 2.1, rolle Produkteier, 2008
Prosjektleder for MinID 3.0, rolle Scrummaster 2009-10
Seksjonssjef for systemutviklingsseksjonen i Difi 2010-12
……………fra 1. mai 2012 jobber jeg med IT-anskaffelser og SSA
Direktoratet for forvaltning og IKT

3. SSA-S
SSA er laget for statsforvaltningen
SSA er standardavtaler som tilpasses i de enkelte
tilfellene ved å tilpasse bilagene
Difi har planer om å komme med mer veilednings-
materiale som viser hvordan dette kan gjøres
Avtaler har først og fremst sin misjon hvis det oppstår
konflikter i prosjektet
Direktoratet for forvaltning og IKT

4. 12 principles of Agile Software
We follow these principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,and trust them to
get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Dato Direktoratet for forvaltning og IKT

5. 12 principles of Agile Software
We follow these principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support what they need, and trust them
to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
Direktoratet for forvaltning og IKT

6. Systemutvikling i offentlig sektor
Kundens Kundens krav-
Kundens krav- spesifikasjon
behov spesifikasjon Det ferdige
Leverandørens tilbud systemet
Kontrakt
Kunngjøring på Doffin Utvikling
Konsulent
Akseptansetest
Finansiering Velge leverandør
Inngå kontrakt, godkjenning
starte utvikling
Statens standardavtaler for IT-anskaffelser
Programutviklings-avtalen
Avtale om utvikling av programvare
Avtalens navn
Samlet vederlag
Avtalens tidsrom
Direktoratet for forvaltning og IKT
6

7. Endringer i SSA-S
Behovsbeskrivelse – ikke kravspesifikasjon
Mer samarbeid enn i andre SSA-avtaler:
Mer ansvar på Kunden, bl.a. ”straff” for manglende
deltakelse
Større adgang til midlertidig stans, avbestilling (Kunde),
oppsigelse av avtalen (Leverandør)
Direktoratet for forvaltning og IKT

8. Begrunnelse for SSA-S-valg:
Mye initiell rigging
-Viktig med kompetanseoverføring
Prosjektleder, ikke scrummaster og produkteier
-Det er en del oppgaver som må løses i tillegg til de som ligger i smidig-rollene
Variabel sprintlengde
-Må ta hensyn til at avklaringer og beslutninger er problematisk i forvaltningen
Produksjonssetter ikke det som er ferdig
-Ofte må hele systemet produksjonssettes på én gang
Midlertidig stans/avbestilling/oppsigelse
-Å få avklaringer/beslutninger kan bli så problematiske at prosjektet må stanse
Direktoratet for forvaltning og IKT

9. De største utfordringene:
Produkteierrollen
-Vanskelig å få gitt én person nok myndighet
Avklaringer/beslutninger
-Tidkrevende, hindrer fremdrift, fører til ”hånd til munn”-utvikling
Tilgang på kritisk kompetanse hos Kunden
-Kunden har sjelden kapasitet til å kjøre prosjektet, får penger men ikke stillinger
”Big bang”-produksjonssetting
-Systemet fører med seg regelverksendring som ikke kan gjøres gradvis
Direktoratet for forvaltning og IKT

10. SSA-S-høring
Mer konkret ønsker vi også synspunkter på:
Måten smidig-metodikken er tatt i bruk – er slektskapet til Scrum til å leve med, sett i
forhold til andre smidige metodikker og teknikker som f.eks. Kanban og Lean?
Testopplegget, med uformell testing av sprintene og fossefallsaktig avlutning av
leveranser som skal aksepteres og settes i drift.
Helhetstesten av den samlete leveransen og godkjenningsperioden til slutt.
Utvikling og planlegging i parallell – fordel eller ulempe? Burde de tas sekvensielt? (se
bl.a. 2.2.12)
Hvem som drifter i de ulike situasjonene – er det regulert nøytralt nok, jf at det er flere
muligheter (kundens egendrift, Leverandørens drift, kundens eksterne driftsleverandør),
og avtalen må ikke låse til bare en av disse mulighetene, men være åpen.
Høringsfrist: 24. mai 2012
Høringssvar merkes med saksnummer 2012/118 og sendes til postmottak@difi.no
Direktoratet for forvaltning og IKT