Projekt menedzsment
Issue megismerése¶
Cél az átvett projekt megismerése, és a kiválasztott issue elhelyezése a projekten belül. Ez a feladat két fő részre bontható. Azon kódrészletek, komponensek azonosítására melyek kapcsolódnak a kiválasztott issue-hoz. Valamint a kapcsolódó issue-k feltérképezésére.
Kapcsolódó komponensek megismerése¶
A feladat részeként keressük meg azokat a kódrészleteket, melyeket előreláthatólag módosítani kell majd a feladat végrehajtása során. Ezután vegyük sorra azokat az elemeket, melyek felhasználják a módosított elemeket.
Ezen komponensek szerkezetét (UML package, osztály vagy egyéb szerkezeti diagram, pl. E/K) és fő funkcióit (UseCase, szekvencia diagram, funkcióleírások screenshotokkal) ábrázolhatjuk.
Mennyi diagramra van szükség?
Mennyi italt kell meginni a JATE-klubban hogy jól érezd magad? A válasz hasonló az issue-k esetében is. Sok mindentől függ. Ki és mit iszik? Mennyire fáradt? Mit evett előtte? Stb. Általánosságban elmondható, hogy a következő lépéseket célszerű követni.
Hol van? Egy vagy több áttekintő ábrán bemutatni a projekt fő elemeit és ezek kapcsolatát, kijelölve (és a hozzá kapcsolódó leírásban kiemelve) a megoldandó issue helyét a rendszerben. Erre a komponens- és a deployment-diagram az egyik eszköz.
Mire lesz jó? Ha az issue új funkciót valósít meg, akkor röviden ismertetve a lehetséges felhasználási eseteket (pl. egy használati-eset diagramon keresztül).
Hogyan működik? Be kell mutatni a folyamatokat, melyeket végrehajt a kapcsolódó rész. Ezt szekvencia-, állapot-diagram vagy folyamatábra felhasználásával szokták megoldani.
Hogyan lesz megvalósítva? A technikai részleteket és módosítandó kód közvetlen környezetét osztály-, csomag-, vagy komponens-diagramal ábrázolják.
Lapos a buli? - Ne legyünk részegek.
Az előző JATE-s példát tovább gondolva, fontos (és bizony kihívás is) hogy ne becsüljük alá vagy túl a szükséges információt. A cél, hogy egy másik fejlesztő az általunk adott adatok alapján megtudja válaszolni a fenti kérdéseket.
Egy jó teszt lehet, hogy mennyi magyarázat kell a közölt adatokhoz. Ha túl sok mindent kell még elmondani akkor az adatok hiányosak, ezeket a magyarázatokat célszerű leírni. Ha inkább azt kell megmutatni, hogy mit hol talál az illető, akkor lehet, hogy túl sok, vagy nem elég rendszerezett az információ.
Mindenkinek értékelhetőnek kell lennie
Az értékelés miatt összesen legalább annyi diagramot kell átadni ahány fő dolgozik az adott issue-n (javasolt diagram típusok: 1, 2). A feltöltés során mindenki a saját felhasználóját használja, hogy egyértelműen el tudjuk dönteni melyik rész kinek a munkája.
Az issue (és a projekt) megismerése során tapasztalt hiányosságok, nehézségek, esetleg pozitívumok rögzítése szintén fontos lehet a feladat végrehajtása során. A projektek komplexitása tetszőleges lehet, ezt átlagember egyszerűen nem képes átlátni. Szerencsére nincs is szükség emberfeletti memóriára, hiszen az issue-khoz rengetek információ kapcsolható, amely szükség esetén elérhető.
Újra kell telepíteni a gépet
Tegyük fel hogy teljesen összeomlott az operációs rendszer a laptopodon. Szerencsére a munkádat feltöltötted a verziókövető rendszerbe, így az nem veszett el, de a gépet újra kell telepíteni. Vagyis a fejlesztési környezetet újra létre kell hozni és be kell állítani.
Mennyivel egyszerűbb dolgod lenne, ha a különböző környezeti változók értékeinek beállításait megtalálnád az issue alatt kigyűjtve. Nem kell rá emlékezni, hogy mik voltak, sem azt hogy vajon hova írtad fel őket hiszen minden az issue-hoz kapcsolódó tudás elérhető az issue alatt.
Csak akkor tudunk segíteni tudunk a problémáról!
A feladat megoldása során felmerülő komplikációkról azonnal tájékoztatni kell a gyakorlatvezetőt (ha másképp nem rendelkezik akkor e-mail-ben).
Ezt vajon miért írtam fel?
Ha egy issue-hoz másikat kapcsolunk mindig adjuk meg hogy mi a kapcsolat köztük.
Melyik segít többet? #42 vagy előfeltétele: #42
Értékelés¶
Értékelés
A kapcsolódó komponensek megismerése részfeladatra összesen 4 pontot lehet szerezni. Az issue-hoz kapcsolódó információkat az issue alá kell gyűjteni. Az folyamat során azonosított hibákat, fejlesztési javaslatokat és alfeladatokat új issue-ként kell rögzíteni és említéssel belinkelni a fő issue alá.
Kapcsolódó issue-k összegyűjtése és munka összehangolása¶
Keresztbe-módosítás
Képzeljük el hogy egy adott feladatot, pl. az egyik eszköz parancssori kimenetének színezését több különböző könyvtárral is meglehet oldani. Teszt Elek a HiperSzínes csomagot, míg Pró Béla a SzívárványConsole csomagot választja. A fejlesztés egészen addig gond nélkül folyik amíg össze nem ér a két rendszer. Pl.: szeretnénk kiemelni a hibaüzenetek színét egy közös helyre, hogy egységes legyen minden eszközben.
Ilyenkor az egyik megvalósítást át kell írni a másik javára, vagyis vagy Elek vagy Béla fölöslegesen dolgozott. Ez a kellemetlen helyzet és a projekt számára kidobott erőforrás (munkaidő) elkerülhető lett volna, ha Béla és Elek tisztában vannak az issue-k közötti kapcsolatokkal.
A példában bemutatott helyzet elkerülése érdekében az issue-kat (legalább) említésekkel össze szokták kötni. Az issue-k egy gráfot vagy hálózatot alkotnak. Azonban nem szabad elfelejteni, hogy a hálózat mögött emberek (szoftverfejlesztők) és az ő munkájuk közötti kapcsolat húzódik. A nagyobb méretű vagy összetett csapat-hierarchiával rendelkező projektek esetén ritka, hogy egy ember képes legyen átlátni az egyes feladatok közötti kapcsolatokat. Vegyük figyelembe, hogy a feladatokhoz technikai részletek is tartoznak, például, hogy melyik könyvtárcsomagot vagy tervezési mintát használjuk.
Ezek a jelenségek a projektmunka kapcsán is megfigyelhetőek. Bár a CodeMetropolis közepes méretű rendszerek közül a kisebbek közé tartozik, de a több gyakorlaton és szemeszteren átívelő fejlesztés növeli a folyamatok összetettségét. Ezt az alábbi csomag- és objektum-diagram mutatja.
Látható, hogy bizonyos esetben a hallgatók által választott issue-k olyan más issue-khoz kapcsolódnak amit másik gyakorlatra járó hallgató társuk választott. Az is előfordulhatnak olyan issue-k melyek ebben a félévben nem kerülnek megoldásra.
Az issue-k társas lények
Nagyon ritkán fordul elő, hogy egy issue-ban leírt feladat független a többi issue-ban definiálttól. Az issue-k általában összetett hálózatot alkotnak, mely megismerése fontos lépés a feladat elvégzése során.
Fontos felismerni, hogy bár az issue-k listája szétbonthatóak kisebb csoportokra a kapcsolataik mentén, de ezek végül egy közös rendszerhez kapcsolódnak, ami itt a CodeMetropolis projekt. Vagyis szükséges összehangolni az egyes részeken végzett munkát. Ezt a projektszintű összehangolást a gyakorlatvezetők fogják végezni a hallgatók segítségével.
Egységesség
Képzeljük el, hogy vezetőként el kell döntenünk hogy a projektben mennyire készültek el a naplózás funkciók. Ez 3 issue-ban került kiosztásra 3 különböző fejlesztőnek. Kakszi Lajos szereti az angol (amerikai) szakkifejezéseket, például naplózás helyett loggol-ást használ. A szleng és a poénok megszállottja Turbók Imre szenior fejlesztő, soha nem hagy ki egyetlen szóviccet se, még akkor se ha csak ő érti. Végül Király Sándor, egy junior fejlesztő, nem igazán ismeri a szakkifejezéseket, ezért gyakran rosszul használja, például keveri a kimenet és a naplófájl fogalmát.
Vezetőként mennyilyen érzés lenne egymás után olvasni a 3 issue alá írt megjegyzéseiket? Mennyi időt venne el az egyes stílusok közötti váltás? Mire fordítnád az egységes stílus bevezetése után felszabaduló időd?
Az egyes funkciócsoportok egységességének biztosítása érdekében kijelölt vagy vállalt felelősöket szoktak alkalmazni a projekt menete során. A felelősöknek feladata, hogy az elkészült részek dokumentáltsága egységes formátumú és stílusú legyen. Ezt a kisebb módosítások és formázások (tipok, csoportosítás, sablonok, példák) elvégzésével, de legtöbb esetben a többi fejlesztő figyelmeztetésével és tanácsokkal éri el.
A felelős nem uralkodó
Az egyes részek felelőse nem parancsol és nincs mindig igaza. De az ő felelőssége hogy szemelőt tartsa az egységességet és ezzel kapcsolatban kifejezze az irányelveket és tanácsokat.
Lali segít - egy-pontos kapcsolattartó
Az előző példát folytatva, Kakszi Lajos legújabb kedvenc rövidítése a SPOC (single point of contact). Ezért eldöntötte, hogy segít a projekt-menedzsernek. Készített egy sablont az issue-k számára, ami minden fontos információt tartalmaz. Létrehozott egy Wiki oldalt a projektkezelőben, amely az egyes kapcsolódó szakkifejezéseket tartalmazza. Végül ezek alapján (példaként) kijavította saját megjegyzéseit és issue-át.
A többieknek is átküldte az elkészült anyagot. Elmagyarázta Sanyinak, hogy miért fontos a megfelelő szakkifejezések használata. Felhívta Csoki (Imre) figyelmét, hogy sajnos a vicces megjegyzései sokszor félrevezetik a kezdő fejlesztőket, valamint sokkal nehezebb kiszűrni a lényeget.
A menedzser sokkal hamarabb végzett Lali és Sanyi issue-inak átnézésével. Így volt ideje a projektzáró sörözés megszervezésére, ahol sokat beszélgetett mindenkivel. Kiderült, hogy Sanyi szívesen képezné magát. Lalit a következő projekt során több funkciócsoport felügyeletére is felkérték, végül a bértárgyalás során fizetésemelést kapott konstruktív és felelősségteljes hozzáállásáért.
Sajnos Csoki stílusa nem sokat változott. A vezetőség felé egyre több panasz érkezett, hogy hátráltatja a munkát. Ezért a következő értékelés során közös megegyezéssel elhagyta a céget.
A felelős nem dolgozik senki helyett!
Ha a felelős nem kerül kijelölésre, minden érintett pontot veszít. Ha a hallgató figyelmen kívül hagyja a felelős jogos tanácsát, akkor tőle pontot vonunk le, de a felelős nem veszít emiatt pontot.
Egyeztessünk!
A hallgatók megfelelő issue-k választásával befolyásolhatják, hogy kivel kell szorosabban együtt dolgozniuk.
A munkát kritizáld ne az embert!
A negatív véleményeket, javításra vonatkozó tanácsokat általában illik privátban jelezni az érintett felé. Sajnos a vitás esetek elkerülése érdekében a gyakorlatvezetőket muszáj bevonni a felelős és a többi hallgató kommunikációjába. Ez a Coospace-n történik majd. Fokozottan ügyeljünk rá, hogy ne szégyenítsünk meg senkit a többiek előtt és törekedjünk az építő szándékú tanácsokra.
A felelősök számára csak az igazolható munkáért tudunk pontot adni: kommunikáció Coospace-n vagy GitLab-on.
Értékelés¶
Értékelés
A Kapcsolódó issue-k összegyűjtése és munka összehangolása részre a hallgató összesen 8 pontot kaphat. A hallgató feladata, hogy a kapcsolódó issue-kat hivatkozza (említse) a választott issue-ja alatt. Fontos hogy a feladat elvégzésének része az egymás közötti kommunikáció és egyeztetés.
Az összekapcsolódó issue-kat választó hallgatók közösen megegyeznek az adott funkciócsoport egységességéért felelős hallgató személyében. Ezt egy új issue létrehozásával jelzik <funkciócsoport neve> egységesítése, és ellátja integration címkével, melyhez a felelős hozzárendeli magát és megjelöli benne a kapcsolódó issue-kat. Az élőző példa alapján az új issue naplózás egységesítése lenne, amihez Lali rendeli hozzá magát és a három issue kerül benne említésre.
Az egységesítésre tett törekvéseket, munkát és a szervezésben való részvételt be kell mutatni az órán. A bemutató során mindenki egyénileg számol be arról, hogy hogyan járult hozzá az elvégzett feladata integrációjához. Ebbe bele tartozik a többi hallgatóval való kommunikáció is, melynek helye a feladathoz kapcsolódó issue, merge request és projekt a hallgatói GitLab-on.
| részfeladat | maximális pontszám | kinek? |
|---|---|---|
| kapcsolódó issue-k megjelölése | 4 | mindenki |
| felelős választása és megjelölése | 1 | mindenki |
| egységesség segítése | 3 | felelősök |
| egységesség alkalmazása | 3 | nem felelősök |
Mindenki szerezhet 5 pontot + (felelős szerezhet 3 pontot vagy nem felelős szerezhet 3 pontoz) = 8 pont mindenkinek.
A fejlesztési és egyéb folyamatok követése¶
Tudod mit kódoltál tavaly nyáron?
Ha igen, honnan? Miért pont azt a részt írtad meg? Meddig tartott megkeresni a választ?
Ha nem, miért nem? Elfelejtetted?
A szoftver rendszerek az életciklusuk során folyamatosan változnak. Új verziók készülnek el, gyorsabb hardver jelennek meg, új operációs rendszer frissítéseket telepítenek. A technikai jellegű változásokon kívül a felhasználók igényei is folyamatosan alakulnak.
Kihez fordulnál segítségért?
Képzeljük el, hogy frissen becsatlakozol egy hosszú ideje futó fejlesztési projektbe. A munkád során feltérképezed, hogy a feladatot melyik osztályt érinti. Sajnos a módosítás során előjön egy olyan kivétel, amelyet nem tudsz értelmezni.
Kihez fordulnál segítségül?
Biztos hogy mindegyik szenior átlátja a program minden részét?
A vezető fejlesztő mindenre tudja a választ?
A fenti kérdéseket a verziókövetéssel és a projekt menetének folyamatos dokumentálásával érhető el. Egy jól felépített és helyesen használt verziókövető rendszer esetén nem csak az adott osztály, de akár a kérdéses sor szerzőét is pillanatok alatt le lehet kérdezni.
Forráskód verziókövetése¶
Szoftver rendszer régészet
A CodeMetropolis jelenleg szorosan támaszkodik a BlockModifier csomagra. Vajon miért került ez ennyire kiszervezve? Miért nem része a render eszköznek?
Egyáltalán miért fontos ezt tudnunk? A központi projektbe beemeléssel csökken a kezelendő függőségek száma, egyetlen egy fordítási folyamattal elő tudjuk állítani a BlockModifier és a CodeMetropolis legfrissebb változatát.
Bár a rendszer használ verziókövetést, ezt úgy tűnik ebben az időszakban elég hiányosan tette. A vizsgált könyvtár egyetlen egy commit-ban szerepel, abban ami valószínűleg a teljes projektet átemelte egy korábbi verziókezelő rendszerből. Ez 2016-ban volt, gyakorlatilag az első olyan commit amiben tényleges forráskód szerepel.
A fejlesztők nem emlékeznek a pontos okra, hogy miért került ez a csomag külön, így ez örökre feledésbe merül. A tudás hiánya sajnos rizikót is jelent. Vajon ha beemeljük a központi projektbe azzal nem okozunk-e olyan problémát amire már nem emlékszünk?
Nagy bináris fájlok Git-ben
A (nagy) bináris fájlok tárolása nagyon lelassítja a Git működését. Ezért nem szoktunk ilyeneket feltölteni. Minden bináris fájlnak számít amit nem tudsz elolvasni, ha egyszerű Notpad-el megnyitod. Általában semmilyen generált fájlt sem töltünk fel, hiszen ezek előállíthatóak a forráskódból.
Gitben nagy bináris állományok (*.class, *.jar, *.zip, *.rar, ...) tárolása tilos (max. 3 pont levonás jár érte), a .gitignore fájl segíthet ennek követésében.
Értékelés¶
Értékelés
A hallgató a Forráskód verziókövetése részfeladatra összesen 6 pontot szerezhet. A hallgató feladata a forráskódon végzett módosítások folyamatos verziókövetése Git rendszer segítségével.
| részfeladat | maximális pontszám | kinek? |
|---|---|---|
| Git és GitLab használat | 3 | mindenki |
| git flow követése | 3 | mindenki |
A hallgatónak törekednie kell hogy segítse a további módosítások bevezetését. A fejlesztés során használjuk a git-flow branching modelt. Az értékelés során csak azokat az elemeket vesszük figyelembe ami a saját felhasználóval került fel a hallgatói GitLab szerverre.
Fejlesztési folyamatok dokumentálása¶
A fejlesztés során a forráskódon kívül sok más információ is keletkezik. Ezek nyomon-követése és gyűjtése legalább annyira fontos mint a kódbázis maga.
Éjszakázás ellen
Pró Barbara és Teszt Elek hallgatók ugyan azon a funkció csoporton dolgoznak a félév során. Hétfőn mindkettőjüknek elmarad egy órája, így van idejük megbeszélni a következő lépéseket. Barbi nemrég hallott egy új programcsomagról ami szerinte remekül illene a feladathoz. Elek szeretné meg befejezni a választott issue-jához kapcsolódó rész átnézését. Így a csomag kipróbálását Barbi vállalja. A maradék időben a főbb megvalósítandó funkciókról esik szó.
Mindketten hazaindulnak, de Barbi a TIK-ben felejtette a táskáját ezért vissza kell mennie érte. A villamos lerobban félúton. Szóval ez nem az ő napja. Másnap eszébe jut a Kalkulus 2 ZH így egész héten arra készül. Elekkel péntek délután fut össze aki kíváncsian kérdi milyen az új programcsomag.
Barbinak nem érti mire gondol, volt valami a Rendszerfejlesztés 2 projektmunkával kapcsolatban, de kisebb gondja is nagyobb annál, hogy most ezzel foglalkozzon. Sajnos a határidő ettől nem változik, így mindketten egész hétvégén az új csomag megismerésével foglalkoznak, amit végül sikerül működésre bírni. Hétfő hajnalban már egyikőjük se mer módosítani a kódon, nem értik miért működik, ezért félnek hogy elromlik.
A fenti vitás helyzet és a határidőhöz közeli kapkodás részben elkerülhető lett volna a folyamatok megfelelő naplózása segítségével. A megbeszélések után célszerű memo-kat írni, melyből kiderül milyen döntésekben állapodtak meg. Az új feladatokat issue-k formájában szokták rögzíteni. A korábbi feladatokhoz kapcsolódó információkat az issue-k alá megjegyzésben írják, hogy minden egy helyen legyen. A határidőket és az egyes feladatok haladását, felelősét frissíteni kell az issue-k alatt. Ezzel nem csak azt érjük el, hogy mindenki számára egyértelmű lesz a saját felelőssége, hanem hogy ezeket az információkat bármikor a többiek zavarása nélkül is elérheti.
Egy feature - egy branch - egy merge request¶
A hallgatók (a feature méretétől függően) egy általuk választott feature-ön dolgoznak. A hallgatók egy feature-t (vagyis egy issue-t) egy branch-ben fejlesztenek. A branch neve a feature-hoz kapcsolódó issue számát tartalmazza. A branch neve a következő formátumot követi: <issue szám>-<rövid leírás>. Ezt a branchet és a hozzá kapcsolódó merge request-et a hallgatóknak kell létrehoznia.
A branch neve a feature megvalósításának kezdetén jön létre és a munka elvégzése után merge-elésre kerül a hallgatók által a develop branch-be.
Csak az a munka értékes aminek eredményét eléred
Az egy feature-ön dolgozó hallgatók munkájának (commit-jainak) a fent létrehozott branch-re (és így a merge request-be) kell kerülni. Csak azt a munkát pontozzuk, mely elérhető a merge request-ből.
Hogyan látszik az a munka, amit nem a kódon végeztünk?
A szoftverfejlesztés során több olyan feladatot is el kell látni, mely nem kapcsolódik a kódoláshoz. Ilyen például a többi fejlesztővel való megbeszélések. Ezeknek nem commit-ként látszanak, így ezeket a hallgatók memo-k formájában kell rögzíteniük. A memo-kat a merge request-hez kell csatolniuk.
Értékelés¶
Értékelés
A hallgató a Fejlesztési folyamatok dokumentálása részfeladatra összesen 7 pontot szerezhet. A félév során a következő fejlesztési elemek dokumentált használatát pontozzuk.
| részfeladat | maximális pontszám | kinek? |
|---|---|---|
| issuek karbantartása | 3 | mindenki |
| heti megbeszélés memo (példa) | 2 | felelősök |
| aktív részvétel heti megbeszélésen | 2 | nem felelősök |
| összefoglalás egységesítése | 2 | felelősök |
| összefoglalás kapcsolódó részeinek kitöltése | 2 | nem felelősök |
Levelező tagozaton az issuek karbantartására 2, az összefoglalásra 3 pont szerezhető.
Mindenki szerezhet 3 pontot + ((felelős szerezhet 2 + 2 pontot) vagy (nem felelős szerezhet 2 + 2 pontoz)) = 7 pont mindenkinek.
Az agilis módszertanokhoz hasonlóan kövessük nyomon a feladatok végrehajtását. Mindenkinek legyenek saját issuejai (válalt feladatok és részfeladatai). Ezek állapotát a hallgatói GitLab szerveren a saját gyakorlathoz tartozó issue board-on kell frissíteni folyamatosan a félév során.
A projekt lezárásaként egy összegzést kell készíteni. Az összegzést a feature-höz tartozó merge request-ben kell elhelyezni és MarkDown formátumban kell elkészülnie.
A következőknek mindenképpen szerepelnie kell a riportban:
- Felhasznált témák és technológiák bemutatása
- Leadandók eredményei, linkjei
- Leadandókról született dokumentációk linkjei
- Összefoglalás és konklúzió
Az összefoglalónak bizonyítania kell, hogy a hallgató elsajátította a módszereket és technológiákat, ami egy projekt karbantartásához kell. Ahhoz, hogy ezt bizonyítsa átfogóan de lényegre törően kell bemutatni az alkalmazott technikákat a beadandó projekten. Ehhez hozzá tartozik a probléma lépésről lépésre történő megoldásának leírása az alkalmazott eszközök és azoknak használatával kibővítve.
Értékelés összefoglalása¶
| részfeladat | maximális pontszám | kinek? | |
|---|---|---|---|
| kapcsolódó komponensek megismerése | kapcsolódó komponensek | 4 | nappali tagozat |
| kapcsolódó komponensek | 4 | levelező tagozat | |
| Kapcsolódó issue-k összegyűjtése és munka összehangolása | kapcsolódó issue-k megjelölése | 4 | mindenki |
| felelős választása és megjelölése | 1 | mindenki | |
| egységesség segítése | 3 | felelősök | |
| egységesség alkalmazása | 3 | nem felelősök | |
| Forráskód verziókövetése | Git és GitLab használat | 3 | mindenki |
| git flow követése | 3 | mindenki | |
| Fejlesztési folyamatok dokumentálása | issuek karbantartása | 3 | nappali tagozat |
| issuek karbantartása | 2 | levelező tagozat | |
| heti megbeszélés memo | 2 | felelősök | |
| aktív részvétel heti megbeszélésen | 2 | nem felelősök | |
| összegzés egységesítése | 2 | felelősök | |
| összegzés kapcsolódó részeinek kitöltése | 2 | nem felelősök | |
| összegzés elkészítése | 3 | levelező tagozat | |