Reflections around estimates in the BankID projects
•Download as PPTX, PDF•
0 likes•42 views
Reflections around estimates in the BankID projects. It is in Norwegian, and is 80+ MB, so careful with your mobile data.
Recommended
Recommended
More Related Content
Similar to Reflections around estimates in the BankID projects
Similar to Reflections around estimates in the BankID projects (20)
Reflections around estimates in the BankID projects
- 4. Live med brask og bram
- 5. estimering
- 6. estimering
- 9. Historien
- 10. Refleksjoner
- 11. Håper dere kan dra nytte av dette!
- 13. Overblikk • 2 prosjekter • Innlogging med nytt produkt • Selv-administrering • Tjenester/produkter • BankID Privat • BankID Bedrift • xID • Partner-sider 13 KNOWIT 09-11-16
- 15. Estimering 15 KNOWIT 09-11-16 Kraftig nedskjæring i scope Ikke godt grunnlag, ullent Ikke UX-skisser Uvisset om 3-parts API-er
- 16. Innlogging – runde 1 16 KNOWIT 09-11-16 Mye var ukjent teknologi Første implmentasjon sub-par Burde hentet inn hjelp Ble refaktorert senere
- 17. “Kontakt oss”-skjema 17 KNOWIT 09-11-16 Gjorde mer enn jeg burde
- 18. Innlogging - runde 2 18 KNOWIT 09-11-16 Økende kompleksitet Brukerhåndtering Lite erfaring Trigget refaktorering
- 19. 3-partsintegrasjoner 19 KNOWIT 09-11-16 I første prosjekt: Uferdige miljøer Kommunikasjon Hvor ligger feilen? Hos oss eller de?
- 20. Ukjente problemer (1/2) 20 KNOWIT 09-11-16 Cross site request forgery Return url Måtte tilbake å gjøre endringer Gjøres både i LPAGE og MPAGE
- 21. Ukjente problemer (2/2) 21 KNOWIT 09-11-16 2 innlogginstyper Hvordan skal disse forholde seg til hverandre? Skapte mer jobb
- 22. Testing 22 KNOWIT 09-11-16 Enhetstester Refaktorering av enhetstester Endringer etter tilbakemeldinger
- 23. Ikke i estimatet 23 KNOWIT 09-11-16 Endringer på sider som ikke skulle arbeides på, men likevel ble berørt
- 24. Refaktorering 24 KNOWIT 09-11-16 Fortløpende Kodebasen skulle bli bedre Tar tid Eksempel: Én frontend
- 25. Rutiner & annet 25 KNOWIT 09-11-16 Code reviews Pull requests Arbeid i JIRA Kommunikasjon Redaksjonelt oppsett av arbeid som er rullet ut i test/stage/prod
- 26. Konsekvens 26 KNOWIT 09-11-16 Det ble fler oppgaver Oppgaver tok lenger tid
- 28. Inntrykk 28 KNOWIT 09-11-16 • Mye tid på å implementere ukjent funksjonalitet • Refaktorerte senere • Må bare begynne i en ende, og scopet vokser underveis
- 29. Kodekvalitet 29 KNOWIT 09-11-16 • Koden skulle være bedre enn den var • Balansegang • Levetid • Burde være tydelig på at jeg gjorde dette • Unngå teknisk gjeld i den grad det er hensiktsmessig
- 30. Estimering 30 KNOWIT 09-11-16 • Hadde ikke ordenlig grunnlag • Ikke UX-skisser • Usikkerhet rundt 3-parts API-er • Ble litt resignert, burde tatt tak, og hentet inn hjelp • Slet med å skjønne hvor mye tid scopet ville ta • Vær negativ
- 31. Spørre om hjelp 31 KNOWIT 09-11-16 • Lettere å spørre når en har en relasjon til den som kan hjelpe • Litt stolthet og nederlag
- 32. Det store bildet 32 KNOWIT 09-11-16 • Forhold til estimatet på den konkrete oppgaven • Ble bare en dato vi skulle rekke • Vanskelig å si tall jeg trodde på
- 33. Joharis vindu
- 35. Dette kan jeg. Dette kan andre. Liten risiko
- 36. Har noen andre gjort dette? Kan jeg få hjelp til å forstå dette? Noe større risiko Dette kan jeg. Dette kan andre. Liten risiko
- 37. Har noen andre gjort dette? Kan jeg få hjelp til å forstå dette? Noe større risiko Er det noe jeg burde fortelle andre? Kompleksitet eller en situasjon jeg ser kommer? Følger jeg meg ikke trygg på estimatet? Noe større risiko Dette kan jeg. Dette kan andre. Liten risiko
- 38. Har noen andre gjort dette? Kan jeg få hjelp til å forstå dette? Noe større risiko Er det noe jeg burde fortelle andre? Kompleksitet eller en situasjon jeg ser kommer? Følger jeg meg ikke trygg på estimatet? Noe større risiko Skal vi lage noe som er ukjent? Har ingen eller veldig få gjort dette? Ukjent terreng. Større risiko Dette kan jeg. Dette kan andre. Liten risiko
- 39. Men, hva blir ofte glemt?
- 40. Tid fra ferdig kode til kunden kan teste. Dokumentasjon og dialog med kunde og team.
- 41. Informasjonsinnhenting. Kommunikasjon. Prosjekter en ikke er allokert på.
- 42. Ikke god nok tid til å estimere. Code reviews, gjennomgang av merge requests. MASSE tid på kommunikasjon med 3-part.
- 43. Dokumentasjon, review av andre utviklere, og ad hoc testing under utvikling.
- 44. Diskusjoner/review. Utvikling av testklienter/relaterte testverktøy/Postman-testing mot API. I vedlikehold; å holde dependencies oppdatert. Release- arbeid.
- 45. Administrasjon og kundekommunikasjon. Man tar ofte ikke høyde for at det går tid på å endre ting etter tilbakemeldinger.
- 46. Møter, code reviews, testing, bug fixing
- 47. Ting som kommer inn etter estimering er vanligvis ikke godt gjennomtenkt. Hvis kunden lager noe uten å involvere UX, kan det føre til mange runder.
- 48. Research tar tid, kan lede til uforutsette utfordringer med teknologien man skal jobbe med. For dårlig krav-spec. Ting som er diskutert i forprosjekt som ikke er blitt med i estimatene fordi jeg ikke var med der. Forarbeid med backlog utrolig viktig. Kan egentlig gange tiden du tror det tar med 2.
- 49. Eksterne avhengigheter. Uforutsigbart hva som skal gjøres. Definition of done. Prosjektleder må involveres. (1/2)
- 50. Teknisk kvalitet Ressursallokering og opplæring Task switching Forventningsstyring (2/2)
- 51. Hva burde en tenke på ved estimering?
- 53. (BEKLAGER)
- 54. Dokumentasjon (1/1) • Skrive • Beskrive tanke bak arkitektur og strukturering av koden? • Tegne • Tegne applikasjonen? For eksempel ved å bruke C4-modellen • Hvilke deler av applikasjonen/oppgaven trenger mest å bli dokumentert i form av tekst og/eller diagrammer? • Innlogging • Implementasjon av business-regler 54 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 55. Implementasjon (1/4) • Ny funksjonalitet • Balanse mellom over-engineering og å ikke lukke døren for senere endringer • Refaktorering av eksisterende funksjonalitet • Ved endringer skal det se ut som om koden var designet for dette fra starten av • Vedlikehold og refaktorering av eksisterende funksjonalitet du berører i løpet av oppgaven • Sikkerhet • Lager du login, eller funksjonalitet som krever autentisering og autorisering? Dette kan kreve at en gjør oppgaven ekstra nøye. • GDPR • Behandling av personopplysninger 55 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 56. Implementasjon (2/4) • Research og opplæring • Er dette ukjent for deg? • Blir ny ressurs satt på prosjektet som trenger opplæring? • Kommentering av kode • Forklar ting som ikke forklarer seg selv, for eksempel implementasjon av business-regler. Gå ut i fra at andre kan lese kode. • Testing • Enhetstesting • Ad hoc-tester du selv gjør • Endringer etter tilbake meldinger fra interne testere og kundes tester 56 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 57. Implementasjon (3/4) • Risiko • Hvor komplekst er dette? • Hvor ukjent er dette for meg, for andre, eller for alle? • Hva vet jeg ikke at jeg ikke vet? • Hvor sannsynlig er det at jeg må reimplementere dette etter at jeg har lært mer om det? • Hvor busniess-kritisk er det at dette fungerer? Burde jeg være ekstra nøye med implementasjon og tester? • Den lille detaljen som alltid ellers pleier å gå smertefritt, og du nå bruker masse tid på 57 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 58. Implementasjon (4/4) • Integrasjon • Dårlig dokumentasjon? • Lang tid å få svar? • Hvor ferdig er tjenesten du skal integrere mot? • Hvor sannsynlig er det at jeg må endre integrasjonen senere ved endringer i 3-partstjenesten? • Må du vente (kalendertid) på at den skal bli ferdig? Legg tid på estimatet. • Skal 3-parts tjenestene testes? Kan de forventes ustabile? Hvordan påvirker dette din løsning? • Kan egentlig gange estimatet med 2 58 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 59. Kommunikasjon (1/1) • Kommunikasjon • Med kunde • Med 3-part • Med UX • Med prosjektleder • Med dedikerte testere • Med interne utviklere (trenger dere diskutere noe?) 59 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 60. Rutiner (1/2) • Bitbucket • Pull requests • Commit messages • Merge reviews • Code reviews • JIRA • Holde seg kjent med backlog • Oppdatere saker • Lage nye saker 60 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 61. Rutiner (2/2) • Definition of done: Hva skal inn i oppgave beskrivelsen? Hvilke steg må være ok før en oppgave er ferdig? • Ad hoc bug-fiksing? • Estimere på rett grunnlag! • Ha UX-skisser • Vit hva som støttes av 3-parts API-er • Det er noenlunde sikkert hva som skal lages • Forventningsstyr kunden • Prosjektleder må legge på sitt påslag på estimatene • Må kjenne til forholdene hos kunde, Tar det lang tid å få avklaringer? • Hvilke eksterne avhengigheter har vi? 61 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 62. Misc (1/1) • Skifte passord • Skrive ut dokumenter • Ringe printer-service • Den filen du ikke fikk med i pull request-en • En test til som burde lages, eller en som burde endres • Booke møte • Glemte å fjerne utkommentert kode eller console.log i en commit/pull request • Merge conflicts 62 KNOWIT 09-11-16 Når du estimerer, tenk over dette
- 63. Ting tar tid. Masse.
- 64. Viktige punkter oppsummert • Kompetanse • Kompleksitet • Research og informasjonsinnhenting • Rutiner • Kommunikasjon • Dokumentasjon • Testing og refaktorering av tester • Eksterne avhengigheter 64 KNOWIT 09-11-16 • Teknisk kvalitet • God nok «Definition of done» • Endringer etter tilbakemeldinger • «Kritisk» kode • Hvor krevende er kunden?
- 66. Spørsmål?
- 67. Takk til alle som kom med innspill!
Editor's Notes
- Hello! Jeg skal snakke om…
- Når vi lager de utrolig flotte løsningene våre….
- …som går live med brask og bram, er det en ting vi både har gjort, gjort noe av, og ikke gjort i samme prosjekt…
- Estim…
- Estimering!
- For å unngå kunder som er mindre imponert, er det bra å få…
- …tiden rett. Jeg har jobbet et års tid med 2 prosjekter for BankID, og skal nå fortelle litt om erfaringer rundt estimering i disse prosjektene. Fokuset ligger nok på prosjekt nummer to. For min del var dette relativt komplekse prosjekter, men en del ukjente elementer. Prosjektene gikk over budsjett begge to.
- Først skal jeg fortelle en kort versjon av historien om propsjektet - noen utvalgte highlights, og noen mer generelle punkter. Jeg vil fortelle litt om hvorfor disse tingene var utfordrende, og hva konsekvensen av dette ble.
- Etter at jeg har fortalt historien, vil jeg fortelle litt hva jeg tenker rundt estimering i disse prosjektene.
- Jeg håper dere lærer noe av historiene og tankene jeg skal fortelle, og unngår kjedelige situasjoner andre prosjekt!
- 2 prosjekter: #1 LPAGE (Landingsside for xID) #2 MPAGE (En “Min side” hver for xID og BankID) Tenkniske utfordringer som håndtering av innloggede brukere, utlogging, integrasjoner mot OIDC, Service Desk, Confluence, API-er. Det eksisterte også partnersider, både for ikke-innloggende brukere og innloggende brukere. Dette skulle ikke endres på, bare beholdes slik det var. LPAGE ble utviklet samtidig ved at arbeid ble gjort på xID og TINFO (tjeneste for lagring av tilleggsinformasjon). Dette førte til tidvis ustabile 3-partsmiljøer.
- Nå for en reise gjennom forskjellige historier fra prosjektene
- MPAGE: Kraftifg nedskjæring i scope (10-12 millioner til 2 millioner). Ullent grunnlag. Lite UX-skisser, lite visshet om hva 3-part støttet. Estimatet ble aldri brutt ned i småbiter. I starten av MPAGE ble scope kraftig kuttet for å ligge under 2 millioner, slik at prosjektet ikke måtte godkjennes av styret. Videre ønsket kunden ha dette klart i starten av juli. Det var gjort noe arbeid av Bekk, som vi overtok. Men etter nedskjæringer i scope, var det ikke så mye igjen av det Bekk hadde gjort, og vi måtte inn med en UX-jobb. For progresjonens del, forsøkte vi å estimere basert på avtalt scope for hva som skulle lages, men uten ferdige UX-skisser, og uten å vite helt hva 3-parts API-er kunne støtte. Kom omsider i gang.
- Dette var et ukjent område for meg. Jeg hadde ikke mye erfaring med OIDC fra før. Jeg leste, og prøvde meg frem. Jeg var usikker på hva som eksisterte av ferdig funksjonalitet for dette allerede. Visste det var noe, men var usikker på om jeg kunne bruke noe som kunne integrere med Episerver. Var også usikker på hva som fantes i .NET-verdenen. Gjorde et spakt forsøk på å spørre etter hjelp, men fant etter hvert litt ut av det, og skrev en løsning hvor jeg gjorde en del selv. Senere fant jeg noen mer ferdigkomponenter i .NET-verdenen. Refaktorerte til å bruke disse. Leste nå ut OIDC URL-er fra config URL-en, i stedet for å ha disse i web.config. Usikker på om jeg hadde ivaretatt sikkerheten godt nok. Fant etter hvert en løsning som jeg slo meg til ro med. Benyttet meg av state og nonce som jeg kunne sende med inn. Validerte requesten som kom tilbake. Hadde den en feil? Hadde den en authorization code? Var det riktig http request type? Hentet tokens, hvor jeg validerte nonce-en som lå i de. Hentet ut claims fra tokens, som jeg gjorde noe validering på. Hadde heller ikke egentlig håndtert innloggende brukere noe særlig før. Baserte meg på hvordan dette var implementert for eksisterende innloggede partnersider. KONSEKVENS: Research, sub-par kode, som senere ble refaktorert opp til flere ganger.
- GJORDE MER EN JEG BURDE, UKJENT HVA: Dette skjemaet skulle sender saker til BankID JIRA Service Desk. Det tok tid, inkludert kommunikasjon med kunden, å finne ut av hvordan jeg kunne opprette en sak i service desk via API-et, samt legge ved et vedlegg. Et annet punkt jeg brukte mye tid på var en fallback hvis ikke ajax-funksjonaliteten brukt ved filopplasting var støttet. I dag er jeg usikker på om dette var nødvendig. Jeg burde hørt med noen, sjekket det ut bedre, og sannsynligvis ikke brukt så mye tid på det. Brukte også litt tid på skjemavalidering som må kjøres både i nettleseren, og på serversiden. Samt hvordan brukeren fikk feedback om valideringen feilet på serveren. Jobbet også med request limiting, så ingen skulle kunne spamme JIRA-en deres for mye. Samt at det bare skulle kunne sendes én request om gangen. KONSEKVENS: En del tid brukt på å løse integrasjonen, men by far mest tid på fallback-filopplasting, og hvordan stilingen skulle oppføre seg på mobil og desktop.
- Ny innlogging. Kompleksiteten rundt innlogging, utlogging, og brukerhåndtering øker. Ikke jobbet mye med før. Trigget refaktorering. Mye jobb ble gjort litt slik: «Jeg vet ikke helt hvordan dette skal løses, så jeg må bare begynne å gå». Prøving og feiling, forsøke å få en god struktur på det hele, og få mye av det testet, tok lang tid. Mye ukjente områder for meg.
- Tidvis ustabile 3partsmiljøer. Delvis også uferdige 3-partsmiljøer, men det var mest under LPAGE-prosjektet. Kommunikasjon tar tid. xID og TINFO ble utviklet parallelt med LPAGE, så 3-partssystemer kunne gå ned. Ved feil i funksjonalitet relatert til integrasjonene, ble man feilsøkende for å finne ut hvor feilen lå. Lå den hos 3-part, måtte dette rapporteres inn. All kommunikasjon tar masse tid. Det skal nevnes at 3-partene har vært hyggelige folk KONSEKVENSER: Ting tar tid. Igjen.
- Oppdaget i ettertid. Fant sikkerhetshull. Måtte «tilbake» å gjøre sikkerhetsarbeid. Måtte legges både i LPAGE og MPAGE. KONSEKVENS: Disse sikkerhetsissue-ene visste andre om. Anti forgery token var allerede implementert. Dette kunne jeg funnet ut av tidligere, men jeg tenkte bare ikke på dette.
- Et annet eksempel på noe som ble funnet i ettertid. Hvordan skulle innlogget xID- og BankID-bruker forholde seg til hverandre? Når dette var avklart, ble de nødvendige endringene implementert, som endte med refaktorering og omstrukturering. KONSEKVENS: Dette ble igjen ekstra tid som jeg ikke hadde forutsett.
- Det tar mye tid å skrive enhetstester, og å refaktorere disse ved endringer i den testede koden. Det tar tid å gjøre endringer etter intern og ekstern test. HVA: Ved forskjellige anledninger måtte tester refaktoreres og skrives om. Jeg forsøkte også å legge til tester i deler av logikken som ikke hadde dette, hvor jeg mente det burde være tester. Mye tid gikk også på endreinger etter tilbakemelding fra enten intern eller ekstern test.
- Innloggede og ikke-innloggede partnersider skulle ikek gjøres noe med. Frontend-endringer påvirket disse sidene. Vi la ingenting i estimatet for dette. Funksjonalitet som ikke skal røres kan likevel få litt tid i estimatet, for sikkerhetsskyld.
- Vedlikehold og refaktorering skulle gjøres fortløpende. Ønsket å gjøre kodebasen bedre. Burde kanskje hatt noe mindre fokus på det, men en bør også forebygge teknisk gjeld, slik at ikke den skaper unødvendig mye problemer senere. Å ta vare på kodebasen tar tid. I starten av LPAGE (det første prosjektet), ble det bestemt at LPAGE (landingssiden for xID) skulle legges i samme løsning som bankid.no for å spare Episerver-lisenskostnader. Kunden ønsket at LPAGE skulle kunne plukkes lett ut av løsningen, og dermed ble det med hensikt duplisert en del logikk mellom bankid.no og LPAGE, slik at denne skulle plukkes relativt greit ut av bankid.no-løsningen. Dette inkluderte f.eks. frontend. LPAGE fikk en egen frontend, og benyttet bl.a. Bootstrap. Bankid.no benyttet ikke bootstrap. View og frontend-messig, levde bankid.no og LPAGE i hver sin verden. Noe av ønsket i MPAGE var å slå sammen disse 2 verdene, men i et prosjekt presset på tid, kunne dette bli en utfordring. Det endte med at vi gikk for å slå de sammen. Vi ønsket også å gå fra en klassisk MVC-mappestruktur, til en Feature-inndeling. Der kom vi ikke i mål. Dette vedlikeholdet ble gjort sammen med nyutvikling, som en del av de oppgavene. Vi forsøkte å legge inn tid i estimatet slik at det skulle være tid til å ta refaktorering fortløpende per oppgave. Vi kunne nok lagt på mer. Utfordring med budsjettrammen på 2 millioner og tidsfristen for levering av prosjektet.
- Rutiner tar også tid. Code reviews, kommunikasjon, møter, oppsett i test/stage/prod. Jeg brukte litt over en uke på redaktørarbeid når vi rullet ut MPAGE til stage. Jeg hadde aldri trodd jeg kom til å bruke ca en uke i strekk med redaktørarbeid for å sette opp den nye løsningen i stage. Det tar tid å kummunisere. KONSEKVENS: Tiden gikk.
- Ting var ukjent, og da ble dette konsekvensen. Som dere skjønner, når en jobber med noe ukjent, begynner fort scope å vokse. Det var stadig vekk ting som meldte seg, for eksempel sikkerhetshensyn eller refaktorering. Når viktig logikk som er testet endres, må det testes på nytt. Tester må skrives om. Konsekvend? Tiden går.
- Mye tid å implementere ukjent funksjonalitet. God mulighet for å måtte skrive om implementasjonen og tester senere. Måtte bare begynne i en ende, og se hvor det gikk. Inntrykket jeg sitter igjen med er at det tar mye tid å skulle implementere denne type ukjent funksjonalitet. Dette er fordi når du har implementert den en gang, og skrevet tester, er det en god mulighet for at du må skrive det om senere, og derav også testene igjen. Og tester tar det tid å skrive. Når en jobber med områder hvor en ikke har så mye erfaring, er det også en god sjanse for at det ting du ikke vet at du ikke vet, ting som dukker opp, både under utvikling, og i etterkant, som vil ta tid. Mye av programmeringen rundt de mer komplekse områdene i applikasjon var jeg usikker på hvordan jeg skulle løse, og måtte bare begynne i en ende, for å se hvordan det kunne gjøres. Som et resultat, vokste scopet. Det kan også være små ting som trekker ut tiden, detaljer i koden som trigger omskriving.
- Koden skulle være bedre enn den var. Refaktorering og vedlikehold burde ofte legges inn som en del av estimatet i en oppgave. Ettersom en ønsker å gjøre en god jobb, og et ordentlig håndtverk, ønsket jeg i utgangspunktet å forlate koden bedre enn den var da jeg startet. En må finne en balansegang mellom å ikke over-engineere, men heller ikke gjøre det veldig vanskelig å legge til senere funksjonalitet. Jeg mener at refaktorering og vedlikehold burde ofte legges inn som en del av estimatet i en oppgave, fordi det er nødvendig å være pro-aktiv i å ta vare på kodenbasen. Jeg burde også vært tydligere på, og sagt i fra om, refaktorering og vedlikehold som ble gjort til prosjektleder. Tanken når vi estimerte var at denne typen jobb var en del av hvert estimat, og vi skulle ta denne jobben løpende mens prosjektet ble jobbet med. Det synes jeg fortsatt er en god idé. Det tar tid å skulle få en god struktur på kodebasen, og å sørge for at du ikke har referanser dit de ikke burde være og at logikk ligger i rett lag av applikasjonen. Hele løsningen er jo et slags puslespill man skal få til å passe sammen best mulig, et sett med legoklosser en skal bygge sammen på en god måte. Men, når jeg har dette i bakhodet, må jeg si fra om dette, så andre enn meg også vet at jeg jobber på denne måten. Her burde jeg sikkert også vært hardere på hva av refaktorering som jeg burde gjort og ikke gjort. Det ble nok gjort mer enn jeg trengte, samtidig kan dette fort bli et to-egget sverd som treffer deg senere. Teknisk gjeld kan koste mye på sikt. Det var også tidvis en tanke om at «gjør ikke jeg det nå, blir det heller aldri gjort». Med erfaring vil man kunne kjenne igjen røde flagg når de dukker opp. Det er det ikke sikkert en gjør, men et flagg kan man stort sett se; og det er når du ser at jeg rekker ikke dette innenfor estimatet.
- Ikke UX-skisser. Ikke sikre 3-partsintegrasjoner. Ullent. Vær negativ. Gang estimatet med 2. Slet med å forstå scope-et. Litt resignert mtp estimater. Vanskelig å gi tall en trodde på. Burde hentet hjelp. Det hjalp heller ikke prosjektet å skulle estimere uten UX-skisser, og uten å noenlunde sikkert vite hvordan integrasjonene mot 3-parts API-er kom til å bli. Da blir det et ullent estimat, hvor en synser som best en kan. Et tips som alltid er lurt når en estimerer, er å være litt negativ, for ting tar tid. Kanskje denne oppgaven går litt under estimat, men neste oppgave går plutselig en del over. Da er det bra å ha en time-buffer i prosjektet. Når jeg var på skolen, hadde vi et fag et halvår hos Funcom. Der husker jeg vi ble fortalt at en kunne så å si gange estimatet sitt med PI, 3.14. Over 3 ganger så mye virker som en del, men en kan gange i alle fall med 2, som jeg også fikk feedback på når jeg spurte litt rundt om hva folk opplevde at var den største tidstyven i en oppgave som gjør at estimatet sprekker. Du angrer ikke når du har passert orginalestimatet ditt, men fortsatt har masse tid igjen fordi du ganget med 2. En ting som jeg ikke klarte var å forstå hvor lang tid det scope vi hadde ville ta å gjennomføre. Tech-lead på prosjektet trodde ikke på at vi kom til å rekke starten av juli. Jeg sa ikke noe på det, men det satt seg liksom ikke skikkelig. Jeg hørte det, og hadde det i hodet, men den overbevisningen som kommer når noe «klikker», var ikke der. Det viste seg at det var helt rett. Det å faktisk ha et forhold til hvor lang tid noe tar fordi du har gjort lignede, eller har lang erfaring, er utrolig nyttig. Jeg tenkte litt sånn at «hvis alt går bra, kan vi jo kanskje rekke det». Men, ting går ikke bra. Jeg ble litt resignert med tanke på estimater i prosjektet, og tok ikke ordentlig tak i å se på hvor lang tid resterende oppgaver ville ta. Hva ville vi bruke tid på? Hvor mye tid skulle jeg bruke på å gå igjennom backlog-en i detalj for å estimere resterende oppgaver, vs å få jobbet videre med programmeringen? En annen ting som gjorde det vanskelig å si noe om hvor lang tid noe ville ta, var følelsen av at de fleste oppgavene tok så lang tid, og at jeg slet med å forutse det. Oppgaver varte å rakk, og da ble det vanskelig for meg å si noe om når de var ferdig. Dette var nok mye på grunn av at det var en del nytt for meg, mye som hadde dukket opp underveis. «Noen dager til» kunne liksom bli en del flere dager til enn det. Da ble det vanskelig å levere fra seg tall som jeg selv trodde på. Her burde jeg nok tatt en timeout, funnet noen som hadde mer erfaring, og gått igjennom backlog-en sammen for å se på oppgaver som sto igjen.
- Lettere når en har en relasjon til personen du spør. Var litt stolthet og nederlag i det også. Med tanke på det å spørre om hjelp, så tror jeg for min del å kjenne personen du spør og/eller å ha jobbet med personen før, minsker terskelen en del. Når en jeg hadde en bra relasjon til var tech lead en periode, var det veldig liten terskel for meg å spørre ham, som også satt ved siden av meg. Det dro både jeg og prosjektet mye nytte av. Vi fikk en ny tech lead på prosjektet, men han var jeg ikke noe flink til å spørre om råd. Det var flere ganger hvor jeg burde spurt om råd og hjelp. Det kan ha gått litt på stolthet også, kanskje oppfattes litt som et nederlag, men det var egentlig tullete å ikke forsøke å bruke ham mer.
- Estimatet ble bare en dato vi skulle rekke. Kun estimat på større deler av applikasjonen, ikke tydelig hvor lang tid du hadde per mindre del, burde tatt mer ansvar på det. Går du over estimatet, si i fra så tidlig så mulig. Det er viktig å ha et estimat på små deler av løsningen, ikke bare de større delene av løsningen. For min del ble estimatet en stor helhet, og en dato vi skulle rekke. Her burde vi kanskje gått over estimatene når design og tredjeparts-API-ene begynte å lande litt mer, brutt estimatene litt mer opp etc, kanskje skrevet timer på JIRA-oppgavene. Vi hadde kun timer på større områder av applikasjonen, så hvor lang tid du egentlig hadde på en liten sub-del av applikasjonen var ikke tydelig, men heller ikke noe jeg tenkte på. Når oppgaver blir oppdaget og lagt til i JIRA underveis, oppgaver som måtte gjøres, vokser timebruken. Jeg tror estimatet ble slik fordi grunnlaget som estimatet ble opprinnelig gjort på var utydelig og ullent. Når ting begynte å komme på plass, var det bare å begynne å jobbe. Uheldigvis, når jeg gang etter gang ikke klarer å svare på hvor lang tid det er igjen, går det utover tilliten til deg. Hvis du ser at du går over estimat, rop ut så tidlig så mulig! Hvis du ser at alt tar tid, må du kanskje ta et skritt tilbake å evaluere det større bildet for å få et inntrykk av hvordan ting går. Jeg vet også at i MPAGE-prosjektet hadde vi utfordringer i kundekommunikasjonen. Jeg tror det var en del kommunikasjon som gikk forbi hverandre. Dette var det ikke jeg som følte mest på, men hovedsakelig UX og prosjektledelsen.
- Nå i det siste har jeg tenkt litt, og kom til å tenke på Joharis vindu. Kjenner noen til dette? Det er egentlig ikke tiltenkt estimering, men en kan trekke konseptet inn dit. Egentlig er det en teknikk for å bedre forstå seg selv og ens forhold til seg selv og andre. Men, skal jeg synes litt og bruke det med tanke på estimering/arbeid med et prosjekt. Jeg har skrevet inn noen setninger i hver rute som kan være kjekke å tenke på når en estimerer eller skal gjøre en oppgave.
- Her kan du se vinduet. Egentlig tror jeg deg selv og en annen skal skrive inn adjektiver fra et sett med adjektiver i rutene. Slik ser man hva andre tenker og vet om deg, og hva du tenker og vet om deg. Dette kan oversettes til spørsmål/tanker en kan stille seg selv når en ser på et prosjekt eller oppgave.
- Dette vet alle.
- Hva vet ikke jeg som andre vet?
- Hva vet jeg som andre ikke vet?
- Gjør vi noe helt nytt?
- Jeg spurte litt rundt for å finne ut hva personer mente ofte ble glemt i forbindelse med et estimat. Tusen takk for alle som delte sine tanker. Jeg tenkte vi kunne klikke igjennom og se på hva som ble nevnt. Jeg har omskrevet noe og oppsummert. Hvis noen kjenner igjen noe de sa som ble feil, er det bare å ta kontakt med meg etterpå.
- Snakket litt lenger med en om hva som burde være med i et estimat. Praten gikk mest med utgangspunkt i MPAGE-prosjektet. Punkter på denne og neste slide.
- Ting å tenke på når en estimerer en oppgave eller et prosjekt.
- Spesielt masse 3-partsutvikling som din løsning bruker.
- - Kompetanse: Hvor godt jeg kan og/eller andre dette? - Kompleksitet: Hvor vanskelig er dette? - R&I: Hvor mye info trenger vi finne ut om dette? - Rutiner: Code reviews, utrulling, oppsett i miljø, holde seg up-to-date i JIRA - Kommunikasjon: Internt, kunde, 3-part - Dokumentasjon: I kode og i wiki/readme etc - Testing: Skriving av enhetstester og refaktorering av disse - Eksterne avhengigheter: Er dere avhengig av avklaringer, API-er, 3-part (litt det samme som kommunikasjon) - Teknisk kvalitet: Er løsningen bruk og kast, og teknisk gjeld irrelevant, eller bør vi bruke tid på å holde teknisk gjeld nede? Vedlikehold og refaktorering - DOD: Hvilke flyter må en oppgave igjennom før den er ferdig? Godkjenning av kunde? Annet? - Endringer etter test av kunde: Her kan det gå noen runder - Hvor nøye bør jeg være med koden jeg skal skrive, og hvor nøye bør jeg teste den? - Hvor krevende er kunden: Skal de detaljstyre?
- Ikke vær for optimistisk når du estimerer, men ellers er det greit!
- Spørsmål?