kun aloitan työskentelyn Agile product Teamin kanssa, yksi yleisimmistä tilanteista on, että tiimeillä on pitkiä ja turhauttavia Sprintin suunnittelukokouksia, koska ruuhka-asiat on huonosti määritelty ja ymmärretty; niissä on hidas nopeus ja huono suunnittelu, koska yksityiskohtia hiotaan vielä sprintin aikana; ja jätettä ja uudelleenkäsittelyä on paljon, koska ruuhkaa ei ole validoitu.

muista, että korkeamman järjestyksen tavoitteemme on vahvistaa ideamme nopeimmalla ja halvimmalla mahdollisella tavalla. Tuoteidean Rakentaminen ja lanseeraaminen on yleensä hitain ja kallein tapa vahvistaa idea.

minkä vuoksi olen suuri puolestapuhuja sille, mitä joskus kutsutaan Dual-Track Agileksi (alias Dual-Track Scrum, Fake It Before You Make It, Build Things That Don ‘t Scale/Build Things That Do Scale, Move Fast/Don’ t Break Things, Continuous Discovery/Continuous Delivery, jne.).

minulla oli tapana viitata tähän pelkkinä Löytöpyrähdyksinä, mutta se on seurausta aikalaatikosta löytymisestä ja myös vaiheiden sarjallistamisesta. Jeff Patton ensimmäinen jaettu minulle termi “Dual-Track Scrum” ja pidän tätä termiä, koska se paremmin kaappaa rinnakkainen luonne löytö ja toimitus.

Discovery trackissa on kyse validoitujen tuotekannatuserien nopeasta tuottamisesta, ja Delivery trackissa on kyse luovutettavien ohjelmistojen tuottamisesta.

toinen syy, miksi pidän Kaksiraitaisesta ketterästä metaforasta, on se, että monet ihmiset tekevät Scrum-kehyksissään lähinnä pieniä minivedoksia. Tuotepäällikkö tekee jonkinlaista “vaatimuksia” työtä, ja se siirretään suunnittelijalle, joka tekee hänen suunnittelee ja tuottaa hänen esineitä (yleensä merkityt rautalangat), ja sitten se luovutetaan toimitustiimille rakentamaan ja testaamaan.

sen sijaan Kaksiraiteisessa ketterässä työvirralle ei ole tyypillistä, että jokainen rooli toimittaa artefakteja seuraavaan vaiheeseen; pikemminkin se on yhteistyötä-tuotepäällikkö, suunnittelija ja pääinsinööri työskentelevät yhdessä, side-by-side, luoda ja vahvistaa backlog kohteita.

näiden artikkelien lukijat tietävät, kuinka tärkeänä pidän käyttäjäkokemuksen suunnittelua, mutta yksi hankaluuksista monille ketterille joukkueille on se, että ketterän rytmi ja tahti voi olla hyvin vaikeaa perinteisillä UX-joukkueilla. Tämän takia olen Lean UX: n fani. Lean UX ja Dual-Track Agile on tehty toisilleen. Sen sijaan keskittyä esineitä, keskitymme prototyyppejä ja validointi nämä prototyypit Discovery, lisäetuna, että prototyyppi toimii spec toimitus.

mikä tärkeintä, toisin kuin Vesiputousprosessissa, jossa validointi tapahtuu julkaisun jälkeen, Dual-Track Agilessa validoidaan Discoveryn aikana. Periaatteella validoida niin nopeasti ja halvalla kuin voimme, paljon aikaa voimme itse asiassa tehdä validointi ennen kuin kirjoitamme mitään tuotantokoodia, hengessä “fake se ennen kuin teemme sen.”

joten jos tuoteryhmäsi on turhautunut jätteen määrään ja hitaaseen tahtiin saavuttaa todellisia liiketuloksia, harkitse Kaksiraitaisen ketterän kokeilemista. Katso, jos tämä voi innostaa tason yhteistyötä, nopea iterointi ja validointi, joka johtaa paljon parempaa työtä.

Vastaa

Sähköpostiosoitettasi ei julkaista.