Agilis fejlődés

Az agilis fejlesztés egy olyan szoftverfejlesztési megközelítés, amely rövid iterációkban végzi a munkát, folyamatosan beépíti a visszajelzéseket, és a terveket a megértés fejlődésével módosítja. A megközelítést a 2001-es Agilis Manifesztóban fogalmazták meg, amely négy értékpreferenciát határozott meg: az egyének és az interakciók a folyamatok és eszközök helyett, a működő szoftver az átfogó dokumentáció helyett, az ügyfél-együttműködés a szerződéses tárgyalásokkal szemben, és a változásokra való reagálás a terv követésével szemben.

A manifesztó megfogalmazását gyakran félreidézik, de ez lényeges. Minden egyes állítás két olyan dolog közötti preferenciát fejez ki, amelyek mindkettőnek értéke van, nem pedig a második elutasítását. A dokumentum kifejezetten kimondja, hogy bár a jobb oldali tételekben van érték, a bal oldali tételeket nagyobbra értékelik. Azok a megvalósítások, amelyek a manifesztót a dokumentáció, a tervezés vagy a szerződések tiltásaként értelmezik, a benne foglaltak felét elvetették, és jellemzően azt a zűrzavart okozzák, amelyet a kritikusok magának a megközelítésnek tulajdonítanak.

Az alapvető indoklás a bizonytalanságon alapul. A szekvenciális fejlesztés feltételezi, hogy a követelmények előre pontosan meghatározhatók, ami jól ismert problémák esetén igaz, de kudarcot vall azoknál a termékeknél, amelyek értéke attól függ, hogy az emberek hogyan reagálnak rájuk. Az iteratív szállítás csökkenti a tévedés költségét azáltal, hogy lerövidíti a döntés és a róla szóló bizonyítékok közötti időintervallumot, ami a probléma bizonytalanságával arányosan értékes.

A gyakorlatban a leggyakoribb kudarc az alapelvek nélküli ceremóniák bevezetése. A szervezetek napi megbeszéléseket, iterációs határokat és becslési gyakorlatokat vezetnek be, miközben megtartják a fix hatókört, a fix határidőket, az éves tervezést, és nem rendelkeznek mechanizmussal a visszajelzésekre való reagálásra. Az eredmény egy szekvenciális fejlesztés, amelyet kéthetes szegmensekben végeznek, további megbeszélésekkel, ami lassabb, mint bármelyik megfelelően végrehajtott megközelítés, és széles körű szkepticizmust eredményez a módszertannal kapcsolatban.

Az ügyfél-együttműködési elem az, amit a szervezetek a legnehezebben találnak meg, és amit a leggyakrabban kihagynak. A visszajelzésekhez való alkalmazkodás tényleges visszajelzést igényel, ami azt jelenti, hogy valódi felhasználóknak kell rendszeresen kapcsolatba lépniük a működő szoftverekkel. A proxy alapján működő csapatok – legyen az belső érdekelt fél vagy írásos specifikáció – rendelkeznek az iterációs ritmussal anélkül, hogy a célt adó bemeneti információ birtokában lennének, és magabiztosan iterálnak egy olyan irányba, amelyet senki sem validált.

A skálázás valódi nehézségeket vet fel, amelyeket az eredeti megfogalmazás nem kezelt, mivel a manifesztumot kis, közösen elhelyezkedő csapatok szem előtt tartásával írták. Több csapat koordinálása egyetlen terméken összehangolási, függőségkezelési és architekturális koherenciát biztosító mechanizmusokat igényel, és a különböző skálázási keretrendszereket, amelyek ezt kezelik, gyakran kritizálják azért, mert újra bevezetik azt a folyamatsúlyt, amelyet a megközelítés csökkenteni hivatott. A feszültség valós, nem pedig a megértés kudarca.

Az értékelésnek az eredményekre kell összpontosítania, nem pedig a betartásra. A lényeges kérdések a következők: lerövidült-e az ötlettől a validált tanulásig eltelt idő, képes-e a csapat irányt váltani, amikor a bizonyítékok indokolják, fenntartható-e a minőség, vagy nem a határidő alatt csökken, és mérhetően jobb-e a termék a felhasználók számára. Azok a csapatok, amelyek minden előírt gyakorlatot végrehajtanak, miközben évente egy fix specifikáció szerint szállítanak, átvették a szókincset, de az előnyökből semmit sem húztak.

Mivel a megközelítés a szervezeti feltételektől és a csapatmunka gyakorlatától is függ, az adaptáció gyakran olyan változtatásokat igényel az irányításban, a finanszírozásban és a tervezésben, amelyek kívül esnek a megvalósító csapaton. A gyakorlatban ezt a csapaton belül kezelik. termékfejlesztés maga a szállítási folyamat mellett, a visszacsatolási ciklus támogatásával felhasználói kutatás, és a képességet belsőleg építő szervezetek általában egy termékosztály ahol a tervezés és a megvalósítással kapcsolatos elszámoltathatóság együtt jár.