Ez az írás a napjainkban egyre nagyobb teret hódító Agilis szoftverfejlesztési technikák áttekintése. Az Agilis Fejlesztés egy gyűjtőnév, ami alá több konkrét módszertan is tartozik, ezek egy része szoftverfejlesztési módszertan, más része menedzsment-módszertan, és szinte mindegyiknek része egyfajta hozzáállás is.
Nem célom az, hogy miután ezt bárki elolvassa, zsupsz, fejest ugorhasson bele, és holnaptól már használhassa a neki szimpatikus technikákat, már csak azért sem, mert a hozzáállás nem változik meg egyik napról a másikra. A cél az, hogy egyáltalán az esély meglegyen arra, hogy bárkinek megtetsszen ez vagy az a technika. Aztán ha megtetszett, akkor utána lehet utánanézni alaposabban.
Valamennyire törekedtem arra, hogy a legagilisebb, legrugalmasabb technikáktól haladjak a hagyományosabb, vízesés-szerűbb módszertanok felé.

Scrum menedzsment

A Scrum menedzsment jellemzői

• Kell egy prioritás szerint rendezett lista az élő, felgyülemlett feladatokról.
• Ebből a listából kell egy nagyon szigorúan meghatározott részlistát megcsinálni egy rövid nekifutással, amit sprintnek nevezünk.
• Kell egy rövid megbeszélés mindennap, amit scrumnak nevezünk, ahol kiderül, hogy mi lett készen, mi lesz készen a közeljövőben, és mik a problémák.
• Kell egy rövidke tervezési összeröff, ahol az aktuális sprintre vonatkozó feladatokat kell kitalálni.
• Kell egy szívdobbanásnyi visszatekintés, amikor a csapattagok visszatekintenek a hátuk mögött lévő sprintre.

A scrum-oknál van egy Scrum-Mester, akinek az a fő dolga, hogy elhárítsa a csapat útjában lévő akadályokat, amik meggátolják, hogy a tehetségüket használják. A Scrum Mester nem a csapat főnöke, lévén a csapat jobbára önszerveződő, de pufferként funkcionál a csapat között és a destabilizáló hatású befolyások között.

A Scrum azzal segíti elő a csapatok önszerveződését, hogy bátorítja a kommunikációt a csapat tagjai között, meg egyáltalán mindenki között, aki csak a projektben van.

A Scrum egyik fő alapelve, hogy alapvetően gyakorlati jellegű kihívásokat nem lehet pusztán tekintély-alapon megoldani. Ezért a Scrum elfogadja, hogy a problémát nem mindig lehet teljesen megérteni, vagy meghatározni, ehelyett inkább a csapat teljesítményét kell maximumig fokozni, hogy aztán a csapat agilisen és rátermetten oldja meg ezeket a problémákat.

A Scrumnak nincs 'receptje' a sikeres projekt menedzsmentre, mert nem előre meghatározott előírásokban látja a projekt sikerét. A Scrum inkább egyfajta hozzáállás.

Egyszerűsített Scrum

Sok szervezet van, amelyik igencsak ellenáll a lentről jövő módszertani kezdeményezéseknek. A Scrum azonban könnyen bevezethető 'fű alatt' is. Ehhez három alapvető dologra van szükség:

• Ütemezz be egy demót az ügyféllel, mostantól számított 1 hónap múlva.
• A csapat készítse fel a szoftvert a demóra - írja meg, amit kell, semmi screenshot.
• A demónál kérd ki az ügyfél véleményét, aztán ugorj a lista elejére, és a csapat eme vélemény alapján készítse fel a szoftvert a demóra.

Ezzel az eljárással, ami egyszerű józan ész, a Scrum módszerének a lényege meg van valósítva, és lehet rá építeni.

Alkalmazkodó projektmenedzsment

Manapság nem túl gyakori, hogy egy szolgáltató megmondja a projekt jellemzőit és követelményeit elsőre. Sokkal gyakoribb az inkrementális szállítás, vagy az, hogy az ügyfél nem veszi át az eredményt. Viszont senki sem akarhatja megkövezni az ügyfelet azért, mert nincs tisztában azzal, hogy pontosan mire van szüksége. Lehet, hogy az ügyfél nem is végfelhasználó. Az ilyesfajta sokszereplős helyzetekben gyakran csak agilis módszerekkel lehet sikerre vinni egy projektet, mert hiába határozta meg az ügyfél hajszálpontosan, hogy mi kell neki, ha a végfelhasználó közbeszól, és mindent megváltoztat.
Itt egy pár tipp a Scrum-ból:

• Az ügyfélnek valami formában részévé kell válnia a fejlesztőcsapatnak.
• Gyakori közbülső kiadások KÖTELEZŐEK.
• A fejlesztőcsapatnak kell kockázattervet készítenie, minél gyakrabban.
• Napi szintű megbeszéléseket kell tartani a helyzetről.
  • Mit csináltál meg tegnapról?
  • Mit tervezel holnapra?
  • Van-e bármi probléma?
• Az egyes modulok tervének és a modulok összefüggésének MUSZÁJ átláthatónak lenni.
• Ha valamelyik feature-rel baj van, nem szabad a programot kiadni.
• Gyakran kellenek olyan találkozók, amikre MINDEN résztvevő eljön.
• Semmilyen problémát nem szabad a szőnyeg alá söpörni. Senkit nem szabad megbüntetni egy probléma miatt.
• Energikus munkahely, és hasznosan töltött munkaórák ELENGEDHETETLENEK. A 'túlóra' nem szükségképpen jelent 'túlmunkát' is.

A napi találkozók ütemezése

A legjobb pillanat a napi találkozókra ebéd után van. A reggeli találkozó nem jó ötlet, különösen olyan cégeknél nem, amelyek flexibilisen dolgoznak. Általában ezek a találkozók nem tartanak sokáig, úgyhogy lehet csinálni 'állófogadást' is, amikor mindenki feláll, és odasétál egy táblához, aztán ott beszélgetnek egy kicsit. Az ebédszünet alatt az emberek általában úgyis megbeszélik az élet nagy dolgait, úgyhogy az ebéd utáni beszélgetéseket könnyebb a munkára koncentrálni, és az emberek is jobban oda tudnak figyelni. Ráadásul miután mindenki mögött fél nap munka áll már, ezért az eszük is jobban rááll addigra a feladatra.

KristályTiszta elvek

Kristály: emberközpontú, kommunikációban erős, kicsiket szállít, ön-adaptálódó.

Az alábbi központi elemekből áll:

• Kezdd azzal, hogy jól megnézed magadnak a projekt tagjait, a kulturális hátterüket, faggasd ki őket négyszemközt.
• Használd valamelyik agilis módszertant, hogy eldöntsd, mit kell tenni, és mit kell elkerülni.
• Szedd szét a projektet elkülönülő, független részekre (partíciókra).
• Határozd meg a lehető legkevesebb szabályt, ami nélkül abszolút nem haladna a projekt előre.
• Határozd meg, mi az elképzelhető minimum, amivel elő kell állni a projekt végén.
• 1-4 hónapig tartó lépésekben haladj előre.
• Minden lépés közepén és végén tarts visszapillantás-jellegű találkozókat, határozd meg, hogy mi működik, és mi nem. Készíts egy 3 oszlopos táblázatot, az oszlopok fejléce legyen rendre Elkezdeni, Abbahagyni, Folytatni legyen. Így finomítsd az eljárást.

Ehhez igazából 3 dologra lesz előre szükséged, amiket némi utánajárással a netről, vagy könyvekből lehet összeszedni:

• Alapvető technikák a projekt-interjúkhoz.
• Alapvető technikák az eredmények meghatározásához
• Alapvető technikák a visszapillantó-találkozókhoz.

Egy képzeletbeli párbeszéd, ami segít megvilágítani, hogy miről szól a KristályTiszta gondolkodásmód (és egyben arra is rávilágít, hogy 'siker-recept' ennek a módszernek sem része - a ford.):

• Én: Az ön-alkalmazkodás része a Kristálynak.
• Jómagam: Igen, de egy másik, alapvetőbb elvből következik: 'Azok tudják legjobban, hogy hogyan kell dolgozni, akik a munkát ténylegesen végzik.'
• Én: Igen, de ebből következik: 'Ha a munkát végzők megkapják azt a munkát, hogy határozzák meg, hogy a legjobb dolgozni, akkor ezt a munkát is ők fogják tudni legjobban elvégezni.'
• Jómagam: Igen, de ennek előfeltétele, hogy az legyen a céljuk, hogy a munka el legyen végezve.

Ugyanakkor az is igaz, hogy az ön-alkalmazkodás nem csak alulról jöhet, egy rátermett menedzser is megtalálhatja a módját annak, hogy a munkavégzés módja alkalmazkodjon a körülményekhez. Az is megtörténhet, hogy bár az embereknek nem az a célja, hogy a munka el legyen végezve, de rá vannak kényszerítve, és viszont akkor már jobban megéri a lehető leghatékonyabban dolgozni. Olyan is van, hogy ők ugyan szeretnék, ha a munka el lenne végezve, de nem áll rendelkezésükre minden, ami a munka leghatékonyabb kialakításához kell - jogkör, információ, tapasztalat, vagy erőforrás is hiányozhat ehhez. A Kristály lényege tehát egyfajta decentralizált ön-alkalmazkodás, egy közös cél érdekében.

Dinamikus Rendszerfejlesztési Modell (DSDM)

(Úgy látom, ez a DSDM inkább üzleti, sőt talán kifejezetten ERP-jellegű bevezetésekről szól, tehát úgy tessék olvasni, hogy nem általános szoftverprojektről van szó. Ezzel együtt ez a legidétlenebb leírás mind között, próbáltam a faszságot kibogozni, de nem mindig volt lehetséges. Viszont az tuti, hogy az ERP projektek jó részének az a baja, hogy a tökéletes megoldást keresve kicsúsznak minden elképzelhető határidőből és költségvetésből. - a ford.)

A DSDM alapelvei

• A DSDM fő célja, hogy olyan rendszert szállítson le, amelyik a jelenlegi üzleti igényeket elégíti ki. A cél nem egy tökéletes üzleti rendszer leszállítása, amely minden elképzelhető igényt kielégít, hanem a projekt létfontosságú céljainak elérése.
• Egyetlen rendszert sem lehet elsőre tökéletesre megírni. A rendszerfejlesztés során a funkcionalitás 80 százalékát meg lehet írni a tökéletes rendszer kifejlesztéséhez szükséges idő 20 százalékában. Az a 20 százalék, ami a működő és a tökéletes rendszer között van, gyakran okozza a projektek kicsúszását a határidőből és a költségvetésből. A DSDM célja éppen ezért annak a 80 százaléknak az előállítása.
• A projektnek a határidőn és a költségvetésen belül kell végződnie, jó minőségű termék előállításával.
• A rendszerrel szemben támasztott követelményeknek tartalmaznia kell valamelyes rugalmasságot, a fenti elvekből következően.
• A DSDM-ben minden lépésnek addig kell eljutnia, hogy a következő lépést lehetővé tegye, egy centivel se tovább. Így a következő lépéssel a lehető legkevesebbet kell várni, és a rendszer minden lépésben fejlődni fog.
• A kommunikáció a projekt összes résztvevője között elengedhetetlen követelmény a projekt sikeréhez.
• Az ügyfél bevonása nélkül ebből kifolyólag lehetetlen sikeres projektet csinálni.
• A csapatnak felhatalmazást kell kapnia olyan döntések meghozására, amik fontosak lehetnek a haladás érdekében.
• A DSDM tartalmaz projekt menedzsment technikákat, és szoftverfejlesztési technikákat is.
• A DSDM használható létező rendszerek továbbfejlesztésére is, sőt nem IT-vel kapcsolatos, hanem inkább üzleti változás-jellegű projektekben is.

A DSDM használatának előfeltételei

A DSDM sikeres alkalmazásához szükség van egy-két dologra. Először is arra, hogy a csapat tagjai között, a leendő végfelhasználók között, és a felsővezetés között interaktív, kétirányú kapcsolat legyen. Ez azért kell, hogy elkerülhetők legyenek azok az ismert hibák, amik a felsővezetés motivációjának hiányából erednek, ésvagy a felhasználó közreműködésének hiányából. Másodszor is, a projektnek felbonthatónak kell lennie, vagyis lennie kell értelmes dekompozíciónak. A DSDM iteratív, inkrementális technikái csak elkülönülő részekre működnek igazán jól. Azt is meg lehet tenni, hogy a nagy projekt szétesik sok kis alprojektre, amelyek egymástól függetlenül használnak DSDM-et, vagy valami mást, és a nagy projektet kezeljük DSDM-mel. Harmadszor, a követelményeket egyértelműen meg kell határozni, és prioritás szerint sorba kell rendezni.
Ha egy projekt ennek a három dolognak nem felel meg, akkor kevésbé célszerű DSDM-et alkalmazni. Például túlságosan bonyolult projekteket, amik nem esnek szét független részekre, nem lehet iteratívan fejleszteni. Hasonlóképpen, olyan projektek, amelyeknek nincsenek egyértelműen meghatározott céljai, következésképpen nem is lehet ezeket prioritás szerint sorbarendezni, jó eséllyel fognak minden létező határidőből és költségvetésből kicsúszni, és ezen a DSDM sem tud segíteni.
Ezenfelül vannak olyan projektek, amelyeknek mindennél fontosabb célja a biztonságos működés, vagyis olyan alkalmazás készítése, ami minden körülmények között rendelkezésre áll. Ezek tipikusan emberéletekkel kapcsolatos alkalmazások. Az ilyen projektekben az égvilágon mindent le kell tesztelni, és a legkisebb hibát is addig kell csiszolni, amíg el nem tűnik, ez pedig ellentmond annak, hogy a DSDM célja nem a tökéletes szoftver elkészítése, hanem egy elfogadhatóan jó szoftver készítése határidőn és költségvetésen belül. Ugyanebből az okból nem alkalmas a DSDM újrahasznosítható komponensek és hasonlók készítésére sem, ahol az 'elég jó' nem elég jó, hanem csak a tökéletes felel meg, hiszen nem lehet előre tudni, hogy milyen alkalmazás mit fog elvárni a komponenstől.

A DSDM fázisai

A DSDM három fázisból áll, a pre-projekt fázisból, a projekt-fázisból, és a poszt-projekt fázisból. A projekt-fázis a legbonyolultabb, ennek 5 állomása van, amelyek iteratívan, lépésről-lépésre közelítik meg a projekt célját.

A pre-projekt fázis

A pre-projekt fázisban először is meg kell határozni a lehetséges projekt-jelölteket, meg kell szerezni a támogatást a projekthez, és ki kell alakítani a projekt iránti elkötelezettséget minden résztvevőben. Azzal, hogy ezeket a dolgokat az elején elintézzük, sok fejfájástól kíméljük meg magunkat a későbbiekben.

A projekt életciklusa

Ez az ábra mutatja a projekt állomásait a második fázisban. Az első két állomás egymás után következik, és egymást egészítik ki. Miután ezeket elhagyjuk, megkezdődik a rendszer iteratív és inkrementális fejlesztése, a Funkcionális modell, Tervezés és építés iteráció, és Megvalósítás állomásokon keresztül.

Első állomás: a Megvalósíthatósági Tanulmány (Feasibility Study

Ezen az állomáson azt kell megvizsgálni, hogy a projekt megvalósítható-e DSDM segítségével. A már említett előfeltételek meglétét kell megvizsgálni, olyan kérdéseken keresztül, mint például 'Ez a projekt alkalmas-e az üzleti igény kielégítésére?', 'Mik a legkomolyabb kockázatok és a legfontosabb célok?'. A legcélszerűbb erre a workshop-ok, műhelytalálkozók szervezése. A végeredmény pedig a Megvalósíthatósági Tanulmány és a Megvalósítható Prototípus, amelyek alátámasztják a projekt megvalósíthatóságát. Ezt ki lehet bővíteni még egy globális Körvonalas Tervvel, ami a projekt hátralévő részét írja le körvonalakban, és egy Veszélynaplóval, amelyik a legfőbb kockázatokat tartalmazza.

Második állomás: az Üzleti Terv (Business Study)

Az üzleti terv a Megvalósíthatósági Tanulmány kiterjesztése. Miután kiderült, hogy a projektet meg lehet valósítani DSDM segítségével, meg kell vizsgálni, hogy milyen üzleti eljárásokra van szükség, kik a felhasználói csoportok, és milyen igényeik és kívánságaik vannak. Itt is a műhelytalálkozók a leghasznosabbak, ahol a különböző résztvevők összeülnek, és megbeszélik a rendszert. Ezekből az ülésekből áll össze a végső igénylista, amelynek fontos jellemzője, hogy az igények prioritással együtt kerülnek rá. Az igények prioritására a 'Mükéné' rendszert javasoljuk. (Eredetileg MoSCoW - a ford.) Ez négy csoportba sorolja az igényeket: Muszáj; Kéne, ha lehet; Nem ártana, ha belefér; Nem kerül be, de majd később esetleg. Ezekre a prioritásokra alapozva készül el a fejlesztési terv, ami iránymutatóként szolgál a projekt teljes időtartama alatt. A terv kialakításának fontos része az időkeretek megállapítása. A DSDM sikere jórészt itt dől el, hiszen a végső cél az, hogy az időkereteken és a költségvetésen belül maradva sikerüljön elég jól megközelíteni a célt, a helyes időkeretek meghatározása tehát nagyon fontos. Lehet készíteni architektúra-tervet is, ami szintén iránymutatóként szolgálhat a fejlesztés során.
A kimenet pedig annak az üzleti területnek a meghatározása, amelyet a projekt le akar fedni, megy egy rendszerterv és fejlesztési terv, amelyek együtt határozzák meg a fejlesztés legfontosabb lépéseit és állomásait. Ezen két dokumentum alapja pedig a prioritásos követelménylista, amely a Mükéné-elv alapján van sorbarendezve. A Veszélynaplót is frissíteni kell, mert jó eséllyel változnak a projektre leselkedő veszélyek is.

Harmadik állomás: Funkcionális Modell Iteráció (Functional Model Iteration)

Az igényeket, amelyeket az előző lépésben összegyűjtöttünk, most funkcionális modellé alakítjuk. Ez a modell egy működő prototípusból, és modellekből áll. (Esküszöm, ez van odaírva, pedig tényleg hülyeség - a ford.) A prototípus-készítés fontos része ennek a lépésnek, mert ettől függ a felhasználók bevonása a projektbe. A kifejlesztett prototípusokat meg kell néznie minden érintett felhasználói csoportnak. A minőség biztosításának érdekében a DSDM minden iterációs ciklusában szükség van tesztelésre. A funkcionális modell négy további lépésre bontható:

• A funkcionális prototípus meghatározása: Meg kell határozni, hogy milyen funkcionalitása legyen a prototípusnak, ami majd az iteráció végén létrejön.
• Ütemterv: ki kell egyezni, hogy mikor és hogyan fogjuk kifejleszteni a prototípust.
• A funkcionális prototípus létrehozása.
• A prototípus átnézése: ellenőrizni kell a kifejlesztett prototípust. Ez történhet a végfelhasználók által, ésvagy a dokumentáció átnézésével.

Az eredménye mindennek egy Funkcionális Prototípus, meg egy Funkcionális Modell, amelyek együtt képviselik azt a funkcionalitást, amit ebben az iterációban ki lehetett fejleszteni, és készen állnak a felhasználói tesztre. Aztán frissíteni kell a Követelménylistát, ki kell törölni, ami elkészült, és a maradék igények prioritását újra kell gondolni.

Negyedik állomás: Tervezés és építés iterációi (Design and Build iteration)

A lényege ennek az állomásnak, hogy a komponenseket, amik az előző fázisban létrejöttek, integrálni lehessen egy rendszerbe, amelyik a felhasználóknak megfelel. Itt kell gondolni a nem funkcionális jellegű követelményekre, amelyeket a rendszerrel szemben támasztunk. A tesztelés ennek az állomásnak is nélkülözhetetlen része. Ez az állomás is négy lépésre bontható:

• A tervezési prototípus meghatározása: Meg kell határozni azokat a funkcionális és nem funkcionális követelményeket, amelyeket a tesztrendszerrel szemben támasztunk.
• Ütemterv: ki kell egyezni, hogy mikor és hogyan történik a tesztrendszer megvalósítása.
• Tervezési prototípus elkészítése: Olyan rendszert kell készíteni, amelyet bátran oda lehet adni a végfelhasználóknak napi használatra.
• A tervezési prototípus átnézése: le kell ellenőrizni a kész rendszer helyességét. A tesztelés és az átnézés a legfontosabb.

A végeredmény egy Tervezési Prototípus lesz, amelyet a végfelhasználók tesztelhetnek, és Tesztelt Rendszer címszóval mehet tovább a következő állomásra.

Ötödik állomás: Bevezetés (Implementation)

A bevezetés során a tesztelt rendszert a dokumentációval együtt átadjuk a végfelhasználóknak, és betanítjuk a további végfelhasználókat. A kész rendszert átnézzük, hogy megfelel-e azoknak a követelményeknek, amiket a projekt elején állapítottunk meg. Ezt az állomást is négy lépésre lehet bontani:

• Felhasználói jóváhagyás és útmutatás: A végfelhasználók jóváhagyják a rendszert, és közösen létrehozunk egy útmutatást, hogy hogyan kell használni a rendszert, mit tud, és mire való.
• Felhasználók betanítása: a majdani végfelhasználókkal meg kell ismertetni a rendszert.
• Bevezetés: A tesztelt rendszert feltelepítjük a végfelhasználó telephelyén.
• Az üzleti terület átnézése: megnézzük a bevezetett rendszer hatását az elején meghatározott üzleti területre. Ennek végeredményétől függően a projekt vagy átkerül a poszt-projekt fázisba, vagy egy korábbi állomásra kerül vissza, további fejlesztés céljából.

A végeredmény egy Bevezetett Rendszer a végfelhasználók munkahelyén, és részletes felhasználói dokumentáció a rendszerről.

Harmadik fázis: poszt-projekt

A poszt-projekt fázis célja, hogy biztosítsa a rendszer hatékony működését. Ez karbantartással, javításokkal és bővítésekkel érhető el, a DSDM elveknek megfelelően. Akár új projekteket is lehet indítani a létező rendszer kibővítésére, vagy új rendszerkomponens kifejlesztésére.

Tesztelésen Alapuló Fejlesztés

Ezt már lefordítottam egyszer, tessék elolvasni itt.

Funkcionalitáson Alapuló Fejlesztés

Sajnos nem találtam ide bevezetőt, úgyhogy megpróbálok én összehozni valamit. A dolog lényege, hogy a projektet szakterületekre osztjuk, és minden szakterületnek van egy vagy több szakértője, és egy Vezető Programozója, aki maga is fejlesztő. Ezenfelül van egy architektúra-csapat, akiknek van egy Vezető Tervezője. Elsősorban ez is üzleti jellegű alkalmazásokra van, és egészen egyértelműen csak objektum-orientált rendszerekre működik. Nagy csapatokra van kitalálva, és nagy projektekre.
Ezek után jöhetnek az egyes lépések, amelyekből 5 darab van.

Első lépés: Átfogó terv készítése

Ehhez az egész projekt-csapat kell, és a Vezető Tervező vezényli ezt a lépést.
Magas szinten végig kell menni az egész rendszeren, és a kontextusán is. Ezután az egyes szakterületeken kell végigmenni, úgy, hogy a csapat kisebb csoportokra oszlik. Az egyes csoportokban lennie kell az adott szakterület szakértőiből, fejlesztőkből, és tervezőkből is. Minden csapat készít egy tervet a maga szakterületéről, amelyben a szakterületet Részterületekre osztják, és megmutatja a többieknek. Valamelyik tervet, illetve leginkább a tervek ötvözetét a teljes csapat elfogadja, és onnantól az a szakterületre vonatkozó terv. A végén ezeket a terveket egybe kell kovácsolni egy átfogó tervvé, ami maga a projektterv. Ez a projektterv még iteratívan változni fog a negyedik lépésben. Lévén objektum-orientált az egész, a projektterv gyakorlatilag egy Objektummodell, amely felsorolja az osztályokat és az ő összefüggéseiket.

Második lépés: Követelménylista készítése

Ezt egy olyan csapatnak kell véghezvinnie, ami rendszerint a Vezető Progrmaozókból áll, de nem mindig. Az adott szakterületet Részterületekre bontják, azon belül Üzleti Tevékenységeket állapítanak meg, amelyek Lépésekből állnak. Minden lépés egy követelmény. Ezáltal a Követelménylista legfelsőbb szintje a szakterület, alatta a részterület, azalatt az üzleti tevékenység, és legvégül a lépések. Minden üzleti tevékenységhez tartozik egy kulcsfontosságú osztály, amelyik felelős az adott tevékenység végigviteléért. Ezenfelül további osztályok tartoznak hozzá, amelyek a lépések során játszanak szerepet.
Az egyes követelményeknek 'szemcséseknek' kell lenniük, tehát önmagukban érthető egészeket kell képezniük. Egy követelményt megvalósítani legfeljebb két hétig tarthat, de nem szabad olyan részletesnek lennie, hogy konkrét pszeudokódot tartalmazzon. Ha egy követelményt nem lehet két hét alatt megcsinálni, akkor tovább kell bontani.
A követelményeket a továbbiakban funkcionalitásnak tekintjük.

Harmadik lépés: Funkcionalitás szerinti tervezés

A projekt menedzser, a fejlesztési vezető, és a vezető programozók megtervezik azt a sorrendet, amely szerint meg kell valósítani a funkcionalitást. A sorrend alapját a funkcionalitások közötti függőségek, a fejlesztőcsapat terhelhetősége, és a funkcionalitások bonyolultsága képezi. A lényeg nem az, hogy egy szigorú sorrendet határozzanak meg, hanem hogy együttesen vegyék figyelembe a követelményeket, tehát fokozatosan finomítsák a listát, és aztán megnézzék az egyes változások hatását a többi elemre. Tipikusan ez úgy megy, hogy megnézik a fejlesztés sorrendjét, aztán megnézik, hogy hogyan vannak az üzleti tevékenységek kiosztva a vezető programozóknak, és melyik kulcsfontosságú osztály melyik fejlesztőnek van kiosztva (ugye a vezető programozó is fejlesztő). Ha sikerült az egyensúlyt megtalálni, és a fejlesztés sorrendje megvan, és minden üzleti tevékenység valamelyik vezető programozóhoz van rendelve, akkor kell az osztályokat is kiosztani (kivéve a kulcsfontosságú osztályokat, mert azok már ki vannak eddigre osztva).

Negyedik lépés: Tervezés Funkcionalitás Szerint

Ezt minden funkcionalitásra meg kell csinálni.
Először meg kell tervezni a következő időszakban megvalósítandó funkcionalitásokat. Aztán hozzá kell ezeket rendelni a vonatkozó Vezető Programozóhoz. A Vezető Programozó kiválaszt ezek közül valahányat, lehet, hogy éppen úgy, hogy azonos osztályokat (tehát ugyanazt a fejlesztőt) igényelnek. A gyakorlatban szinte sose csak egy funkcionalitással foglalkozik egy Vezető Programozó. Ezeket a kiválasztott funkcionalitásokat nevezzük a Vezető Programozó Munkacsomagjának.
Ezután a Vezető Programozó egy Funkcionalitási Csapatot hoz létre úgy, hogy meghatározza, hogy előreláthatóan mely osztályok tulajdonosainak kell majd közreműködnie az ő Munkacsomagjának elkészültéhez. A csapat pedig megtervezi a kijelölt funkcionalitások működését. A Vezető Programozó a terv alapján finomítja az Objektummodellt.
Ezután a fejlesztők megírják az osztályok és metódusok előzetesét. A végén Tervellenőrzést tartanak.

Ötödik lépés: Funkcionalitás szerinti építés

Ezt minden funkcionalitásra meg kell csinálni.
A tervekből kiindulva, a fejlesztők elkészítik az osztályaikat, és azokat a dolgokat, amik az osztályaik működéséhez kellenek. Ezután jónnek a kódra vonatkozó részegység-tesztek, és a kódvizsgálatok, a Vezető Programozó által kijelölt sorrendben. Ha mindkettő megvolt, a kód bekerül a projekt kimenetébe.