Bár őszintén szólva a grid téma kapcsán arra számítottam, hogy a hazai webdizájnerek, sitebuilderek közül 3-nál többen elmondják szakmai véleményüket, és ezzel egy elég fontos alapkérdésben láthatunk tisztábban, végül ez mégsem következett be. Igaz ugyan, hogy páran rámcseteltek, és privátban értekeztünk a témáról. De szerintem a problémakör azért több ingert kellett volna, hogy kiváltson. Mindegy. Aki esetleg utólag szeretne kommentelni, a postnál megteheti.
Mindezek után bedobnék még egy témát, ami szerintem elég fontos ahhoz, hogy szó legyen róla. Sőt, akár kommentelésre is ösztönözzön.
A téma egy kicsit a projektmenedzsment. Pontosabban annak a szoftveres, számítógépes részén túli világa. Én nemrégiben vezettem be a munkahelyemen a Kanban-táblához hasonló falra írós ticketelési rendet. Ha a Kanbant (lean módszereket) úgy magában nem is tartom minden tekintetben a világ leghatékonyabb projektszervezési módszertanának, de azt az elvet, hogy fizikailag is kerüljünk kapcsolatba feladatokkal (vagy azok reprezentációival) egy olyan szakmában, ami alapvetően elvont, mindenképpen jónak gondolom.
Nagyon egyszerű whiteboard reprezentciót választottam a projekthez. Egyrészt a whiteboard úgy van feltéve a falra, hogy a projekt résztvevői mind rálássanak. Másrészről a négy fázisos verziót használom: egy ticket vagy várakozik, vagy folyamatban van, vagy elkészült, vagy pedig át van adva.
Amíg egy ticket nincs átadva, addig visszakerülhet bármelyik korábbi állapotba. Vagyis elkészült ticket is visszamehet a "folyamatban" oszlopba, és egy folyamatban lévő ticket is visszamehet "várakozik" státuszba. Ha azonban egy ticketet átadtunk, akkor az le van pecsételve. Haladni kell a többivel.
A postitekre a feladat rövid megnevezése mellett az adott tickethez rendelt komplexitás-szám van még ráírva. És az etapok különböző színű postitekre vannak írva. Így az is jól látszik, hogy mi az, ami régóta bent ragadt feladat, és mi az, ami újabb, és gyorsabban mozog a táblán.
Néhány hete ezzel kapcsolatban kértem is a véleményeteket Twitteren. Egyetlen komoly és részletes válasz érkezett, mégpedig Szűcs Attilától (Arkon):
Azt láttuk, hogy egy 60-70 fős cégnél már elég nagy energiát kell abba fektetni, hogy tudjuk, ki milyen projekten dolgozik, milyen összefüggések vannak a projektek között, és hogyan tud 60-70 ember egymást segítve gördülékenyen együtt dolgozni. Arra jutottunk, hogy kell egy átlátható, egyszerű roadmap. Mi ez a "csomagolópapír roadmap", miért kezdtük el használni? Hiszünk a lean megoldásokban, úgyhogy a futárunk vett az Ápiszban csomagolópapírt és Post-it-et (fontos, hogy valódi Post-it legyen, különben lefújja a szél a terveket!). Amit most láttok, az egy "publikus béta" roadmap, kb. 3 hónapja használjuk, szóval még van hova fejlődnie. A terveink szerint idővel eljutunk oda, hogy 4 negyedévre szól majd folyamatosan, egyelőre kb. év végéig látunk előre. Epic szintű (azaz 2-6 hét) között lefejleszthető feladatcsokrok vannak egy-egy cetlin. Minden kéthetes fejlesztési ciklus kezdetén és végén összegyűlik a csapat, és kipipálja az elvégzett feladatokat.
Ők amúgy 4 hónapja használják a postit falat, és pozitívumként azt emelik ki, amit én is meg tudok erősíteni: a tábla nemcsak azért jó, mert látható a munkanap bármelyik pillanatában, hogy hogyan állunk a feladatokkal, hanem egyszersmind mindenki (avagy: nem csak projekttagok) számára látható a fal. Így transzparens a munka. És ennek nagyon fontos hatása van a nyugodt munkavégzésre.
(Kanban tábla az Arkon Zrt.-nél)
Azt is kiemelik az arkonosok, hogy sokkal kézzelfoghatóbbá válik, hogy hogyan haladnak egy adott sprinttel. Ezt is meg tudom erősíteni. Mindenki pontosan látja, hogy egy adott időpillanatban mennyire áll jól a sprint.
Felsoroltak néhány problémát is:
- Jó lenne, ha lenne egy távolról is elérhető verziója. A területi képviselők például ritkán vannak az irodában, jó lenne, ha ők is látnák. Gondolkozunk egy webkamerán vagy valamilyen online eszközön.
- Figyelni kell rá, hogy aktuális maradjon, még nem teljesen szoktuk meg, hogy heti gyakorisággal ránézzünk, aktualizáljuk. Időnként gyomtalanítani kell, ezt ez egyik kollégánk önként vállalta.
- A függőségeket manuálisan kell kezelni (átteszünk egy cetlit, nem viszi magával a függőségeket automatikusan).
- A felelősöket rá kell írni a cetlire.
- Archiválásra jó lenne valamilyen megoldás, pl. lefotózni időnként.
- Gyakran nehéz rövid, de pontos és közérthető elnevezésket írni a cetlikra. Ha nem sikerül, akkor "tolmács" kell a projekteket közelről nem ismerők számára.
- Nem mindig egyértelmű, hogy egy téma "megérdemel-e" egy külön cetlit.
- Jó lenne az összes roadmapet egy helyen látni, de ahhoz egy 4m magas fal kellene...
Az én legnagyobb kontrám az egésszel kapcsolatban az, hogy extra adminisztrációs feladatot ró minden munkatársra. Nálunk az a szabály, hogy mindenki maga írja meg a hozzá tartozó ticketeket postitre, és maga is teszi fel a táblára, és sajátmaga mozgatja a táblán. Ez kétségtelenül extra elfoglaltság. Hiszen a normál projektmenedzsment rendszerben is vezetni kell ugyanezeket. Néha lemaradoznak ticketek, nem mozognak át az új helyükre. És ez zavart tud okozni.
Ezzel együtt azt gondolom, hogy ez egy egyszerű és jó módszer arra, hogy egy random pillanatban is elég jó képet kapjunk arról, hogy ki min dolgozik, hol tartunk a projekttel, mennyire tartható a határidő. Ráadásul mindezt úgy, hogy sem határidők, sem időpontok nincsenek a táblára írva.
Szűcs Attilának pedig még egyszer köszönet a részletes és érdekes leírásért.
Ti használtok hasonló megoldásokat? Ha igen, mi a véleményetek? Ha nem, miért nem próbáltátok eddig ki?
Mefi · http://mefi.be/ 2012.09.03. 21:42:22
ESz · http://emich.hu 2012.09.03. 21:42:42
A cetlik, ilyen sok együttműködő csapat esetén már nem tennivalókat képviselnek, hanem gyakran többhetes ügyeket (epic -eket). Valójában egy roadmap fal és nem kanban fal.
A kanbanos cetlifal egy (akár 6-8 fős) csapat esetén még jól tud működni, viszont ennél több ember együttműködése esetén csavarni kell a zoomon hogy áttekinthető legyen.
A csapatok Jira -t használnak (egy igen népszerű és sokat tudó agilis tool), azon belül is GreenHoppert. Ennek legfrissebb (6 -os) verziója már nagyon kézreálló Kanban vagy SCRUM falakat tud.
Léptékek nagyon leegyszerüsítve:
- task: max néhány órás tennivaló egy embernek (Jira)
- story: max néhány napos feladat egy csapatnak (Jira)
- epic: több hét - több hónap egy csapatnak (roadmap fal)
- cél: negyedév - év egy osztálynak (google sites és fal)
- vízió: sok év a vállalatnak (google sites)
davidtoltesy 2012.09.03. 22:07:36
viteez 2012.09.03. 22:28:42
és ugye evernote-nál (is) megoldható lenne az, h mások is lássák, h hol állok, csak ez már egy felsőbb szintű döntés lenne a cégnél…
az evernote-ban a különböző notebookok a projektek, maguk a notes-ok az adott feladatok, a tag-ek pedig jelzik, h hol áll az adott feladat, ill. a kollégáknak van tag-jük, h ha náluk áll. az egész meg be van vezetve zendone-ba, ahol látom a határidőket.
Leni 2012.09.04. 11:58:02
De ismet visszaterunk a falhoz pont a public-manifest miatt.
Moblirol kuldve ennyi fert be.
davidtoltesy 2012.09.04. 11:58:10
Jatekfejleszto kisiparos 2012.09.04. 11:58:18
ESz par tipp. Jira jo de azert elegge korlatozott egy bizonyos ido utan, foleg hogyha scrum rendszert hasznaltok. Probald meg a Hansoft-ot nekem sokkal inkabb bejott.
Mentalitasbeli problemakat velek felfedezni David es Vitees hozzaszolasaban. Egyfelol valoszinu azert nemsikerul meggyozni a beosztottakat es a vezetoket, mert nektek sincsen eleg nagy tapasztalatok abban, hogy ez gyakorlatban hogyan mukszik. Ezen nagyon egyszeru segiteni elegge sok szakirodalom van ezzel kapcsolatban ( Scrum rendszer vagy Agile) de biztos vagyok abban is hogy tovabbkepzesek is leteznek otthon erdemes elvegezni oket mert otthon meg mindig a papir sokkal tobbet szamit mint a tenyleges tapasztalat.
Azt ugyancsak erdemes megemliteni, hogy ez a tablara irogatasos rendszer csak akkor er sokat, hogyha a munkafolyamatok is ez alapjan epulnek fel.
Adminisztracios ido? Ugyan mar! Azt senki sem gondolhatja komolyan, hogy olyan sok ido felirni egy cetlire hogy aznap/azon a heten min is fogok dolgozni. Ha megis az lenne akkor ott sokkal komolyabb problemak vannak.
Barhol is dolgoztam azt tapasztaltam hogy nagyon rovid ido utan mindenki borzasztoan buszke arra, hogy a kiadott a feladatot megcsinalta atteheti a Done ala. Ha szamokat kellene mondanom akkor kb 30-50%-al nott a hatekonysag a csapaton belul. Arrol mar nem is szolok, hogy mennyi idot sporoltunk meg azzal, hogy mindenki pontosan tisztaban volt azzal, hogy ki min dolgozott es ezert egybol hozza fordult ha vmi kapcsolodo gondja, kerdese volt. Ugye ez az idomegtakaritas nem igazan merheto, csak erzekelheto. Vegul de nem utolsosorban ez a rendszer a vezeto szemszogebol a legtutibb, hiszen folyamatosan tisztaban van azzal, hogy ki hol all es igy sokkal pontosabb kepet tud adni a projekt egeszet nezve. Ezt ugye nem is kell reszleteznem, hogy mennyire jelentos.
Szemely szerint, hogyha valaha is hazaterek es vagy az iparagon belul helyezkedek el vagy sajat ceget inditok ez alap lesz. Ha a bevezetes es a vegrehajtas kovetkezetes akkor nagyon gyorsan hozza lehet szoktatni mindenkit.
tvk · http://kodzaj.blog.hu 2012.09.04. 11:58:28
- Kanbanban sprint? Érdekes.
- A Trello.com-t próbáljátok ki elosztott csapatok organizálásához. Joel Spolsky-ék csinálják.
- Még nem hivatalos, de szeptember 19.-én lesz Java User Meeting (JUM), ahol lehet hogy lesz előadás egy Scrum-eszközről.
sancho04 2012.09.04. 11:58:37
csak ajánlani tudom.
Mellette nálam evernote a jegyzeteknek, viteezhez hasonlóan notebook/projectenként és producteev a saját taskok-ra.
Kamela 2012.09.04. 14:01:25
Ajánlom elolvasásra a cikket a Trello "készítőjétől":
www.joelonsoftware.com/items/2012/07/09.html
És persze a bemutató/demo video:
www.youtube.com/watch?v=aaDf1RqeLfo
Swacsa 2012.09.04. 14:01:32
www.adaptiveconsulting.hu/sites/default/files/KanbanEsScrum_MindkettobolALegjobbat_1.pdf
Baranovics Krisztián 2012.09.04. 14:01:40
RolFic · http://onlinetrendek.blog.hu 2012.09.04. 15:34:43
d4n3sz 2012.09.05. 11:24:39
Én ezt használom saját projekthez:
www.targetprocess.com/
A Kanban részét nem használom, de nekem nagyon bejön, hogy User Story alapján tudom csoportosítani a Task-okat (és ez mind a Kanban, mint a Scrum táblán úgy jelenik meg)
kg_kilo 2012.09.05. 11:39:53
Mefi · http://mefi.be/ 2012.09.06. 10:45:59
develop 2012.09.06. 10:48:49
A Trellot én is kipróbáltam. A Kanban táblája is könnyen használható, de nagy hiányossága volt, amikor néztem, hogy nem találtam benne olyan megoldást, ami az elszámolást, vagy az egy feladatra fordított idő rögzítését segítette volna.
Mivel magáncélra (is) kerestem PM megoldást így mindenképpen olyat szerettem volna, ami minden - a cégnél eddig felmerült-, és a magánjellegű igényeimet is kielégíti.
A nagy keresgélésnek az lett a vége, hogy elkezdtem magam írni egy alkalmazást, amit saját célra már a kezdetektől fogva használok. Cél volt, hogy a feladatokat folyamatokban tudjam kezelni (teendő-folyamatban-készre jelentett-ügyfélnél-lezárt), és ezeket vizuálisan, kanban táblában is lássam.
Persze ennek a saját megoldásnak is megvannak még a gyerekbetegségei meg a hiányosságai, pláne egy több éve, nagy csapat által fejlesztett alkalmazásokhoz képest, de a lendület és a fejlődés töretlen. :)
A PM-ről bővebben: evolutionsuite.hu/
(A keresgéléseim közepette viszont a több tucat külhoni megoldás mellett nem találtam szinte semmilyen magyar, még aktívan fejlesztés alatt lévő eszközt.)
Jatekfejleszto kisiparos 2012.09.07. 10:39:08
Jira tokeletes bugok kezeleseben. Persze mind minden programnak ennek is vannak hatarai, korlatai, bar ezeket en inkabb az emberi tenyezoben latom. Csak a felreertesek elkerulese vegett egy 20-30 de meg egy 50 fos fejlesztoi kornyezetben ezek a hibak soha nem fognak elojonni. De egy ennel sokkal nagyobb fejlesztoi kornyezetben mar igen. Az teny hogy nagyon szemelyre szabhato eszkoz, es rengeteg erdekes neha mar mar hasztalan dolgot is lehet vele csinlani.
Viszont pl egy scrum rendszernek pont az a lenyege hogy ne csak az adott szemely lassa a taskot amit el kell vegeznie vagy csak az aki watcherkent be van allitva, hanem barki. Na erre nem alkalmas a JIRA, hiszen nem is erre terveztek. Azon progikat amiket a tobbiek ajanlottak csak felszinesen ismerem ezert velemenyt mondani roluk nem lenne helyenvalo. Viszont a Hansoft-ot igen. Pont arra valo ami itt a lenyeges kerdes volt, hiszen ez pont arra lett kifejlesztve. Ugyancsak bovitheto, es nem okoz neki gondod, hogy egy nagyobb fejlesztoi csapatot is kiszolgaljon.
Joparszor megtapasztaltam mar a vezetes elore nem latasat azaz hogy olyan programmal kezdtek el dolgozni amit utana a fejleszto csapat egyszeruen kinott. Ilyen pl a Bug-track is. Egyszeruen sokkal tobb bug jott egy fejlesztes alatt mint ami a maximum kapacitasa volt. Egy ilyen szituacio egy fejlesztesnel rengeteg gondot okozhat. De vegyuk csak develop hozzaszolasat. Kepzeljuk el hogy egy progival kezdunk neki a fejlesztesnek. Azt azutan kinovi a csapat vagy kiderul hogy a megvaltozott korulmenyek miatt mar nem alkalmas arra amire hasznalni kivantuk. Egy valtas a fejlesztes kozepe vege alatt sokkal tobbe kerul ( es itt nemcsak a penzrol beszelek, hiszen az idotenyezo neha sokkal tobbet er) mintha eleve egy sokkal komplexebb progival kezdtunk volna neki a fejlesztesnek. Persze az sem szerencses hogyha megvesszuk a csili vili legjobb cuccot es csak 10%-at hasznaljuk ki. Ez a felsovezetes dontese, de a hatasa sokkal inkabb a csapaton csattan.
M_a_x_x 2012.09.12. 23:09:43
A feladatok kezelését egy egyszerűen és jól paraméterezhető folyamatmotor adja, mellyel tetszőleges folyamatok írhatóak le. Két kiemelt képernyőnk a feladatkosár, melyen (sárga színű) postiteken megjelennek csoportosítva, hogy milyen feladataim vannak és mikor keletkeztek, illetve hogy milyen feladatokat kapott a csoportom (ezeket még nem vett senki magára), másik kiemelt képernyő a projektáttekintő, mely a feladatok "fejléce", (kék postiteken) nyomon követhető tetszőleges csoportosításban a futó projektek. Ezeken általában azt jelezzük (paraméterezhető a megjelenő adat), hogy ki a projekt felelőse, mennyi idő ment el már a megvalósításra, hol tart éppen a projekt, mi a zárás várható időpontja. A postitet kijelölve megnézhetőek az ügy során keletkezett feladatok, dokumetumok, hozzászólások.
Az ügyfeleinknek szállított rendszerekben legtöbbször összetett folyamatokat kell leírnunk (pl banki belső folyamatok), de előfordul olyan is, aki az említett todo-inprogress-done folyamatot alkalmazza.
Az ügyfelek fejlesztési megrendeléseinek nyomon követésére mi egy, a két véglet közötti folyamatmodellt alkalmazunk, melynek fő feladatai, állapotai a következőek:
1. feladatkiosztás (fejlesztő kijelölése, de a fejlesztő maga is leveheti magához)
2. terv készítés (az ügyben rögzített bejelentés alapján a fejlesztő leírja, hogy hogyan képzeli a megvalósítást)
3. terv jóváhagyás (a feladatot megkapva látom a fejlesztő tervét, melyet elutasíthatok, vagy megjegyzéssel láthatok el)
4. fejlesztés (a fejlesztő rögzíti, hogy miben történt a változás)
5. tesztelés (a tesztelő csoport megkapja a feladatot, ahol látja hogy mi volt az igény, mi a terv és melyik patchel tudja tesztelni a változtatást)
6. release kiadás (gyakorlatilag a patch küldése)
7. ügyfél megtudja, hogy megkapta a fejlesztést és nézze meg, hogy oké-e minden
8. számlázás (számlázásnál kiköpi a rendszer, hogy mennyi ráfordítás ment el az üggyel, illetve ha volt ajánlat külön, akkor az mennyiről szólt)
Természetesen számtalan ág ki van alakítva, melyek most nem lényegesek (pl tesztelés nem sikerül, visszakapja a fejlesztő a postitjét...stb)
Ezen felül egyes feladatcsoportok meghatározhatnak státuszokat az ügyhöz. Ezek a felületen könnyen csoportosíthatóak és láthatóak, hogy mik vannak "beérkezett", "fejlesztés alatt", "lezárt" státuszokban.
A post-itek kaptak még egy jópofa beállítható tulajdonságot: az elvégzetlen feladatok, ahogy öregednek, jól láthatóan gyűrődnek és sötétednek, mellyel ránézésre megállapítható, hogy ez a feladat már régi és még mindig nincs elvégezve.
A valós kanban táblán kellene pár tíz évet várni, hogy meglátszódjon rajta, hogy egy feladat régi ;D!
Swacsa 2012.09.25. 16:42:48
- A csapat létszáma folyamatosan - egy napon belül - változik, így a WIP korlát túlságosan rugalmas
- A mcsv (munkacsoport-vezető) is több projekten dolgozik, így az esetleges WIP korlát ütközésnél nem mindig van jelen
- A feladatok több olyan forrásból érkeznek be, amivel gond van:
○ Problémások:
§ Email (amin az IT csapatvezető nincs rajta)
§ JIRA (nem nézi rendszeresen a JIRA-t az IT mcs vezető)
□ Ez már kezelve lett , minden felvett feladatról kapok értesítést (viszont sajnos a státusz váltásokról is, így rengeteg a JIRA levél…)
§ Személyes ill. "cetlis" kérés projektvezető, egyéb munkacsoport-vezető, munkacsoport-tag , ügyviteli dolgozó részéről
○ Ami rendben van
§ Emailes kérés - IT mcsvezető legalább cc-ben
§ Közös egyeztetés megbeszéléseken elhangzott feladat
§ Feladat kérése IT mcsv-n keresztül (kvázi bármilyen formában)
- 1-1 feladat nem rendelhető csak 1 erőforráshoz, így nehéz a WIP korlát betartása
○ Talán érdemes kisebb egységekre szedni (pl adott CR javítása - kell tesztelő/db szakember/fejlesztő)