Regisztráció Blogot indítok
Adatok
M_a_x_x

0 bejegyzést írt és 4 hozzászólása volt az általa látogatott blogokban.

2010.03.01. óta tag.
Admin Szerkesztő Tag Vendég
Tiszakécske Blog Óvatosan a fűnyírókkal, elfogadták a zajrendelet módosítását 2013.07.09 08:12:56
Elfogadták a rendkívüli testületi ülésen a zajrendelet módosítását, így érdemes figyelni arra, mikor nyírunk füvet, vagy hallgatunk zenét. A zajrendeleten némiképp puhítottak módosítottak Polyák József alpolgármester kezdeményezése nyomán. A Tisza-parti…..
M_a_x_x 2013.08.14 08:14:00
Tiszakécske Blog Zajrendelet: mikor lehet füvet nyírni, porszívózni és zenét hallgatni? 2013.07.09 14:43:53
Módosította a tiszakécskei képviselő testület a 2001-es zajrendeletet a keddi, rendkívüli testületi ülésen. Mint arról percről-percre tudósításunkban már beszámoltunk: a rendelet korlátozza a hangos kerti munkákat és a zenehallgatást is. Polyák József alpolgármester…..
M_a_x_x 2013.07.10 10:01:10
Számomra furcsák a szavazatok! Sokszor az az érzésem, hogy ha valamit kihoznak rendeletbe, akkor az ellen már fel kell háborodni, bezzeg amikor a délutáni szundításból kelt fel egy ütvefúró, akkor meg fel van háborodva, és akkor már ne is beszéljünk arról, hogy amikor a szülő fáradtan leteszi kisbabáját esti alváshoz, de a szomszéd akkor ereszti szabadjára a hifi hangerejét...
A cikkíró kommentárjaival sem feltétlen értek egyet, ugyanis a hangos, vagy mások számára zavaró, tökéletesek ilyen esetekre, hisz ha azt írták volna, hogy nem lehet olyan eszközt működtetni, amely 90dbnél nagyobb zajt kell 3 méter távolságban, akkor meg az lett volna, hogy "rohangáljon mindenki mérő eszközzel?". A hangos egy közérthető kifejezés, melyet egy felnőtt társadalom ki tud értékelni, hogy mi hangos és mi nem...
Úgy hogy kedves tiszakécskei lakosok örüljetek, hogy próbálnak jobban védeni a zajtól Titeket!
M_a_x_x 2013.07.11 18:26:03
Webisztán Projektmenedzsment a szemnek: post-it fal 2012.09.03 19:43:31
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…..
M_a_x_x 2012.09.12 23:09:43
10 éve fejlesztünk projektmenedzsment szoftvert, mely webes és a megjelenő feladatok felülete nagyon hasonlít a cikkben is fotózott post-it táblára, gyakorltailag egy webes kanban táblánk van (ezért kaptam fel a fejem a cikkre).
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!
felhasználási feltételek adatvédelmi tájékoztató segítség jogi problémák dsa impresszum médiaajánlat süti beállítások módosítása