Adatok
Marhefka István
0 bejegyzést írt és 8 hozzászólása volt az általa látogatott blogokban.
A valuta árfolyamok elérhetőek a Magyar Nemzeti Banktól nem csak web oldalon keresztül, hanem SOAP híváson keresztül is. Gondoltam, hogy amikor ügyfélnek mutatok be SOAPui tesztet, demózok, akkor miért ne ezt a szolgáltatást használjam? A WSDL ezen az oldalon érhető…..
Egyáltalán nem triviális és nem is egyszerű hatékonyan vinni egy projektet, megszervezni a munkát, menedzselni a feladatokat. A szoftverfejlesztés sokszor rapid döntéshozatalt és rugalmas projektszemléletet kíván meg. Az elmúlt években egyre kiforrottabbá váltak az úgynevezett…..
Marhefka István
2010.05.17 19:42:20
@Amby: Hát, megértem a gondodat :)
Ha már próbálkoztatok vele, akkor biztosan tudod, hogy az egész "agilizmus" a kommunikáción alapszik. Nem gyártunk felesleges doksikat, hanem egymással beszélgetünk, és így oldjuk meg a problémát.
Ez már akkor is nehéz, ha Te meg én csak telefonon (vagy Skype-on tudunk beszélni), de még nehezebb, ha kulturális és/vagy nyelvi különbség is van a felek között... Vagy netán még telefonon se tudunk beszélni, mert más időzóna szerint dolgozunk. Esetleg az említettek mindenféle kombinációja :)
A videokonferenciát szokták említeni megoldásként. Pl. standupokon így vesznek rész a távollévő felek.
Bár nem voltam ilyen szituációban, úgy gondolom, próbálnám a maximumot kihozni a helyzetből, és semmiképpen nem térnék vissza a hagyományos megközelítéshez, és az agilis pályán maradnék.
Egyébként - véleményem szerint - akkor sem egyszerű az agilitást véghez vinni, ha a virtuális csapat problémája nem áll fenn. Sok dolognak kell klappolnia egyszerre. Pl. kell egy jó csapat, a projektnek és az ügyfélnek is megfelelőnek kell lennie.
Nem irigyellek :)
Ha már próbálkoztatok vele, akkor biztosan tudod, hogy az egész "agilizmus" a kommunikáción alapszik. Nem gyártunk felesleges doksikat, hanem egymással beszélgetünk, és így oldjuk meg a problémát.
Ez már akkor is nehéz, ha Te meg én csak telefonon (vagy Skype-on tudunk beszélni), de még nehezebb, ha kulturális és/vagy nyelvi különbség is van a felek között... Vagy netán még telefonon se tudunk beszélni, mert más időzóna szerint dolgozunk. Esetleg az említettek mindenféle kombinációja :)
A videokonferenciát szokták említeni megoldásként. Pl. standupokon így vesznek rész a távollévő felek.
Bár nem voltam ilyen szituációban, úgy gondolom, próbálnám a maximumot kihozni a helyzetből, és semmiképpen nem térnék vissza a hagyományos megközelítéshez, és az agilis pályán maradnék.
Egyébként - véleményem szerint - akkor sem egyszerű az agilitást véghez vinni, ha a virtuális csapat problémája nem áll fenn. Sok dolognak kell klappolnia egyszerre. Pl. kell egy jó csapat, a projektnek és az ügyfélnek is megfelelőnek kell lennie.
Nem irigyellek :)
Marhefka István
2010.05.18 10:01:39
@bodozs: Elég jó projekteken dolgozhatsz. Én amióta dolgozom (kb. 7-8 éve), egyszer sem találkoztam olyannal, hogy az ügyfél óradíjban fizetne. A jellemzőbb inkább a fix áras ajánlat, amivel persze, nincs gond, ha - fix határidőt feltételezve - a szkóp mozgó. Ez utóbbit tekintve már voltak változások a projektekben.
Unit-teszt: Annyira természetes, hogy mindenki tud unit-tesztet írni? Szerintem a jó unit-teszt írása nem triviális. Ha rosszul írják őket (és általában ez a jellemző), akkor a változások miatti folyamatos tesztkarbantartás rengeteg időt visz el. Az eredeti kérdésemben is igazából ezt próbáltam feszegetni. Mi volt a tapasztalatod: az EPAM-nál mindenki tud unit-tesztet írni, és ismeri az XP technikákat?
Azt írtad, hogy a régi kódhoz akkor növekszik a code coverage, ha abban változtat valaki. Ebből arra következtetek, hogy korábban nem készült unit teszt, hanem utólag pótolják őket. Tehát egy legacy rendszer fejlesztéséről van szó. Az ilyen helyzetekben tipikusan nem lehet unit-teszteket írni, hiszen az eredeti kód mindig egy nagy maszlag (nem unit-tesztelhető). Nem lehet, hogy ebben a projektben nem unit-tesztek, hanem integrációs tesztek készülnek?
Neked mi a véleményed? Mi az oka annak, hogy 120 ember kell ahhoz, hogy ez a projekt elkészüljön? Miért nem elég - mondjuk - 20?
Unit-teszt: Annyira természetes, hogy mindenki tud unit-tesztet írni? Szerintem a jó unit-teszt írása nem triviális. Ha rosszul írják őket (és általában ez a jellemző), akkor a változások miatti folyamatos tesztkarbantartás rengeteg időt visz el. Az eredeti kérdésemben is igazából ezt próbáltam feszegetni. Mi volt a tapasztalatod: az EPAM-nál mindenki tud unit-tesztet írni, és ismeri az XP technikákat?
Azt írtad, hogy a régi kódhoz akkor növekszik a code coverage, ha abban változtat valaki. Ebből arra következtetek, hogy korábban nem készült unit teszt, hanem utólag pótolják őket. Tehát egy legacy rendszer fejlesztéséről van szó. Az ilyen helyzetekben tipikusan nem lehet unit-teszteket írni, hiszen az eredeti kód mindig egy nagy maszlag (nem unit-tesztelhető). Nem lehet, hogy ebben a projektben nem unit-tesztek, hanem integrációs tesztek készülnek?
Neked mi a véleményed? Mi az oka annak, hogy 120 ember kell ahhoz, hogy ez a projekt elkészüljön? Miért nem elég - mondjuk - 20?
Marhefka István
2010.05.19 14:57:54
@deejayy:
1. Ha jól értettem arra gondolsz, hogy ha egyben tekintünk át egy problémát, és azt normálisan végiggondoljuk, akkor hatékonyabban lehet egyszerre megoldani, mintha azt sok kis szeletre bontanám, és prioritások szerint rendezve mindig csak azzal foglalkoznék, amivel éppen kell. Az így kapott kis feladatok a végén különböző időpontban készülnek el, ráadasul több újradolgozásra (rework) lenne szükség, mintha egyszerre csinálnánk meg. És ez költséges.
Elméletben igazad van, azonban a gyakorlatban ez másképpen történik. Gyakran kiderül, hogy a kisebb prioritású elemekre nincs is idő, pénz, nem is fontosak(!!), ezért kihagyhatóak. Pontosabban agilis megközelítés esetén meghagyjuk a lehetőségét annak, hogy ezek helyett az alacsony prioritású elemek helyett valóban fontos funkciókat fejlesszünk ki. Olyanokat, amikre eredetileg nem gondoltunk.
Sokan nem is gondolják, hogy mennyi felesleges funkciót fejlesztetnek ki velünk az ügyfelek, akik megálmodják a rendszert! A _valódi prioritások_ meghatározásához pontosan kell ismerni az ügyfelet és az üzleti problémát.
A szoftverfejlesztésben a folyamatos refaktorálás, automatizált tesztek (unit- és integrációs tesztek) biztosítják azt, hogy egy későbbi változás nem lesz költséges. A kód folyamatosan karbantartott, könnyen olvasható, módosítható, az automatizált tesztek pedig biztosítják, hogy ha módosítunk, nem rontunk el más részeket. (Vagy legalábbis hamar értesülünk róla.)
Ez régen nem így volt, és valóban szükség volt arra, hogy először jól végiggondoljunk mindent az elején.
2. Azt szokták "viccesen" mondani (nem mindenkinek lesz vicces), hogy egy jó (agilis) csapat munkáját a PM azzal tudja támogatni, hogy pizzát hoz nekik. Nem gondolnám, hogy a PM felesleges, viszont érdemes abba belegondolni, hogy a legjobb szakmai döntést nem egy olyan személy tudja meghozni, aki a legtöbbször nem is ért a szakmához. Nem is a vezető fejlesztő, aki ért hozzá, hanem maga a teljes szoftverfejlesztő csapat. Pont ez a Scrum egyik lényege: felruházza a csapatot a döntés jogával, hogy mit hogyan valósítson meg (empowering teams). Egy idő után, feltéve, hogy a csapat megfelelő környezetben dolgozik, kialakítja magának a legjobb munkamódszert. Ezt értik önszerveződő csapatokon. Ez csak akkor működik, ha a csapatban dolgozó emberek motiváltak és hozzáértőek (vagy vannak benne olyanok, akik meg tudják tanítani a többieket jól dolgozni). A motiváltság nem mindig magától jön. Ha egy csapatban megbíznak, aki így önnönmaga meghozhatja döntéseit, ha a csapat találkozhat az ügyféllel minden demó során, és mindenki saját maga bemutatja, hogy mit dolgozott a sprint közben, akkor a motiváció öngerjesztővé válik. Ezért lehet jó a Scrum. Ha a Scrum átfajul "ipari Scrummá", ahol azért alkalmazzák a Scrumot, mert az "menő", és igazából csak szolgaian követik a Scrum szabályait, olyan sokat nem profitálnak belőle. Nem fog kialakulni a profi csapat, aki a legjobb döntéseket hozva folyamatosan tanul és minőségi munkát végez.
3. Valóban vannak szabályok, de ezeket a szabályokat maga a csapat alkotja, és ha kell változtat rajtuk. Miért ne bíznánk meg egymásban? A későbbi továbbfejlesztés, karbantartás miatt pedig állandó refaktorálásra, unit- és integrációs tesztekre van szükség. Ha ez a tudás nincs meg a csapatban, akkor kellenek olyan fejlesztők, akik ezt be tudják hozni.
4. Hát, ez már nem egy könnyű kérdés :) Az ügyfeledtől és a projekttől függ. (Nincs aranyszabály, mindenki úgy köt szerződést, ahogy tud.) Korábbi hozzászólásomban küldtem egy linket, ami agilis szerződésekkel foglalkozik.
1. Ha jól értettem arra gondolsz, hogy ha egyben tekintünk át egy problémát, és azt normálisan végiggondoljuk, akkor hatékonyabban lehet egyszerre megoldani, mintha azt sok kis szeletre bontanám, és prioritások szerint rendezve mindig csak azzal foglalkoznék, amivel éppen kell. Az így kapott kis feladatok a végén különböző időpontban készülnek el, ráadasul több újradolgozásra (rework) lenne szükség, mintha egyszerre csinálnánk meg. És ez költséges.
Elméletben igazad van, azonban a gyakorlatban ez másképpen történik. Gyakran kiderül, hogy a kisebb prioritású elemekre nincs is idő, pénz, nem is fontosak(!!), ezért kihagyhatóak. Pontosabban agilis megközelítés esetén meghagyjuk a lehetőségét annak, hogy ezek helyett az alacsony prioritású elemek helyett valóban fontos funkciókat fejlesszünk ki. Olyanokat, amikre eredetileg nem gondoltunk.
Sokan nem is gondolják, hogy mennyi felesleges funkciót fejlesztetnek ki velünk az ügyfelek, akik megálmodják a rendszert! A _valódi prioritások_ meghatározásához pontosan kell ismerni az ügyfelet és az üzleti problémát.
A szoftverfejlesztésben a folyamatos refaktorálás, automatizált tesztek (unit- és integrációs tesztek) biztosítják azt, hogy egy későbbi változás nem lesz költséges. A kód folyamatosan karbantartott, könnyen olvasható, módosítható, az automatizált tesztek pedig biztosítják, hogy ha módosítunk, nem rontunk el más részeket. (Vagy legalábbis hamar értesülünk róla.)
Ez régen nem így volt, és valóban szükség volt arra, hogy először jól végiggondoljunk mindent az elején.
2. Azt szokták "viccesen" mondani (nem mindenkinek lesz vicces), hogy egy jó (agilis) csapat munkáját a PM azzal tudja támogatni, hogy pizzát hoz nekik. Nem gondolnám, hogy a PM felesleges, viszont érdemes abba belegondolni, hogy a legjobb szakmai döntést nem egy olyan személy tudja meghozni, aki a legtöbbször nem is ért a szakmához. Nem is a vezető fejlesztő, aki ért hozzá, hanem maga a teljes szoftverfejlesztő csapat. Pont ez a Scrum egyik lényege: felruházza a csapatot a döntés jogával, hogy mit hogyan valósítson meg (empowering teams). Egy idő után, feltéve, hogy a csapat megfelelő környezetben dolgozik, kialakítja magának a legjobb munkamódszert. Ezt értik önszerveződő csapatokon. Ez csak akkor működik, ha a csapatban dolgozó emberek motiváltak és hozzáértőek (vagy vannak benne olyanok, akik meg tudják tanítani a többieket jól dolgozni). A motiváltság nem mindig magától jön. Ha egy csapatban megbíznak, aki így önnönmaga meghozhatja döntéseit, ha a csapat találkozhat az ügyféllel minden demó során, és mindenki saját maga bemutatja, hogy mit dolgozott a sprint közben, akkor a motiváció öngerjesztővé válik. Ezért lehet jó a Scrum. Ha a Scrum átfajul "ipari Scrummá", ahol azért alkalmazzák a Scrumot, mert az "menő", és igazából csak szolgaian követik a Scrum szabályait, olyan sokat nem profitálnak belőle. Nem fog kialakulni a profi csapat, aki a legjobb döntéseket hozva folyamatosan tanul és minőségi munkát végez.
3. Valóban vannak szabályok, de ezeket a szabályokat maga a csapat alkotja, és ha kell változtat rajtuk. Miért ne bíznánk meg egymásban? A későbbi továbbfejlesztés, karbantartás miatt pedig állandó refaktorálásra, unit- és integrációs tesztekre van szükség. Ha ez a tudás nincs meg a csapatban, akkor kellenek olyan fejlesztők, akik ezt be tudják hozni.
4. Hát, ez már nem egy könnyű kérdés :) Az ügyfeledtől és a projekttől függ. (Nincs aranyszabály, mindenki úgy köt szerződést, ahogy tud.) Korábbi hozzászólásomban küldtem egy linket, ami agilis szerződésekkel foglalkozik.
Webisztán
"Nagy lépés, ha egy cég rájön arra, hogy problémái vannak" - A Scrum módszerről (2. rész)
2010.05.18 12:48:00
Folytatjuk a beszélgetést Bodó Árpád Zsolttal, a Sprint Consulting alapítójával. Az interjú első részében a Scrum szoftverfejlesztési modell működéséről és sajátosságairól esett szó. (Akik nem annyira jártasak a témában, mindenképpen olvassák el az interjú első…..
Marhefka István
2010.05.18 20:08:22
@Amby: Azt hiszem, hogy olyan kérdésekre próbálsz választ találni itt, amit a Scrum nem válaszol meg, mert ő felteszi, hogy olyan környezetben dolgozol, hogy őt alkalmazhatod :)
Ha jól gondolom, akkor Téged az agilis szerződések érdekelnek. Ezzel is foglalkoznak a neten. Ez itt nem egy rossz leírás: agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts
Szerintem ne várd senkitől itt ezen a fórumon, hogy megoldja ezeket a problémákat, ugyanis ezekkel az egész iparág küszködik :) Én úgy látom, hogy jobban jársz, ha Te magad jársz utána a dolgoknak :)
Ha jól gondolom, akkor Téged az agilis szerződések érdekelnek. Ezzel is foglalkoznak a neten. Ez itt nem egy rossz leírás: agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts
Szerintem ne várd senkitől itt ezen a fórumon, hogy megoldja ezeket a problémákat, ugyanis ezekkel az egész iparág küszködik :) Én úgy látom, hogy jobban jársz, ha Te magad jársz utána a dolgoknak :)
Marhefka István
2010.05.18 20:11:17
@aston21: Ki csinálta nálatok a Scrum-bevezetést?
Belépve többet láthatsz. Itt beléphetsz
Jajjj! Szívemből szóltál! :)