Blås i smidige team, jeg vil ha smidige applikasjoner!

Skip to end of metadata
Go to start of metadata

Title

Blås i smidige team, jeg vil ha smidige applikasjoner.

Summary

Applikasjoner starter som små, håndterbare prosjekter. Smidige team implementerer effektivt ny funksjonalitet. Applikasjonen vokser, men få produkteiere måler om funksjonaliteten faktisk brukes. Den smidige applikasjonen blir til et beist av legacy, spagetti kode. Her må det ryddes, for å skape rom for ny verdiskaping.

I denne presentasjonen vil jeg vise hvordan vi igjen kan gjøre applikasjonen endringsvillig. Gjennom verktøy, arkitektur og godt håndtverk kan vi trygt fjerne gammel, ubrukt funksjonalitet.

Abstract

Verden forandrer seg, funksjonalitet som ble bestillt og levert for kort tid siden er ikke lenger i bruk. Smidige team mangler mandat og interesse av å synligjøre levetidskostnader for applikasjoner. Vedlikehold binder opp største delen av kostnadene til en applikasjon. Når vi nå håndterer endringsvillige team som en selvfølge, så bør vi sørge for at applikasjonene vi lager også er endringsvillige.

I dag har vi verktøy som kan måle alle funksjonskall i applikasjonen vår, uten å påvirke ytelsen nevneverdig. Vi har endelig mulighet til enkelt å sjekke om den funksjonaliteten som "noen" bestillte faktisk gir verdi for oppdragsgiver i dag.

I dette foredraget vil jeg vise at ved å fokusere på den funksjonaliteten som faktisk brukes, så kan vi vri kostnader fra vedlikehold, til investering i ny verdiskaping. Grunnlaget for denne tryggheten skaper vi ved å forstå hva som egentlig skjer i tjenestene og produktene vi jobber med.
God verktøy som måler all aktivitet, nye verktøy for å vise statistikk gir oss informasjon om faktisk bruksmønster i produksjon. Strategisk bruk av logging, og effektiv varsling ved feil hjelper oss til raskere å avdekke og løse feil.

Key take-away: Skap rom for verdiskaping gjennom å luke ut ubrukt kode som ikke gir verdi til oppdragsgiver, i dag.

Outline

  • Intro - 5 min
    • Fokuser på kode som faktisk skaper verdi, i dag.
    • Problem: Den smidige modellen fokuserer på prosjektet, neste sprint. Modellen støtter ikke livsløpet til en applikasjon.
      • Vedlikehold av ubrukt funksjonalitet skaper uønsket kompleksitet.
      • Vi sletter "aldri" features, vi legger på.
      • Vedlikehold stjeler likviditet fra investeringer som kan gi verdi, og morro.
    • Reduser tid til feilfinning og -retting.
    • Reduser tid fra idee og kostnad, til inntekt genereres.
    • Frykten hemmer oss fra å skape endringsvillige applikasjoner.
  • Hva - 10 min
    • Kjenn din applikasjon.
    • Mål og rapporter all aktivitet i applikasjonen.
    • Rapporter på de bruksmønstrene som skaper verdi.
    • Slett funksjoner som ikke er verdifulle lengre.
    • Rask feilsøking og feilretting
      • Konkret strategi for logging - planlegg hva som skal logges.
      • Strategi for varsling av feil. Separat fra å tyde logger!
    • Dette gir smidigere applikasjon.
  • Hvorfor - 10 min
    • Vite om våre investeringer betaler seg, eller kun skaper fremtidig kostnad.
    • Vri kostnadene fra vedlikeholdsbudsjett til investeringsvilje.
    • Kortere tid fra en idee skapes, til inntekter kommer.
      • Støtte raske endringer i hele levetiden til produktet.
    • Lavere kostnad på feilretting. Let etter virkelige feil, ikke de du tror er der.
    • Stolthet: Skryte av hva vi faktisk har levert!
  • Måle bruksmønstre. - 10 min
    • Hva er et bruksmønster.
    • Hvordan oppdage, og identifisere bruksmønstre i eksiterende applikasjon.
    • Måle bruk og bruksmønster til en feature.
      • Underlag for å si noe om man traff markedet eller ikke.
      • Underlag for å fjerne funksjonalitet.
      • Underlag for å velge hvilke features man vil investere i å videreutvikle og forbedre.
    • Måle responstid og bruk
      • Varsle hvis en for stor andel får dårlig brukeropplevelse pga. høy last eller annet.
      • Varsle hvis bruk av feature minker/uteblir.
    • Støtter prioriteringer for når man må velge manuelle, dyre tester.
  • Basis i verktøy og arkitektur - 5 min
    • Javaagent målinger
    • Rapportering i separat prosess.
    • Varsling på avvik i bruksmønstre i separat prosess.
    • Automatiserte tester vi kan stole på.
      • Stole 100% på features som genererer verdi.
      • Kalkulert risiko på features med lav test-dekning.
    • Overvåkning
      • Verktøy finnes, hvilke hjelper oss.
      • Rapporter alle transaksjoner og bruksmønstre, alltid.
    • Statistikk
      • Eksisterende verktøy
      • Egenutvikling som må til.
    • Logg-strategi
      • Logg fordi det gir verdi til leser, ikke for å avhjelpe utvikler.
      • Gi med nok context info, så feilretting blir enkel.
      • Reduser logg-støyen.
  • Hvordan
    • Måle alle tjenestekall.
      • Kast overflødig informasjon, aggreger på rett nivå.
      • Ta vare på nødvendig informasjon, når den er nødvendig.
    • Bevis verdien for en tjeneste og feature.
      • Bevis at den faktisk brukes.
    • Legg ubrukt funksjonalitet på "wach-list"
      • Verifiser at den ikke brukes.
      • Verifiser at den ikke vil bli savnet, om mulig.
      • Etter x tid eller leveranser, slett koden som støtter denne funksjonaliteten.
    • Fjern funksjonalitet som ikke brukes.
      • Med rett tagging finner du den igjen i versjonstysemet ditt, hvis du må.
      • Testdekningen gir trygghet for at annen funksjonalitet ikke berøres.
      • Kost for å gjeninføre funksjonalitet er antakelig lavere enn kosten den skaper i vedlikehold.
  • Statistikk og oppfølging, valg av metodikk. - 10 min
    • Overvåkning
      • Egen applikasjon. Ser på trender, feil som oppstår.
      • Overvåke hver enkelt transaksjon.
      • Eksiterende verktøy
      • Skreddersydd varsling.
      • Valg av strategi for overvåkning. Hvordan overvåke alle transaksjoner.
    • Statistikk
      • Bruk av features, public metoder.
      • Vise public metoder som ikke brukes.
      • Vise trender på bruk, throughput og responstid.
      • Vise statistikk for hver enkelt transaksjon. Dette muligjør å se avvik som skjules i gjennomsnittsmålinger.
  • Arkitektur - 5 min
    • Hvordan skaper vi sporbarhet i femtidig implementasjon.
      • Forenkler feilsøking, feilretting og sletting i ny kode.
    • Hvordan innfører vi disse prinsippene i eksiterende arkitektur.
    • Bør vi endre arkitektur eller deler av arkitekturen på eksisterende applikasjoner?
  • Key take-away - 2 min
    • It´s fun to erase code, just do it.
    • Forretningsiden vil elske deg, når du reduserer vedlikeholdsbudsjettet på din applikasjon.
      • De vil ha lav driftskost, og høy investeringsfrihet.
  • Q&A - 5 min

Antall minutter != 60, men gir en indikasjon på omfang pr seksjon.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Apr 28, 2014

    Erik: Lean startup fasen
    Test om ting funker i markedet, få ting ut.
    Ta det vekk om det ikke fungerer.
    Punkter 4 og 5 fra http://theleanstartup.com/principles
    Kopier inn på foredraget.

    Det er ikke kode som er viktig å gjenbruke. Det er tankegangen bak som gjelder.
    Koding er billig, tankegangen er dyr.
    Sletting:
    Dokumenter tankegangen bak koden.
    Legg på tag til koden.

  2. Apr 28, 2014

    Bygg på andre sine tanker, det gir dine tanker mer vekt.

    • Lean
    • Logging - Kelvin Hennie