Hvordan bør det første teamet se ut?
| Fase | Typisk sammensetning |
|---|---|
| Nytt produkt eller MVP | 2–3 fullstack-utviklere, 1 designer på deltid, produkteier hos dere |
| Voksende produkt | Frontend- og backend-utviklere, 1 QA-ingeniør, en teknisk leder |
| Skalerende plattform | Flere funksjonsteam, DevOps-ingeniør, testautomatisering, leveranseleder |
Dette er utgangspunkter. Riktig miks avhenger av arkitekturen deres, lanseringsrytmen og hvor mye av teamet dere allerede har internt.
Hvordan fungerer smidige seremonier på tvers av tidssoner?
- Daglig stand-up i de felles timene: europeisk ettermiddag for amerikanske team, når som helst for europeiske team
- Sprintplanlegging og gjennomgang samme dager for alle, med backloggen forfinet skriftlig i forkant
- Asynkrone oppdateringer i saker og pull requests, slik at ingen venter på et møte for å komme videre
- Retrospektiver som inkluderer både utviklerne deres og teamet, ikke separate
Hvordan holder dere kodekvaliteten høy?
- Samme gjennomgangsregler for alle: ingen merge uten godkjenning, i begynnelsen minst én gjennomgåer fra deres side
- Automatiserte tester og linting i pipelinen, slik at kvaliteten ikke avhenger av oppmerksomheten til den som gjennomgår
- Arkitekturbeslutninger dokumentert i korte skriftlige notater, slik at nye utviklere forstår hvorfor ting er bygget som de er
- Jevnlig parprogrammering mellom seniorutviklerne deres og teamet de første månedene
Les videre
Hvordan holdes kildekoden sikker?
Utviklerne jobber bare i repositoriene deres, med personlige kontoer med flerfaktorautentisering og de rettighetene rollen krever. Hemmeligheter ligger i secret manageren deres, aldri i kode eller chat. Tilgang til produksjon er begrenset og loggført, og tilgangen fjernes samme dag som noen forlater teamet. Alle teammedlemmer er bundet av taushetsplikt.
Hvilke leveransemålinger bør dere følge?
| Måling | Spørsmålet den besvarer |
|---|---|
| Deployment frequency | Hvor ofte leverer vi til produksjon? |
| Lead time for changes | Hvor lang tid går det fra commit til kjøring i produksjon? |
| Change failure rate | Hvor stor andel av lanseringene forårsaker en hendelse eller tilbakerulling? |
| Time to restore service | Hvor raskt kommer vi oss når noe går i stykker? |
Hvordan skaleres teamet opp eller ned?
Legg til folk når veikartet, ikke kalenderen, krever det: et nytt produktområde, en plattformmigrering eller en backlog for testautomatisering. Nye utviklere kommer raskere i gang når de blir med i et etablert team med dokumenterte rutiner. Hvis dere må redusere teamet, avtal oppsigelsestid og en overleveringsplan i kontrakten slik at kunnskapen blir værende hos produktet deres.