når jeg først begynner å jobbe med Et Agile produktteam, er en av de vanligste situasjonene jeg finner, hvor lagene har lange Og frustrerende Sprintplanleggingsmøter fordi ordrereserveelementer er dårlig definert og ikke godt forstått; de har langsom hastighet samt dårlig design fordi detaljer fortsatt blir utarbeidet under Sprinten; og mengden avfall og omarbeid er svært høy fordi ordrereserveelementer ikke er validert.

Husk at vårt høyere ordens mål er å validere våre ideer raskest og billigste mulig måte. Faktisk å bygge og lansere en produktidee er vanligvis den tregeste, dyreste måten å validere ideen på.

Det er derfor jeg er en stor talsmann for Det som noen ganger refereres Til Som Dual-Track Agile (Aka Dual Track Scrum, Fake It Before You Make It, Build Things That Don ‘T Scale/Build Things That Do Scale, Moves Fast/Don’ T Break Things, Continuous Discovery / Continuous Delivery, etc.).

jeg pleide å referere til dette som Bare Discovery Sprints, men det har en implikasjon av time-boxed Discovery, og også serialisering av faser. Jeff Patton først delte med meg begrepet “Dual-Track Scrum” og jeg foretrekker dette begrepet fordi det bedre fanger parallell Natur Oppdagelse og Levering.

Oppdagelsessporet handler om å raskt generere validerte produktreserveelementer, og Leveringssporet handler om å generere frigjørbar programvare.

En annen grunn til At Jeg liker Dual-Track Agile metafor er at jeg finner mange mennesker i hovedsak gjør små mini-fosser innenfor Deres Scrum rammeverk. Produktlederen gjør en slags “krav” arbeid, og det sendes til en designer som gjør hans design og genererer sine gjenstander( vanligvis annoterte wireframes), og så blir det overlevert til leveringsteamet for å bygge og teste.

I Motsetning, I Dual-Track Agile, er arbeidsflyten ikke preget av at hver rolle leverer artefakter videre til neste trinn; snarere er det samarbeidende – produktsjef, designer og ledende ingeniør jobber sammen, side om side, for å skape og validere ordrereserve elementer.

Lesere av disse artiklene vet hvor viktig jeg anser brukeropplevelsesdesign, men en av vanskelighetene for Mange Agile-lag er at rytmen og tempoet I Agile kan være svært vanskelig på tradisjonelle UX-lag. Det er derfor Jeg er En Fan Av Lean UX. Lean UX Og Dual-Track Agile er laget for hverandre. I stedet for å fokusere på gjenstander, fokuserer vi på prototyper og validerer disse prototypene I Discovery, med den ekstra fordelen at prototypen fungerer som spec for Levering.

viktigst, i motsetning Til En Foss prosess der valideringen skjer etter utgivelsen, I Dual-Track Agile, validerer vi under Discovery. I prinsippet om å validere så raskt og billig som mulig, kan vi i stor grad gjøre vår validering før vi skriver noen produksjonskode, i ånden av ” fake it before we make it.”

så hvis produktteamet ditt er frustrert over mengden avfall og det langsomme tempoet i å oppnå faktiske forretningsresultater, bør du vurdere Å prøve Dual-Track Agile. Se om dette kan inspirere til et nivå av samarbeid, rask iterasjon og validering som resulterer i mye bedre arbeid.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.