JIRA - ezt mindenhol igy csinaljak? :(

Projektek általános

Disclaimer: Nincs sok tapasztalatom ezugyben, szoval ha ez az igaz ut valahogy majdcsak megszokom.

(1)

Mondjuk adott 3 feature amelyek mindegyike lebonthato 3 lepesre: megirni az SQL-t, megirni hozza adott programmozasi nyelvben a "wrapper" fuggvenyt, majd megirni a kodot ami hivja.

Beszelgettem a tech lead-unkkel, hogy talan jobb lenne ha egy task egy feature lenne, tobb ertelme lenne szamomra az ido logolasanak szempontjabol. Az volt a valasz, szamara jobb az, ha layer-enkent van egy task, azaz menjen az SQL egy taska, aztan a wrapperek, es igy tovabb. Oke, majd hozaigazitom, milyen sorrendben csinalom a dolgokat, nem nagy ugy.

Na de... valahogy a vegen (fenti peldan mutatva) minden kulon task-ot kapott, 3 SQL task, 3 wrapper task, 3 call site task.

Tenyleg ez a normalis, a jo, internalizaljam ezt a modjat a dolognak? Mert szenvedek mint a hatot kolykedzett kutya (nyilvan ennel a peldanal nagyobb projektrol van szo)... szerintem ez tul granularis.

(2)

EDIT: a masik dolgot onmagaban meg el tudnam viselni, de a ket problema egyutt nagyon durvan erositi egymast.

Ezek a task-ok ugy szulettek, hogy a cimukbe ki lettek masolva a solution document egyes fejezeteinek alcimei, igy tele van olyanokkal, hogy "Create SQL function", semmi egyeb, szoval ugralnom kell a dokumentum, a jira es a valos munka kozott, es ha valami adja magat, hogy megcsinalom, ami ezen a folyamaton kivul esik, akkor vagy borul a time logging, vagy 20 percnyi munka kovetese erdekeben kell plusz ketszer elszenvednem ugyanezt.

Ez kicsit mas mint az elso problemam, nem tudom elkepzelni, hogy ez helyes. De attol meg all a kerdes: ez is mindenhol igy megy?

--------------

En vagyok a hulye? Ha igen, jol fogom fogadni a konstruktiv kritikat. Szeretnem, ha nalam tobb tapasztalattal rendelkezok velemenyeznek ezt a ket problemat.

Koszonom.

  • 3695 megtekintés

( uid_4278 | 2017. 07. 29., szo – 13:54 )

A Tsystemsnel dolgozol? :P

Nem szabad elfelejteni, hogy ezek az eszkozok vannak az emberekert/projektert, nem pedig forditva. Ha nem segiti a fejlesztest, akkor feleslegesen hasznaljatok.

( muszike | 2017. 07. 29., szo – 13:59 )

Mi is használunk Jira-t.
A Jira nem erőlteti, hogy a team milyen módszertant, milyen mélységű WBS-t használjon.

Esetleg kérdezd meg, mi az oka az ekkora részletezettségnek.
Olyan bontást érdemes használni, hogy a kódernek egyértelmű legyen, mit kell csinálni.

( sz332 v | 2017. 07. 29., szo – 14:10 )

Oké, most már csak azt kellene tudni, hogy ha van 3 task, akkor a követés mit jelent? Commitolsz egy task-ra? Vagy időket is kell írnod?

( sj | 2017. 07. 29., szo – 14:29 )

az 1 task = 1 feature teljesen vallalhato.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( gee v | 2017. 07. 29., szo – 21:04 )

Változó, hogy mennyire bontják fel.
Személy szerint én szeretem, ha egymástól független taskok vannak, olyanok, amiket adott esetben külön emberek is elkészíthetnek.
Ennek akkor nincs sok értelme, ha gyakorlatilag csak egyszerre lehet rajtuk dolgozni.
Persze a feature-ök külön vannak, hiszen az egész felbontásnak az az értelme, hogy látható legyen, melyik feature hogy áll.
Viszont én a fejlesztő idejének követésére sosem használom a jirát.
Jirában a taszkokból hátralevő becsült időt vezetem. Ennek ugyanaz a célja: hogy látszódjék hogy haladunk, mennyi esély van mindennel elkészülni időben.

"Viszont én a fejlesztő idejének követésére sosem használom a jirát. Jirában a taszkokból hátralevő becsült időt vezetem."

Ugy gondolom elsodlegesen nalunk is ez lenne az egesz celja. Ezert sem ertem, miert van szukseg vezetni, adott feature elkeszitese kozben mennyi idot szantam kulonbozo fuggvenyekre...

El tudok kepzelni egy vedheto ervet: hogy minel nagyobb a dekompozicio, annal pontosabb lesz a becsles. Vagy igy van vagy nem, de vedheto allaspontnak tunik. De akkor konyorgom, tortenjen meg ez egy meeting-en, Jira task-ok meg legyenek feature granularitasuak es adjuk ossze ezeket a mikronnyi becsleseket. Ez a masik problemara is jo lenne, hogy ne csak semmitmondo soldoc fejezetcimekbol alljon egy-egy jira.

Nemtom, en - bar nem kedvelem semmilyen szinten a feladataim elvegzesehez szukseges ido becslesenek szuksegesseget - megertem, hogy a szervetezet par mas szegleteben akar szukseg is lehet erre az infora akkor is, ha nem tud 100% pontos lenni, igy aztan elfogadom az ido logolasanak szuksegesseget is. Vagy nem, de aki ugy erzi szuksege van erre az infora az ugysem fog lemondani rola, ugyhogy akar bele is torodhetek, hogy ez van.

Van olyan, hogy pl. A feature-t más fizet mint B feature-t.

Ezt kiválóan lehet úgy kezelni, ha az emberek a timesheet-be beírják, hogy A-n dolgoztam ma 4 órát, B-n meg 2-t, meg még 2-t csak úgy a projekten, nem feature specifikusan.

A munka egy része úgyse jelenik meg Jirában vagy máshol, mert a munka nem csak a taszkokból áll.

Láttam már több helyen, hogy jirából vagy hasonló rendszerből generáltak time sheet-et, de ez szerintem teljesen rossz irány. Ez csak akkor megy, ha egyben az emberek elkezdik emiatt kamu adatokkal tölteni a rendszert.

"Láttam már több helyen, hogy jirából vagy hasonló rendszerből generáltak time sheet-et"

Nalunk igy van, en pl. eleve azt hasznalom esoleges feluetnek az ido logolasara.

Ezek szerint ez altalaban nem szokott igy lenni, csak itt-ott csinaljak igy? Mashol hogy oldjak ezt meg, olvastam mar - azt hiszem stack overflow-on - hogy ezt a ket dolgot kulon kene kezelni.

Volt egy másik post pár hete, idő követéséről.

Ott már leírtam egyszer kb. ugyanezt:

Elméletileg ugye az ember beír valamit valahová, és kész. Gyakorlatilag viszont ha több, különféle célra akarják használni az adatokat, akkor jó eséllyel eltérő adatokat szeretnének a különféle célokra - vagyis egy rendszer nem fog működni.

Láttam már pár példát:
1) Belső használatra pontosan vezetni, hogy az ember mennyi időt töltött az irodában. Mikor jött, mikor ment, megvan-e a 40 óra egy héten, mennyi túlóra halmozódott fel, stb.
2) Hatóság számára jelenlétet vezetni. Kb. ugyanaz, mint az első, csak pl. túlórából nem lehet túl sokat beírni, szóval itt már hazudni kell.
3) ügyfélnek számlázni: minden napra 8 órát kell írni (vagy 1 napot). Rugalmas munkaidőből jövő eltérések nem számítanak, ha túlórát az ügyfél nem fizet, akkor azt nem szabad feltüntetni. Extrém esetben akár teljesen más is lehet, mint a valóság (hallottam már olyanról, hogy 2 embert számláztak egy ügyfélnek egy projekten, és az egyik közben teljesen máson dolgozott)
4) Egy-egy feature mennyi időt (költséget) igényelt. Ebben benne lehet sok olyan dolog is, pl. megbeszélések, másokra várakozás, stb., amik nem jelennek meg feladatok között
5) adott feladatra mennyi időt töltött el az ember -> pl. Jirában idő logolás

Mindegyik megközelítésnek más a célja, és nem használhatod, vagy csak nagyon nehezen az egyik megközelítést egy másik cél eléréséhez.

Ha pl. nálatok Jirából készül a time sheet, vagyis az 5-ös példához használható eszközt használod az első három példa valamelyikéhez, akkor valamit a normálistól eltérően kell csinálnotok.
Esetleg ti Jirában felvesztek mondjuk minden nap egy scrum meetinget is és logoltok rá 15 percet? Meg kávészünetet? Meg pisilést? Ha esetleg nem, akkor ugye nem a valóban fejlesztéssel töltött időt írod egy taszkhoz, hanem a bruttó időt. De akkor meg mi értelme Jirában írni a kamu számot egy issue-hoz, ahelyett, hogy egy excelbe vagy papírra írná az ember?

( naszta v | 2017. 07. 29., szo – 21:19 )

Van Sub task a jira-ban: 1 fő projekt, 3 alprojekt. Teljesül mindenki vágya. :)
--
http://nasz

Hasznaljuk.

Annyi a hozadeka, hogy - mintha mindez nem lenne eleg - meg arra is oda kell figyelnem, veletlenul nem-e foprojektbe logolok idot, mert ugy kezelik, hogy sum(alprojektek) == foprojekt, amivel a foprojektbe logolas nem konzisztens.

Errol is... valakinek velemeny?

Talan ha lenne akarmilyen faszerkezet jellegu vizualizacioja a hierarchianak, ami nincs pluginba kiszervezve, amit 0.003% eselyed van atverni a komplett cegen. Talan ugy segitene kicsit, es talan nemi csalassal (megnezni mennyi idot toltottem egy feature-rel es egyeloen elosztani azt a subtaskok kozott) megoldana az elso problemam, a granularitast. De mindez a azzal egyutt, hogy a legtobb jira kizarolag a solution doc alcimeit tartalmazza, ezt igy meg mindig - khm - "karcinogennek" erzem.

Gondolom itt nem projektekről van szó, hanem különféle Jira issue-król beszélünk.

Fa struktúrába szervezéshez én a Structure plugint használtam. Nem rossz, bár voltak hülyeségei. De szerintem ez a te problémádra nem adna megoldást. Ez arra jó, ha mondjuk egy Epic-et több kisebb epic-re bontunk szét, amik alatt esetleg még lehetnek epic-ek vagy user story-k.

Ugye elméletileg akármennyi szinten lehet kisebb részekre tördelni valamit, ami fent egyetlen kártya volt. Alapból a Jira ezt nem annyira támogatja.

Ha jól értem, a te problémád az, hogy van egy backlog item, amit korábban feature-nek hívtál, ez egy Jira issue. Ez alá fel kell venned taszkokat. Ez úgy megy, hogy a feature issue-ban létrehozol három sub-taskot.

Ha a time tracking engedélyezve van, akkor vannak olyan mezőid, hogy originalEstimate, remainingEstimate, és van olyan gombod, hogy log work.

Ha a subtaskban ráböksz a log work-re, akkor egyfelől tudsz akármennyi órát logolni rá, másfelől frissíteni tudod a remainingEstimate mezőt.

Úgy emlékszem, ilyenkor a feature issue-nál is kijelzi a hátralévő órákat, ami a subtaszkokra beírt számok + az issue-ba beírt szám összege. Ha az issue-ba nem írsz órát, akkor csak a subtaskok órái számítanak, és ez pont az, amit szeretnél.

Disclaimer: kb. egy éve nem használtam Jirát, emlékezetből írom ezt.

( deje | 2017. 07. 29., szo – 21:21 )

Ahol több a Jira task, mint az elvégzendő munka, ott valami gáz van a vezetéssel. Ilyen felbontás csak akkor működik, ha futószalag-fejlesztés megy, azaz mindenki csak annyi munkát csinál, mint amennyit egy futószalag mellett dolgozó munkás: egyetlen lépést. Kreatív munkára ilyen helyen nincs szükség.
Dolgoztam egyszer ilyen helyen. Nem sokáig. Nekem nem fekszik a droidmunka.

( imp | 2017. 07. 29., szo – 23:07 )

Nem mindenhol. Nalunk 1-2 (de van hogy tobb) napos munkakat szoktunk kartyara rakni, az ennel reszletesebb todo-zast mindenki maganak csinalja, ha akarja.

( haspokember | 2017. 07. 30., v – 11:56 )

This is Scrum/Agile for you.

Tippelek: UK? Eszedbe ne jusson megprobalni megreformalni a rendszert, vagy erdemben megprobalni valtoztatni rajta. Ezek ilyenek. Egyszer valami birka (nevezzuk mondjuk "Uncle" Bob Martinnak) kitalalta, hogy ezt igy kell csinalni, es azota csak ez a jo. Precedens-alapu jogrend van, de ilyen a gondolkodasuk is, szoval ha reggel elkezdened utemesen a fejed a falba verni, kozben magas fejhangon visitanal, akkor is ertelmesebben toltened az idodet (es kevesbe neznenek ki maguk kozul - sot, lehet, hogy akar te lennel az uj faszacsavo, felteve, ha megfeleloen nagy a szakallad, mert a divat azert fontos! :)).

Juniorkent nem sok opciod van, olyan ceget talalni, aki nem agile, scrum, tdd, bdd, vagy barmilyen mas 3 betus roviditessel hirdeti magat (ertsen a betuszavak alatt barmit is) eleg nehez manapsag.

Szoval egyszeruen vonj vallat, es sz*rd le a rendszert. Mosolyogj, bologass, mindenbe egyezz bele, es keress magadnak mas ertelmesebb hobbit. Mondjuk idegesitsd a kollegakat azzal, hogy Javaban ugy programozol, mintha Haskellben programoznal (az igazi programozo BARMILYEN nyelven kepes Fortranban programozni, ugye?), es utana a code review alatt torj borsot az orruk ala, hogy nem ertenek belole semmit :)

(ui: van olyan hely, ahol nincs tenylegesen agile, meg scrum, meg hasonlo borzalmak, de ezeket nehez megtalalni, mert MINDENKI igy hirdeti magat manapsag. Egy otletet adok, hogy hol erdemes nezelodni: bankoknal. Ott a business es az IT altalaban eleg elesen elvalik, ezzel lehetoseget teremtve arra, hogy a business megfeleloen magas szintu korlatokat szabjon csak (gyerekek, legyen kesz az uj reporting tool jovo honapban), igy az IT a ketrecen belul szinte teljesen szabad kezet kap. Az agile-ban megnyomoritott fejlesztok altalaban nem is ertik, hogy mi van, aztan ket eset lehetseges:

1. rajonnek, hogy milyen szuper igy dolgozni, es az egyeb mellekes zavaro tenyezoket elfogadjak, mint kompromisszum

2. osszeroppannak a nyomas alatt, vagy agyon idegeskedik magukat, hogy nincs minden keszen a szajukba rakva, elore megragva, felig megemesztve (mikromeretu jirak es tarsaik)

Szerintem egy probat meger, megha a kettes csoportba kerulsz is, rengeteget fogsz tanulni, soft skilleket is, es a penzzel sem lesz problemad.

Ha igazan tokos legeny vagy, akkor persze sajat ceget alapitasz, es onnantol mindenki teged szid majd azert, hogy milyen a rendszer, ez mar egy masik tortenet :))

Az agile metodologiak nem szentirasok, hanem csak egy framework a hatekony munkahoz a szervezeten belul. Nagy cegnel az ad-hoc "ma ezzel van kedvem foglalkozni, ezt csinalom", meg "minek bontsuk fel ugyis osszevissza dolgozom" nem megfelelo, mert ahol dollar/font/euro milliokrol van szo, ott bejon a "busz-effektus", azaz, ha esetlegesen elcsap a busz/lebetegszel/eleged volt, es azonnali hatallyal felmondassz, akkor se alljon meg az uzlet, es a kollega tudja folytatni az altalad elkezdett munkat.

Volt nekunk is kollegank, aki a "nekem ne ird elo, hogy hogy csinaljam, en ismerem a rendszert, megoldom kreativan" attitud alapjan dolgozott (es sajnos kapott is ra engedelyt), ami azt eredmenyezte, hogy mikor egeszsegugyi okokbol heti fel napot volt bent, majd levettek a csapatrol, akkor ott alltunk mint a hulyegyerekek, hogy hat tok jo lenne tudni, hogy pontosan mit is csinalt, de igazabol fogalmunk sincs.

Annyi legalabb mellette szol, hogy viszonylag jol kommentelte a ticketeket, tehat nagyjabol ki tudtuk silabizalni, hogy megis mire gondolt a kolto akkoriban, de az, hogy keverte a ticketeket, tehat a commit messageben levo Jira azonosito lehet, hogy 2-3 masik storyt is takart... probald meg 2 honappal, mikor a kollega mar nincs ott megfejteni, hogy mi es miert tortent.

Azt kell eszrevenni, hogy a programozas/IT egy resze nagyjabol a manufakturak/gyarak szintjen van, azaz kreativitas nem igazan kell (a penztermelo metodologiak mar elegge fejlettek ahhoz, hogy ne kelljen kitalalnod uj dolgokat, eleg csak a meglevo ismereteidet alkalmazni), tehat a futoszalagos hasonlat nagyjabol megallja a helyet.

Nagy cegnel, ahol kreativitas kell, az a kulonbozo (legacy) rendszerek integracioja, illetve annak megertese, hogy a valtoztatas hogy erinti a kulonbozo departmenteket, es kidolgozni a mindenkinek megfelelo megoldast. Ez nem klasszikus programozoi, hanem inkabb fejlesztoi munka, nagyjabol a developer felso szintjetol/senior leveltol valik ez elerhetove. Alatta tenyleg csak betanitott munkasok kellenek, akik a senior altal megalmodott dolgot implementaljak (mondjuk intuitiv fejlesztokkel egy jo senior meg a csapat is jobban tud teljesiteni).

A klasszikus "majd en megoldom, ne szoljatok bele, majd szallitom a vegeredmenyt" hozzaallas egy bizonyos szint utan mar kontraproduktiv. Az ilyen emberek a startup scenaban talalhatjak meg a szamitasaikat, napi 10-12 orakat dolgozva, de szabadon, mikozben a befektetok ontik bele a penzt, de ahogy a ceg elkezd penzt termelni, es novekedni letszamban, ezek azok az emberek akiktol a ceg hamar megvalik, mert egyszeruen bizonyos meret felett nem _lehet_ igy dolgozni, mert abbol csak kaosz lesz.

Az extremek altalaban roszak, es te a masik veglet ellen ervesz. Szerintem sok alternativa van akozott amirol te beszelsz es akozott amirol pl. en irtam ami akar jobban is mukodhet mindkettonel. Nekem ez igy szalmababnak tunik, bar gondolom azert irtad azt amit, mert ezzel a veglettel van (negativ) tapasztalatod es vegulis nem offtopic.

Nem mindenhol hasznaljak ilyen kreten modon az Agile/scrum-ot. A "20 perc egy SQL" nagyon nem scrum. A time logging sem. Sot, normalis scrum eseten a userek szavaznak a feature-ok hosszarol, es a minimum szavazhato az 0.5 ora. A "10 perced van SQL-t irni, 15 perced api endpointot es time loggingot nezzuk" az konkretan egy valos felmondasi indok, mert mashol nem lesznek ennyire faszok az hetszentseg.

Abban igazad van hogy ha megprobalod megreformalni es nem te vagy a munkaltato csak rosszabb lesz. Egyszerubb szimplan nem vezetni a rendszert csak megcsinalni a feladatokat es pentek delutan/hetfo reggel behuzni az osszeset amit megcsinaltal, beszelni azzal a par emberrel aki esetleg rad varhat. Kirugni ezert nem fognak, mert gyorsabban haladsz mint a tobbi es amit radszabtak azt megcsinaltad.

A problema azzal, amit pozitivnak allitasz be, hogy nem reprodukalhato (egyaltalan). Vegulis te azt mondod, hogy a projektmenedzsment felesleges, ha a projekttagok okosak/ugyesek/tudjak mirol van szo. Elkepzelheto, hogy mukodik (egy ideig). Ha viszont valami nem megy (pl. nincs keszen idore a termek, nem feltetlen a fejlesztok hibajabol, csak lehet, hogy a hatarido volt tul szuk, vagy a szkop tul nagy vagy zavaros, etc.), akkor
- nincs trivialis mod arra, hogy hozzacsapj ugy embereket a csapathoz (mert nincs dokumentalva, hogy mi van kesz es mi nincs, ill. nincs dokumentalva, hogy mik a konkret feladatok)
- nincs trivialis mod arra, hogy kommunikald az uzleti reszleggel, hogy hol tart a projekt, mi van meg hatra, mi van kesz

Amit az 'agile' ad, az nem a mikromeretu JIRA-k (tenyleg eleg gaz lenne ugy dolgozni, ahogy a nyito posztban irjak). Az agile a transzparenciarol szol, ennyi. Dolgozhatsz akarhogyan, csak a framework nem engedi meg, hogy olyasmit csinalj, amirol fogalmad csinal, hogy hova vezet. Aki meg SQL query-irasrol vesz fel ticketeket, az igy jart. :)

Ja, a bankos peldad vicces; marmint rendesebb investment bankokkal van 'nemi' tapasztalatom, es tenyleg van olyan fejlesztesi metodologia, amirol te beszelsz (es jonak tartasz), meg is van az eredmenye. :)

----------------------
while (!sleep) sheep++;

( Jason v | 2017. 07. 30., v – 11:56 )

Tipikusan nem igy csinaljak.

JIRA-rol tudni kell, hogy nagyon rugalmasra csinaltak, ennel sokkal idiotabb dolgokat (screen-ek, workflow-k, workflow validation-ök, &c) is össze lehet hozni.
De azert, mert a tech lead egy idiota, meg nem a JIRA, mint ticketing rendszer a hibas.

Van ráció abban, amit ő mond, de akkor az issue description-jébe bele KELL másolni a dokumentáció vonatkozó részeit, hogy "be legyen fagyasztva" a teendőd.
Példa: elkezdesz csinálni valamit, leadod, 2 héttel/hónappal később megváltozik a doksi, majd te leszel a hibás mert rosszul teljesítetted, pedig az akkori doksi szerint jó voltál.
Ezért kell a ticketbe beletenni a konkrét teendőd. (Pl. mert verziózva vannak a változtatások :))
Ja, meg a subjectbe is, hogy _mihez_ kell a SQL function, hogy már onnan tudd, melyik task a 3-ból (13-ból, 21-ből, &c).

Ahogy mások is írták, ezt úgy lenne érdemes csinálni, hogy 1 task per feature, majd 3 subtask a három részhez, mindegyik subtaskban a vonatkozó fejezet, a fő taskhoz meg attachment maga a doksi. Legyen mire mutogatnod, ha a tech lead sunyiban megváltoztatná a doksit -- komolyan, ez a CYA fontos feladatod: nem csak akkor kell tudnod igazolnod, hogy A Feladatot teljesítetted, amikor Resolved-re állítod a taskot, hanem utána is, bármikor.

"De azert, mert a tech lead egy idiota"

Hmm... van egy team lead-unk meg egy tech leadunk. A tech-lead rakja ossze a doksit, a team lead a Jira task-okat. Lehet ez a gond(edit: hogy ez a tech lead feladata kene h legyen)? Dolgoztam taskokkal amiket a tech lead rakott ossze, azok elhetobbek voltak, bar kisebb scope-hoz, ugyhogy ki tudja.

Ez _most_ van.
Érted, mire célzok, ugye?

Például ha beüt egy BKK-TSystems méretű balhé nálatok, és valaki utólag módosítja a doksit, hogy Te legyél a balek, akkor rábasztál. Pláne, ha nem csak kirúgnak, hanem feljelentés, kártérítési vonzat is van. A CYA évekre előre biztosítás.

Az egész ott el van már kúrva, ha 1-nél több helyen van a rendszer követelménye leírva.

Ha csak Jirában, OK. Ha csak doksiban, az is lehet OK (bár a legtöbb ilyen esetben a doksi nagy része felesleges). De amint megvan egyszer itt és egyszer ott (és esetleg még máshol is), rögtön nem csak az időt pazarolták el felslegesen (mert a fejlesztő úgyis egy helyen fogja csak elolvasni), de mivel a különböző változatokat nem fogják tudni szinkronban tartani akkor se, ha egyáltalán megpróbálják, ezért ráadásul egy csomó félreértés is lesz. A elolvassa az egyiket, B a másikat, aztán a kész rendszer meg nem működik.

( carlcolt | 2017. 07. 30., v – 14:34 )

"van egy task, azaz menjen az SQL egy taska" ... "time logging"

Az a hulye aki ilyenkor nem mond fel. 10-bol 9 helyen biztosan nem igy csinaljak.

Talalsz jobb munkat. Tenyleg. Ez mar a legalja.

( kisg v | 2017. 07. 30., v – 21:28 )

Szerintem taszknak az a jó granularitás, hogy 1 kódolási taszk az 1 (pull request (Github, Gitlab) | Changeset (Gerrit) | CR (Rietveld)). Tehát megfelel egy olyan egységnek, amit code reviewzol. Ezeket a taszkokat persze lehet összefogni feature-ré ... stb.

És nyilván ésszel kell csinálni, van olyan eset, ahol nem éri meg külön taszkot létrehozni egy CR-hoz.

A fenti Sql-es példánál maradva: ha az SQL query megírásához hozzácsapjuk a kapcsolódó teszteket esetleg DAO kódot, akkor már van értelme erre egy taszkot nyitni.