Emlékeztető: Adaptív és prediktív módszertanok

Átírás

1 Agilis fejlesztés

2 Emlékeztető: Adaptív és prediktív módszertanok Prediktív módszertan Kövess több szabályt! Sok szabályt határoz meg A felhasználó feladata a felesleges elemek eltávolítása az aktuális fejlesztésből Pl.: szükség van változásmenedzsmentre? Nem tudjuk, ezért biztos ami biztos tartsuk meg... Hova vezet mindez? Adaptív módszertan Kövess kevesebb szabályt! Kevés szabályt határoz meg A felhasználó feladata, hogy hozzátegye azokat az elemeket, melyekre még szüksége van az adott fejlesztéshez

3 Kitekintés: Adaptív vs. prediktív módszertanok Pl.: MSZ EN 50128:2011 Tevékenységek száma: 10 életciklus fázis Szereplők: 10 szerepkör Eszközök: több, mint 70 technika Kimenet: 46 féle dokumentum Ajánlások különböző technikák kombinációira Ha a szabvány által ajánlott kombinációt használjuk, azt az asszesszor érvényesnek fogadja el, csak a helyes használat kérdését vitathatja Alkalmazhatóak-e az agilis módszertanok biztonságkritikus rendszerek fejlesztésében? Pl.: SafeScrum, amely egy olyan módszer amely az agilis szoftver fejlesztési alapelveket alkalmazza a biztonságkritikus szabványokra (pl. IEC 61508)

4 Emlékeztető: Tanulságok Vegyítsük a módszereket (és eszközöket) igényeink szerint! Tartsuk tiszteletben minden módszer szabályrendszerét! Ha használunk valamilyen módszert, és úgy döntünk, hogy nem ragaszkodunk tovább valamely szabályához, ne nevezzük többé a nevén Pl. SSADM legyen SSADM alapú Pl. Scrum legyen Scrum-alapú módszer Stb. Ne feledjük, hogy a vegyítésnek vannak hátrányai! Eml.: hibrid módszertanok

5 Problémafelvetés Rengeteg olyan termék készül, amit soha nem használnak semmire Az emberi gyengeséget nem tudjuk kikerülni Hosszas megfigyelést követően sem tudunk pontosan becslést adni a jövőről Nehezen kezeljük a bizonytalanságot (változásokat)

6 Miről lesz szó? Egy olyan módszertanról amely: Az emberekről szól Amiről azt hiszik mindent megold, pedig csak a gyengeségeket hozza felszínre Ami mindenkinek valós és helyes képet ad arról, hogy mi történik Nem módszer! A hogyant nem mondja meg! Alkalmazás: főként a SW fejlesztés területén

7 AGILE dióhéjban Ügyesen/gyorsan reagálni a változásokra Legyen ritmus (pl. hallgató vizsgára készülése utolsó pillanatban) Mi a helyes? Vitassuk meg? Próbáljuk ki? Működő terméket hozzunk létre (nem terveket gyártunk) Csapatmunka (az emberek interakciója a lényeg) Gyakorlatorinetált (nem teória), változás iránti készség Együttműködés az ügyféllel/ megrendelővel

8 Agile manifesto/agilis kiáltvány I. 1. Legfontosabbnak azt tartjuk, hogy a vevőnk elégedett legyen, mert értékes szoftvert szállítunk neki hamar és folyamatosan. 2. Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis módszertanok befogadják a változást a megrendelő versenyképességének érdekében. 3. Gyakran szállítsunk működő szoftvert, pár hetes és hónapos időközönként, lehetőleg a rövidebb periódust választva. 4. A megrendelők, üzleti szakemberek és a szoftverfejlesztők dolgozzanak együtt minden nap a teljes projekt során. 5. Építsük motivált egyénekre a projekteket. Teremtsük meg nekik a számukra szükséges környezetet és támogatást, és bízzunk bennük, hogy elvégzik a munkát. 6. A személyes beszélgetés az információ átadásának leghatásosabb és hatékonyabb módja a fejlesztő csapaton belül.

9 Agile manifesto/agilis kiáltvány II. 7. Az előrehaladás elsődleges mércéje a működő szoftver. 8. Az agilis módszertanok elősegítik a fenntartható fejlesztést. A szponzoroknak, fejlesztőknek, felhasználóknak korlátlan ideig képesnek kell lenniük az egyenletes sebesség megőrzésére. 9. A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást. 10. Az egyszerűség az el nem végzett munkamennyiség maximalizálásának művészete alapvető érték. 11. A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatmunkából alakulnak ki. 12. A fejlesztői csapat rendszeres időközönként megfontolja, hogyan válhatna hatékonyabbá és ennek megfelelően változtatja viselkedését.

10 Középpontban az ember (értékek) Elkötelezettség Koncentráció Nyitottság Bátorság Tisztelet A jó csapat is holtig tanul!

11 SHU-HA-RI SHU: amikor a tanuló követi a mestere minden instrukcióját kérdés nélkül (szabálykövetés) HA: amikor a tanuló tanárrá válik és elszakad mesterétől (szabályalkotás) RI: te magad vagy a szabály 守 - 破 - 離

12 Emlékeztető: Agilis életciklus

13 Agilis módszertan alkalmazása egy szervezetben Az alkalmazás feltételei: Kevesebb, gyakorlottabb és nagyobb szakértelemmel rendelkező fejlesztő A szervezet támogatja a folyamatos párbeszédet a fejlesztők és megrendelők között A szervezet megbízik a fejlesztőkben és elfogadja azok döntéseit Munkakörnyezet lehetővé teszi a fejlesztők közötti gyors, hatékony kommunikációt Mikor ne alkalmazza a szervezet? Szétosztott (több különböző helyszínen történő) fejlesztés A vezetés túlságosan parancsosztó jellegű Nagy projektméretek Mikor alkalmazza a szervezet? Összeszokott, tapasztalt fejlesztők Gyakran változó követelmények Kis/közepes projektméret

14 Agilis módszertan és módszerei Saját módszerein túl integrálhatja bármely eddig bemutatott strukturális, objektumorientált módszert is! XP PP Kanban LEAN DSDM CI SCRUM TDD FDD Crystal BDD

15 SCRUM

16 Bevezetés Rögbiből átvett kifejezés: dulakodás Iteratív és inkrementális (eml.: fejlesztési életciklus modellek) Nagyfokú adaptivitás Jellemzők, alapelvek: A megrendelő a fejlesztő csapat része Gyakoriak a köztes szállítások működő funkcionalitással A köztes állapotokat is ellenőrzik, hogy ne csak a végén derüljenek ki a problémák Gyakori a kockázatelemzés: napi megbeszélést tartanak Hatékony munkavégzés: a több munkaóra nem feltétlenül vezet több eredményre

17 Szerepkörök Terméktulajdonos (Product Owner) A megrendelő képviselete A csapat csak az üzleti szempontból fontos dolgokkal foglalkozzon A termék-teendőlistát (product backlog) bővítse a megrendelői igényekkel A fejlesztőcsapattal együtt prioritással lássa el az igényeket Scrum Master Akadályok elhárítása (sprint megvalósításának biztosítása) Scrum helyes alkalmazása (szabályok betartatása) Munka feltételeinek megteremtése és megtartása Csapat védelme (így csak a feladatra koncentrálhatnak) Nem a csapat vezetője! Csapat (team) A termék elkészítése Átlagosan 5-9 fő Önszerveződésen alapul

18 Folyamat és szereplők a folyamatban

19 Product Backlog Felelőse: Product Owner A termék(ek)re vonatkozóan tartalmaz magas szintű követelményeket Fejlesztési célok Eml.: követelmények csoportosítás (funkcionális és nemfunkcionális) A követelménylista elemeit prioritás szerint rendezik Becslések a fejlesztések üzleti értékére és ráfordításigényére Az üzleti értéket a PO határozza meg, A fejlesztési ráfordításigényt a fejlesztők határozzák meg A becslések képezik az alapját a prioritások meghatározásának Azt a fejlesztést valósítjuk meg először, aminek jobb a megtérülése

20 Product Backlog Item (PBI) Követelmények: INVEST Independent (független): PBI legyen önálló, ne függjön más PBI-ktől Negotiable (megbeszélhető): PBI-k nem szerződések, ezért biztosítani kell a megvitathatóságukat Valuable (értékes): minden PBI biztosítson értéket az érdekeltek szemszögéből nézve Estimate-able (becsülhető): minden PBI méretének becsülhetőségét biztosítani kell Small (kicsi): olyan méretű PBI-ket kell definiálni, melyek jól méretezhetőek/tervezhetőek Testable (tesztelhetőség): minden PBI legyen ellenőrizhető és definiálja az ellenőrzéséhez szükséges információkat

21 User Stroy User Story (felhasználói történet): a termék funkcióinak magas szintű, megrendelő-központú leírása Kártya előlapja: Szerep (Ki?) Funkció (Mit?) Érték (Miért?) Conversation: úgy legyen megfogalmazva, hogy Lehessen róla beszélgetni Lehessen emlékezni rá Kártya hátlapja: DoD: Definiton Of Done Elfogadási kritérium Confirmation: az ellenőrzéshez szükséges legfontosabb ismeretek

22 Product Backlog (példa) Project: Shopping Website Priority Product Backlog Items User Story # 1 Database Creation 9 2 Login Page 15 3 Category Paga 23 4 Payment Process 18 5 Contact Page 3 6 Banner Area 1 User Story As an operations engineer, I want to be able store all customer information, so that I can serve to customers. As a site member, I want to login the site, so that I can do online shopping. As a site member, I want to be able to look for different categories of brands, so that I can choose what I want. As a site member, I will be able to make payment, so that my deliveries can be shipped. As a site member, I want to be able to find contact information of the site, so that in case I need, I can contact. As a marketing personnel, I want to be able to make advertisement, so that I can attract visitors. Story Point Estimate (Hours)

23 Sprint tervező megbeszélés Sprint (futam): a futamtervezés során kiválasztott teendők megvalósítására szánt rövid iteráció (2-4 hét) Minden sprint előtt megtartják, céljai: Az elvégzendő feladatok kijelölése a Product Backlog-ból Időszükségletek becslése Kommunikáció az érdekeltekkel Sprint Backlog előkészítése Sprint Review és Retrospective előkészítése Maximum 8 óra hosszúságú (4 hetes sprint) Rövidebb sprint esetén rövidebb

24 Sprint Backlog

25 Daily stand-up (Napi megbeszélés) Rövid (kb. 15 perc), naponta (és állva) tartott megbeszélés, ahol a csapattagok megbeszélik, hogy ki: Mit csinált tegnap? Mit fog csinálni ma? Vannak-e akadályok a céljai elérésben? Semmilyen problémát nem söpörnek a szőnyeg alá Mindenkit meghallgatnak, aki felismer valamilyen problémát

26 Sprint Review A sprint során mely munkák készültek el és melyek nem Az elkészült munka bemutatása a PO-nak és a fejlesztésben érdekelteknek Demo Be nem fejezett munkát nem szabad bemutatni! Maximum 4 óra hosszúságú (4 hetes sprint) Rövidebb sprint esetén rövidebb

27 Retrospective (visszatekintés) Folyamatos folyamatfejlesztés Célja meghatározni, hogy: Mi ment gördülékenyen? Mi működött jól? Mik okozott problémákat, hibákat? Mi nem ment jól? Mit kellene másképpen csinálni a következő sprintben? Hogyan növeljük a hatékonyságot? Hogyan szűntessük meg a problémákat? Minden csapattag elmondja a véleményét az utolsó sprinttel kapcsolatban A csapat megegyezik hogy mit változtatnak a fejlesztési folyamaton a következő sprintben Maximum 3 óra hosszú (4 hetes sprint) Rövidebb sprint esetén rövidebb

28 Becslés, folyamatmonitorozás, metrikák I. Burn-down/Burn-up chart A sprint teendőlistájából hátralévő munka mennyiségét mutatják Mindenki számára elérhetők Minden nap frissítik őket Burn-down chart: Veszély (elvégzendő tevékenységek száma elvégzett tevékenységek száma)/nap Burn-up chart: (elvégzendő tevékenységek száma nem elvégzett tevékenységek száma)/nap Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében

29 Becslés, folyamatmonitorozás, metrikák II. Burn-down chart lehetséges lefutások

30 Becslés, folyamatmonitorozás, metrikák III. Velocity (sebesség): a csapat sebessége a sprint során elkészített elemek száma (összpontszáma) A sebességbecslés céljai: Jól becsülhető,hogy az ismert teendőlista mikor fogy el Megmutatja, hogy a folyamatváltoztatások javítottak-e a hatékonyságon PO felhasználja release tervezéshez: Hány csapatnak hány sprint fog kelleni a kívánt funkcionalitás eléréséhez? A Burn-down/Burn-up chart-ban célszerű megjeleníteni Új csapatok esetén a sebesség jellemzően futamról-futamra nő Tapasztalt csapatok esetén közel állandó

31 SCRUM összefoglalás PROCESS PEOPLE ESTIMATION USER STORY Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében

32 Kanban

33 Bevezetés Kan = kártya (japán) Toyota: a folyamatban lévő munkák alatt lekötött készletek korlátozása a gyártótérben Alapja a Lean húzó ütemezési rendszer: egy elem csak akkor léphet a következő állapotra, ha felszabadul erőforrás amely foglalkozni tud vele A Kanbant adaptálták a SW fejlesztésbe, mint projekt menedzsment megközelítés

34 A kanban alkalmazásának hasznai A szűk keresztmetszetek időben azonosíthatóak Változékony környezet kezelhetővé válik Növeli a folyamatok átláthatóságát (várakozási idők csökkennek) Csökkenti a felhalmozott erőforrásokat (ezáltal csökkenti a vállalti költségeket) Hulladék megszűntetése (túltermelést elkerüljük, ezáltal időt és erőforrásokat spórolunk meg)

35 Alapkoncepció Munkafolyamatok ábrázolása Kanban tábla (Kanban board) Elvégzendő feladatok azonosítása Kártya: hol tart a feladat a folyamatban WIP (work in progress) korlátozása A folyamatban lévő tevékenységek mennyiségének korlátozása minden állapotban Átfutási idő (lead time) mérése A tevékenységek végrehajtására fordított átlagos idő Mérés célja a folyamat optimalizálása 6

36 Kanban tábla (példa)

37 Rugalmas tervezés (nincs időigénye) és WIP korlát A munkafolyamat ábrázolásával csökken az egyik feladatról a másikra való áttérés sebessége Ha egy folyamatnak hosszabb időtartamra van szüksége, akadálytalanul végrehajtható (nem kell darabolni), a befejezett feladatok a következő állapotba kerülhetnek A várakozási idő csökken Stressz csökken Szűk keresztmetszetek azonosítása és feloldása Függőség csökkentése a feladatok/részfeladatok között

38 Húzó rendszer Két különböző sebességű csapat közti konfliktus feloldása Ha az egyik csapat végez a tevékenységgel, akkor magára veszi a következőt (vagyis akkor kezdi el amikor már készen áll rá) Nem kap külső utasítást a tevékenység megkezdésére A két csapat közé célszerű egy korlátozott kapacitású puffert tenni, melynek hasznai: A munka felhalmozódása elkerülhető Erőforrás kiegyenlítődés Várakozási idő csökken A csapatok állandó tempót tarthatnak (előtérben a minőség)

39 Ciklusidő minimalizálása Feladatok ciklusidejének mérése a folyamatok optimalizálása céljából (ciklusidők csökkentése) Szűk keresztmetszetek azonosítása Hogyan vehetjük észre a Kanban táblában? Az n. oszlop kártyákkal telített, míg az n+1. oszlop üres

40 Folyamatos szállítás (continous delivery) Rendszeres időközönként folyamatosan szállítunk Folyamatos kapcsolattartás a felhasználóval: Felhasználó céljainak megértését segíti Amire nincs igény, azzal nem foglalkozunk Visszajelzéseket kapunk a szállított termékről Követelmények: A fejlesztők nem lesznek túlterheltek különböző igényekkel A fejlesztők a szállításra koncentrálnak Nincs részben befejezett tevékenység A hangsúly a munka befejezésén van, nem a megkezdésén A munkafolyamat optimalizálása (inkrementális fejlesztés segítése)

41 A metrikák megjelenítése, követése Metrikák: WIP (work in progress) Idők Ciklusidő (cycle time) Átfutási idő (lead time) Bármilyen diagramban Jellemző a cumulative flow diagram

42 Középpontban a hatékonyság Középpontban az ügyfél igényei állnak Értékteremtés az ügyfél számára Hatékonyság elérése: Kommunikáció az ügyféllel, az igények reálissá tétele Megfelelő WIP beállítása a feladatokhoz Húzó rendszer: minden feladatot befejeznek Átfutási idő optimalizálása: gyorsul a szállítás Metrikák nyomon követése: szűk keresztmetszetek feltárása, azonnali beavatkozás

43 Érték áramlás Minden olyan tevékenység, amelyet a projekt elejétől a végéig elvégeznek értékadás szempontjából: A tevékenység értéket ad a projekthez A tevékenység nem ad értéket a projekthez, de kikerülhetetlen az elvégzése A tevékenység nem ad értéket a projekthez, viszont kikerülhető az elvégzése (hulladék) Hulladékok a SW fejlesztésben: Kódfejlesztési hulladék Projektmenedzsment hulladék Csapatmunkából származó hulladék

44 Hulladékok a kódfejlesztésben Részben befejezett munka: Elavulhat Használhatatlanná válhat Megoldás: Iteratív fejlesztés Modularizálás Hibák a kódban: A tesztelés és a javítás időigényes Megoldás: Iteráción belüli tesztelés Folyamatos kapcsolat az ügyféllel (visszajelzések fogadása/feldolgozása)

45 Hulladékok a projektmenedzsmentben Extra folyamatok: Pl. szükségtelen dokumentáció (idő és erőforrás igényes) Megoldás: Tevékenységek értékelése relevancia szempontjából Dokumentáció felülvizsgálata Extra funkciók: Azok a funkciók, melyekre az ügyfélnek nincs szüksége Megoldás: Folyamatos kommunikáció az ügyféllel (követelmények letisztítása) Feladat átadás: a munka átadása egy személytől/csapattól egy másiknak (a befejezést követően) Tudáshiány keletkezik Megoldás: Folyamatok grafikus megjelenítése (tisztává tétele)

46 Hulladékok a csapatmunkában Váltogatás a feladatok között: több feladat egyszerre történő megoldása (multitasking) Megoldások: Csak egy tevékenységgel foglalkozzunk A nagyobb tevékenységeket bontsuk fel kisebbekre Folyamat átláthatóságának javítása Tevékenységek közti függőségek csökkentése Metrikák használata (szűk keresztmetszetek megszűntetése) Várakozások: az információk beszerzésére irányulnak Megoldások: Hozzuk meg a döntéseket, ne várjunk az utasításra Az információforrásokat csak szükség esetén használjuk fel

47 Kanban összefoglalás Alkalmazás: bejelentett hibajegyek gyors kezelése PROCESS célja: minél hamarabb DONE WIP CUMULATIVE FLOW DIAGRAM BOTTLENECK Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében

48 Scrum vs. Kanban Összehasonlítás

49 Szerepkörök Scrum Kanban Product Owner (PO) Scrum Master (SM) Team Nincsenek Mindkettő kiegészíthető további szerepkörökkel, ha a fejlesztés ezt igényli! De győződjünk meg arról, hogy az általunk kialakított szerepkör hozzáadott értéket képvisel, és nem ütközik a módszer más szerepköreivel!

50 Munkafolyamat napi megbeszélés Scrum Daily stand-up: a Scrum-csapat minden nap rövid megbeszélést tart ugyanabban az időben, ugyanazon a helyen Aznapra tervezett feladatok Akadályok Stb. Egyénközpontúság Kanban Nem szabályozott Ha megtartják Szűk keresztmetszetek Stb. Tábla központú

51 Munkafolyamat lefutási grafikon Scrum Burn-down chart Célja, hogy a csapat világosan lássa az ütemtervhez képesti aktuális helyzetet a sprint folyamán Elmaradás esetén gyors beavatkozás Kanban Nem szabályozott Bármilyen grafikon formát alkalmazhatnak a munkafolyamatok követésére Példa: cumulative flow diagram

52 Munkafolyamat lefutási grafikon Scrum: burn-down chart Kanban: cumulative flow diagram

53 Iterációk Scrum Kanban Iterációk Eml.: életciklus modellek Időkeret: 1-4 hét (ütem!) Szakaszai: Tervezés Megvalósítás Kibocsátás (verzió) Folyamatfejlesztés (retrospective) Nem ír elő iterációkat Nincs időkeret A szakaszok (tervezés, folyamatfejlesztés, kibocsátás) időpontja tetszőlegesen választható Rendszeres tevékenységek (pl. naponta) Pl. Szükség esetén végezzük el (pl. új release kiadása egy új funkció sikeres integrációjakor)

54 Iterációk (példák) 1. hét 2. hét 3. hét 4. hét 5. hét 6. hét 7. hét 8. hét Egy ütem (scrum sprint) SPRINT 1 SPRINT 2 Három ütem Igényvezérelt (tervezés és kiadás igény esetén) Tervezés Demó verzió Verzió kiadás Visszatekintés

55 Iterációkon belüli változtatás lehetősége (új igények) Scrum Scrum csapat: Nem tudjuk ezt az új tevékenységet vállalni ebben sprintben. Javasoljuk, hogy beszéljen a PO-val. PO rögzíti az igényt a PB-be A következő tervezéskor a PO és a csapat újradefiniálják a prioritásokat és eldöntik a következő sprint során elvégzendő tevékenységeket (az új igény vagy köztük lesz vagy nem) Válaszidő: sprint hossza Kanban Kanban csapat: Elhelyezzük feladatot a Teendők között, de a WIP korlátaink miatt nem tudunk azonnal foglalkozni vele, amint lesz szabad kapacitásunk, megkezdjük az új igény megvalósítását. Válaszidő: szabad kapacitás keletkezésének ideje

56 Inkrementális szemlélet A Scrum és A Kanban is inkrementális szemléletű Emlékeztető: életciklus modellek Egy Scrum-csapat csak olyan elemeket vállal el, amelyek egy sprinten belül teljesíthetőek Ha egy elem túl nagy ahhoz, hogy beférjen a sprintbe, a csapat és a PO együttesen próbálja kisebb részekre bontani Nincs szabály arra nézve, hogy az elemeknek bele kellene férniük valamely időkorlátba Cél az átfutási idő minimalizálása, ezért a folyamatokat szintekre (kisméretű részekre) bontják

57 Inkrementális szemlélet (példák)

58 WIP korlátozása I. Scrum Kanban Időegységre korlátozott (iterációk) Sprint backlog SCRUM - Sprint backlog (egyszerűsített) Tevékenység Folyamatban Elkészült Tevékenységekre korlátozott (munkafolyamat-lépések) Kanban-tábla Kanban-tábla (egyszerűsített) Tevékenység Folyamatban Elkészült 3 O O P P Q Q R R

59 WIP korlátozása II. Scrum Indirekt korlát: a csapat a sprint elején eldönti, hogy milyen tevékenységek kerüljenek fel az adott sprint backlogra Csapat sebességét mérik, ebből következtetni tudnak a korlátokra Kanban Direkt korlát: a csapat a Kanban-tábla tevékenységeihez egy-egy számot (korlátot) rendel Minden tevékenységhez számot kell rendelni A munkafolyamatokon való áthaladás ideje mérhető (teljesítési határidők becslése) Nem célszerű túl sok tevékenységet egyszerre folyamatban tartani! Célszerű nagyjából azonos méretű tevékenységeket definiálni!

60 Táblák alaphelyzetben állítása, újraindítása Scrum Sprint végén a sprint backlog alaphelyzetbe kerül Kanban A Kanban táblát sohasem kell alaphelyzetbe állítani (folyamatosság) SCRUM - Sprint backlog (1. nap) SCRUM - Sprint backlog (sprint közben) SCRUM - Sprint backlog (utolsó nap) Tevékenység Folyamatban Elkészült Tevékenység Folyamatban Elkészült Tevékenység Folyamatban Elkészült O O O P P P Q Q Q R R R

61 Táblák kezelése I. Scrum Sprint backlog: egy csapathoz tartozik, csak a csapattagok változtathatják meg Keresztfunkcionális csapat: a sprintben megvalósítandó tevékenységek megvalósításához szükséges minden szaktudással és képességgel rendelkezik Kanban Kanban tábla: egy tevékenységhez tartozik Szabályok szükségesek arra nézve, hogy kik és hogyan használhatják a táblát Opcionálisan keresztfunkcionális csapat is kezelheti

62 Táblák kezelése II. Scrum Kanban SCRUM - Sprint backlog (egyszerűsített) Tevékenység Folyamatban Elkészült Kanban-tábla (egyszerűsített) 3 Tevékenység Folyamatban Elkészült O P Q R O P Q R

63 Feladatlista és priorizálás Scrum Kanban Product backlog elemeinek sorba rendezése Hatását a következő sprintre fejti ki Nem definiált: tetszőleges priorizációs mechanizmust alakíthatunk ki (ha akarunk) Döntési szabályokat kell definiálni, hogy világos legyen a következő feladat, pl.: Mindig a legfelső elemet kell választani Mindig a legrégebbi elemet kell választani A csapat kapacitását egyenlő arányban kell elosztani a termékek között (lásd később) Stb.

64 Empirikusság I. A Scrum és a Kanban is empirikus módszerek: kísérletezésen keresztül a felhasználónak kell saját körülményeinek megfelelően hangolni őket Milyen típusú szabályozókkal konfigurálhatjuk a folyamatainkat? Direkt szabályzók Tervezhetőség Megvalósítási sebesség Átfutási idő Minőség Stb. Indirekt szabályzók Fejlesztők száma Sok kis csapat/kevés nagy csapat Alacsony WIP korlát/ Magas WIP korlát Rövid iterációk/hosszú iterációk Stb.

65 Empirikusság I. (példák) Scrum Kik legyenek a csapatban? Mennyi tevékenységet emeljen be a csapat egy sprintbe? Kanban Mekkorára állításuk be a WIP korlátot? A Kanban kevesebb szabályt ír elő, ezért több paraméter szabályozásáról kell gondoskodni!

66 Empirikusság II. Mind a Scrum mind a Kanban esetében a folyamat: Változtassunk valamely paraméteren (cél: hatékonyság növelése) Vizsgáljuk meg a változtatás eredményét Vonjuk le a tanulságokat és annak megfelelően újra 1. lépés Ciklikus visszacsatolás: Hosszú visszacsatolási ciklus: a folyamatfejlesztés üteme lassú Túl rövid visszacsatolási ciklus: a folyamataink nem tudnak stabilizálódni a változtatások között

67 Empirikusság (példák) Rövid visszacsatolási ciklus gyors folyamatfejlesztés Scrum példa: páros programozás Visszacsatolási idő: akár néhány másodperc is lehet Ennek a for ciklusnak nem 0-tól kellene futnia? Jól fejlesztjük a terméket? (emlékeztető: verifikáció) Kanban példa: szűk keresztmetszetek a Kanban-táblában Az n. oszlop adatokkal telített, míg az n+1. oszlop üres (példa!) Hosszú visszacsatolási ciklus lassú folyamatfejlesztés Scrum példa: Sprint Visszacsatolási idő: néhány hét Ennek a számlálónak a maximális értéke nem 100 kell legyen? Jó terméket fejlesztünk? (emlékeztető: validáció) Kanban példa: átfutási idő Minden alkalommal frissítendő, amint egy tevékenység elkészül Ha nem vagy ritkán frissítik elvész a megfelelő visszacsatolás lehetősége

68 Becslés és tervezés Scrum Feladatok egymáshoz viszonyított mérete A sprintek végén az elvégzett feladatok méretét összeadva adódik a csapat sebessége (v: velocity) A sebesség alapján készíthetőek el a release-tervek Kanban A tervezés nem előírás Ha vállalásokat (pl. határidőket) kell teljesíteni, az előre jelezhetőséget ki kell dolgozni Scrum-hoz hasonlóan becslés Azonos méretű feladatokra bontás A funkciók MMF-ekbe (minimum marketable feature, minimális hasznos funkció) csoportosítása és az MMF átlagos átfutási idejének mérése Stb.

69 Becslés és tervezés (példa)

70 Termékek párhuzamos fejlesztése Scrum és Kanban esetén is alkalmazható Hány csapatunk van? Egy csapat: A csapat egy sprintben egy termékre koncentrál A csapat egy sprintben több termékre koncentrál Több csapat: Egy csapat egy sprintben egy termékre koncentrál Egy csapat egy sprintben több termékre koncentrál Termékek megkülönböztetése a táblákon Pl. különböző színű kártyák használata Pl. Vízszintes sávok alkalmazása

71 Termékek párhuzamos fejlesztése SCRUM Product backlog SCRUM Sprint backlog (sprint közben) SCRUM Sprint backlog (sprint közben) A A Tevékenység Folyamatban Elkészült Tevékenység Folyamatban Elkészült B C B A A 1. termék B A D C A B B 2. termék B A B A 3. termék A

72 Lean szemlélet Scrum és Kanban is Lean szemléletű JIT (Just In Time) szemlélet Húzórendszer: amint a csapat végez egy feladattal újat húz ki vagyis nem kívülről tolják a csapatra a feladatot Lean Kaizen folyamatos javítás elve Stb. A Scrum kevésbé Lean a tevékenységek időkeretek közé szorítása miatt Folyamatosan rövidebb és rövidebb iterációkat bevezetésével közelítjük a Kanban elvet Egy hét alatt érdemes elgondolkodni az időkeret megszűntetésén

73 Kanban vs. Scrum hasonlóságok összefoglalás Agilis módszertan technikái Húzórendszeren alapulnak Korlátozzák a végrehajtás alatt lévő feladatok számát (de különböző módon) Folyamatos folyamatfejlesztés Korai és gyakori szoftverkibocsátásra koncentrálnak Önszerveződő csapatok Feladatok részfeladatokra bontása Termékek párhuzamos fejlesztését kezelik Empirikusság (folyamatos kísérletezés és hangolás) Lean szemlélet alkalmazása

74 Kanban vs. Scrum különbségek összefoglalás Scrum Kanban Időkeret közé szorított iterációk Csapat elköteleződése Sebesség Keresztfunkcionális csapatok Feladatok megfelelő méretre bontása Lefutási diagram használata kötelező Indirekt WIP korlát Kötelező becslés Folyamatban lévő sprinthez új tevékenység nem adható Sprint backlog egy csapat kezelése alatt Priorizált product backlog Időkeret használata opcionális Csapat elköteleződése opcionális Átfutási idő Jellemzően specializált csapatok Feladatméret nem korlátozott Bármely diagram használható Direkt WIP korlát Opcionális becslés Bármikor felvehető új tevékenység, ha lesz rendelkezésre álló kapacitás, akkor végrehajtják Kanban tábla megosztható Priorizálás opcionális

75 Összefoglalás Agilis fejlesztés Scrum Kanban Scrum és Kanban összehasonlítása

76 Köszönöm a figyelmet!