PTI BSc Rendszertervezs 15 Gyakorlat Dr Pauler Gbor
PTI BSc Rendszertervezés 15. Gyakorlat Dr. Pauler Gábor, egyetemi docens PTE-TTK BRITT, 7624 Pécs, Ifjúság u. 6. F 104 Mobil: 30/9015 -488, Skype: gjpauler E-mail: pauler@t-online. hu Facebook: PTE-TTK PTI Rendszertervezés https: //www. facebook. com/groups/2405209163039365/ ftp: //gamma. ttk. pte. hu/pub/pauler/PTIRendszer. Tervezes/
Az gyakorlat tartalma Scrum dokumentációk Product Backlog Sprint Backlog Shared. Risk tábla Potentially Shippable Increment Teljesítmény Diagrammok A sikeres Scrum-ot nehezítő tényezők A Scrum továbbfejlesztett változatai: Scrumban Scrum of Scrum Le. SS 15 -1 Házi Feladat
Scrum dokumentációk: Product Backlog 1 DEF: Product Backlog (PB) A terméken elvégzendő feladatokat leíró Product Backlog Itemek (PBI) fontossági sorrendbe rendezett halmaza egy Sprinthez. A tételek a következők lehetnek: DEF: User Story - üzleti folyamat BPD-n DEF: User Case – üzleti folyamat adott elágazása DEF: Function/Feature – támogatott üzleti folyamat lépés DEF: Remove function – eltávolítandó funkció DEF: Bug fix – folyamatlépés működés problémájának megoldás DEF: Knowledge aquisition – szakmai kutatás egy jövendőbeni probléma megoldási módszereiről DEF: Technical work – hardware/oprendszer háttéren végzett művelet DEF: Non-functional requirement – díszitmények, hab a tortán A PBI-k egymástól függése nyilván van tartva benne (így valójában adatbázisilag nem sima lista, hanem hálózat!!!) A PB tartalmába minden szereplő betekinthet, de csak a következők írhatnak bele: Product. Owner DEF: Relative Business Value Story Pointokat rendel PBI-khez: DEF: Kerekített Fibonacci skálán (pl. 1, 2, 3, 5, 8, 13, 21, következő szám az előző kettő összege) – ezzel pszichológiailag jobban lehet fontos és kevésbé fontos dolgokat elkülöníteni mint pl. lineáris, százalékos súlyokkal. Dev. Team végzi a PBI-k komplexitásának felmérését: ALT: DEF: Relative Complexity Story Pointokat rendel kerekített Fibonacci skálán titkos szavazással PBI-khez (DE: Ehhez demokratikus szavazásitársadalmi kultúra kell: nekünk mindig megmondják előre kire kell szavazni, így nem megy!) ALT: Felméri a fejlesztési munkaóra szükségletüket (DE: sokkal nagyobb tapasztalatot igényel, néha lehetetlen)
Scrum dokumentációk: Product Backlog 2 Product. Owner prioritási listát állít fel PBI-k közt a következő célfüggvény alapján: Rel. Bus. Val. Stor. Pts / Rel. Compl. Stor. Pts = Return. On. Investment → Max (15. 1) Product. Owner + Dev. Team: DEF: Definition Of Done (Do. D) teljesítési követelményeket fogalmaz meg minden PBI-vel kapcsolatban: hogy kell működnie ha átadják Product. Owner + Dev. Team eldönti mely PBI-k férnek bele adott Sprint össz kapacitásába, ezek a lista tetejére emelődnek a DEF: Sprint Backlog (SB)-ba Sprint Backlog tételeket jobban kifejtik a finomítás során, az alacsony prioritásúakat nem DEF: Melléktermék effektus: lehetséges, hogy sprint teljesítése során Sprint Backlogban nem szereplő PBI-ket is teljesíteni tud a csapat, mert az alkatrészeik más okokból előállnak, főleg ha újrafelhasználhatóan írják a kódot.
Scrum dokumentációk: Sprint Backlog DEF: Sprint. Backlog(SB) + Task. Board(TB): Olyan Üzleti folyamat-/Gantt-diagramm, Melynek soraiban a rangsorolt Sprint PBI-k vannak (a tetején a legfontosabb), egy vonal alatt lehetnek olyan fontosabb PBI-k, amik nem részei a sprintnek de melléktermékként meg lehetne csinálni Oszlopaiban a PBI|Taskok: Elemzés, Fejlesztés folyamatban, Tesztelés, Sprint határidőre átadás Celláiban tevékenységdobozok, melyik PBI melyik taskja mely Dev. Team tagra van kiosztva (dobozszín kódolja), a dobozba beleírva, a taskból mit csinál ma Dobozok közt lehetnek nyilak amelyek előfeltételi-követési viszonyokat ábrázolják Alapban a Dev. Team tagok maguk vállalnak el Taskokat, az alapján, mi rokonszenvesebb számukra De Scrum. Master átütemezheti a feladatkiosztást, ha valamely fejlesztő túl/alulterhelt (DE: Igaz-e hogy mindenkihez ért és felcserélhető a tudásuk? – általában nem)
Scrum dokumentációk: Shared. Risk tábla DEF: Shared. Risk (SR) tábla: Ez az SB tábla csak olyan részét ábrázolja, ahol 1 beakadt előfeltétel PBI|Task fog több követő PBI|Taskot akár láncolatban Ilyenkor a Scrum. Master az egész láncolathoz rendelhet plusz erőforrást, de mindenképp kijelöl egy felelős fejlesztőt az egész láncolatért, hogy az egyes lépések felelősei ne tudják egymásra tologatni a dolgokat DEF: Potentially Shippable Increment (PSI) A Sprint keretein belül kifejlesztett szoftverrész, ami működőképes, kapcsolódik az előző Sprintek eredményeihez és önállóan telepíthető (DE: tervezési fázisban nem lesz ilyen! Scrum arra ösztönöz, hogy gyorsan összetaknyolják a tervezést-elemzést) Megfelel a Definition of Done (Do. D) teljesítési követelményeknek (DE: Scrum nem foglalkozik vele, hogy milyen szabványosított formában kell leírni ezeket a követelményeket, a legtöbbször sima full text, ami tele lehet félreérthető megfogalmazásokkal)
Scrum dokumentációk: Potentially Shippable Increment Átmegy a tesztelésen (DE: Scrum összemossa: DEF: Sandbox teszt, fejlesztőrendszerben adatok nélkül: DEF: User Acceptance Test (UAT): Próbarendszer kisméretű adatokkal, végfelhasználó tesztel DEF: Regressziós teszten (Reg. Test): Nem éles rendszerben, történelmi valós méretű adatokon, valós felhasználó tesztel nem kezeli túl jól a köztük lévő Incidenteket és hibajavításokat) A Product. Owner autonóm döntése, hogy elkészültekor DEF: Release-re kerül: a Business Stakeholderek számára elérhetővé válik az éles termelő rendszerben. Lehet, hogy nem megy élesbe, mert pl. nincs elég munkaerő UAT/regtesztelni, nem állhat meg a termelés a sok megrendelés miatt, hogy átálljanak az új rendszerre, stb. (DE: Ha előfeltétele lenne másnak, és nem rilizálja, akkor széttúrja vele a következő Sprintek tervezését)
Scrum dokumentációk: Teljesítmény Diagrammok DEF: Sprint Burn Down Chart (SBDC): Axis. X: Aktuális Sprint napjai × Axis. Y: munkaórák vagy complexity story point Tényleges hátralévő mennyiség Tervezett hátralévő mennyiség – lineáris trendvonal (DE: struktúrált programozás nemlineáris menetű, elején lassú végére exponenciálisan begyorsul, ha jól csinálják) Hátralévő task szám Napi teljesített task szám DEF: Release Burn Up Chart (RBUC): Axis. X: Sprint number × Axis. Y: Business Value Story Point Sprintenkénti kumulált teljesített Rel. Bus. Val. Stor. Pts Ennek 3 jövőbeli extrapolációja (lineáris, optimista, pesszimista) (DE: nem veszi figyelembe struktúrált programozás nemlináris munkameneti jellegét) Mean Value Points (MVP): A Release Scope Sprintenkénti újraértékelése mentén mennyi lesz a Release teljes üzleti értéke Average Velocity (AV): a Dev. Team sprintenkénti átlagos haladási sebessége Rel. Bus. Val. Stor. Pts-ban, a jövőbeli terhelhetőségéhez nyújt becslést.
Az gyakorlat tartalma Scrum dokumentációk Product Backlog Sprint Backlog Shared. Risk tábla Potentially Shippable Increment Teljesítmény Diagrammok A sikeres Scrum-ot nehezítő tényezők A Scrum továbbfejlesztett változatai: Scrumban Scrum of Scrum Le. SS 15 -1 Házi Feladat
A sikeres Scrum-ot nehezítő tényezők 1 Fejlesztők földrajzi/részmunkaidős széttagoltsága Bár videokonferencia/csoportmunka technológia sokat fejlődött Minden videokonferencia eszközben sokkal jobban lehet bújkálni a személyes találkozóhoz képest (ez ott felhasználói igény is) Nincs meg a személyes ráhatás tagok közt Fejlesztők egyenlőtlen képzettsége és természetes specializálódási hajlama Ellene hat a Scrum. Master általi rugalmas átdobásuknak PBI|Taskok közt Kereszt-tréningekkel lehet ellene tenni, de ez drága, a tréning 2 vagy több tagot von ki a Dev. Team-ból. Tapasztalatlan Dev. Team tagok kapásból kb. 8 -szorosan alábecsülik a a User Storyk komplexitását ha a Product Ownerrel alkudoznak, tarthatatlan határidők jönnek ki Egy tapasztalt Scrum. Master előre láthatja komplexitás 50%-át, viszont a kkor döntő szava kell legyen a tapasztalatlan Dev. Team tagok felett, de ez rombolja a demokratizmust. Komplex termék, PBI-k közti magas számú előfeltételi függések, hosszas Sandbox/UAT/Regtest igény emberi élet-kritikus termékeknél Nagyon nehézzé teszi a release rövid, átadható végtermékű sprintekbe tagolását és ezek tervezését, ilyenkor jobb a vízesés modell
A sikeres Scrum-ot nehezítő tényezők 2 Scrum nem támogatja a teljes termékéletciklust A szerződéskötési/rendszer elemzési/tervezési fázisok és a A tesztelés, kiszállítás, felhasználó beoktatás, folyamatos karbantartás alulreprezentáltak benne
A Scrum továbbfejlesztett változatai A Scrum hibáit megpróbálták más módszerekkel kombinálva enyhíteni: DEF: Scrum. Ban: Alapból a Scrum a fix határidős Sprintjeivel nem alkalmas szoftver karbantartási/helpdesk tevékenységek támogatására, ahol az Incidensek váratlanul, ütemezetlenül bukkannak fel DEF: Kanban: Toyota eredetű munkaszervezési módszer a következő elvekkel: A teljes folyamatot bontsd fel kis Release|PBI|Task lépésekre Minden Dev. Team tag legyen informálva a saját és az előzmény/követő Taskok követelményeiről (Sprint. Task. Boardon, és láthatja a PBI-k Do. D-ját) Így a tag jó eséllyel rájön, ha a teljesítés nem megfelelő, és joga van minden tagnak megállítani a fejlesztési folyamatot Tagot a fejlesztési hiba észrevételéért jutalmazzák, így elkerülhető, hogy hibás előfeltételekre épüljön rá és váljon használhatatlanná drága fejlesztői munka A folyamat nem fix időbeli ütemezés szerint zajlik, hanem az Incidens/Fejlesztési/Javítási igény felbukkanása indítja el az előfeltételi Taskokat Időben visszafele ütemez: a hiba kijavítási határidejéből vonogatja a le az előfeltételi Task lánc munkaidő igényeit, hogy kiszámítsa, az egyes Taskokat mikor kell elkezdeni Úgy integrálták Kanbant Scrum-mal, hogy a Task. Board minden időben hátraütemezett Taskot egyszerre mutat, függetlenül, hogy melyik javítási Sprinthez tartozik, és Scrum. Master ebben osztja el fejlesztők közt a terhelést. Ezt viszont már nemigen lehet papíron hatékonyan megtenni, ezért támogató szoftverek jelennek meg: Assembla, JIRA, Agilo Keresztképzett, mindenhova átdobható Dev. Team helyett specializált Dev. Team-ot használ, gyorsabb hibajavítás érdekében.
A Scrum továbbfejlesztett változatai: Scrum of Scrum DEF: Scrum of Scrum Több Scrum Dev. Team munkájának összehangolása ugyanazon Releasen, hogy nagyobb rendszerek is fejleszthetők legyenek Scrum-mal megfelelő határidőre és minőségben Szerepek: DEF: Scrum ambassador: Kijelölt Dev. Team tag vagy a Scrum. Master Tevékenységek: DEF: Daily Scrum. Of. Scrum Meeting A Scrum Ambassadorok 15 perces napi fix idejű, fix helyszínes álló meetingje: Témája: RIDA modell: R Risk – jövőbeli kockázat, amit vagy elfogadunk (Accept) vagy ellenlépéssel elkerülünk (Mitigate) I Impedience – jelenbeli fejlesztési akadály D Dependency – egyik Scrum Sprint előfeltétele a másiknak A Assumption – Olyan közös alapfeltevés, amin több Scrum Sprint alapul Résztvevők felkészülési/jelentési kötelezettsége: ROAM modell: R Resolve: Milyen RIDA-t oldott fel tegnap? O Own: Saját Sprintemben milyen új RIDA jelentkezett A Accept: Jövőbeli RIDA-t jelent be más csapat Sprint-je számára, az elfogadja-e? M Mitigate: Milyen RIDA-t tervez ma feloldani? Dokumentumok: DEF: Risk. Board: Soraiban: egy release RIDA-inak fontosság szerinti listája Oszlopaiban: a lehetséges taskok ROAM modell szerint Celláiban: melyik Scrum Ambassador a felelős érte (színkóddal), hol tart éppen a task végrehajtásban
A Scrum továbbfejlesztett változatai: Le. SS DEF: Large Scale Scrum (Le. SS) Több 8 csapatos Scrum. Of. Scrum egységet fog össze egy nagyon nagy fejlesztésben (pl. telekom, bankrendszer) Főleg menedzsment dolgokkal foglalkozik, hogyan tartaható a Scrum. Of. Scrum-okat irányító szervezet laposan, kevés számú hierarchikus szinttel.
15 -1 Házi feladat Az utolsó csoportbeadandó létrehozását (csoportprojekt egy kiválasztott munkaképernyőjére prototípus létrehozása) Scrumként kellene megvalósítani, a megalkotott scrum dokumentumokat benyújtani hozzá (8 p)
- Slides: 15