Skalert smidig rammeverk


Håndterer lengre planleggingshorisonter Rediger

Utviklingsteam forbedrer vanligvis etterslaget opp til to til tre iterasjoner fremover, men i større organisasjoner må produktmarkedsføringsteamet planlegge lenger fremme for deres forpliktelser til markedet og diskusjoner med kunder. De vil ofte jobbe med et veldig høyt nivå, 12 til 18 måneders veikart, og deretter planlegge samarbeid med teamene for tre måneders arbeid. Utviklingsteamene vil fortsatt komme i detaljert forbedring 2-3 iterasjoner fremover, bare komme inn i detaljerte oppgaveplaner for neste iterasjon.

Holde seg smidig på abstrakte nivåer av ansvar Rediger

Mens utviklingsteam har en rekke rammer som definerer hvordan de skal være smidige, det er veldig lite som beskriver dette for ledelsen. SAFe leverer mange av de samme prinsippene, for eksempel tverrfunksjonelle team, til gruppene som håndterer de mer abstrakte nivåene av ansvar og planlegging (produkt og portefølje). SAFe har også blitt kritisert for å samle for mange ulik praksis.

Håndtere delegert autoritetEdit

I Scrum forventes produkteieren å ta ansvar for hele produktets livssyklus, inkludert avkastningen på investeringen av utviklingsbeslutninger, samt ytelse i markedet. På storskalautvikling ønsker organisasjonen en visning på tvers av flere lagetterslep, for eksempel levert av en produktsjef. Selv om SAFe antar at produkteierrollen sitter i produktadministrasjon, har det likevel blitt kritisert for å skille produkteiere inn i utviklingsorganisasjonen.

Synkronisering av leveranserEdit

Agile rammer er designet for å muliggjøre utvikling team for å være autonome og fritt til å designe hvordan de fungerer. SAFe erkjenner at det, i størrelsesorden mange titalls eller hundrevis av utviklingsteam, blir mer og mer kaotisk for team å selvorganisere seg fullt ut. Det legger derfor noen begrensninger på dette, slik at der team jobber med det samme produktet, kan deres leveranser bedre synkroniseres for å slippe sammen, selv om dette har vært et område der SAFe har blitt kritisert.

Tillater tid for innovasjon og planlegging Rediger

SAFe-planleggingssyklusen anbefaler å inkludere en ekstra iterasjon etter en utgivelse, slik at teamene kan forbedre sin praksis og er klare for neste planleggingsøkning. Tidligere utgaver av SAFe designet også dette for å være en herdende iterasjon, det vil si å stabilisere eller herde produktet før det slippes. Dette var basert på komplikasjonene ved å jobbe med store integrasjonsmiljøer der avhengigheter betydde at du ikke kunne teste alt til slutten. SAFe ble kritisert for dette fordi det representerte et anti-smidig eller fosselement, men var i tråd med magre 90-dagers trinn som gjør 13 uker, og hvis du gjør to-ukers sprint, trenger du seks av dem pluss en ukes planlegging eller herdesyklus. Dette er ikke inkludert i nyere utgaver av SAFe.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *