A Scrum-ról szóló cikksorozatom első részében egy rövid összefoglalást adtam arról, hogy mik a Scrum alapszabályai. Ígéretemhez híven folytatom azzal, hogy mi hogyan alkalmazzuk a Scrum-ot.
Ez a post a product backlog-ról szól.
Continue reading
A Scrum-ról szóló cikksorozatom első részében egy rövid összefoglalást adtam arról, hogy mik a Scrum alapszabályai. Ígéretemhez híven folytatom azzal, hogy mi hogyan alkalmazzuk a Scrum-ot.
Ez a post a product backlog-ról szól.
Continue reading
A céges projektünk lassan 3 éve tart. Az első évben szenvedtünk. Állandóan a projekttervet próbáltuk karbantartani: feladatokra bontottunk, ütemeztünk, erőforrásokat terveztünk. Ezt az akkori projektteamből 3 ember végezte (közülük én voltam az egyik). Hiába próbáltuk up-to-date tartani a projekttervet, és frissítettük rendszeres időközönként, az újabb és újabb projekttervek is néhány nap múlva szétcsúsztak.
Pár hónap alatt eljutottunk oda, hogy semmit nem ér az egész. Semmit nem lehet előre tervezni és jelezni, ráadásul sok időt visz el a tervezés. Jött az ötlet, próbáljuk ki a Scrum-ot. (Csuti hozta az ötletet.) Akkor a fejlesztői csapat még nem hallott róla, ezért elolvastunk az Infoq-n egy elég jó összefoglalót. Ez egy emészthető bevezetés a Scrum-ba, gyakorlati megközelítéssel. Utólag 2 év “Scrumozás” után az a véleményem, hogy bőven elég volt ezt az egy ismertetőt elolvasni. Ez alapján el lehet indulni.
Continue reading
Ez egy rendkívüli post, elnézést az offtopicért.
“Hagyományos iratkezelés az elektronikus dokumentumok világában” címmel 2009. szept. 30-án egy egész napos szakmai konferencián vettem részt Budapest Főváros Levéltárában. A konferenciát az IDSzSz szervezte (Irat- és Dokumentumkezelési Szakmai Szövetség). A résztvevők egyrészt a szakmából valók voltak (pl. levéltárosok, más közfeladatot ellátó szervezetek érdeklői), és beszállítói oldalról is jelentek meg képviselők.
Számos témáról volt szó, egy-egy előadó 20-30p-es előadást tartott. Az egyes előadások rövid jellemzése következik.
Már sokszor utaltam arra, hogy mennyire fontos az, hogy a fejlesztett szoftverünk kódja jól olvasható legyen. Egy jól olvasható kód magáért beszél: csökkenti a fejlesztők közötti közvetlen kommunikáció szükségességét, valamint lehetővé teszi, hogy a szoftver könnyebben továbbfejleszthető, karbantartható legyen.
Ha jó a kód, akkor abból “visszafejthető” maga az üzleti igény, a mögöttes üzleti gondolkodás. A mai post-ban való világbeli példákat vettem elő.
Continue reading
Az elv lényege az (üzleti) szoftverfejlesztésben az, hogy ha programot írunk, akkor a kódban mindent próbáljunk névvel, ill. megfelelő névvel illetni.
Ökölszabály: a kódban lévő azonosítók kövessék az üzleti terület fogalmi rendszerét. Építsünk egy mindent átható nyelvet (Ubiquitous Language), amelynek célja, hogy egy közös nyelvet beszéljünk az ügyféllel és ugyanezen fogalmakat használjuk a program kódjában is.
Continue reading
A szoftverprojektek szállítása egy komplex feladat, komplex rendszerként viselkedik. Ennek a rendszernek rengeteg összetevője van: maga a rendszer, a fejlesztők, tesztelők, az üzleti környezet, a futtató hardver, az infrastruktúra, a folyamatos bizonytalanság, a kockázatok stb. Hogyan biztosítható az (vagy hogyan csökkenthetőek a kockázatok), hogy egy fejlesztés alatt lévő komplex rendszer olyan irányba fejlődjön, hogy végül azt alkalmazni lehessen?
Sokat hallani másoktól, hogy írjunk kommentet a kódba. A fő érv a javaslók körében az, hogy ezáltal a programkódot érthetőbbé tehetjük. Az idők során megtanultam azonban azt, hogy a kommentek sok esetben nemhogy hasznosak, de kifejezetten károsak is tudnak lenni. Continue reading
Immáron két és fél éve éneklek egy budapesti kamarakórusban basszistaként. A tavalyi évben felkérést kaptunk egy másik kórustól, hogy közösen adjunk elő egy 20. századi darabot. Continue reading
A cikksorozat első része egy rövid bevezetőt tartalmazott a DDD hátteréről, és arról mit várhatunk a DDD alkalmazásától. Íme a folytatás.
Continue reading
A szoftverfejlesztési projektek terméke nem csupán maga a szoftver, hanem annak dokumentációja is. Dokumentációt általában azért kényszerülünk írni, hogy az ügyfél ez irányú kérését kielégítsük, vagy pedig azért, hogy a cégünk belső szabályozásainak eleget tegyünk.