Skip to end of metadata
Go to start of metadata

Foredrag: Niklas Bjørnerstedt

Hvem er jeg: 10 år Smalltalk, 10 år som produkteier, visjon: profesjonalisering av kunderollen i IT-prosjekter

(Tankenotater for foredraget)

"Intuitivt riktige" ting er noen ganger helt feil

To typer av konverteringsprosjekter: endre eller skrive nytt
(inviter Bjørnar Evenshaug fra CSC for å snakke om SICSnt: 100 000 klasser, Smalltalk->Java)

Ofte falskt behov - hva er det egentlige motivet?

  • Se opp for big bang - du dør
  • Agile Release Strategy wikien - mye "internalisert kunnskap"
  • Felles språk viktig
  • Samle erfaring fra ulike kontekst (Shared database eksempel)

Studer gammelt system

  • Myte at kunnskap om gammelt system blinder deg.
  • Bruk tid på å forstå gammelt system: det vil gi ideer, ikke ta bort dem
  • Lettere å forstå brukerne
    (Bokklub eksempel: distribusjonstabellen)
    Krev at utviklerne bruker det gamle systemet i noen dager
    "Hvis du behandler et system som en black box så tenderer det å se ut som en monolitt"

Absolutte deadlines dreper - du trenger mye større margin enn du antar

Replacement prosjekter har ikke brukerverdi - skummelt. Hvordan gi prosjektet verdi for brukere?

Hva skal bygges først?

  • Verdifundamentaliser: "størst brukerverdi"

Hva er verdi i et replacement prosjekt?

  • mest sentral funksjon?
  • fortest i produksjon?
  • størst risikoreduksjon
  • mest økt kunnskap
  • størst reduksjon i endringsmengde på eksisterende system

Vanlig startposisjon:

  • lite kjennskap til gammelt system
  • nytt team
  • nye verktøy
  • ny kunderelasjon

...
Burde vi ikke velge "enkle" oppgaver først?

Vanlige kilder til overraskelser i replacement prosjekt:
dynamiske egenskaper - tid
Bokklubb eksempel og inkasso

Labels:
presentasjon presentasjon Delete
presentation presentation Delete
year2010 year2010 Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 14, 2010

    "Studer gammelt system"

    Den viktigste verdien med å sette seg inn i gamle system er at man sikrer et vist felles nivå av domenekunnskap som er sentralt for å sikre riktige og verdiskapende valg i erstatningsprosjektet. Men man må passe seg for den motsatte myten: "det gamle systemet er fasitten" som gir fastlåsthet og et system med de samme egenskapene og svakhetene som man kanskje ønsket å fjerne med erstatningsprosjektet.

    "Absolutte deadlines dreper"

    Erstatningsprosjekter er mere utsatt for forsinkelser enn greenfieldprosjekter. IMHO så har dette lite med selve prosjektkompleksiteten/planen å gjøre, men med den overdrevne risikoaversjonen for selve switchen, og kan dermed ikke løses med å gi prosjektet lengre tid - det eneste som hjelper er en gradvis side-by-side strategi.

  2. Jan 14, 2010

    Helt enig. Med absolutte deadlines mener jeg deadlines av typen: 1.1.2011 vil det gamle systemet slutte å virke. Nytt system må være i drift før den dato, ellers er det konkurs.

    Hvis man har en deadline av denne typen så må man få det nye systemet i drift med så stor margin som mulig. Min erfaring er at mange i denne situasjonen opererer med for liten margin.

  3. Mar 17, 2010

    Hei Niklas

    Interessant at du nevner SICSnt. Du var selv med på omskrivingsprosjektet (skrev COBOL SICS om igjen fra grunnen av, i Smalltalk), og de siste årene har vi konvertert systemet fra Smalltalk til Java. Begge deler har vært vellykket. Begge deler tok lengre tid enn først planlagt.. Liten tvil om at en forutsetning for at omskrivingsprosjektet lyktes, var anerkjennelse av funksjonaliteten i det systemet som ble skrevet om, og respekt for kunnskapen til de som kjente systemet. "Lyktes" i denne sammenheng, betyr at eksisterende kunder (globalt) og markedet generelt aksepterte det nye systemet, og oppgraderte/implementerte det.

    I dag sliter vi litt med at kunder vegrer seg for å implementere Java-versjonen. Utfra risikovurdering.. (les: frykt..). Smalltalk-versjonen er stabil og fungerer godt. Java-versjonen er identisk (funksjonelt, brukergrensesnitt, osv), derfor lite insentiv til å oppgradere, samt at man frykter et mer ustabilt system. Til de grader at noen kunder heller betaler T&M for rettelser et års tid (support avsluttes i juni i år) enn å være blandt de første som oppgraderer.. Heldigvis viser første test-erfaringer fra kundene at også Java versjonen er så stabil som vi forteller dem at den er..

    Snakkes.

  4. Mar 18, 2010

    Ja, dere var på en måte i en heldig situasjon. Selv om systemet skulle skrives om, var det mye i det gamle COBOL systemet som kunne brukes som inspirasjon for det nye. Mange organisasjoner sliter med legacy system som er basert på en helt utdatert måte å løse oppgaver på.

    Hva gjeller det å få kunder over på Java versjonen så burde du se litt på: http://wiki.cantara.no/display/ARS/Differentiators. For at en kunde skal velge å bytte system må det nye tilby noe som de virkeli ønsker. Det er mye viktigere enn "feature parity".