Korábban már írtam a Scrum-ról. Most találtam ezt a részletesebb leírásomat a témában.
A scrum-ot elsősorban szoftverfejlesztéshez találták ki, de persze máshol is alkalmazható. Azért terjed, mert kezelni tudja a menet közben érkező ügyfél oldali változtatásokat. 1-2 hónapos ciklusokból épül fel a menetrend. A ciklusok elején egy sima listába felírjuk az ügyféllel közösen, hogy mit szeretne/énk elérni a ciklus végére. A listát addig rágjuk, amíg mindkét oldal megérti és ugyan azt érti az egyes feladatok alatt. A feladatokhoz prioritást rendel az ügyfél. Ekkor még csak azt tudjuk tehát, hogy mik a feladatok és az ügyfélnek melyik milyen fontos. Ezután leülünk a fejlesztőkkel és átbeszéljük, hogy melyik feladat milyen konkrét tennivalókra bontható, és melyik tennivaló mennyi órát vesz igénybe. Így kijön, hogy a ciklus végére mennyi feladattal tudunk végezni. Ezzel az infóval visszamegyünk az ügyfélhez és meggyőzzük róla, hogy a listája alján lévő dolgokat ebben a ciklusban nem fogjuk tudni megcsinálni. Ekkor ezt elfogadja, vagy kicsit átpriorizálja, de a lényeg, hogy ennek a megbeszélésnek a végén befagyasztjuk a feladatlistát. Az ügyfél szinte végig jelen van a ciklus tervezésnél, és majdnem minden ponton beleszólhat. Ezzel zárul a tervezés, és megkezdődnek a ciklus hétköznapjai.
A fejlesztők által összeállított tennivalók akkorára vannak szabva, hogy egy embernek kb. 1, max 2 napját tegye ki. A ciklus közbenső napjain mondjuk reggel átbeszéljük az előző napot, ki hol tart, és mit szeretne a tennivalók közül ma megcsinálni. Mindenki kérhet neki tetsző feladatot. Frissítjük a táblázatban, hogy mennyi feladat van hátra, így minden nap pontos képünk van arról, hogy hány órányi munka marad a ciklus végéig.
Ciklus hétköznapjai alatt a feladatlista nem változhat! Se mi, se az ügyfél nem változtathatja meg. Ha erre mégis szükség van, akkor - elvileg - le kéne lőni a ciklust és újra csinálni, persze csak nagyobb változtatásokhoz. A gyakorlatban, ha ilyen szitu van, akkor egyezkedések kezdődnek: ok bevesszük még ezt a feladatot, de akkor ezt meg ezt kivesszük stb. Ilyenkor résen kell lenni a rendszer függőségei miatt.
Fontos, hogy egy feladat az egy komplett feature, egy elejétől a végéig befejezett funkciója a rendszernek, egy olyan dolog, aminek elkészültsége könnyen mérhető. Hiába van meg pl. egy kalkulációs rész logikája, ha nincs rendesen kivezetve a felületre, akkor még nem használható így nincs készen.
Ciklus végén megmutatjuk az elkészült funkciókat az ügyfélnek. Ez konkrétan azt jelenti, hogy fogunk egy projektort és a fejlesztők ki-ki a maga által (vagy pont mások által) készített részt bemutatja, ledemozza. Az ügyfél ezt a prezentációt végignézi és, ha minden megbeszélt feladat elkészült, akkor elfogadja a ciklust. Ez azt jelenti, hogy megkapja a terméket, és fizet az addigi munkáért. Ha nem fogadja el a ciklust, akkor nem kell fizetnie, de (ez is egyezkedés eredménye) esetleg a termék újabb feature-eit sem kapja meg. A fejlesztő cégnek ott a kockázat, hogy 1-2 havi munkáját nem fizetik ki, az ügyfélnek meg ott, hogy 1-2 hónapot vár és esetleg nem kap semmit.
Fontos, hogy a határidők (pl. ciklus vége) nem változtatható. Nincs olyan, hogy megleszünk az összes feladattal, de egy hetet csúsznánk. Olyankor meg kell beszélni az ügyféllel, hogy figy. az a helyzet ,hogy nem lesz meg minden feladat. Lelövöd a ciklust, vagy még így is akarod?
A módszer bizalomra épül. Az ügyfél belelát a munkába. Bármikor megnézheti az előrehaladást a feladatlistában. Ott lesz, hogy ki melyik tennivalót csinálja és mennyi van még hátra. (persze lehet trükközni, kijátszani az ügyfelet, de csak legvégső esetben érdemes.
A felelősségek szerepekre vannak bontva. Van Project Owner-i szerep. Ő képviseli az ügyfelet. Ügyfél oldali döntéshozó. A fenti leírásban ami ügyféllel kapcsolatos feladat azt mind ő látja el. Őt az ügyfél adja. Vele tartjuk a kapcsolatot. Kicsit olyasmi mint egy projekt manager.
Van a Scrum Master szerep. ő a mentora a fejlesztő csapatnak. ő vezeti a reggeli megbeszéléseket. Hozzá fordulnak a fejlesztők ha bármi problémájuk, panaszuk van. Lassú a számítógép, a Józsi nem hagy békén stb. Célja, hogy a csapat hatékonyan működjön. Utasítani nem utasíthat, csak javasolhat, tanácsolhat.
Végül van a Team. Ő a fejlesztő csapat (a scrum master is tagja). Olyan mint egy cserkész őrs: együtt szívunk, együt örülünk. Ha valaki nem dolgozik, vagy elkalandozik, lusta stb. akkor nem az egyén szív, hanem az egész csapat, ha emiatt bebukják a ciklust, tehát a Team szól rá az egyénre, nem egy főnök vagy ilyesmi. A team tartja kézben saját magát.
Nem minden projekt esetében tud az ügyfél egy teljes embert teljes időben a projektre szánni. Ilyenkor van lehetőség rá, hogy a fejlesztő cég adjon Project Owner-t az ügyfélnek. Az ügyfélnek teljesen meg kell bíznia abban az emberben és minden döntési jogkört meg kell kapjon, ezért ez elég ritka. Inkább csak összeszokott partnereknél fordul elő.
Létezik olyan is, hogy kívülről (ügyfél irányból) nem látszik, hogy scrum-mal dolgozik a cég, mert minden szerepet a fejlesztő cég lát el, és kvázi belső projektként kezelik. Belső meetingek vannak a feladatlistát is belül állítják össze. Persze le lehet egyezteti az elkészült feladatlistát. A ciklusok végén lehet prezentációt csinálni. de a ciklus elfogadása/elutasítása már nem tudom hogyan kivitelezhető.
Sajnos a ruby-s binding-ok használhatatlanok.
Hunspell-hez létezik JNA itt: http://dren.dk/hunspell.html
suggest, misspelled működik, de stem és az analyze nem. A JNA csomagban van előre fordított hunspell lib, de vmi régi verzió, amiben ezek a funkciók még kísérleti fázisban vannak. A használatához újra kellene fordítani —with-experimental kapcsolóval. Próbáltam elszáll számos helyen: befejezetlen a kód.
Leszedtem legfrissebb hunspell-t, amiben ezek már alapból benne vannak. lefordítottam. stem megy. Az analyze-hoz kicsit módosítani kell a JNA-t, mert nincs megírva a binding. Semmi vész egy copy paste az egész. A HunspellLibrary.java file-ban felveszed a Hunspell_analyze metódust, Hunspell_stem alapján, illetve Hunspell.java-ban lemásolod a stem metódust és átírod a nevét.
Végül ant clean aztán ant és kész.
Ha valaki egy fehér Macbookot próbál nektek eladni (főleg utcán), akkor nézzétek meg az Airport hardvercímét, ami ha 00:19:E3:03:8A:B5, akkor vérmérséklet szerint kezdjétek el légyszi ütni a bitangot vagy ráhívni a rendőrt, mert az a gép az enyém. Köszönöm.
Reblognak is nagyon de nagyon örülök.
Az alábbi parancssor részlet mutatja, hogyan lehet 60KByte/s-re lassítani Mac-en a localban futó webserver sávszélességét. Az utolsó sorral törölhető a korlátozás
az ipfw egyébként egy firewall alkalmazás.
lodovik
az osx-es kicsomagoló nem ismeri a war file-okat, de a fenti screencast megmutatja hogyan lehet neki megtanítani.
[video]
Többünk számára érthetetlen okból a Ruby Standard Library Timeout Module-ja nem StandardError-ból származó exception-t dob az idő lejártakor. Vélhetően az Interrupt téves éretelmezése miatt a Timeout::Error-t abból származtatták, amit a sima rescue nem kapja el.
Az alábbi monkey patch segít, hogy az elvárható módon működjön a timeout.
Újabban inkább twitterezem. Ha napi szinten érdeklődsz, akkor http://twitter.com/vida_balazs
Mysql Macports-szal lett felrakva.
sudo port install ruby19
sudo gem1.9 install rails —no-ri —no-rdoc
wget http://tmtm.org/downloads/mysql/ruby/mysql-ruby-2.8.1.tar.gz
tar xzf mysql-ruby-2.8.1.tar.gz
cd mysql-ruby-2.8.1
ruby1.9 extconf.rb —with-mysql-lib=/opt/local/lib/mysql5 —with-mysql-config=/opt/local/lib/mysql5/bin/mysql_config
make
sudo make install
cd
rails -r `which ruby1.9` -g -s -d mysql PROJECT