Hur bör det första teamet se ut?
| Fas | Typisk sammansättning |
|---|---|
| Ny produkt eller MVP | 2–3 fullstackutvecklare, 1 designer på deltid, produktägare hos er |
| Växande produkt | Frontend- och backendutvecklare, 1 QA-ingenjör, en teknisk ledare |
| Skalande plattform | Flera funktionsteam, DevOps-ingenjör, testautomation, leveransansvarig |
Det här är utgångspunkter. Rätt mix beror på er arkitektur, er releasetakt och hur mycket av teamet ni redan har internt.
Hur fungerar agila möten över tidszoner?
- Dagligt stand-up under de gemensamma timmarna: den europeiska eftermiddagen för amerikanska team, valfri tid för europeiska team
- Sprintplanering och sprintgenomgång samma dagar för alla, med backloggen förfinad skriftligen i förväg
- Asynkrona uppdateringar i ärenden och pull requests, så att ingen väntar på ett möte för att komma vidare
- Retrospektiv som omfattar både era ingenjörer och teamet, inte separata
Hur håller ni kodkvaliteten hög?
- Samma granskningsregler för alla: ingen sammanslagning utan godkännande, till en början minst en granskare från er sida
- Automatiska tester och linting i pipelinen, så att kvaliteten inte beror på granskarens uppmärksamhet
- Arkitekturbeslut dokumenterade i korta skriftliga anteckningar, så att nya ingenjörer förstår varför saker är byggda som de är
- Regelbunden parprogrammering mellan era seniora ingenjörer och teamet under de första månaderna
Läs vidare
Hur skyddas källkoden?
Ingenjörerna arbetar bara i era repositorier, med personliga konton, flerfaktorsautentisering och de behörigheter som rollen kräver. Hemligheter finns i er secret manager, aldrig i kod eller chatt. Åtkomst till produktion är begränsad och loggad, och åtkomsten tas bort samma dag som någon lämnar teamet. Varje teammedlem är bunden av sekretessförpliktelser.
Vilka leveransmått bör ni följa?
| Mått | Fråga det besvarar |
|---|---|
| Driftsättningsfrekvens | Hur ofta levererar vi till produktion? |
| Ledtid för ändringar | Hur lång tid tar det från incheckning till att koden körs i produktion? |
| Andel misslyckade ändringar | Hur stor andel av releaserna orsakar en incident eller återställning? |
| Tid till återställning | Hur snabbt återhämtar vi oss när något går sönder? |
Hur skalas teamet upp eller ned?
Lägg till folk när färdplanen, inte kalendern, kräver det: ett nytt produktområde, en plattformsmigrering eller en backlogg för testautomation. Nya ingenjörer kommer snabbare i gång när de ansluter till ett etablerat team med dokumenterade arbetssätt. Om ni behöver minska teamet bör ni komma överens om uppsägningstider och en överlämningsplan i avtalet så att kunskapen stannar hos er produkt.