A két termékfejlesztési módszer háttereinek részletesebb ismertetése ezekben a cikkekben található. A módszer gyakorlati alkalmazásáról István bővebben is ír a blogján.
A Scrum háttere
A Scrum gyökereit két japán kutató, Ikujiro Nonaka és Hirotaka Takeuchi fektette le a „The new new product development game” c. publikációjában. A kutatásuk középpontjában az a kérdés állt, hogy hogyan képes néhány vállalat az iparági átlagot magasan meghaladó színvonalon végrehajtani termékfejlesztési projektjeit. A Scrum tehát nem egy elméleti menedzsment modell, hanem a termékfejlesztésben sikeres vállalatok gyakorlatát összegző kutatás eredménye.
A tanulmány egyik legfontosabb megállapítása, hogy a hatékony termékfejlesztést megvalósító vállalatok nem a vízesés – másnéven fázisolt PPP (Phased Product Planning) – menedzsment módszert követik, hanem egyfajta iteratív megközelítést alkalmaznak, melynek során a termék számos jellemzőjét nyitva hagyják egészen a fejlesztés végéig. Ez nagyban különbözik azoktól a tradicionális megközelítésektől, melyek során a lehető legpontosabb specifikációra törekednek már a tervezés megkezdése előtt. A Scrum modellben fejlesztő vállalatok a kialakítandó termék néhány legfontosabb jellemzőjét fektetik le, a részletekre vonatkozó döntéseket a fejlesztői csapatra bízzák.
Takeuchi és Nonaka felismerése szerint lényegesen hatékonyabb, ha a vízesés modellnél alkalmazott funkcionális csoportszervezés (pl. külön marketing, tervező és megvalósító csoport) helyett keresztfunkcionális, termékorientált csoportokat hoznak létre, melyben minden szakterület képviselteti magát. Egy Scrum csapatnak ugyanolyan szereplője a vevői elvárásokat kutató marketing szakember, mint a termék műszaki tervezéséért felelős mérnök, vagy a majdani gyártási folyamatot megtervező gyártásszervező. Ez a szemlélet teszi lehetővé, hogy a termékjellemzőket úgy alakítsák ki, hogy azok a termék teljes életciklusát figyelembe véve optimálisak legyenek. A termékjellemzők különböző szempontjait a fejlesztési időszakban ütköztetik és hozzák meg a szükséges kompromisszumokat, illetve egy-egy felfedezés vagy ötlet eredményét bármely szempontba képesek visszavezetni. A Toyota Prius fejlesztésénél például a fejlesztés nagyon késői szakaszában hozták meg azt a döntést, hogy az autó hibrid hajtásának akkumulátorait nem a motortérben, hanem hátul a csomagtér alatt helyezik el, mivel a motor melletti nagy hőmérsékletingadozást az akkumulátorok nem viselnék el. Ez a döntés az autó számos jellemzőjét (csomagtér, aerodinamika, hajtáslánc stb.) befolyásolta. A projekt elején nem volt még világos, hogy milyen akkumulátorok bizonyulnak majd optimálisnak, ezért a döntéssel számos kísérletet kellett megvárni. Egy ilyen horderejű döntés halogatása nem lett volna kivitelezhető, ha a csoport nem képes rövid idő alatt, saját hatáskörben elemzni annak következményeit (pl. a rövidebb motortérből adódó jobb városi manőverezési képességek, vagy a nagyobb csomagtér jelent több előnyt?). A Scrum jellemzője tehát a magas fokú döntési önállóságot élvező termékfejlesztési csoport.
Mivel a csoport nem előre meghatározott termékjellemzők és tervek szerint állítja elő a terméket, ezért szükség van olyan mechanizmusokra, melyek világosan megmutatják, hogy a projekt elfogadható mederben halad-e. Ennek megvalósításához a Scrum csapatok egyértelmű, vizuális mérési rendszereket alkalmaznak, melyeken bárki, első ránézésre láthatja a projekt előrehaladását, illetve segíti a csapattagokat abban, hogy könnyen felismerjék a projekt előmozdításához legfontosabb végrehajtandó feladatokat.
Scrum projekt bontás
A Scrum projektben megvalósítandó termék funkcióinak, valamint a projektben elvégzendő legfontosabb feladatoknak a listáját a product backlog tartalmazza. Fontos, hogy a product backlog elemeihez mindenképpen prioritások vannak rendelve, melyek egyben a feladatok elvégzésének sorrendjét is jelentik.
A projekt megvalósítását a team sprintekbe szervezve végzi, melyek azonos időtartamú végrehajtási egységek. A team minden sprint megkezdése előtt elvégzi a sprint-tervezést, melynek során a product backlog legmagasabb prioritású feladatai közül kiválasztja, illetve szükség esetén tovább bontja azokat a feladatokat, amelyeket a következő „nekifutásra” képes megvalósítani. Az adott sprintre vonatkozó feladatok listáját a sprint backlog tartalmazza. Minden sprint végeredménye egy tesztelt és elméletileg átadható funkció.A sprintek során a team működése szempontjából kiemelkedő fontosságú az intenzív és hatékony kommunikáció. Ezt segíti a minden nap megtartandó stand-up meeting, ahol a team tagjai „szinkronizálják” feladataikat, valamint a korábban már említett vizuális menedzsment eszközök használata.
Vizuális menedzsment eszközök
A vizuális projektirányítási eszközökkel szembeni legfontosabb elvárás a gyors „leolvashatóság” és az egyértelműség. A Scrum napi tevékenységeiben a két legjelentősebb ilyen eszköz a team board és a burn-down chart.
Team board
A team board a csapat által az adott sprintben végrehajtandó feladatokat és azok aktuális státuszát tartalmazza.
A feladatokat egy-egy „cetli”, más néven kanban jelöli. (A kanban a japán „vezérlő-kártya” szóból származik.) A kanban kártyákon szereplő információk csapatról csapatra változhatnak, de minimálisan a feladat nevét és a feladat becsült méretét tartalmazzák. A feladatok méretének becsléséhez többféle módszer használatos, de a méret kifejezésére általában story-pont elnevezést használják. A lényeg, hogy a feladatok méretének meghatározásához használt skála nagyjából állandó legyen, azaz egy adott csapat minden egyes sprintben összesen közel azonos story-pont értékű feladat megvalósítására legyen képes.
A csapat minden nap megtartja a stand-up összejövetelt, ahol a csapattagok a kanban kártyák mozgatásával jelzik, ha egy feladat végrehajtását megkezdték vagy éppen befejezték. Ez a mechanizmus biztosítja, hogy mindenki lássa, hogy melyek azok a feladatok, melyek végrehajtásához erőforrásra van szükség. A team-board tehát a csapat kommunikációs felülete.
Burn-down chart
A team board biztosítja, hogy a csapat tagjai világosan lássák az egyes feladatok státuszát, illetve, hogy a csapat számára teljes listát adjon az összes elvégzendő feladatról.
A sprint sikerességének méréséhet viszont a team board nem rendelkezik az összes szükséges jellemzővel, mivel nem olvasható le róla azonnal, hogy a tervekhez képesti előrehaladás megfelelő-e.
A sprint tervhez viszonyított haldását mutatja a „burn-down chart”. A grafikon függőleges tengelye mutatja a sprintbe tervezett feladatok mennyiségét story-pontban. A vízszintes tengely az időt jelzi. A szaggatott vonal a sprint ideális, terv szerinti lefutását mutatja.
A csapat minden stand-up összejövetel végén behúzza az adott napon megvalósított feladatok összesített story-pont értékét a grafikonon. (Folytonos, piros vonal.) A piros vonal gyakorlatilag a sprint során még megvalósítandó feladatok összes értékét mutatja. A gyakorlatban a vonal fölfelé is mozdulhat, ha például kiderül, hogy egy feladat lényegesen komplexebb annál, mint ahogy a csapat a tervezéskor gondolta.
Nincsenek megjegyzések:
Megjegyzés küldése