Adaptív menedzsment. A Scrum-tól a lean/kanban módszerig december. Adaptive Consulting Kft.

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "Adaptív menedzsment. A Scrum-tól a lean/kanban módszerig december. Adaptive Consulting Kft."

Átírás

1 A Scrum-tól a lean/kanban módszerig 009. december Adaptive Consulting Kft.

2 Szerző: Csutorás Zoltán Szerzői jogok A dokumentum szabadon terjeszthető, bemutatható és előadható az alábbi feltételekkel. Az Adaptive Consulting Kft-re mint szerzőre és a dokumentum címére történő hivatkozással A dokumentum nem használható fel kereskedelmi céllal A dokumentum részeiben vagy egészében kizárólag változtatás nélkül terjeszthető A dokumentumban felhasznált fényképek forrása: istockphoto

3 [Tartalom] Bevezetés 4 Az agilis kiáltvány félreértelmezve Tévhit: az agilis projekt lazán kezeli a határidőket Tévhit: az agilis projekt tagjai nem viselnek felelősséget 6 Lean menedzsment 7 A tömegtermelés eszméje 7 Az egydarabos áramlás Agilis fejlesztés a lean menedzsment tükrében 9 A tömegfejlesztés jelensége 9 A lean elvek szerinti fejlesztés 10 Termékfejlesztés 1 A Scrum háttere 1 Scrum projekt bontás 13 Vizuális menedzsment eszközök 14 A Scrum vizuális eszközeinek korlátai 16 A kész definíciójának szerepe 19 A lean/kanban fejlesztés 0 A folyamatos áramlás biztosítása 0 Húzórendszer kialakítása 1 Veszteségek felszámolása 3 Problémák azonnali felszámolása 3 A lean/kanban rendszer jellemzői 4 3

4 Bevezetés A csatákra való felkészülés során készített tervek mindig haszontalannak bizonyultak, de a tervezés maga nélkülözhetetlen. Eisenhower A szoftverfejlesztési projektek sikerességi mutatói az elmúlt évtizedekben meglehetősen kiábrándító képet mutattak. A vízesés modell szerint menedzselt fejlesztések résztvevői mind a felhasználói-megrendelői, mind a fejlesztői oldalon folyamatosan szembesülnek a műfaj nehézségeivel és kudarcaival. Ebben a környezetben mindkét fél könnyen okolhatja a másik oldalt a tervektől jelentősen elmaradó eredményekért. Az utóbbi néhány évben egyre többen kérdőjelezik meg azokat a módszereket, amelyek meghatározták az egyedi szoftverfejlesztési projektek menedzselésének módját. A tradicionális vízesés modell központi eleme a követelmények teljeskörű feltérképezése a projekt kezdetén, amit a rendszer részletes terveinek elkészítése követ. A fejlesztés csak azt követően kezdődhet el, hogy a projekt résztvevői pontosan meghatározták a jövőbeni rendszer minden paraméterét. Az előrejelzés ilyen szintű hangsúlyossága miatt szokás a vízesés módszertant prediktív modellnek is nevezni. A tervezhetőség a megrendelők és felhasználók megkérdőjelezhetetlen, jogos igénye. A prediktív megközelítés ugyanakkor rendkívüli hatékonyság-csökkenést eredményez az egyedi szoftverfejlesztésben. Ezt ismerték fel az egyre népszerűbb agilis fejlesztési módszertanok megalkotói. Az agilis fejlesztési megközelítés központi eleme az a felismerés, hogy az egyedi fejlesztési projektekben készítendő rendszerrel kapcsolatos minden elvárás és követelmény nem mérhető fel teljeskörűen a projekt legelső szakaszában. A fejlesztés során mind a felhasználók/megrendelők, mind pedig a fejlesztők egyre pontosabb képet kapnak a lehetőségekről és a valós igényekről, melyek legtöbbször felülírják az eredeti elképzeléseket. Ha ez így van, akkor a kezdeti részletes, mindenre kiterjedő követelmény-elemzésbe fektetett energia nagy része felesleges ráfordítás, a túl korán meghozott döntések és megkötések pedig gyakran hibás irányba terelik a projektet. Az igények folyamatos megismerésébe és a változó körülményekhez történő alkalmazkodási képességre fektetett hangsúly miatt az agilis módszereket gyakran nevezik adaptív megközelítésnek. Paradox módon sok sikeres projekt bizonyítja, hogy az adaptív módszertanokban alkalmazott eljárások megfelelő alkalmazása végül a prediktív modellekénél magasabb fokú előrejelezhetőséghez vezet. A vízesés modell gyökerei kiforrott, más iparágakban jól bevált projektmenedzsment módszerekre vezethetőek vissza, ezért követői jogosan várnak el hasonló megalapozottságot a minden eddigi konvenciót felrúgó adaptív módszerektől. Ez a dokumentum az adaptív módszerek mögött meghúzódó, bizonyítottan sikeres menedzsment megközelítések áttekintő ismertetését célozza meg. 4

5 Az agilis kiáltvány félreértelmezve Az agilis kiáltvány indította útjára az agilis fejlesztési mozgalmat. Az üzenetei egyrészről egyértelműek és világosak: koncentráljunk azokra a tevékenységekre a fejlesztés során, amik a majdani rendszer felhasználói számára közvetlenül valódi értéket teremtenek és helyezzük ezeket a másodlagos, közvetett tevékenységek elé. Ezek szerint fontosabb: az egyén és a személyes kommunikáció, a módszertanoknál és az eszközöknél a működő szoftver, az átfogó dokumentációnál a megrendelővel való együttműködés, a szerződéshez való ragaszkodásnál a változásra való reagálás, a tervek rigorózus követésénél. Az egyetlen probléma az agilis kiáltvánnyal, hogy a fázisolt termékfejlesztési módszertanokon (vízesés modell) nevelkedett vezetők és mérnökök egy részében azt az érzetet kelti, hogy az agilis fejlesztés egyfajta fejlesztői "munkásforradalom", akik előrébb helyezik a hobby szerű fejlesztést a professzionális, minőségorientált munkával szemben. Értelmezhetjük így is az agilis kiáltványt: nem igazán fontosak a módszertanok, nem akarjuk dokumentálással tölteni az időt, nem vállalunk felelősséget a tevékenységünkért, ezért kerüljük a szerződéskötést. Ez alapján a logika alapján az utolsó pont sem meglepő: még a tervezést sem tartjuk fontosnak! Nyilván nem ez húzódik meg az irányzat mögött. Tévhit: az agilis projekt lazán kezeli a határidőket Ez a hiedelem még agilis fejlesztési módszertanokkal foglalkozó portálokon is megjelenik és jelentős projektmenedzsment fórumokon is elhangzik, mint végkövetkeztetés. Ha az agilis kiáltvány félreértelmezéséből indulunk ki, akkor ez logikus következmény. Az is igaz, hogy főként azok a vállalatok alkalmazzák az agilis módszereket, akik dobozos termékeket fejlesztenek (pl. Google, Apple, Microsoft stb.) Másrészt viszont ha megvizsgáljuk ezeknek a módszereknek a gyökereit, akkor észrevehetjük, hogy a Scrum vagy a Toyota Product Development System olyan közegben alakult ki, ahol a szigorú véghatáridőre leszállított eredmény alapvető követelmény! Nehéz elképzelni a Toyotáról, hogy egy autókiállításra beharangozott típussal nem készül el határidőre... Igaz, hogy az agilis fejlesztési projektek más megközelítést igényelnek, mint a vízesés modellben vezényelt projektek, ugyanakkor a meghatározott időpontra, meghatározott célokat kielégítő, magas minőségű eredmény talán még sokkal nagyobb hangsúlyt kap!

6 Tévhit: az agilis projekt tagjai nem viselnek felelősséget A félreértés másik hibás következtetése. Az agilis pl. Scrum teamek felelőssége lényegesen nagyobb, mint az erős projektmenedzser által irányított fejlesztési projekteken, ahol a felelősséget végső soron egy személyben a projektvezető viseli. (A személyi felelősség megjelenik az adaptív menedzsmentben is. A product owner és Scrum master a Scrum-ban, vagy a chief architekt a Toyotánál teljes körű felelősséget visel a projekt sikeréért, de a direkt irányítás helyett a mechanizmusok fenntartására és javítására, a jó csapat összeállítására helyezi a hangsúlyt.) A különbség abban áll, hogy az agilis módszertanok belátják, hogy a szoftverfejlesztés nem más, mint ezernyi kisebb-nagyobb döntés együttese. Minden fejlesztő, minden órában döntéseket hoz, amiket nem lehet előre megtervezni, sem irányítani. A komplex rendszereknek (mint amilyen a szoftverfejlesztői team is) bizonyos fokú önállóságot kell biztosítani, a folyamatos vezetői kontrollt pedig egyértelmű, transzparens, a valós előrehaladást mindenki számára világosan megjelenítő visszajelző mechanizmusokkal kell helyettesíteni. A tervektől való eltérést pedig azonnal ki kell értékelni és a team tudását felhasználva, közösen kell kitalálni a lehetséges megoldásokat. Az agilis módszereknek ez a mechanizmusa könnyen keltheti azt az érzetet, hogy az irányítást a menedzsment kiadta a kezéből. Az eredeti agilis környezetekben az elkövetett hibákért a team tényleges felelősséget vállal, a folyamatosan rosszul teljesítő csapatokat pedig megszüntetik vagy átszervezik. A csapatoknak ennek tudatában kell teljesíteniük. A valóságban tehát a menedzsment a felelősséget nem megszünteti, hanem kiterjeszti azokra, akik valóban hatással vannak a projekt sikerére: a projekt teamre. 6

7 Lean menedzsment A lean (jelentése: karcsú, vékony) menedzsment az egyik legjobb kiindulópont az agilis filozófia megértéséhez. A lean menedzsment gyökerei a Toyota gyártási rendszeréhez nyúlnak vissza. A Toyota bebizonyította, hogy ezzel a gyökeresen új menedzsment megközelítéssel óriási piaci előnyre lehet szert tenni. A lean menedzsment sikerét nem kell különösebben bizonygatni, mára gyakorlatilag az összes autógyár átvette a Toyota gyártási módszer elemeit. A Toyota 007. évi profitja nagyobb volt, mint a 3 legnagyobb amerikai autógyáré együttvéve. A Toyota nettó profithányada az iparági átlag,3-szorosa. Forrás: Jeffrey K. Liker, A Toyota módszer A tömegtermelés eszméje A lean menedzsment gyakorlatilag a klasszikus tömegtermelési módszerek hibáinak felismerésével jött létre. A tömegtermelés alapelve a nagy mennyiségben, alacsony egységáron történő gyártásban rejlik. Ezt úgy lehet elérni, ha nagy sorozatszámban gyártunk és a drága berendezések kihasználtságát maximalizáljuk, azaz folyamatosan termelünk. Ennek érdekében a tömeggyártás során hatalmas nyersanyag és gyártási készleteket halmoznak fel, hogy semmiféle fennakadás ne hátráltassa a folyamatos termelést. A következőkben Jeffrey K. Liker, A Toyota módszer c. könyvéből vett példáján keresztül nézzük meg a tömegtermelés és a lean elvek szerinti gyártás közötti különbségeket. Az alábbi ábra a tömegtermelésben készülő termékek gyártási folyamatának leegyszerűsített modelljét mutatja. 7

8 Képzeljünk el egy számítógép-gyártó sort, ahol az első lépésben legyártják a gépházat és a gép belsejét. A második lépésben legyártják a monitort és a gépházra szerelik. A harmadik lépésben tesztelik az összeállított gép helyes működését. Az egyszerűség kedvéért minden gép, minden egyes fázisa egy percig tart. A gyártósorról 10 darabos egységekben szállítják át a készletet a következő feldolgozási folyamathoz. Az egyes műveleteket specializált folyamat-szigetek végzik. Ebben a modellben az első gépet 1 perc múlva állítják elő, az összes gép legyártásának ideje pedig 30 perc. Ha a tesztelés során kiderül, hogy az egyik gép gépháza hibás és az például az egyik gyártási egység meghibásodásából adódott az akár az összes gyártósoron lévő gépet érintheti. Az egydarabos áramlás A lean menedzsment ezzel szemben az egydarabos áramlás eszméjét próbálja megközelíteni. Ugyanennek a terméknek az egydarabos áramlás szerint történő gyártása úgy valósulna meg, hogy a folyamat-szigetek helyett úgynevezett termelő szigeteket alakítanak ki, melyek egy termék teljes legyártását végzik. A gyártási lépéseket egymáshoz közel helyezik el, hogy ne legyen szükség a készletek gyűjtésére és szállítására. A termelő szigeten elsőként legyártják a gépházat, amely azonnal a következő feldolgozási egységhez kerül, ahol összeszerelik a monitorral, majd az elkészült gépet azonnal tesztelik. A megoldás eredményeként az első gép 3 perc alatt elkészül, majd percenként legyártanak egy-egy újabb terméket. Az összes gép legyártásának ideje így mindössze 1 percre csökken úgy, hogy mindössze 3 gép van egyszerre feldolgozás alatt. Ez a megközelítés lényegesen nagyobb rugalmasságot biztosít, arra az esetre, ha például a megrendelői igények hirtelen változnának. A hibás darabokat a gyártás során azonnal felismerik, a hiba maximum 3 gépet érinthet.

9 Agilis fejlesztés a lean menedzsment tükrében Az agilis fejlesztési módszertanok mögött rejlő filozófia megértésében sokat segítenek az előző fejezetekben leírtak. De nézzük, hogy mi köze van a gyártásnak a szoftverfejlesztéshez? A tömegtermelés analógiájára menedzselt fejlesztési módszertanokra szoktam használni a tömegfejlesztés kifejezést. Ez a módszer gyakorlatilag vízesés modell néven ismertté vált megközelítés. A Standish Group minden évben elkészíti a szoftverfejlesztési projekteket vizsgáló jelentését, a Chaos Report-ot. Az egyik ilyen felmérésnek az eredménye jól rámutat a vízesés modellben megbújó veszteségekre. A jelentésben azt vizsgálták, hogy az egyedi fejlesztésű rendszerekben megvalósított funkciókat milyen arányban használják a felhasználók. Az eredmény önmagáért beszél: a fejlesztett funkcióknak mindössze 0%-át használják állandóan, vagy gyakran, míg 64%-át soha, vagy nagyon ritkán veszik igénybe. Ha gyártási analógiával akarunk élni, akkor ez a túltermelés tökéletes megnyilvánulása. Mi az oka ennek a túltermelési jelenségnek? A tömegfejlesztés jelensége Állandóan 7% Ritkán 19% Gyakran 13% A vízesés modellben történő fejlesztést ábrázolva a tömegtermelés mechanizmusához nagyon hasonló folyamatot fedezhetünk fel. Soha 4% Néha 16% Forrás: Standish Group Chaos Report v3 Interjúk, követelmény gyűjtés! Specifikáció Tervezés Fejlesztés Tesztelés A vízesés modell szerint a különböző megmunkálási fázisok nagy tömegben állítják elő a szoftver különböző elemeihez tartozó alkatrészeket. Első lépésben a felmérésre, követelményelemzésre specializálódott elemzői csoportok elkészítik a teljes rendszert lefedő követelményelemzést, majd ebből a követelményspecifikációt. Miután ezzel 9

10 elkészültek, továbbítják a specifikációt a tervező folyamat-szigethez, ahol elkészítik a rendszer logikai, esetleg fizikai rendszertervét. A következő lépésben a fejlesztés folyamat-sziget elkészíti a működő rendszert, amit végül a tesztelésre specializálódott tesztelői csoport ellenőriz. Jól látható, hogy az egyes fázisok között hatalmas méretű és értékű készletek mozognak, hiszen minden egyes fázisban óriási mennyiségű szellemi termék keletkezett. Itt érdemes visszatérni a Standish Group eredményeire. Ha elfogadjuk a kutatás következtetését, akkor a fejlesztésre fordított energia minimum 4%-a teljes pazarlás volt, hiszen olyan funkciók elkészítésével töltötte a csapat az idejét, amire lényegében nincsen szükség. A valóságban ennél lényegesen több pazarlás jelentkezett a rendszerben, ha figyelembe vesszük az alábbiakat: a felhasználók az állandóan, vagy gyakran használt 0%-nyi funkciót csak akkor tudják alkalmazásba venni, amikor elkészült a 0%-nyi ritkán vagy, egyáltalán nem használt funkció is a valóságban a projekt különböző fázisaiban sok funkció kihagyásáról döntenek, melyek az előző fázisok feldolgozási folyamatain már végigmentek (pl. a fejlesztési szakaszban kihagyott funkció specifikálásába és tervezésébe fektetett munka ugyanúgy veszteség) a felmért és megtervezett funkciók nagyon nagy arányban változnak a fejlesztés során, amely változások visszavezetése a korábbi fázisok dokumentációiba hatalmas energiákat emészt fel. A tömegtermelés filozófiájával szemben a lean menedzsment a fenti problémák kiküszöbölésére fekteti a hangsúlyt. A lean elvek szerinti fejlesztés Az agilis szoftverfejlesztési módszerek lényegében felfoghatók a lean gyártás analógiájaként. Ebben az esetben a rendszerben megvalósított funkciókat ideális esetben egyenként valósítjuk meg a felméréstől egészen a tesztelésig. Minden folyamat eredménye egy potenciálisan átadható és használatba vehető funkció. Az agilis fejlesztés, hasonlóan a lean gyártásban bemutatott számítógép összeszereléshez lehetővé teszi, hogy a felhasználók lényegesen hamarabb jussanak 10

11 hozzá a valóban hasznos funkciókhoz. A felmérési, specifikációs szakaszban elkövetett hibák gyakorlatilag azonnal felismerhetők, hiszen a koncepciót rendkívül gyorsan kipróbálható kód követi. A rugalmasság A lean gyártás akkor valósítható meg hatékonyan, ha a gyártósor magas fokú rugalmassággal rendelkezik. Ez a rugalmasság teszi lehetővé, hogy ugyanazokkal a termelő-berendezésekkel kielégíthetőek legyenek a változó igények. Ez például az autógyártásnál azt jelentheti, hogy ugyanazt a típust bőr üléssel és különböző színű kárpitokkal is folyamatosan tudják gyártani, az igényeknek megfelelően. Szemben a tömegtermelési modellel, ahol például a piackutatási előrejelzések alapján első körben legyártanak 100 fekete szövet kárpittal szerelt autót, majd 0 bőr üléssel szerelt autót, a lean gyártásban minden bőr kárpittal szerelt autót két fekete szövet kárpittal szerelt autó követ. Ez teszi lehetővé, hogy a megrendelői igények változása esetén ne halmozódjanak fel eladhatatlan készletek, ha például az derül ki, hogy mégis nagyobb igény mutatkozik a bőr kárpittal szerelt autók iránt. A gyártósor rugalmassága a szoftverfejlesztésben a rendszer módosíthatóságának felel meg. Mivel az agilis fejlesztés során nem készítünk átfogó, a rendszer teljes funkcionalitásának ismeretén alapuló rendszertervet, ezért a módszer akkor működik, ha az elkészült kód a a projekt során szerzett új ismereteknek megfelelően könnyen módosítható, kiegészíthető. Az agilis fejlesztést gyakorlatilag a szoftver-technológia olyan újításai teszik lehetővé, melyek éppen a fejlesztés rugalmasságát támogatják. Ezek az újítások többek között a modern fejlesztői környezetek és nyelvek, vagy az olyan fejlesztési technikák, mint az Módosítás költsége Vízesés fejlesztés automatikus tesztek, a teszt-vezérelt fejlesztés, vagy a gyakori refaktoring. Ezeket a fejlesztési technikákat gyűjtötte egységes, működő rendszerré az extreme Programming. A klasszikus, vízesés modell abból a feltevésből indul ki, hogy egy fejlesztési projektben a rendszeren végzett módosítások költsége exponenciálisan nő az idő előrehaladtával. Ez a feltételezés a korai időkben igaz is volt és indokolta, hogy minél korábbi időpontban rendelkezzünk az összes olyan információval, ami a rendszer funkcionalitását befolyásolhatja. A modern fejlesztési módszerek bevezetésével ez a feltételezés már nem állja meg a helyét. Egy jól szervezett, automatikus tesztekkel alaposan lefedett kód módosítása ma már korántsem jelent akkora többlet költséget, mint a régi időkben. Ma már a kód módosításának, az esetleges újratervezéseknek a költségei általában lényegesen alacsonyabbak, mint a tömegfejlesztés módszeréből adódó túltermelési veszteségek költsége, nem is beszélve a funkciók folyamatos és korai bevezetéséből adódó time-tomarket idő csökkentéséből fakadó üzleti haszonról. XP Idő 11

12 Termékfejlesztés A lean menedzsment alapvetően a gyártási folyamatok irányításának a filozófiája. Az egyedi szoftverfejlesztés azonban csak részben termelés, legalább ennyire hangsúlyos a termékfejlesztés mivolta. A legismertebb és mára leginkább elterjedt egyedi szoftverfejlesztésekhez alkalmazott menedzsment keretrendszer a Scrum. Kevésbé nyílt és ismert, de alapelveiben nagyon hasonló megközelítést képvisel a Toyota termékfejlesztési módszertana, a TPDS (Toyota Product Development System). A két termékfejlesztési módszer háttereinek részletesebb ismertetése: 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 viszonylag 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 1

13 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 elemezni 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 végrehajtandó legfontosabb 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 alapvetően meghatározzák. Product backlog Napi stand -up Sprint backlog Átadható funkció Sprint tervezés Sprint, megvalósítás 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 zárásakor a team kiértékeli a sprint tapasztalatait, az esetlegesen elkövetett hibákat és ennek ismeretében folyamatosan javítja munkamódszerét. 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ó, maximum 1 perc hosszúságú 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. 13

14 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 mutatja. Várakozik Folyamatban Kész Team board A feladatokat egy-egy cetli, más néven kanban jelöli. (A kanban japán szóból ered, körülbelüli jelentése: vizuális vezérlő jel.) 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. 14

15 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 adott sprintben elvégzendő összes feladatról. A sprint sikerességének méréséhez 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. Tervezett összes feladat mennyisége Burn-down chart Sprint tervezett időtartama A sprint tervhez viszonyított haladá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. 1

16 A Scrum vizuális eszközeinek korlátai A Scrum egy szándékosan nyitva hagyott keretrendszer és rengeteg olyan részletet nem szabályoz, melyek gyakorlati megvalósítása nagyban befolyásolja a projekt sikerét. Ennek elsődleges oka talán az, hogy ezek a gyakorlati részletkérdések nagyban függnek a projekt környezetétől és adottságaitól. A Scrum-ban még járatlan csapatok első néhány sprintjét gyakran jellemzik az itt látható burn-down chartok. De mi lehet ennek az oka? Gyanús sprint lefutás A burn-down chart sem mond el önmagában sokat arról, hogy a sprint sikeres volt-e vagy sem. M i n d e n e s e t r e, h a v i s s z a ny ú l u n k a l e a n menedzsment alapelveihez érezni lehet, hogy a fenti ábra szerint lezajlott sprint igencsak gyanús, mivel nem követi az egyenletes termelés ideálját. Ahhoz, hogy többet lehessen tudni arról, hogy mi is történhetett valójában, érdemes egy pillantást vetni a projekt jellemző időpontjaiban a team boardra is. Várakozik Folyamatban Kész Sprint. napja Látható, hogy a sprint. napján még látszólag minden rendben halad, a csapat három feladat végrehajtásával foglalkozik, egyet pedig már be is fejezett. 16

17 Várakozik Folyamatban Kész Sprint 6. napja A sprint 6. napján látszódnak már a problémák. A vízszintes vonalat némileg magyarázhatja, hogy kettő darab nagy feladat is folyamatban státuszban van, ezek előrehaladásáról a tábla nem igazán ad felvilágosítást. Lehet, hogy már csak egy-két óra munka van mindkettővel, ezért bármelyik pillanatban lezuhanhat a grafikon. Várakozik Folyamatban Kész Sprint 7. napja Az előző (6.) napon aggasztó jel volt, hogy összesen öt feladat volt fejlesztés alatt. Ezek után nem meglepő, a megosztott erőforrások miatt mindössze egyetlen feladattal sikerült végezni a 7. napon. 17

18 Várakozik Folyamatban Kész Sprint 9. napja Mivel feltételezett csapatunk igen lelkiismeretes (és mert saját vállalása volt a sprintbe tervezett feladatok mindegyike) túlórázik és végülis legyűri az összes feladatot. A menedzsment tehát elégedett lehet. Vagy mégsem? 1

19 A kész definíciójának szerepe A Scrum egyik nagy nyitva hagyott kérdése, hogy milyen fázisokon keresztül készítünk el egy szoftvert. Annak ellenére, hogy a grafikon lefutása ilyen púpos lett, elképzelhető hogy a csapat teljesítette a folyamatos termelés ideálját? Mi történt a feladatokkal az alatt, amíg a folyamatban státuszban voltak? Egyáltalán bízhatunk abban, hogy a sprint utolsó harmadában elkészített funkciók ugyanolyan alapossággal készültek, mint az első harmadban lezárt feladatok? A válasz valószínűleg nem, de az mindenesetre biztos, hogy önmagában a burn-down chart és a team board alapján nem derül ki a válasz. Annak érdekében, hogy a fenti kérdéseket biztonsággal megválaszolhassuk, fontos tisztázni, hogy mikor tekintünk egy feladatot késznek. A kész egy jó definíciója lehet az alábbi: a kód elkészült, unit-tesztekkel lefedett, a manuális és automatikus regressziós tesztek sikeresen lefutottak, az elkészült funkciók dokumentálva vannak, a súgók készen vannak, inicializáló, telepítő szkriptek készen vannak. Ha a kész minden esetben ugyanazt jelenti, akkor már jó eséllyel bízhatunk benne, hogy a rendszer minőségi jellemzői az elvárásoknak megfelelőek és a sprint utolsó harmadában nem az történt, hogy a fejlesztői csapat összecsapta a feladatokat. 19

20 A lean/kanban fejlesztés Míg a Scrum a fejlesztési projekt termékfejlesztési vonatkozásaira fekteti a hangsúlyt, addig a lean/kanban projektmenedzsment ezek mellett erősen koncentrál a fejlesztési folyamat termelési megközelítésére is. A lean/kanban fejlesztés az agilis módszertanok második nagy hullámát képviselik és jobban koncentrálnak a folyamatokra. A lean/kanban módszer nem jelenti a Scrum leváltását, inkább annak kiegészítésének érdemes tekinteni. A kanban rendszer bevezetésének első lépcsőfoka a Scrum, aminek az átugrásával kockázatos próbálkozni. A lean menedzsment néhány fontos célkitűzése az alábbi: a feladatok folyamatos áramlásának biztosítása annak érdekében, hogy a termelés természetes egyszerűséggel, megszakításmentesen haladjon az igényeken alapuló húzórendszer kialakítása a túltermelés elkerülése érdekében a veszteség felszámolása a felesleges tevékenységek kiiktatásával és a túltermelés megszüntetésével minden probléma és akadály azonnali feltárása és megszüntetése A fenti elvek a Toyota lean termelési rendszeréből származnak és minden szervezetnek érdemes megfontolnia. Mit jelent ezek követése a szoftver projektmenedzsment szempontjából? A folyamatos áramlás biztosítása A folyamatos áramlás szellemében a projekt sprintekbe szervezése nem optimális megoldás, mivel megszakítja a feladatok folyamatos végrehajtását. A lean szoftverfejlesztés alapelveinek megfelelő rendszerben pontosan azonosított minden olyan tevékenység, amely szükséges annak érdekében, hogy a terméket elkészítsük és használatra átadjuk az ügyfél számára. (A klasszikus Toyota módszer a folyamatot az áru ellenértékének beérkezésével zárja.) Ha feltérképeztük a fejlesztési folyamat lépéseit, akkor ezeket ábrázolhatjuk is a vizuális menedzsment eszközünkön. 0

21 Backlog Kiválasztva Előkészítés Megvalósítás Tesztelés, Folyamatban Kész Folyamatban Kész javítás Kész Kanban board A kanban táblán tehát minden olyan tevékenységet szerepeltetünk, amelyek végrehajtása szükséges ahhoz, hogy a rendszert elkészítsük és leszállítsuk. Ezeknek a lépéseknek egy példáját tartalmazza a fenti ábra. A Backlog oszlopban szerepelnek azok a feladatok, melyek megvalósítását a Product Owner a közeli jövőben szükségesnek tartja. A Kiválasztva oszlopba kerülnek azok a feladatok, melyek megoldása a legnagyobb prioritással bír. A fejlesztő csapat tagjai ezek közül választhatnak, ha szabad kapacitásuk van. Az Előkészítés fázisban lévő feladatok azok, amelyek tervezését, előkészítését a csapat éppen végzi. Általában az előkészítés legfontosabb kimenete a kész feladat ellenőrzési módjának meghatározása, azaz: a csapat pontosan határozza meg, hogy milyen kritériumok, tesztek megvalósulása esetén tekinti a feladatot késznek. A Megvalósítás státuszban lévő feladatok azok, melyek fejlesztését a csapat éppen végzi. Az oszlopok egy részét szokás további kettő státuszra bontani: folyamatban, kész. Ezek a státuszok egyrészt jelzik a tesztelő csapat tagjainak, hogy a Fejlesztés/kész státuszban álló feladatok tesztelését megkezdhetik, másrészt jól mutatják a fejlesztési folyamat gördülékenységét. Ha sok feladat áll valamelyik oszlop Kész státuszában az azt jelenti, hogy a fejlesztés lüktet, nem kiegyenlített. Húzórendszer kialakítása A húzórendszer lényege, hogy addig semmilyen feladatot ne hajtsunk végre, amíg az azt felhasználó következő munkafázis nem készült fel annak feldolgozására. Ez a gyakorlatban például azt jelentheti, hogy a fejlesztői csapat addig nem lát neki újabb funkció fejlesztésének, amíg az előzőleg elkészített funkció tesztelése meg nem kezdődött, mert ez a tesztelés számára történő túltermelést jelentené. 1

22 Backlog Kiválasztva Előkészítés Megvalósítás Tesztelés, Folyamatban Kész Folyamatban Kész javítás Kész! Húzó rendszer 1 Az oszlopok tetején lévő piros számok az adott fázis elemszám korlátját jelölik A húzórendszerben tehát minden esetben a folyamat utolsó fázisának felszabadulása adja ki a jelet az őt megelőző fázisnak egy újabb feladat feldolgozásának megkezdésére, mely továbbgyűrűzik egészen a legelső fázisig. Ez a megközelítés kezdetben kissé furcsának tűnhet, de a gyakorlatban több csapat is nagy sikerrel alkalmazza. A húzórendszer megvalósításának feltétele, hogy az egyes fázisokon lévő munkaterhelés kiegyenlíthető legyen. Ez elméletben azt jelenti, hogy minden feladatnak megegyező méretűnek kell lennie és minden fázishoz úgy kell hozzárendelni az erőforrásokat, hogy az egyes feldolgozási fázisokban egy munkadarab /funkció ugyanannyi időt töltsön, különben kiegyenlítetlen, lüktető lesz a fejlesztés. A szoftverfejlesztési gyakorlatban ez nem igazán valósítható meg, kialakítható viszont olyan csapatösszetétel, amely képes a munkafázisok közötti erőforrásigények kiegyenlítésére. Más szóval ez azt jelenti, hogy több olyan ember is dolgozik a teamben, aki képes több fázisban is feladatokat ellátni pl. egy elemző/szervező elvileg minden szükséges kompetenciával rendelkezik ahhoz, hogy tesztelhesse az alkalmazást, vagy sok fejlesztő és tesztelő képes telepítő szkripteket készíteni, vagy dokumentálni. Ezzel megvalósítható a munkafázisok közötti kiegyenlített áramlás.

23 Veszteségek felszámolása A veszteségek felszámolása a lean menedzsment központi eleme és mint ilyen, a téma jóval túlmutat ennek a dokumentumnak a keretein. A veszteségek nyolc forrása közül több összefüggésben áll a készletek felhalmozásával és a túltermeléssel. A lean szoftverfejlesztésben a készletek csökkentésének egyik eszköze a feldolgozási státuszban lévő feladatok számának korlátozása. (Work in progress limit/ WIP-limit). Kiválasztva Előkészítés, tervezés Fejlesztés Tesztelés, javítás Dokumentálás Release előkészítés WIP limitek Mivel a fejlesztési projektet vezérlő üzleti elvárások és prioritások folyamatosan változnak, az egyik leggyakoribb veszteség forrás a félbehagyott kód, vagy funkció. Azért, hogy a projekt veszteség nélkül, rugalmasan reagálhasson a változó üzleti igényekre, minimalizálni kell a feldolgozás alatt lévő feladatok számát. A gyakorlatban ez azt jelenti, hogy maximum annyi feladat lehet az egyes feldolgozási lépésekben, ahány üres hely áll rendelkezésre a kanban táblán az adott munkafázishoz. A feladat-limitek meghatározása a projekt és a fejlesztői team jellegzetességeinek figyelembe vételével történik. Az ábrán zöld színnel vannak jelölve a felhasználható helyek, azaz a tábla biztosítja, hogy például egyszerre maximum kettő feladat lehet fejlesztés alatt. A barack színű hely a tesztelésből hibával a fejlesztésre visszakerült feladatok számára van fenntartva. Problémák azonnali felszámolása A WIP-limit bevezetésével a folyamat érzékenyen reagál a hibákra, ezért azokat azonnal fel kell számolni. A lean/kanban rendszer nem alkalmazza a rendszeres kiértékelést, ehelyett minden egyes felmerülő hibát azonnal, késlekedés nélkül kiértékelnek, javítanak és módosítják az eljárásokat, hogy többé ne fordulhasson elő. 3

24 A lean/kanban rendszer jellemzői A lean/kanban talán a legszigorúbb és legnagyobb fegyelmet követelő menedzsment módszer, mely ugyanakkor a végtelen fejlődés előtt nyitja meg az utat az alkalmazói számára. Ciklusidő A kanban rendszerben nincs szükség burn-down chart alkalmazására, a csapat teljesítményének mérésére a ciklusidő szolgál. A ciklusidő azt mutatja meg, hogy egy egységnyi funkció elkészítése és élesbe állításra történő felkészítése mennyi ideig tart. Ha például minden fázisban 1 napot tölt egy funkció, akkor hat nap a csapat ciklusideje. A módszer feltételezi azt, hogy a csapat képes a funkciókat megközelítőleg egyenlő méretű feladatokra bontani. Elképzelhető az egységnyi story pontra számított ciklusidő mérése is, ekkor egy 3 story pontos feladat háromszor annyi idő alatt fut végig a rendszeren, mint egy 1 story pont méretű feladat. Ez a megoldás megnehezíti ugyanakkor a kiegyenlített termelés megvalósítását. A lean/kanban rendszer kihívásai Fontos tisztában lenni azzal, hogy a lean szoftverfejlesztési projektmenedzsment rendszer kialakítása rengeteg nehézséget tartogat az átállás elején, cserébe viszont kitűnő visszajelző rendszerként szolgál a fejlesztési módszerekben lévő hibák, vagy szabályozatlanságok felderítésére és kijavítására. A lean/kanban rendszer egyik legfontosabb jellemzője, hogy nagyon nagy fegyelmet követel a csapattól és nagyon pontos előkészítést igényel a folyamatlépések, valamint a wip-limitek jó meghatározása. A módszer rendkívül érzékeny a hibákra, mivel a feladatok méretének hibás becslése, vagy a gyakori hibajavítás a teljes fejlesztési folyamatot blokkolja, mivel nem szabadul fel kapacitás az egyes munkafázisokon. A lean/kanban rendszerben rejlő lehetőségek A módszer alkalmazásával nagyon jól szabályozottá, tervezhetővé és rugalmassá válik a csapat fejlesztési tevékenysége. Mivel a rendszer rendkívül érzékeny a hibákra, ezért a teljes csapatot rákényszeríti a hibák forrásának felkutatására és azonnali kijavítására, amivel a magas minőségi szint gyakorlatilag automatikusan együtt jár. A ciklusidő egy jól megfogható, egyszerű és lényeges mérőszám, aminek a javítására könnyen ösztönözhető egy csapat. A ciklusidő folyamatos csökkentése állandó teljesítmény-növekedést von maga után. 4

Agilis projektmenedzsment

Agilis projektmenedzsment Agilis projektmenedzsment 2013. április 10. 1 Adaptive Consulting Kft. Csutorás Zoltán Agile coach, tréner zoltan.csutoras@adaptiveconsulting.hu 2 www.scrummate.hu 3 Agilis ernyő Scrum Lean/Kanban Crystal

Részletesebben

Ami a vízesésen túl van

Ami a vízesésen túl van Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két

Részletesebben

cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től

cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Alapfogalmak: 1. hiba: egy már meglévő, funkcionalitásban hibás működést eredményező programrész hibás működésének leírása konkrét

Részletesebben

FMEA tréning OKTATÁSI SEGÉDLET

FMEA tréning OKTATÁSI SEGÉDLET FMEA tréning OKTATÁSI SEGÉDLET 1. Hibamód és hatás elemzés : FMEA (Failure Mode and Effects Analysis) A fejlett nyugati piacokon csak azok a vállalatok képesek hosszabbtávon megmaradni, melyek gazdaságosan

Részletesebben

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok

Részletesebben

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család

Részletesebben

Informatikai projekteredmények elfogadottságának tényezői

Informatikai projekteredmények elfogadottságának tényezői Informatikai projekteredmények elfogadottságának tényezői Rabi Ákos 2014.02.18. Tartalom 1. Problémafelvetés Informatikai projekteredmények elfogadottsága 2. Informatikai projektek sikertényezői 3. Szoftverek

Részletesebben

Projekt siker és felelősség

Projekt siker és felelősség Projekt siker és felelősség dr. Prónay Gábor 10. Távközlési és Informatikai Projekt Menedzsment Fórum 2007. április 5. AZ ELŐADÁS CÉLJA figyelem felhívás a siker kritériumok összetettségére, az elmúlt

Részletesebben

Vállalatfejlesztési Diagnózis

Vállalatfejlesztési Diagnózis Vállalatfejlesztési Diagnózis ÚT A BELSŐ POTENCIÁL FELTÁRÁSÁHOZ Az eredmények bemutatásának tartalmi elemei Motiváció Kompetencia Eredmények A Vállalatfejlesztési Diagnózis egy olyan integrált szervezeti

Részletesebben

Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar

Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 12. előadás Szoftverfejlesztési módszerek és modellek Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A szoftver

Részletesebben

Versenyképesség fokozása, avagy az élenjáró élelmiszeripar

Versenyképesség fokozása, avagy az élenjáró élelmiszeripar Versenyképesség fokozása, avagy az élenjáró élelmiszeripar (www.leancenter.hu) Tömpe László Címzetes egyetemi docens Senior lean/tpm tanácsadó Minden jog fenntartva! Versenyképesség Támogató folyamatok

Részletesebben

30 MB INFORMATIKAI PROJEKTELLENŐR

30 MB INFORMATIKAI PROJEKTELLENŐR INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai

Részletesebben

Innermetrix Szervezeti Egészség Felmérés. Vezető János

Innermetrix Szervezeti Egészség Felmérés. Vezető János Innermetrix Szervezeti Egészség Felmérés április 18, 2011 Végezte Innermetrix Hungary Copyright Innermetrix, Inc. 2008 1 IMX Szervezeti Egészség Felmérés Üdvözöljük az Innermetrix Szervezeti Egészség Felmérésén!

Részletesebben

Rugalmas gyártócellák kialakítása

Rugalmas gyártócellák kialakítása Rugalmas gyártócellák kialakítása Miért van szükség gyártócellák kialakítására? Hagyományosan a termelő vállalatok felépítése nem folyamat-, hanem technológia szemléletű. Ez azt jelenti, hogy korábban

Részletesebben

Logisztikai szimulációs módszerek

Logisztikai szimulációs módszerek Üzemszervezés Logisztikai szimulációs módszerek Dr. Juhász János Integrált, rugalmas gyártórendszerek tervezésénél használatos szimulációs módszerek A sztochasztikus külső-belső tényezőknek kitett folyamatok

Részletesebben

Verifikáció és validáció Általános bevezető

Verifikáció és validáció Általános bevezető Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának

Részletesebben

Dunavarsány Polgármesteri Hivatalának Szervezetfejlesztése

Dunavarsány Polgármesteri Hivatalának Szervezetfejlesztése Dunavarsány Polgármesteri Hivatalának Szervezetfejlesztése ÁROP-3.A.1/2008-0018 9. részfeladat Pályázati kiírás 12. területe A projekt szemlélet megerősítése Képzési tematika Készítette: SKC Consulting

Részletesebben

extreme Programming programozástechnika

extreme Programming programozástechnika extreme Programming programozástechnika Készítette: Török T k Balázs G5-S8 Kezdetek Martin Fowler : The New Methodology Legtöbb projekt követelményei állandóan változnak Megoldást adaptív módszerek Kezdetek

Részletesebben

1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI

1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI 1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI 1.1 MIT JELENT ÉS MIÉRT FONTOS A KOCKÁZATMENEDZSMEN T? A Project Management Institute (PMI) definíciója szerint a projekt egy ideiglenes

Részletesebben

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs Bevezetés Projektellenőr szerepe és feladatai Informatika Informatikai függőség Informatikai projektek Mérnöki és informatikai feladatok találkozása technológiák 1 Tartalom Informatikai projektellenőr

Részletesebben

Feladatunk, hogy az alábbiakban látható tízgépes elrendezésre meghatározzuk az operátorok optimális kiosztását a vevői igények függvényében.

Feladatunk, hogy az alábbiakban látható tízgépes elrendezésre meghatározzuk az operátorok optimális kiosztását a vevői igények függvényében. Kosztolányi János Operátorkiosztás tervezése Feladatunk, hogy az alábbiakban látható tízgépes elrendezésre meghatározzuk az operátorok optimális kiosztását a vevői igények függvényében. Első lépésként

Részletesebben

Folyamatfejlesztési projektek a szolgáltató központokban

Folyamatfejlesztési projektek a szolgáltató központokban Folyamatfejlesztési projektek a szolgáltató központokban PMSZ, 2013.május 16. Sződy Noémi 12 év Szolgáltatói szektorra specializált folyamat- és szervezetfejlesztés Nemzetközi projektek I. Lean IT konferencia

Részletesebben

Rendszer szekvencia diagram

Rendszer szekvencia diagram Rendszer szekvencia diagram Célkitűzések A rendszer események azonosítása. Rendszer szekvencia diagram készítése az eseményekre. 2 1.Iteráció Az első igazi fejlesztési iteráció. A projekt kezdeti szakaszában

Részletesebben

I. kommunikációs csomag:

I. kommunikációs csomag: Az uniós pályázatok kedvezményezettjei eltérő tartalmú kommunikációs csomagokat kötelesek megvalósítani. Ezt minden esetben a pályázati útmutató rögzíti a projekt jellegének és mertének megfelelően.a szigorú

Részletesebben

A projektmenedzsment gyakorlata Magyarországon

A projektmenedzsment gyakorlata Magyarországon A projektmenedzsment gyakorlata Magyarországon A Budapesti Corvinus Egyetem és a Magyar Projektmenedzsment Szövetség felmérésének eredményei 2018. május 17. 1 A kutatás célja Kutatás célja és célcsoportja

Részletesebben

Alkalmazkodjunk együtt a digitális változásokhoz! Mizsei Szabolcs XAPT digitális tanszformációs tanácsadó

Alkalmazkodjunk együtt a digitális változásokhoz! Mizsei Szabolcs XAPT digitális tanszformációs tanácsadó Alkalmazkodjunk együtt a digitális változásokhoz! Mizsei Szabolcs XAPT digitális tanszformációs tanácsadó Mi is az a digitális kihívás? Vezetői gyakorlat kihívásai Marketing, termék- és szervezet-fejlesztés

Részletesebben

BME MVT. Dr. Topár József 1. Minőségmenedzsment MSc_ /2013 II felév

BME MVT. Dr. Topár József 1. Minőségmenedzsment MSc_ /2013 II felév 1 Bevezettük az ISO-t, aztán foglalkoztunk a TQM-mel, belevágtunk a SixSigmába, most pedig Leanezünk..?????? Módszer? Divat???? Vezetési eszköz? Gondolkodás mód?????? 2 3 Dr. Topár József 1 1. generáció

Részletesebben

Stratégia felülvizsgálat, szennyvíziszap hasznosítási és elhelyezési projektfejlesztési koncepció készítés című, KEOP- 7.9.

Stratégia felülvizsgálat, szennyvíziszap hasznosítási és elhelyezési projektfejlesztési koncepció készítés című, KEOP- 7.9. Stratégia felülvizsgálat, szennyvíziszap hasznosítási és elhelyezési projektfejlesztési koncepció készítés című, KEOP- 7.9.0/12-2013-0009 azonosítószámú projekt Előzmények A Nemzeti Települési Szennyvízelvezetési

Részletesebben

A Scrum Útmutató. Meghatározó útmutató a Scrumhoz: A játék szabályai. Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland

A Scrum Útmutató. Meghatározó útmutató a Scrumhoz: A játék szabályai. Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland A Scrum Útmutató Meghatározó útmutató a Scrumhoz: A játék szabályai Kifejlesztette és karbantartja Ken Schwaber és Jeff Sutherland Tartalomjegyzék A Scrum útmutató célja... 3 A Scrum meghatározása... 3

Részletesebben

Név: Neptun kód: Pontszám:

Név: Neptun kód: Pontszám: Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,

Részletesebben

Szolgáltatás tájékoztató 2018

Szolgáltatás tájékoztató 2018 Szolgáltatás tájékoztató 2018 Tanácsadás - Folyamatmenedzsment Folyamatmodellezés, elemzés és szimuláció Oktatás: elméleti tanfolyamok és szimulációs játékok A Defenders s.r.o. tanácsadási és tréning szolgáltatásai

Részletesebben

Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni?

Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni? Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni? Kritikus pontok Ethernet interfész soros eszközbe ágyazásakor Az ipari Ethernet technológia az alacsony költségeinek és jelentős hálózati

Részletesebben

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A

Részletesebben

Hatékonyságnövelő program

Hatékonyságnövelő program Hatékonyságnövelő program LARSKOL Tanácsadók 1165 BUDAPEST, FARKASFA U. 21. +3620 931 7979 +3620 329 2651 email: info@larskol.hu web: www.larskol.hu Hatékonyságnövelés - költségcsökkentés A gazdasági környezet

Részletesebben

VIKKK III: firány: Korszer technológia rendszerek fejlesztése, se, optimalizálása

VIKKK III: firány: Korszer technológia rendszerek fejlesztése, se, optimalizálása VIKKK III: firány: Korszer technológia rendszerek fejlesztése, se, optimalizálása Szeifert Ferenc Veszprémi Egyetem, Folyamatmérnöki Tanszék Veszprém, 2006. január Elzmény projektek: Projektek Vegyipari

Részletesebben

Önkiszolgáló BI Az üzleti proaktivítás eszköze. Budapest,

Önkiszolgáló BI Az üzleti proaktivítás eszköze. Budapest, Önkiszolgáló BI Az üzleti proaktivítás eszköze Budapest, 2016.10.27 Tartalom 1. Kihívások Való Világ 2. Hogyan segít az Önkiszolgáló BI? confidential 10/26/2016 2 Riportokkal szembeni igények alakulása

Részletesebben

Magyar Projektmenedzsment Szövetség

Magyar Projektmenedzsment Szövetség Magyar Projektmenedzsment Szövetség A projektmenedzsment szerepe az irányításban Ulicsák Béla Műszaki igazgató BRIT TECH Üzleti Tanácsadó Kft. bela@brit-tech.hu Budapest, 2010. március 17. Tartalom Bevezető

Részletesebben

Tesztmérnök: tesztautomatizálási mérnök Feladat: Elvárások: Előnyt jelent: Beágyazott rendszer tesztmérnök beágyazott rendszer tesztmérnök Feladat:

Tesztmérnök: tesztautomatizálási mérnök Feladat: Elvárások: Előnyt jelent: Beágyazott rendszer tesztmérnök beágyazott rendszer tesztmérnök Feladat: Tesztmérnök: Új munkatársakat keresünk tesztautomatizálási mérnök pozícióba. Várjuk a téma iránt elkötelezett, nyitott és motivált kollégák jelentkezését, tapasztalt, illetve kevésbé tapasztalt jelöltek

Részletesebben

Pécsi Tudományegyetem Közgazdaságtudományi Kar

Pécsi Tudományegyetem Közgazdaságtudományi Kar Pécsi Tudományegyetem Közgazdaságtudományi Kar KREATÍV IPARI SZAKEMBER szakirányú továbbképzési szak 1 Napjainkban a vállalatok, vállalkozások, illetve a munkaerőpiac részéről egyre jelentősebb igény mutatkozik

Részletesebben

TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK

TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,

Részletesebben

9. fejezet címe: Lean menedzsment jellemzése 1. lecke: Lean menedzsment alapjai Elsajátítási idő: 60 perc

9. fejezet címe: Lean menedzsment jellemzése 1. lecke: Lean menedzsment alapjai Elsajátítási idő: 60 perc 9. fejezet címe: Lean menedzsment jellemzése 1. lecke: Lean menedzsment alapjai Elsajátítási idő: 60 perc Mi a lean? A lean menedzsment a TPS (Toyota Product System) módszer európai és amerikai szemléletre

Részletesebben

Email Marketing szolgáltatás tájékoztató

Email Marketing szolgáltatás tájékoztató Email Marketing szolgáltatás tájékoztató RENDESWEB Kft. Érvényes: 2012.03.01-től visszavonásig +3 20 A RENDES (273 337) 1. Minőség Nálunk legmagasabb prioritást vevőink elégedettsége élvez így próbálunk

Részletesebben

Andó Mátyás Felületi érdesség matyi.misi.eu. Felületi érdesség. 1. ábra. Felületi érdességi jelek

Andó Mátyás Felületi érdesség matyi.misi.eu. Felületi érdesség. 1. ábra. Felületi érdességi jelek 1. Felületi érdesség használata Felületi érdesség A műszaki rajzokon a geometria méretek tűrése mellett a felületeket is jellemzik. A felületek jellemzésére leginkább a felületi érdességet használják.

Részletesebben

A Lean alapelvének megvalósulása: Információ áramlás VSM

A Lean alapelvének megvalósulása: Információ áramlás VSM A Lean alapelvének megvalósulása: Információ áramlás VSM Péczely György A.A. Stádium Kft. gyorgy.peczely@aastadium.hu 20/330 5545 Tartalom Mi a Lean? Hatékonyság A vállalatról Előzmények A felmérés Az

Részletesebben

IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél

IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél Molnár László MNB, ITIL Projektvezető Fábián János ICON Professional Services Vezérfonal Az MNB IT működése, a SIP kiváltó okai A projekt módszereinek

Részletesebben

Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével. Gyutai Balázs Loxon Tessényi András - Supercharge

Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével. Gyutai Balázs Loxon Tessényi András - Supercharge Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével Gyutai Balázs Loxon Tessényi András - Supercharge Kik Vagyunk Szoftverfejlesztő cégünk nagy üzleti tudással és

Részletesebben

Hogyan építsünk Lean rendszereket?

Hogyan építsünk Lean rendszereket? Hogyan építsünk Lean rendszereket? 2017.06.29. Pick Szeged Zrt. Péczely György ügyvezető A.A. Stádium Kft. gyorgy.peczely@aastadium.hu 20/330 5545 Mitől működhet jól egy rendszer 1. tanulság: az ember

Részletesebben

INPUT PROGRAM 2. Kanban és SCRUM. KANBAN alapok

INPUT PROGRAM 2. Kanban és SCRUM. KANBAN alapok INPUT PROGRAM 2. Kanban és SCRUM KANBAN alapok 1 2 3 4 SCRUM alapok 5 Mit ígér a SCRUM? Mennyire bonyolult? 6 A SCRUM két alapelve Empirikus folyamat: a részletes tervek és meghatározott folyamatok helyét

Részletesebben

Scrum vagy nem scrum - ahol nem hibázhatunk Röviden a budapesti fejlesztési központról

Scrum vagy nem scrum - ahol nem hibázhatunk Röviden a budapesti fejlesztési központról Röviden a budapesti fejlesztési központról MIT? Érzékelés, mérés Ultrahang (Beparkolás) Video (számtalan szolgáltatás) Radar (Ködben, sötétben ) Műszerfal Szabályzás Váltó és motor Menetstabilizálás (ESP)

Részletesebben

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN

Részletesebben

VÁLLALATGAZDASÁGTAN II. Döntési Alapfogalmak

VÁLLALATGAZDASÁGTAN II. Döntési Alapfogalmak Vállalkozási VÁLLALATGAZDASÁGTAN II. Tantárgyfelelős: Prof. Dr. Illés B. Csaba Előadó: Dr. Gyenge Balázs Az ökonómiai döntés fogalma Vállalat Környezet Döntések sorozata Jövő jövőre vonatkozik törekszik

Részletesebben

CÉGBEMUTATÓ. Emberközpontú üzleti megoldások.

CÉGBEMUTATÓ. Emberközpontú üzleti megoldások. CÉGBEMUTATÓ Emberközpontú üzleti megoldások. A Viapan Group tíz üzletágával Magyarország meghatározó humánerőforrás-szolgáltatója. Cégcsoportunk komplex és egyedülállóan innovatív szolgáltatás nyújt, amelynek

Részletesebben

Összefoglaló jelentés

Összefoglaló jelentés Összefoglaló jelentés A 2018. évi országgyűlési képviselők választásának lebonyolítási időszakában a választást támogató informatikai rendszerek működése során történt informatikai események vizsgálatáról

Részletesebben

Hogyan válaszolhat a gyógyszeripar az új kihívásokra? Gyógyszeripari szakmai nap

Hogyan válaszolhat a gyógyszeripar az új kihívásokra? Gyógyszeripari szakmai nap Hogyan válaszolhat a gyógyszeripar az új kihívásokra? Gyógyszeripari szakmai nap CHINOIN Zrt.- a Sanofi vállalata 2013.09.12. dr. Péczely György A.A. Stádium Kft. Tartalom A gyógyszeripar kihívásai Lehetséges

Részletesebben

evosoft Hungary Kft.

evosoft Hungary Kft. Intelligens eszközök fejlesztése az ipari automatizálásban 9. fejezet: Minőség menedzsment Előadó: Harrer Ágnes Krisztina minőségügyi megbízott menedzser ELŐADÓ: HARRER ÁGNES KRISZTINA Minőségügyi megbízott

Részletesebben

Logisztikai. ellátási lánc teljes integrálására. Logisztikai szolgáltatók integrációja. B2B hálózatokhoz a FLUID-WIN projektben.

Logisztikai. ellátási lánc teljes integrálására. Logisztikai szolgáltatók integrációja. B2B hálózatokhoz a FLUID-WIN projektben. Logisztikai szolgáltatók integrációja B2B hálózatokhoz a FLUID-WIN projektben Külső logisztikai szolgáltatók integrációja interdiszciplináris web-alapú platformon The logistic domai under the 6th Fram

Részletesebben

Minőségmenedzsment és Informatika Test-Driven Development

Minőségmenedzsment és Informatika Test-Driven Development Minőségmenedzsment és Informatika Test-Driven Development Varga Balázs G5S8 2008.10.27 Szoftverfejlesztés jellemzői Megrendelői igények Tervezés Implementálás Tesztelés Dokumentálás

Részletesebben

Email Marketing szolgáltatás tájékoztató

Email Marketing szolgáltatás tájékoztató Email Marketing szolgáltatás tájékoztató RENDESWEB Kft. Érvényes: 2013.03.01-től visszavonásig +3 20 A RENDES (273 337) Adószám: 12397202-2-42 Cégjegyzékszám: 01-09-7079 1. Minőség Nálunk legmagasabb prioritást

Részletesebben

Funkciópont elemzés: elmélet és gyakorlat

Funkciópont elemzés: elmélet és gyakorlat Funkciópont elemzés: elmélet és gyakorlat Funkciópont elemzés Szoftver metrikák Funkciópont, mint metrika A funkciópont metrika alapelveinek áttekintése Bonyolultsággal korrigált funkciópont A funkciópont

Részletesebben

TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS

TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,

Részletesebben

A Lean módszerek lehetőségei az informatika világában

A Lean módszerek lehetőségei az informatika világában A Lean módszerek lehetőségei az informatika világában SzegedTech Meetup Szeged, 2015.09.30. Péczely György Ügyvezető igazgató A.A. Stádium Kft. gyorgy.peczely@aastadium.hu 20/330-5545 www.aastadium.hu

Részletesebben

SLA RÉSZLETESEN. 14. óra

SLA RÉSZLETESEN. 14. óra 14. óra SLA RÉSZLETESEN Tárgy: Szolgáltatás menedzsment Kód: NIRSM1MMEM Kredit: 5 Szak: Mérnök Informatikus MSc (esti) Óraszám: Előadás: 2/hét Laborgyakorlat: 2/hét Számonkérés: Vizsga, (félévi 1db ZH)

Részletesebben

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és

Részletesebben

Lean menedzsment alapjai - tételek

Lean menedzsment alapjai - tételek Lean menedzsment alapjai - tételek Az alábbi tételek visszaköszönnek majd a vizsgán. A válaszok a főbb kiindulási gondolatokat közlik, természetesen mindegyikhez átfogóbb (kidolgozott) válaszokat kell

Részletesebben

Projekt szponzor : siker - felelősség - kompetencia

Projekt szponzor : siker - felelősség - kompetencia Projekt szponzor : siker - felelősség - kompetencia dr. Prónay Gábor 11. Projektmenedzsment a Gazdaságban Fórum 2008. április 10. AZ ELŐADÁS CÉLJA figyelem felhívás a projekt tulajdonos/szponzor meghatározó

Részletesebben

DIAGNOSZTIKA - A FOLYAMAT FELMÉRÉS LEGHATÉKONYABB ESZKÖZE

DIAGNOSZTIKA - A FOLYAMAT FELMÉRÉS LEGHATÉKONYABB ESZKÖZE ERP-rendszerek bevezetésének csupán egyharmada mondható sikeresnek. Unalomig ismert tény, hogy az informatikai projektek mintegy 2/3-a sikertelennek minősíthető, és még a fennmaradóknak is csupán csekély

Részletesebben

PROJEKTMENEDZSERI ÉS PROJEKTELLENŐRI FELADATOK

PROJEKTMENEDZSERI ÉS PROJEKTELLENŐRI FELADATOK Adat és Információvédelmi Mesteriskola MIR a projektben 30 MB KÁLMÁN MIKLÓS ÉS RÁCZ JÓZSEF PROJEKTMENEDZSERI ÉS PROJEKTELLENŐRI FELADATOK 2018.10.19. Adat és Információvédelmi Mesteriskola 1 MIR Tartalom:

Részletesebben

Vállalatgazdaságtan. Minden, amit a Vállalatról tudni kell

Vállalatgazdaságtan. Minden, amit a Vállalatról tudni kell Vállalatgazdaságtan Minden, amit a Vállalatról tudni kell 1 Termelési rendszer vizsgálata 2 képzeljük el az alábbi helyzetet örököltünk egy gyárat mit csináljunk vele? működtessük de hogyan? Hogyan működik

Részletesebben

INFORMATIKAI PROJEKTELLENŐR

INFORMATIKAI PROJEKTELLENŐR INFORMATIKAI PROJEKTELLENŐR MIR a projektben 30 MB KÁLMÁN MIKLÓS ÉS RÁCZ JÓZSEF PROJEKTMENEDZSERI ÉS PROJEKTELLENŐRI FELADATOK 2017. 02. 24. MMK-Informatikai projektellenőr képzés 1 MIR Tartalom: 2-12

Részletesebben

A-TÓL Z-IG GARANTÁLTAN ISMERJÜK A MEDDŐENERGIA MEGSZÜNTETÉSÉNEK MINDEN MÓDJÁT!

A-TÓL Z-IG GARANTÁLTAN ISMERJÜK A MEDDŐENERGIA MEGSZÜNTETÉSÉNEK MINDEN MÓDJÁT! A-TÓL Z-IG GARANTÁLTAN ISMERJÜK A MEDDŐENERGIA MEGSZÜNTETÉSÉNEK MINDEN MÓDJÁT! Energiaveszteség kizárva! Fázisjavítás. Felharmonikus szűrés. Energiamenedzsment. Energiagazdálkodás... már éve! A KEVÉS LÁTHATÓ

Részletesebben

Néhány gondolat a projekt menedzsment kommunikációjához

Néhány gondolat a projekt menedzsment kommunikációjához Néhány gondolat a projekt menedzsment kommunikációjához avagy amiről a módszertanok nem írnak dr. Prónay Gábor 6. Távközlési és Informatikai Projekt Menedzsment Fórum 2003. április 10. AZ ELŐADÁS CÉLJA

Részletesebben

(Teszt)automatizálás. Bevezető

(Teszt)automatizálás. Bevezető (Teszt)automatizálás Bevezető Órák ( az előadások sorrendje változhat) 1. Bevezető bemutatkozás, követelmények, kérdések és válaszok 2. Előadás Unit test in general, 3. Előadás Unit test, Tools and practices,

Részletesebben

Követelmény alapú minőségbiztosítás az államigazgatásban

Követelmény alapú minőségbiztosítás az államigazgatásban Követelmény alapú minőségbiztosítás az államigazgatásban László István 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Témák Követelmény

Részletesebben

Lean Történet Today es. Első lépések: Japán. Autóipari beszállítók. Első hullám: Nemzetközi. Autóipari beszállítók

Lean Történet Today es. Első lépések: Japán. Autóipari beszállítók. Első hullám: Nemzetközi. Autóipari beszállítók Lean Történet 1990-es 2000 2005 Today Első lépések: Japán Autóipari beszállítók Első hullám: Nemzetközi Autóipari beszállítók Második hullám: Multik és Magyar cégek Lean nem működik Tapasztalatok az elmúlt

Részletesebben

TPM egy kicsit másképp Szollár Lajos, TPM Koordinátor

TPM egy kicsit másképp Szollár Lajos, TPM Koordinátor TPM egy kicsit másképp Szollár Lajos, TPM Koordinátor 2013.06.18 A TPM A TPM a Total Productive Maintenance kifejezés rövidítése, azaz a teljes, a gyártásba integrált karbantartást jelenti. A TPM egy állandó

Részletesebben

Continuous delivery: cél a működő szoftver

Continuous delivery: cél a működő szoftver Application Lifecycle Management konferencia Continuous delivery: cél a működő szoftver Csutorás Zoltán, Novák István, Farkas Bálint, Érsek Attila, Kőnig Tibor A folyamatos értékszállítás Csutorás Zoltán

Részletesebben

TAXONÓMIA ÉS MAGYARÁZATUK AZ ÖNÉRTÉKELÉSHEZ

TAXONÓMIA ÉS MAGYARÁZATUK AZ ÖNÉRTÉKELÉSHEZ PROJEKT MENEDZSMENT MESTERSÉG KITŰNŐSÉGÉÉRT ALAPÍTVÁNY www.ipmacert.hu TAXONÓMIA ÉS MAGYARÁZATUK AZ ÖNÉRTÉKELÉSHEZ 1106 Budapest, Jászberényi u. 24-36. 1363 Bubapest 502., Pf. 92/2. +36 30 8631 038 + 36

Részletesebben

A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál

A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál Előadó: Ulicsák Béla műszaki igazgató BRIT TECH Üzleti Tanácsadó Kft. Napirend 1. Az építő-, szerelőipar érdekcsoportjai

Részletesebben

2651. 1. Tételsor 1. tétel

2651. 1. Tételsor 1. tétel 2651. 1. Tételsor 1. tétel Ön egy kft. logisztikai alkalmazottja. Ez a cég új logisztikai ügyviteli fogalmakat kíván bevezetni az operatív és stratégiai működésben. A munkafolyamat célja a hatékony készletgazdálkodás

Részletesebben

Symbol Ügyvitel CRM Extra modul

Symbol Ügyvitel CRM Extra modul Miért CRM? Minden cég alapvető érdeke, hogy lehetséges vevői közül a lehető legtöbbet szerezzen meg, a legtöbbjük számára tudja értékesíteni termékeit vagy szolgáltatásait. A megfelelő eszközzel ezek az

Részletesebben

Grafikonok automatikus elemzése

Grafikonok automatikus elemzése Grafikonok automatikus elemzése MIT BSc önálló laboratórium konzulens: Orosz György 2016.05.18. A feladat elsődleges célkitűzései o eszközök adatlapján található grafikonok feldolgozása, digitalizálása

Részletesebben

Projektek értékelése. dr. Koós Tamás 2013. szeptember 18. Budapest

Projektek értékelése. dr. Koós Tamás 2013. szeptember 18. Budapest Projektek értékelése dr. Koós Tamás 2013. szeptember 18. Budapest Az értékelés Annak a vizsgálata, hogy a projekt vagy program miképpen járul hozzá a kitűzött, átfogó célok eléréséhez; Annak vizsgálata,

Részletesebben

Beszerzési és elosztási logisztika. Előadó: Telek Péter egy. adj. 2008/09. tanév I. félév GT5SZV

Beszerzési és elosztási logisztika. Előadó: Telek Péter egy. adj. 2008/09. tanév I. félév GT5SZV Beszerzési és elosztási logisztika Előadó: Telek Péter egy. adj. 2008/09. tanév I. félév GT5SZV 2. Előadás A beszerzési logisztika alapjai Beszerzési logisztika feladata/1 a termeléshez szükséges: alapanyagok

Részletesebben

A verseny új dimenziója

A verseny új dimenziója A verseny új dimenziója Új helyzet Tartós változásokra kell berendezkednünk A versenyképesség fontos tényezőjévé válik a HR A minőség kritikus feltételévé válik a szervezeti stabilitás A humán erőforrás

Részletesebben

S atisztika 1. előadás

S atisztika 1. előadás Statisztika 1. előadás A kutatás hatlépcsős folyamata 1. lépés: Problémameghatározás 2. lépés: A probléma megközelítésének kidolgozása 3. lépés: A kutatási terv meghatározása 4. lépés: Terepmunka vagy

Részletesebben

Minőségmenedzsment alapok

Minőségmenedzsment alapok MENEDZSMENT ÉS VÁLLALKOZÁSGAZDASÁGTAN (BMEGT20A001) Z ALAPKÉRDÉSEK 2007/08/2 félév 3. zárthelyi dolgozat Minőségmenedzsment alapok Tesztek (A zh-n nem ugyanebben a sorrendben szerepelnek a válaszok, egy

Részletesebben

Az ISO-szabványok 3.1 Az ISO minőségügyi szabványai 3.2 Az ISO 9000 szabványsorozat elemei

Az ISO-szabványok 3.1 Az ISO minőségügyi szabványai 3.2 Az ISO 9000 szabványsorozat elemei 3. Az ISO-szabványok 3.1 Az ISO minőségügyi szabványai A minőségügyi szabványokat az ISO egyik bizottsága, az ISO/TC 176 alkotta, ez a bizottság végzi, a továbbfejlesztés munkáját is. A szabványsorozat

Részletesebben

Képfeldolgozó rendszerek a méréstechnikában

Képfeldolgozó rendszerek a méréstechnikában Képfeldolgozó rendszerek a méréstechnikában www.falcon-vision.com GYÁRTÓSORI ELLENÔRZÉS MINÔSÉGBIZTOSÍTÁS FOLYAMATDIAGNOSZTIKA www.falcon-vision.com Termékeink felhasználási köre Képfeldolgozó mérôrendszerek

Részletesebben

Szervezeti működésfejlesztés komplexitása CMC minősítő előadás

Szervezeti működésfejlesztés komplexitása CMC minősítő előadás Szervezeti működésfejlesztés komplexitása CMC minősítő előadás Sarlósi Tibor 2012. február 28. Érintett területek 1 Diagnózis 2 Stratégiamenedzsment 3 Folyamatmenedzsment 4 Projektmenedzsment 6 rendszerek

Részletesebben

Vezetői teljesítményértékelés értékelő és önértékelő kérdőív Készítették: a KISOSZ munkatársai

Vezetői teljesítményértékelés értékelő és önértékelő kérdőív Készítették: a KISOSZ munkatársai Vezetői teljesítményértékelés értékelő és önértékelő kérdőív Készítették: a KISOSZ munkatársai Veszprém, 6. szeptember Vezetői értékelő lap Kérjük, a megfelelő oszlopban lévő szám aláhúzásával vagy bekarikázásával

Részletesebben

EFOP Köznevelés Sikeres projektportfólió menedzsment Szervezeti feltételek és megoldások. Ríz Ádám november 30.

EFOP Köznevelés Sikeres projektportfólió menedzsment Szervezeti feltételek és megoldások. Ríz Ádám november 30. EFOP Köznevelés Sikeres projektportfólió menedzsment 2018 Szervezeti feltételek és megoldások Ríz Ádám 2017. november 30. Eddig jó Kicsit nehezebb Még egy kicsit nehezebb 2017 2018 2019 2020 Kihívás A

Részletesebben

Előadássorozat vállalkozóknak

Előadássorozat vállalkozóknak Előadássorozat vállalkozóknak Makay Mátyás Patmos Kft. makaym@t-online.hu 2. Előadás A növekedés problémái A kisvállalkozások nagyon különböznek de mégis ugyanolyanok Különböző karakterű tulajdonosok,

Részletesebben

Eladásmenedzsment Bauer András, Mitev Ariel Zoltán

Eladásmenedzsment Bauer András, Mitev Ariel Zoltán Eladásmenedzsment Bauer András, Mitev Ariel Zoltán 1. Fejezet: Az eladásmenedzsment stratégiai szerepe 2/28/2010 1 A fejezet tartalma 1. A különböző eladási helyzetek 2. Az eladásmenedzsment helye a marketingstratégiában

Részletesebben

A minőségköltség - a minőség szerepe a marketingben és a vállalati stratégiában. Ászity Sándor EJJT

A minőségköltség - a minőség szerepe a marketingben és a vállalati stratégiában. Ászity Sándor EJJT A minőségköltség - a minőség szerepe a marketingben és a vállalati stratégiában Ászity Sándor EJJT 1 Tömegtermelés Lean termelés Lean termelés 2 2018.11.24. Minőségköltség Mi a minőség? 3 2018.11.24. A

Részletesebben

Még van pénz a Jeremie Kockázati Tőkealapokban 60% közelében a Start Zrt. Jeremie Kockázati Tőkeindexe

Még van pénz a Jeremie Kockázati Tőkealapokban 60% közelében a Start Zrt. Jeremie Kockázati Tőkeindexe Még van pénz a Jeremie Kockázati Tőkealapokban % közelében a Start Zrt. Jeremie Kockázati Tőkeindexe A Start Zrt. negyedévente adja közre a Start Jeremie Kockázati Tőke Monitor című jelentését, amelyben

Részletesebben

A vállalkozás vezérelvei

A vállalkozás vezérelvei A vállalkozás vezérelvei Developing the future. Magunkról: Raiffeisen evolution project development Cégünk egy Ausztriában, Közép- és Kelet-Európában működő, bécsi székhelyű ingatlanvállalkozás. Sikerünk

Részletesebben

Test Management Strategy Document. Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán

Test Management Strategy Document. Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán Test Management Strategy Document Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán Agenda Bevezetés Ki mit tud statisztika Tesztelési környezet Felelősségek, szerepek és feladatok Tesztelési

Részletesebben

Minőségmenedzsment: azért felel, hogy a projekt teljesítse az elvárt feladatát és a követelményeket.

Minőségmenedzsment: azért felel, hogy a projekt teljesítse az elvárt feladatát és a követelményeket. Jelölje be a helyes választ: ely projektszereplőhöz tartoznak az következő feladatok: sikeresnek vagy sikertelennek nyilvánítja a projektet a megvalósítás során a változtatások engedélyezése a megvalósítás

Részletesebben

Dr. Topár József (BME)

Dr. Topár József (BME) (BME) Budapesti Műszaki és Gazdaságtudományi Egyetem XXII. Magyar Minőség Hét 2013. november 6. 1 Projekt minőségbiztosítás?? minőségmenedzsment??? Projekt K+F+I Mit várunk e rendszerektől? Összehangolás-

Részletesebben

Esettanulmány Folyamatköltség-számítás

Esettanulmány Folyamatköltség-számítás Esettanulmány Folyamatköltség-számítás Az erős versenyben gyorsan növekvő árak és költségek nyomása miatt egyre fontosabb tudni, hogy a közvetlen költségeken kívül milyen közvetett költségek terhelik a

Részletesebben