amikor először kezdek el dolgozni egy Agile termékcsapattal, az egyik leggyakoribb helyzet, amikor a csapatok hosszú és frusztráló Sprinttervezési találkozókat tartanak, mert a lemaradási elemek rosszul vannak meghatározva és nem jól érthetők; lassú sebességük és gyenge tervezésük van, mert a részletek még mindig kidolgozásra kerülnek a Sprint során; és a hulladék és az átdolgozás mennyisége nagyon magas, mert a lemaradási elemek nem validáltak.

ne feledje, hogy magasabb rendű célunk az ötleteink lehető leggyorsabb, legolcsóbb érvényesítése. Valójában egy termékötlet felépítése és elindítása általában a leglassabb, legdrágább módja az ötlet érvényesítésének.

ezért vagyok nagy szószólója annak, amit néha kettős vágányú agilisnak neveznek (más néven kettős vágányú Scrum, hamisítsa meg, mielőtt elkészítené, építsen olyan dolgokat, amelyek nem méreteznek/építenek olyan dolgokat, amelyek méreteznek, gyorsan mozognak/nem törik meg a dolgokat, folyamatos felfedezés/folyamatos szállítás stb.).

régebben ezt egyszerűen Discovery Sprintnek neveztem, de ennek következménye az időkódos felfedezés, valamint a fázisok sorosítása. Jeff Patton először megosztotta velem a “Dual-Track Scrum” kifejezést, és jobban szeretem ezt a kifejezést, mert jobban megragadja a felfedezés és a szállítás párhuzamos természetét.

a Discovery track arról szól, hogy gyorsan generáljon validált termékhátralékokat, a Delivery track pedig a kiadható szoftverek létrehozásáról szól.

egy másik ok, amiért szeretem a kétpályás agilis metaforát, az az, hogy sok ember lényegében kis mini-vízeséseket csinál a Scrum keretein belül. A termékmenedzser valamilyen “követelmény” munkát végez, és ezt átadják egy tervezőnek, aki elkészíti a terveit és létrehozza a műtárgyait (általában jegyzetekkel ellátott drótvázak), majd ezt átadják a szállítócsapatnak, hogy építsen és teszteljen.

ezzel szemben a kétvágányú Agile esetében a munkafolyamatot nem jellemzi az, hogy az egyes szerepkörök műtárgyakat továbbítanak a következő lépésre; inkább együttműködő – a termékmenedzser, a tervező és a vezető mérnök együtt dolgoznak, egymás mellett, hogy létrehozzák és érvényesítsék a lemaradási elemeket.

e cikkek olvasói tudják, mennyire fontosnak tartom a felhasználói élmény kialakítását, de sok agilis csapat számára az egyik nehézség az, hogy az agilis ritmus és ütem nagyon nehéz lehet a hagyományos UX csapatoknál. Ezért vagyok a Lean UX rajongója. A Lean UX és a Dual-Track Agile egymás számára készült. Ahelyett, hogy a tárgyakra összpontosítanánk, a prototípusokra és a prototípusok validálására összpontosítunk a Discovery-ben, azzal a további előnnyel, hogy a prototípus a szállítás specifikációjaként szolgál.

a legfontosabb, hogy ellentétben a vízesés eljárással, ahol az érvényesítés a kiadás után történik, a kettős vágányú Agile-ban a felfedezés során érvényesítjük. A lehető leggyorsabb és legolcsóbb érvényesítés elve szerint az idő nagy részében valójában elvégezhetjük az érvényesítést, mielőtt bármilyen gyártási kódot írnánk, a “hamisítás, mielőtt elkészítjük.”

tehát, ha a termékcsapatot frusztrálja a hulladék mennyisége és a tényleges üzleti eredmények elérésének lassú üteme, fontolja meg a kettős vágányú Agile kipróbálását. Nézze meg, hogy ez inspirálhat-e olyan szintű együttműködést, gyors iterációt és érvényesítést, amely sokkal jobb munkát eredményez.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.