Skip to end of metadata
Go to start of metadata

Et lite utsnitt av det jeg oppfatter som en spennende diskusjon som flere burde henge seg på.. (anonymisert diskusjon gjengitt med tillatelse)

a: lest denne? http://leanandkanban.wordpress.com/2009/06/10/lean-software-development-achieving-better-requirements/
b: vet ikke helt om jeg kjøper det derre flow-greine
a: det ligger mye der, uten tvil, men om det er løsningen på alt er et åpnere spm...
b: det er jo opplagt ikke løsningen på alt
a: spesielt i offentlg/helse mm
a: NAV er jo et premieeksempel
b: og jeg er svært usikker på hvor riktig jeg synes de sammenligningene med japansk bilindustri er
b: software-utvikling er ikke det samme som samlebåndproduksjon av biler
b: hadde vært artig å sett noen studier som beskriver hvordan de bedriftene jobber nå
b: det meste av det det referers til er jo rimelig gammelt
a: poenget er å analysere problemet/bruk for å løse de virkelige problemene og ikke det man tror er problemet.... spesielt der hvor man ikke har konkurranse og opplever at kostnadene går opp når man "automatiserer"
b: "poenget er å analysere problemet/bruk for å løse de virkelige problemene og ikke det man tror er problemet.... " - er vel ingen, uansett metodikk, som er uenig i dette?
b: jeg synes egentlig det er litt paradoksalt.
b: veldig mange i smidig-miljøet er jo tilhenger av "start å kode tidlig -> rett opp underveis"
b: det trenger seff ikke være en motsetning
b: men det kan definitivt være det
a: problemet med Smidig og Lean er at de henger seg på "trenden", men de har ingen forhold til metodikken for å analysere og måle den typen "waste" vi snakker om her
a: så de tar ikke over seg det virkelige problemet/utfordirngen (f.eks ved en Sigma Six analyse eller tilsvarende)
b: så de optimaliserer i blinde
b: det er jeg helt enig i
a: men i enterprise setting, så kan det å starte å kod etidlig ha en mening, iom at det ofte er raskere å utvikle en løsning enn det er å komme frem til enighet
b: nedvurderingen av betydningen av grundige analyser er noe av det som jeg synes agile er dårligst på
a: jeg skjønner motstanden på endel analyser... men det å få analysert problemet bør ikke nedprioriteres
a: hvis det droppes, så er det bare flaks dersom man lager en løsning som løser problemet
b: jeg er helt enig i at en del analyser er unødige, og at det da vil være mer hensiktsmessig å bare "Kjøre på". Et av problemene er kanskje at man ikke har noen metodikk for å skille disse situasjonene

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 30, 2009

    Tror man ofte glemmer å ta utgangspunkt i (eller sjekke hvilke krav til) forventet levetid for et system, og hvor viktig time-to-market er for et gitt produkt. For NAV er levetiden stort sett veldig lang, mens time-to-market er, viktig mhp avtalt tid & kost, men sjelden svært kort som avgjør om det er noe vits i lage produktet overhodet. I et lite privat oppstartsselskap blir disse betingelsene snudd på hodet, selv om det ikke gir noe blanko fullmakt til å lage et makkverk som ikke vil fungerer ved produktlansering. Da kan man jo heller bruke pengene og tiden på noe fornuftig som å gå på kino e.l.

    Jeg synes et viktig poeng er at man får levert noe, slik at man starter læringsloopen. Det gjelder uansett kort- eller langsiktig levetid. Hvorvidt koden skal ha lang levetid blir en avveining som må gjøres på forretningsmessig basis med input fra markedsmessige, tekniske og økonomiske vurderinger.

  2. Oct 12, 2009

    Fra samtale med en fra "kundesiden" fikk jeg høre at etter de gikk over til smidig utvikling (de har holdt på 3-4 år), så har de fått mer forutsigbare leveranser, hyppigere og bedre kvalitet (dvs. mindre bugs). Dette er de selvsagt fornøyd med.

    Samtidig sier de at de har fått dårligere arkitektur, og dårligere treff på business caset, dvs. det leveres mindre verdi enn forventet.

    Jeg synes å høre tilsvarende fra andre miljøer, så jeg tror ikke dette er unikt for denne kunden. Det står ikke noe i smidige bøkene at det skal være slikt - snarere tvert imot, vi skal ha knallhard fokus på verdi, og gjennom refactoring, kontinuerlig bygg, masse testing, så skal vi ha en knakende god arkitektur som tar til seg læring underveis.

    Noen hypoteser på hvorfor man allikevel "sklir" ut kan være:

    • Kompetanse om hvordan man skaper verdi for virksomheten er ikke alltid tilstede når det tas beslutninger i smidige prosjekter; jeg mistenker at det i realiteten er mye brukerfokus, men ikke nødvendigvis god verdi-fokus (og det er ikke gitt at brukerne vet hvordan virksomheten tjener penger...).
    • Tilsvarende når det gjelder arkitekter; de er ikke tilstede eller deres kost/nytte betraktninger blir ikke tatt hensyn til når det tas beslutninger i smidige prosjekter, f.eks. knyttet til vedlikeholdbarhet eller andre kostnader som kommer i etterkant av prosjektet (ref. teknisk gjeld som er blitt et populært tema...)

    Mao. jeg tror ikke smidig/lean tankegodset er direkte feil, men dersom man ikke har riktig kompetanse tilgjengelig er risikoen veldig stor for at det tas beslutninger på feil grunnlag. Måter å bøte på dette er f.eks. å gjøre analyser og få fram disse føringene, slik at prosjektet i det minste er kjent med det. Samtidig må vi for all del ikke gå tilbake til den forherligelse vi hadde på slutten av 90-tallet av lange dokumenter og kompliserte modeller. Det gjorde at vi ikke fikk gjort noe som helst før det var for sent...og de dokumenter vi skulle lese var så store og tunge at ingen orket å gjøre det...

    1. Oct 12, 2009

      Noen hypoteser på hvorfor man allikevel "sklir" ut kan være:

      Det jeg stort sett finner som nummer en årsak på mindre verdi, er faktisk kombinasjonen av prosjektøkonomi (som bare ser på kostnadsbildet) og featuredrivet (flest mulig user-stories/tidsenhet) som lett gjør at man nedprioriterer momenter som vil øke verdien. Husk at prosjektet kun er kostnader - det er i produksjon at verdiene skapes og her er forvaltbarhet, konfigurasjon og "god" arkitektur faktisk viktig

      1. Oct 12, 2009

        Jeg tror at det er et par viktig ting her:

        • Scrum har fokus på hva som skal leveres i neste sprint, dette kan fører til kortsiktighet
        • Avgjørelser kan bli tatt lengre ned i hierarkiet, hvor man ikke nødvendigvis har helhetsbilde