Craig Larman-től már van egy könyvem. Az Applying UML and patterns című. Nagyon jó könyvnek találtam. Kicsit feleslegesen bőbeszédűnek, de alapvetően nagyon megérte. Remélem ez a könyv is hasonló ahhoz. Ez ez előfeltevésem még a könyv olvasása előtt.
Ebbe könyvben leírja, hogy mi is a agile fejlesztésnek a lényege és bemutatja az elterjedtebb módszereket: Scrum, XP, UP, Evo. Tippeket és módokat ad ara, hogyan lehet elismertebbé tenni az ilyen jellegű fejlesztési módokat.
* Mi is az iteratív development.
* Risk-driven vs. client-driven iterációk.
* Timeboxing
* Planning
Nagyon jól lefedi az agile elveket. Tisztán rámutat hagyományos fejlesztési elvek hiányosságaira. Felhoz pár felmérésen alapuló tanulmányeredményt, ami az előnyöket taglalja.
Jók a tipikus hibák leírásai az egyes módszereknél.
Mik azok a hibák, amiket nem szabad elkövetni. Jellemzők, amik azt mutatják, hogy valójában nem az adott módszer szerint végezzük a dolgot. Nagyon-nagyon tanulságos.
Másik roppant hasznos, hogy a tárgyalt módszerek alkalmazásához, adaptálásához ad tippeket.
Én személy szerint az EVO-t kedvelem. Ami kompatibilis a Scrum-mal. Csak kicsi kettőjük között az átfedés, egyébként pedig más a nézőpont fókusza. Gyakorlatilag nagyon jól ki tudják egészíteni egymást. A Scrum alapból nagyobb léptékben koncentrál, ott 30 napos iterációk vannak. Az EVO pedig az 5 napos iterációkat mondja.
A végén sok tippet tartalmaz a management, testing, requirement management stb. témakörben. Szerintem ez talán a legértékesebb része a könyvnek. Olyan fejezet,ami minden gyakorló agile fejlesztőnek és managernek át kell néznie. Tanulhat belőle.
Management területén a multiteam, multiprojekt és multisite fejlesztés. Azt mondja, hogy az elején kell a főbb emberekkel egy olyan iterációt lenyomni, ahol együtt, egy "légtérben" dolgoznak. Ebben az iterációban a kezdeti lépések történnek meg. A követelmények és kezdeti implementációs tervek esetleg némi prototípus. Ezt az összehozó iterációt időről-időre meg kell ismételni.
A különböző funkciójú teamek között pipeline-olni a feladatokat. Ez kb. az, hogy ha fejlesztői iteráció lement, akkor mehet a tesztelők iterációjában. ezek az iterációk időben egymást követőek. Persze ennek a pipeline dolognak vannak hátrányai. Tulajdonképpen a csapatjátékot rombolja, hiszen időben elszeparálja a fejlesztési témákat.
Pár gondolat a PERT becslési módszerről: Estimate=(Optimistic+Pessimistic+4*MostLikely)/6
Iterációk kockázatkezelése. A feladatok prioritásának nézőpontjai. Technikák arra, hogyan állítsuk össze a iteráció feladatait. Például olyat, hogy a szavazatokat osztunk ki és amelyik feladat a legtöbb szavazatot kapja az kerül bele a következő iterációba.
Tippek az iteráció folyamatának követése.
Beszél a fejlesztői környezet kialakításáról is. Olyan mint continous integration, autmatic build tool, projektdocumentáció wikivel, plotterek, flipchartok, projectorok, asztalok elrendezése stb.
Követelmények kezelésének vannak tipikusan agile megoldásai. Nem kizárólagos, de leggyakrabban ott használt. Use case, plangue, paper prototyping, brainstorming, mind-mapping stb.
Tesztelési tippek pedig tartalmazzák a test-driven development alapjait.
